L’infrastructure technique de Framaspace

Tout d’abord quelques mots sur Framaspace…

Il s’agit d’un nouveau projet de Framasoft (disclaimer : j’y suis employé).
Le plus simple pour le décrire est encore de piquer le chapô de l’article du Framablog qui l’explique :

Framasoft souhaite mettre à disposition, d’ici 3 ans, jusqu’à 10 000 espaces « cloud » collaboratifs, gratuitement, à destination des associations et collectifs militants. 40 Go et de nombreuses fonctionnalités à se partager entre 50 comptes sur un espace de type https://monasso.frama.space.

Ces espaces « cloud » sont des instances de Nextcloud qu’on met à disposition avec un certain nombre d’applications validées par Framasoft.
Nous n’autorisons pas d’autres applications tout simplement pour éviter d’avoir des cas particuliers de support à gérer.
Tout le monde aura donc un Nextcloud semblable aux autres, et s’il y a un souci, le résoudre pour une association le résoudra pour tout le monde.

J’ai décrit vite fait l’infrastructure technique de Framaspace dans sa FAQ, mais je profite d’avoir mon petit bout de web à moi pour prendre plus de place pour ça ici 🙂

Découpage chirurgical

Afin de pouvoir créer une infrastructure flexible que je pourrais faire évoluer au gré des besoins, il convenait d’identifier l’ensemble des services nécessaires à Nextcloud de façon à pouvoir les distribuer sur plusieurs serveurs.

Voici ce qui est nécessaire pour un serveur Nextcloud (pour l’usage de Framaspace, tout le monde n’a pas forcément besoin de tout ça)

• une base de données ;
• un serveur web ;
• du PHP ;
• du stockage de fichiers ;
• du cache mémoire (APCu, Redis ou Memcached) ;
• un serveur Imaginary pour la génération de miniatures d’images afin de décharger la charge du serveur où serait PHP ;
• un serveur office (Collabora ou OnlyOffice) ;
• un serveur de logs pour centraliser les logs de tous les services à un seul endroit.

Choix des morceaux et morceaux de choix

Une fois le découpage effectué, il fallait bien choisir quels logiciels allaient être utilisés là où il y avait le choix (en ce qui concerne Imaginary par exemple, il n’y avait pas le choix).

Attention, certains choix sont assez arbitraires (question de préférences personnelles) ou peuvent ne pas être les plus pertinents : je ne suis qu’un humain, faillible et je ne prétends pas avoir une connaissance exhaustive de tous les composants nécessaires à Nextcloud.

• pour la base de données, PostgreSQL.
  PostgreSQL, d’après mon expérience, ne souffre pas de ralentissements, ou si peu, au fur et à mesure du grossissement de ses bases de données.
  On peut objecter que MySQL/MariaDB peuvent avoir de très bonnes performances. Certes, mais au prix de quels efforts de configuration ? PostgreSQL, lui, ne demande aucune modification de configuration pour avoir de très bonnes performances (même si un peu de configuration par rapport à la machine qui l’héberge ne fait pas de mal).
• pour le serveur web, la solution choisie a été Nginx.
  Plus véloce qu’Apache la plupart du temps, et j’ai bien plus d’expérience et d’affinité avec Nginx ;
• pour PHP, PHP-FPM.
  Comme au départ, je souhaitais découpler PHP du serveur web, PHP-FPM était à ma connaissance la seule solution possible (il est capable d’écouter sur une socket réseau… et c’est la manière standard de faire du PHP avec Nginx) ;
• pour le stockage de fichiers, voulant un système extensible, il nous a fallu choisir un système de stockage S3, et ce fut MinIO.
  Nous avons déjà de l’expérience avec Ceph et… disons que le résultat est plus que mitigé. Ceph est complexe, trop complexe pour le temps que nous avons à y consacrer, et la documentation n’est pas toujours à la hauteur. J’ai aussi regardé Garage, mais je l’ai écarté pour deux raisons : MinIO me semblait plus simple d’accès (déploiement, configuration…) et la jeunesse du projet (2020 pour le 1er commit, 2016 pour MinIO, ce qui permet d’avoir plus de recul)
