Outils d'annotation auto-hébergés : ce qu'il faut à chacun pour tourner et où l'héberger

Un outil d'annotation auto-hébergé attend quatre choses du serveur sur lequel il tourne : un disque qui survit aux redémarrages, une base de données que la documentation de l'outil recommande pour la production, un moyen pour les annotateurs de se connecter, et une sauvegarde que vous avez restaurée au moins une fois. Les outils open source diffèrent surtout par le nombre de services qu'ils emportent avec eux, d'un conteneur à dix-huit, et ce nombre détermine l'essentiel du travail d'hébergement que prend en charge une étude.

Auto-héberger signifie ici faire tourner l'outil d'annotation sur une machine que vous contrôlez, qu'il s'agisse d'un serveur de laboratoire, d'une allocation de cloud universitaire ou d'une VM louée, afin que les données ne passent jamais par le service de l'éditeur. L'auto-hébergement est la réponse habituelle quand un comité d'éthique, un accord d'utilisation des données ou un hôpital refuse que les données sortent. La comparaison ci-dessous couvre ce qu'exige une installation auto-hébergée de six outils open source, d'après la documentation de chaque projet en octobre 2026, puis compare les hébergeurs selon leur coût et ce qu'ils conservent après un redémarrage.

Ce qu'exige une installation auto-hébergée

Chacun des outils ci-dessous stocke trois types d'état : les items à annoter (par exemple du texte, des images, des médias), les annotations, et les comptes et projets qui les relient. Une installation auto-hébergée doit garder ces trois types d'état sur un disque qui survit à un redémarrage, les sauvegarder ailleurs et placer une connexion devant eux. Deux autres choix découlent de l'architecture de l'outil. Un outil livré avec SQLite recommande en général un serveur de base de données pour la production, et un outil livré avec une file d'attente, un cache ou un moteur de recherche a besoin que chacun d'eux tourne et soit persistant lui aussi. L'essentiel du travail d'hébergement vient de ces services supplémentaires. Chacun est un conteneur de plus à maintenir en bonne santé et un volume de plus à sauvegarder, et sa version doit rester compatible avec celle des autres à chaque mise à jour.

Six outils comparés

Le tableau résume ce que dit la documentation de chaque projet d'une installation de production auto-hébergée. « Services » compte les conteneurs du fichier Docker Compose de référence du projet.

Label Studio tourne en un seul conteneur ou en pile Compose composée de nginx, de l'application et de PostgreSQL. Il utilise SQLite par défaut, et son guide de stockage conseille d'envisager PostgreSQL au-delà de 100 000 tâches avec 5 utilisateurs simultanés ou plus. Le guide d'installation demande au moins 8 Go de RAM, en recommande 16, et recommande 50 Go de disque pour la production. La comparaison des éditions classe le SSO SAML, LDAP, le contrôle d'accès par rôles et les journaux d'activité parmi les fonctions payantes, et dans l'édition Community, chaque utilisateur voit tous les projets.

CVAT tourne avec Docker Compose ou sur Kubernetes. Son fichier Compose de référence définit 18 services, parmi lesquels PostgreSQL, Redis, kvrocks pour le cache, huit workers d'arrière-plan, Traefik, un service Open Policy Agent pour les autorisations, et une pile d'analyse ClickHouse et Grafana. CVAT documente la sauvegarde pas à pas. Son guide arrête les conteneurs, archive les volumes de la base de données, des médias et de l'analyse, et prévient qu'une restauration exige exactement la même version de CVAT. LDAP est documenté pour l'édition Community, tandis que l'authentification unique OIDC et SAML est marquée Enterprise.

doccano démarre en un seul conteneur avec SQLite, et son fichier Compose de production ajoute Celery, RabbitMQ, nginx et PostgreSQL. Son guide d'installation prévient que la mise à jour du paquet fait perdre une base SQLite. Il documente la connexion par GitHub et Okta. En octobre 2026, sa version la plus récente sur PyPI est la 1.8.4, de juillet 2023, et une 1.8.5 publiée sur GitHub en janvier 2026 a été retirée (yanked) de PyPI.

Argilla se déploie sur Hugging Face Spaces ou avec Docker Compose, où le serveur, un worker, PostgreSQL, Elasticsearch et Redis tournent ensemble. Elasticsearch 8.5 ou OpenSearch 2.4 est requis, et le guide de déploiement note que la plupart des problèmes de déploiement concernent Elasticsearch. Sur un Space gratuit sans stockage persistant, un redémarrage fait perdre les jeux de données, les espaces de travail et les utilisateurs. Sa dernière version date de mars 2025.

INCEpTION tourne comme application Java ou en conteneur, avec MariaDB comme base de production recommandée, parce que sa base HSQLDB intégrée peut être corrompue quand la machine plante. Les annotations et les textes résident dans des fichiers sous son dossier personnel, et le guide d'administration couvre entièrement la sauvegarde et la restauration au niveau du système, avec une section sur la sauvegarde qui s'ouvre sur l'avertissement selon lequel « une sauvegarde qui ne peut pas être restaurée avec succès ne vaut rien ».