• pour le cache mémoire, Redis.
  Le cache mémoire, pour être le plus efficace possible, doit pouvoir être joint par tous les serveurs qui font tourner PHP, donc exit APCu et pouvoir être hautement disponible, ce qui inclut de la réplication de données au sein d’un cluster, donc exit Memcached. Restait donc Redis, qui permet aussi de faire en sorte que les serveurs PHP se partagent les sessions.
• pour la génération de miniatures, Imaginary est le seul outil déporté proposé par Nextcloud, donc bon voilà.
• pour le serveur office, nous laissons le choix aux associations.
  Nous utilisons donc des services Collabora ou OnlyOffice selon les choix des associations.
• pour le serveur de logs, le vénérable Rsyslog.
  J’ai bien essayé de mettre en place des trucs kikoolol comme une stack ELK ou équivalent comme Loki mais j’ai décidé que la complexité de ce genre de bouzin était bien trop importante pour l’intérêt que nous pouvions en tirer. Ça pourra toujours évoluer plus tard, mais en attendant, ça fera le job.
• qui dit infrastructure flexible, dit répartition de charge pour pouvoir rediriger les requêtes entrantes vers les serveurs Nginx, office, etc.
  Nginx peut faire office de répartiteur de charge, mais je préfère les logiciels spécialisés dans une tâche : ils la remplissent généralement mieux que les logiciels qui servent aussi à autre chose.
  N’ayant pas d’expérience dans ce domaine, j’ai testé et adopté le bien connu, bien documenté et réputé HAProxy.

Pour faire tourner tout ça, il faut bien évidemment un système d’exploitation.
Sans surprise, j’utilise Debian parce que c’est simple et stable.

Chaque chose à sa place et une place pour chaque chose

Le choix des outils étant fait, il fallait choisir où mettre quoi.

Le cahier des charges à ce niveau était (relativement) simple : avoir un système évolutif avec une bonne tolérance aux pannes.
Ça paraît si simple, dit comme ça 😂

Il faut aussi avoir en tête que le budget de Framasoft n’est pas extensible à l’infini : si ouvrir le service avec de la redondance dans tous les sens serait une excellente idée, il a bien fallu faire des choix de non-redondance pour certains bouts de l’infrastructure pour limiter le coût de fonctionnement.
La non-redondance totale initiale de l’infrastructure est cependant compensée par sa flexibilité et la possibilité de remonter très vite certains bouts de l’infrastructure de manière quasi-automatique (quasi car il faut quand même lancer la commande qui va bien).

Parcourons une nouvelle fois la liste des éléments nécessaires à Nextcloud.

PostgreSQL

Un serveur PostgreSQL.
C’est un bon début.
C’est simple et rapide à mettre en place.

Mais comme nous voulions un système tolérant aux pannes et que remonter une sauvegarde (voir plus bas pour la solution de sauvegarde employée) peut prendre un certain temps quand les bases de données sont bien remplies (nous avons déjà expérimenté des temps de remontage de sauvegarde de plus de 12h), autant avoir de suite un serveur secondaire, pour répliquer les données.

Deux serveurs PostgreSQL, donc.

J’ai pu me baser sur cet article pour mettre en place la réplication entre les deux serveurs sans toucher à rien, seulement avec mon logiciel de gestion de configuration.

D’autres serveurs PostgreSQL pourront être ajoutés en cas de besoin pour mieux répartir la charge.
Cette distribution de la charge ne concerne cependant que les opérations de lecture : la réplication multi-directionnelle pose des problèmes de performances non négligeables.

Nginx + PHP

Lors du maquettage de l’infrastructure, j’avais initialement découplé (c-à-d mis sur des serveurs différents) Nginx et PHP-FPM.
Cela nécessitait d’avoir les fichiers de Nextcloud sur les deux serveurs (sur le serveur Nginx pour les fichiers statiques, et sur le serveur PHP-FPM pour l’interprétation des fichiers PHP).
Ce n’était pas un problème, techniquement parlant, mais ça sentait un peu l’inutilité.

Nginx n’aurait pas beaucoup fait charger la machine si c’était juste pour servir des fichiers CSS, javascript et autres ressources (icônes, polices de caractère…).
C’est ainsi qu’il fut décidé que Nginx et PHP-FPM seraient sur la même machine.

Il n’y a pas grand-chose sur ce serveur :

• nginx
• php-fpm
• le code de nextcloud
• des fichiers de configuration gérés par le logiciel de gestion de configuration
• de quoi exécuter les tâches cron des instances nextcloud

Si ce serveur tombait, il serait très simple et rapide de remonter un autre serveur.
La redondance de celui-ci n’est donc pas nécessaire pour l’instant (la question se reposera lorsque la charge augmentera) mais elle est prévue : il n’y a que quelques manipulations à faire pour ajouter un serveur supplémentaire et l’utiliser.

Minio

Combien de serveurs ?

Pour avoir de la tolérance de panne, l’outil fourni par la société éditrice de Minio nous indique que nous avons besoin d’au minimum 4 serveurs.

Grâce à cet outil, nous avons pu constater qu’utiliser 5 serveurs nous assurait non seulement une meilleure tolérance aux pannes, mais également qu’en modifiant légèrement le nombre de disques utilisés pour les calculs de parité, nous pouvions augmenter l’espace de stockage disponible pour le prix d’un seul serveur, reculant le moment d’avoir besoin d’augmenter la taille du cluster MinIO.

En effet, il faut savoir que pour augmenter la taille d’un cluster MinIO, il faut ajouter non pas un serveur supplémentaire, mais un pool entier de serveurs.
Nous contenter de 4 serveurs n’aurait fait que rapprocher le moment où nous aurions eu besoin de rajouter 4 serveurs supplémentaires.
Il était moins douloureux financièrement de prendre tout de suite 5 serveurs.

Comment sauvegarder autant de données ?

Le problème d’un stockage qui se compte comme ici en dizaines de Tio, c’est la sauvegarde.
Impossible de sauvegarder rapidement une volumétrie aussi importante que celle que nous prévoyons.

Pour cette raison, nous avons mis en place un deuxième cluster MinIO, situé physiquement loin du premier (en Finlande, quand le premier se trouve en Allemagne) et avons activé la réplication native de MinIO entre les deux clusters.

Cette solution, s’il ne s’agit pas d’une sauvegarde stricto sensu, nous permet d’envisager sereinement une catastrophe (on a déjà vu des centres de données entiers partir en fumée) où nous perdrions entièrement le cluster MinIO primaire.
Nous pourrions alors sans effort basculer sur le cluster de réplication.

Redis

Il y a deux modes pour faire fonctionner Redis en haute disponibilité :

• Sentinel ;
• Cluster.

En mode Sentinel, les données sont répliquées du serveur primaire vers des serveurs secondaires.
En cas de défaillance du serveur primaire, un serveur secondaire va être élu nouveau serveur primaire.
Dans ce mode, le nombre minimal de serveurs est 3.

En mode Cluster, les données sont réparties au sein du cluster : contrairement au mode Sentinel, chaque serveur Redis ne contient pas l’intégralité des données mais contient une partie des données, dans ce qui est appelé des hash slots (tranche de hachage).
Les données sont cependant répliquées vers des serveurs secondaires.
Illustration avec un exemple d’un cluster de 6 serveurs :

• le serveur A va contenir des tranches de hachage de 0 à 5500 ;
• le serveur B va contenir des tranches de hachage de 5501 à 11000 ;
• le serveur C va contenir des tranches de hachage de 11001 à 16383 ;
• le serveur D va être le réplicat du serveur A ;
• le serveur E va être le réplicat du serveur B ;
• le serveur F va être le réplicat du serveur C.

Dans ce mode, le nombre minimal de serveurs est 3 serveurs primaires.
La recommandation officielle pour une mise en production est 3 serveurs primaires et 3 serveurs secondaires.

Nous avons choisi le mode Cluster avec 6 serveurs.

En effet, il nous paraissait plus intéressant de répartir la charge de travail sur plusieurs machines que de la faire reposer sur un seul serveur avec des serveurs secondaires ne servant qu’à garantir la haute disponibilité du service.

Imaginary

Ne servant qu’à la génération de miniatures d’images, Imaginary est le service le moins critique de tous.
Pour cette raison, nous n’avons qu’un seul serveur Imaginary.

Celui-ci étant derrière HAProxy, en cas de charge trop importante, nous pourrions à loisir ajouter de nouveaux serveurs Imaginary sans avoir besoin de changer la configuration des Nextcloud, qui utiliseraient toujours la même URL.

Office