Potato tourne en un seul processus, depuis pip ou depuis une seule image Docker. Le travail de chaque annotateur est stocké dans un fichier sous le répertoire de sortie, avec les données du projet dans SQLite à côté, et MySQL est une option, pas une obligation. Le processus garde en mémoire le pool d'items et la file d'attribution, il tourne donc avec un seul worker gunicorn et davantage de threads, et grandit en passant à une machine plus puissante plutôt qu'en ajoutant des serveurs. La connexion par Google, GitHub, Hugging Face ou tout fournisseur OIDC fait partie du paquet open source et se configure sous authentication.providers.

Le nombre de services de chaque outil reflète les tâches qu'il prend en charge. Les dix-huit services de CVAT comprennent des workers distincts pour l'import, l'export, le découpage en blocs et les rapports de qualité, une pile d'analyse et des autorisations fondées sur des politiques, dont une grande équipe qui fait tourner une installation sur la durée peut tirer parti. Argilla exige un moteur de recherche pour ses jeux de données. Potato s'en tient à un seul conteneur, ce qui convient à une étude qu'un laboratoire met en place, fait tourner quelques semaines puis démonte.

Les hébergeurs selon le coût et la persistance du disque

Chacun de ces outils tourne sur une VM avec Docker, et le choix principal est de savoir si le disque de l'hébergeur survit à un redémarrage. Les coûts ci-dessous sont les estimations qu'affiche Potato 2.10 pour ses cibles potato deploy dans leurs tailles par défaut, et les mêmes machines font tourner les autres outils au même prix, sous réserve des besoins en mémoire de chacun.

Jetstream2 est un cloud de recherche financé par la NSF : un chercheur américain disposant d'une allocation ACCESS ne paie rien, et chaque instance reçoit un nom DNS avec un certificat ordinaire. Le prix forfaitaire de Lightsail comprend l'adresse IPv4 et un disque de 60 Go, et il ne demande que lightsail:* plus sts:GetCallerIdentity, ce qui convient à un rôle IAM universitaire restreint. Une instance Lightsail de 2 Go suffit pour Potato, tandis que le minimum de 8 Go indiqué par Label Studio demande une offre plus grande.

Les sauvegardes sur les hébergeurs qui effacent le disque

Heroku efface le disque chaque jour, et l'offre gratuite de Render comme les Hugging Face Spaces le perdent au redémarrage. Une étude menée sur l'un de ces hébergeurs a besoin d'une sauvegarde qui se restaure aussi, sinon un annotateur qui revient trouve une tâche vide.

À partir de la version 2.10, le bloc backup de Potato copie la sortie d'annotation et des instantanés des bases de données du projet vers un jeu de données Hugging Face ou un bucket compatible S3, toutes les cinq minutes par défaut, et les restaure quand un serveur démarre avec un disque vide. La restauration ramène les comptes avec les annotations, si bien que les annotateurs se connectent avec les mêmes mots de passe et reprennent là où ils s'étaient arrêtés, et elle n'écrase jamais des annotations déjà présentes sur le disque. Ajoutez ce bloc à une configuration, avec HF_TOKEN défini dans l'environnement du serveur et l'extra hosting installé :

backup:
  schedule_minutes: 5
  restore_on_boot: true
  sinks:
    - type: huggingface
      repo_id: lab/pilot-annotations

potato deploy up ajoute la même sauvegarde avec --backup hf ou --backup s3, et refuse de déployer sur Heroku ou sur un Hugging Face Space sans sauvegarde, sauf si --demo déclare les annotations jetables. Render, Railway, Fly et ECS Express en exigent une dans tous les cas, parce que le projet atteint ces hébergeurs par le stockage de la sauvegarde. Sur les hébergeurs dont le disque persiste, la sauvegarde garde quand même une seconde copie hors du serveur, ce qui couvre une instance supprimée aussi bien qu'un redémarrage.

Quel que soit l'outil, testez la restauration avant le début de l'étude. Démarrez une nouvelle instance à partir de la sauvegarde, connectez-vous en tant qu'annotateur et vérifiez que votre dernière annotation s'y trouve. Pour Potato, potato deploy pull copie sur votre machine tout ce qu'un déploiement a recueilli, et potato deploy destroy refuse de supprimer un déploiement qui n'a jamais été récupéré : lancez donc d'abord le pull à la fin d'une étude. Exécuter Potato en local ou dans le cloud donne la commande pour chaque hébergeur.

Pour aller plus loin

• Mise en production, pour gunicorn, Docker et le proxy inverse
• Authentification SSO et OAuth, pour configurer les fournisseurs de connexion
• Comparatif des outils d'annotation, pour les fonctionnalités plutôt que l'hébergement