Les services Collabora et OnlyOffice sont fournis par des conteneurs Docker, chacun tournant sur un port différent, avec des options (domaine pour Collabora, paramètre JWT_SECRET pour OnlyOffice) différentes.

La configuration de ces conteneurs étant gérée par Salt, il est extrêmement simple de remonter un serveur tombé, ce qui nous a conduit à n’utiliser qu’un serveur pour l’instant.

En cas de surcharge, nous pourrons ajouter un serveur supplémentaire facilement. Cependant, au contraire d’Imaginary, ce serveur ne servira pas pour de la répartition de charge d’un même domaine mais pour accueillir de nouveaux domaines de serveurs office.

Les conteneurs sont lancés avec Podman et non Docker car Podman n’intègre pas de dæmon, ce qui a le grand avantage d’éviter de voir les conteneurs s’arrêter et redémarrer lors de la mise à jour de la solution de conteneurisation.

Rsyslog

Pas de redondance prévue pour ce serveur.

En cas de besoin, le remontage du serveur sera rapide, toujours grâce à notre logiciel de gestion de configuration.

HAProxy

Là encore, nous ne prévoyons pas de redondance pour l’instant, mais nous avons toute latitude pour ajouter un serveur HAProxy supplémentaire de façon à répartir la charge au besoin.

Les logiciels supplémentaires

Pour lier toute l’infrastructure dans un ensemble fonctionnel et sécurisé, nous avons utilisé plusieurs outils :

WireGuard

L’établissement de connexions sécurisées entre les serveurs aurait consommé des ressources que nous souhaitions économiser.
L’utilisation de tunnels WireGuard entre les serveurs devant communiquer entre eux permet d’éviter cette consommation supplémentaire, les connexions du VPN étant maintenues dans le temps.

Pgpool-II

Afin de pouvoir répartir les requêtes vers les serveurs PostgreSQL selon leur type (le serveur secondaire ne supporte que la lecture, pas l’écriture) mais aussi pour répartir la charge, j’ai utilisé Pgpool-II.

J’avais regardé PgBouncer mais celui-ci ne sait pas gérer plusieurs serveurs pour une même base de données.

Sidekick

MinIO recommande l’utilisation du répartiteur de charge sidekick au plus près des clients ayant besoin de se connecter au cluster de stockage.
Ainsi j’ai installé sidekick sur la machine Nginx + PHP-FPM car c’est Nextcloud qui accède lui-même au cluster et non les clients depuis leurs navigateurs web.

L’avantage de ce rapprochement du répartiteur de charge du client est d’éviter les points de défaillance unique comme le serait la machine HAProxy si elle avait servi de point d’entrée vers le cluster de stockage comme je l’avais initialement prévu.

Salt

Salt est un logiciel de gestion de configuration.
Utilisé chez Framasoft depuis près de 10 ans, il est une pierre angulaire du projet Framaspace : outre la gestion des machines et de leurs configurations, il permet aussi la gestion des espaces collaboratifs (création, désactivation, suppression et changement de solution bureautique).

Barman

Barman est la solution de sauvegarde des bases de données PostgreSQL de Framasoft depuis maintenant plusieurs années.
Ses sauvegardes « au fil de l’eau », sa facilité de configuration et d’utilisation ainsi que sa fiabilité nous séduisent toujours, nous n’avions aucune raison d’en changer.

BorgBackup et Borgmatic

Pour la sauvegarde des fichiers, BorgBackup et son comparse borgmatic qui en facilite l’utilisation sont nos outils de sauvegarde préférés depuis longtemps.
Pourquoi changer une équipe qui gagne ?

À noter qu’ils ne sont pas utilisés pour sauvegarder les fichiers déposés par les utilisateurs des espaces collaboratifs mais pour sauvegarder les fichiers de configuration de nos différents logiciels.
Si nous pouvons aisément remonter n’importe quel serveur en peu de temps, nous pouvons toujours avoir besoin de consulter l’état d’une machine à un instant précédent (« Oups, j’ai effacé un truc essentiel par inadvertance ! »).

Gotify

Nos différents outils envoient des notifications à diverses occasions (demande d’espace, mauvais fonctionnement…).
Nous utilisons généralement le mail pour de telles notifications mais le serveur de listes (sur lequel nous recevons les mails de notifications) a subi quelques surcharges ralentissant fortement l’envoi des mails.
J’avais commencé à expérimenter Gotify et il me semblait un candidat idéal pour nous avertir rapidement des notifications urgentes, comme les échecs de création d’espaces.

Il remplit parfaitement son rôle 🙂

Les logiciels que nous avons développé

Tous nos développements sont disponibles sur la page Framagit du projet.

On y retrouve notamment :

• Charon, qui est l’interface web au projet, écrit en PHP.
  C’est sur Charon que s’effectuent les demandes d’espaces collaboratifs et leur gestion.
  Une interface d’administration nous permet d’accepter ou de rejeter les demandes, ainsi que d’effectuer des opérations sur les espaces existants.
• Hermès est un dæmon en Python qui interroge régulièrement Charon sur son API afin de connaître les tâches à exécuter : création ou suppression d’espace ou modification de serveur office.
  Hermès utilise Salt pour effectuer les tâches envoyées par Charon.
• Poséidon contient toutes nos recettes Salt (Poséidon, roi des mers, l’eau salée, Salt… vous l’avez ?)
• Chronos est un dæmon, encore une fois en Python, qui se charge d’exécuter régulièrement les tâches cron des espaces Nextcloud.
  Nous ne pouvions pas mettre des centaines de tâches cron en parallèle, c’est pourquoi Chronos fut développé.
  Il utilise pour cela une base de données PostgreSQL pour gérer la file d’attente et exécute les tâches cron en parallèle par paquets de 10 (par défaut)

Nous avons aussi des projets pour les patchs Nextcloud à déployer (nous reportons les patchs au projet Nextcloud mais nous n’attendons pas leur intégration pour en bénéficier), les fichiers de ressources (fonds d’écran, fichiers css, modèles, etc), la page d’accueil de Framaspace et enfin une recette de conteneur Docker pour Collabora (voir plus bas).

Les problèmes rencontrés

Les conteneurs office

Le plus gros souci rencontré venait de notre volonté de proposer un serveur office (Collabora ou OnlyOffice) à chaque espace collaboratif.
Si l’idée était simple, à savoir lancer un conteneur office sur un port différent pour chaque espace, cela a vite posé deux problèmes :

• la surcharge au démarrage de la machine.
  Quand on a 2 ou 3 conteneurs qui se lancent au démarrage d’une machine, ça passe, mais quand on en a 50 ou 100… ça coince vite et les conteneurs se lancent très lentement, quand ils ne plantent pas.
  Pendant ce temps, la machine est inutilisable.
• les ressources consommées.
  Un conteneur Collabora au repos utilise 500Mio de RAM et un conteneur OnlyOffice en consomme 2Gio.
  Sans rien faire.
  Impossible pour le budget de Framasoft de louer des serveurs monstres à tour de bras.
  Fort heureusement, nous avons trouvé une recette de conteneur Docker pour Collabora qui fait sauter les limitations de celui-ci et nous permet d’accueillir plus de personnes en même temps sur le même conteneur.
  J’ai créé une divergence de ce projet sur Framagit pour l’adapter au mieux à nos besoins et pour contourner un bug de la version de Podman de Debian Bullseye.
  Toutes nos modifications ont été proposées au projet d’origine mais toutes n’ayant pas été retenues, nous maintenons notre divergence.

La gestion des versions sur MinIO

Utilisant la fonction de réplication de MinIO, le versionnage était automatiquement activé sur les buckets de MinIO.
Nous pensions pouvoir tirer partie de cela en utilisant l’application Nextcloud S3 versioning, qui permet de restaurer une version précédente d’un fichier en utilisant les versions des objets dans MinIO plutôt que de laisser Nextcloud créer et gérer lui-même des versions.

Malheureusement, nous n’avions pas anticipé que lors de l’envoi d’un fichier de grande taille, Nextcloud le découpe en morceaux de 10Mio, qu’il stocke temporairement avant de reconstruire le fichier.
Avec le versionnage de MinIO, ces fichiers temporaires n’étaient pas réellement supprimés avant le délai de 30 jours que nous avions choisi comme temps maximum de conservation des versions.
Certains usagers remplissaient donc leur bucket tout en étant bien en-dessous des 40Gio d’espace alloué, simplement en téléversant des fichiers de grande taille.

Nous sommes donc revenus à une gestion native des versions par Nextcloud et à une suppression la plus rapide possible des versions de fichiers (un jour).

L’absence de transactions dans Nextcloud

Si certaines opérations de Nextcloud se font dans des transactions, certaines autres sont faites de façon atomiques, avec des écritures dans la base de données et des lectures immédiatement après.
La réplication PostgreSQL n’était au départ pas synchrone : j’imaginais naïvement que Nextcloud utilisait des transactions partout (Pgpool-II dirige les transactions vers le serveur PostgreSQL primaire), ou à tout le moins n’allait pas vérifier un enregistrement juste après l’avoir écrit.

Nous avons patché Nextcloud pour qu’il utilise au maximum des transactions, mais la taille et la dette technique de Nextcloud rendent cette tâche quasiment impossible.

En conséquence, j’ai passé la réplication de PostgreSQL en synchrone, et tant pis pour la petite perte de performance.

Les recettes Salt

Les recettes Salt que nous avons développé permettent :

• de configurer des machines pour les intégrer à l’infrastructure (on leur applique la recette correspondant à leurs rôles et on met à jour la configuration des autres serveurs qui doivent être en connexion avec elles)
• de modifier la configuration des éléments de l’infrastructure au besoin (par exemple, j’ai récemment modifié la configuration de PostgreSQL par ce moyen)
• de déployer les espaces Nextcloud (création de la base de données et du bucket S3, bootstrap de l’espace, ajout dans la configuration de Chronos)
• de changer de suite office
• de mettre à jour Nextcloud et ses applications
• de mettre à jour les espaces collaboratifs vers une nouvelle version de Nextcloud

La ferme de Nextcloud

La structure

Déployer autant de dossiers Nextcloud que d’espaces collaboratifs était exclu vu son poids (519Mio pour le dossier de base sans applications autres que celles recommandées !).

J’ai donc modifié le fichier de configuration de Nextcloud pour qu’il contienne la configuration commune à tous les espaces et qu’il inclue un fichier de configuration contenant la configuration particulière (base de données, bucket S3, etc.) correspondant au nom de domaine de la requête ou à la variable d’environnement NC_INSTANCE (pour que cela fonctionne depuis les outils en CLI).

Nginx utilise comme racine du site web un dossier au nom de l’hôte de la requête qui est un lien symbolique vers la version de Nextcloud de l’espace.

Cette manière de faire nous permet de mettre à jour les espaces de façon séquentielle et diminuer le temps d’indisponibilité de chaque espace (entre 40 et 50 secondes d’indisponibilité par espace).

Les mises à jour

Nous mettons à jour un espace dédié à cela, ce qui récupère la nouvelle base de code, que nous adaptons en réappliquant nos patchs et en modifiant le fichier de configuration comme évoqué ci-dessus.
Nous dupliquons cette base de code pour servir de base de mise à jour : elle recevra un fichier de configuration contenant toute la configuration de l’instance à mettre à jour et nous effectuons un php occ upgrade pour mettre à jour la base de données de l’instance.

Ainsi, pour chaque instance, on a :

• mise en mode maintenance
• copie d’une configuration complète dans la base de code de mise à jour
• php occ upgrade
• modification du lien symbolique du dossier utilisé par Nginx pour pointer vers la nouvelle version de Nextcloud
• sortie du mode maintenance.

Datalove

• 14 serveurs physiques (10 pour Minio, des SX64 et 4 de virtualisation, 3 AX41-NVMe et un AX41, le tout hébergé chez Hetzner)
• 13 machines virtuelles (dont 2 sur notre infrastructure normale)
• 224 Tio de stockage provisionné
• ±400 espaces déployés (sur 10 000 prévus)

Conclusion

C’est sans doute le projet le plus vaste et complexe dont j’ai eu à m’occuper.

Mais c’est aussi sans doute le projet le plus fun !
Imaginer tout ça et le mettre en place m’a apporté beaucoup d’amusement, de joie et de fierté.
La joie et la fierté de l’artisan une fois sa besogne faite, et plutôt bien faite, je trouve.

Merci à mes collègues, tout particulièrement Thomas : sans sa connaissance de Nextcloud et ses propositions de patchs, je me serais sans aucun doute arraché un grand nombre de cheveux.

EDIT (15 juin 2023) : ajout de la section « Datalove »
EDIT (20 join 2023) : spécification des machines physiques utilisées dans la section « Datalove »