Auto-héberger Octop avec Docker Compose sur un VPS

Ce qu’est Octop et pourquoi l’auto-héberger

Octop est un assistant IA auto-hébergé pour un foyer ou une petite équipe. L’intérêt de l’auto-héberger plutôt que d’utiliser une simple interface de chat est qu’il sépare les utilisateurs. Open WebUI fournit une interface web devant un modèle. Octop ajoute des comptes avec un rôle d’administrateur, un espace de travail privé et un jeu d’identifiants pour chaque utilisateur, ainsi qu’une bibliothèque d’agents spécialisés entre lesquels chaque utilisateur peut basculer selon la tâche. C’est cette séparation qui permet à un seul VPS de servir cinq personnes au lieu d’une seule.

Le projet se trouve sur github.com/TencentCloud/Octop. Il s’agit d’un processus unique qui fournit un tableau de bord web, une interface en ligne de commande, des canaux de discussion (Feishu, DingTalk, QQ, Discord, WeCom) et des tâches planifiées. Tous ces éléments utilisent une seule base de données SQLite sous ~/.octop/. Tout ce qui suit concerne le tag v0.9.19, publié le 5 August 2026. Si vous hésitez encore entre plusieurs plateformes, la comparaison des alternatives à Open WebUI exécutables sur un VPS couvre un éventail plus large.

Un point doit être clair avant d’y consacrer une soirée. Octop est un logiciel antérieur à la version 1.0, publié depuis l’organisation GitHub d’un éditeur, avec environ 900 stars en August 2026. Le projet évolue rapidement, comme le montrent les numéros de version, et rien ne garantit ici un chemin de mise à niveau stable. Épinglez un tag, lisez le changelog et conservez des sauvegardes.

Ce qu’il vous faut avant de commencer

• Un VPS sous Ubuntu 24.04 avec Docker Engine et le plugin Compose. Vous débutez avec Compose ? Commencez par les bases de Docker Compose pour un VPS.
• git, car vous allez extraire un tag de release au lieu de télécharger une image.
• Un nom de domaine pointant vers le VPS, car vous voulez placer TLS (transport layer security) devant ce service.
• Un backend de modèle compatible avec l’API OpenAI : une instance Ollama locale, une gateway auto-hébergée ou une clé payante.

Octop est léger. Il se compose d’un processus Python et d’un fichier SQLite. Le poids vient du backend de modèle. Si vous prévoyez d’exécuter le modèle sur le même serveur, dimensionnez le serveur en conséquence.

Pourquoi nous ne recommandons pas l’installateur curl

Le README commence par une commande d’installation sur une seule ligne :

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

Nous ne la recommandons pas sur un serveur important, pour une raison précise : ce script ne se trouve pas dans le dépôt. Il est servi depuis un bucket Tencent Cloud Object Storage. Il n’est couvert ni par un tag git ni par un commit. Vous ne pouvez donc pas comparer le script d’aujourd’hui avec celui de la semaine dernière, et aucun historique n’explique les changements. Le bucket peut servir un contenu différent demain, sans qu’aucun élément du projet ne l’enregistre. Envoyer directement le résultat vers bash signifie également que la machine exécute le script avant que vous ayez pu en lire une seule ligne.

L’installateur écrit également directement sur l’hôte, et non dans un conteneur. Il utilise uv pour récupérer Python 3.12 et créer un environnement dont votre gestionnaire de paquets ne connaît pas l’existence. Sa suppression ultérieure doit donc être effectuée manuellement.

Deux options sont préférables. Récupérez le script, lisez-le, puis exécutez-le. Cela vous prend trente secondes : curl -fsSL <url> -o install.sh, puis less install.sh, puis bash install.sh. Vous pouvez aussi utiliser Docker, ce qui constitue la suite de ce guide. Le paquet PyPI (pip install octop) est au moins un artefact versionné que vous pouvez associer à une release.

Déployer Octop avec Docker Compose, en le verrouillant sur v0.9.19

Aucune image publiée n’est disponible en août 2026. Le fichier Compose fourni construit l’image depuis le dépôt. Verrouiller une version consiste donc à se positionner sur un tag git.

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

Voici le service défini par le fichier, réduit aux éléments importants :

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

Notez le bloc build:. image: octop:latest est le nom attribué à votre propre build, et non une référence de registre. latest désigne donc ici la dernière version que vous avez compilée. Définissez explicitement le chemin des données au lieu de laisser la valeur par défaut, puis attribuez un vrai mot de passe au compte administrateur avant le premier démarrage. Placez ceci dans docker/.env :

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

Un piège mérite plus d’attention que le reste du fichier. Compose lit docker/.env uniquement pour interpoler les variables ${...} dans le fichier YAML. Une clé ajoutée à ce fichier n’est pas transmise au conteneur, sauf si elle est également déclarée sous environment: dans le fichier Compose. Ajouter OCTOP_ACCESS_TOKEN_TTL à .env uniquement ne produit absolument aucun effet, sans message d’erreur. L’autre possibilité consiste à écrire les mêmes clés dans ~/.octop/env, dans le répertoire de données monté. Octop charge ce fichier au démarrage. Le guide sur les fichiers d’environnement et les secrets dans Docker Compose explique pourquoi ces deux mécanismes ne sont pas équivalents.

Construisez l’image et démarrez-la :

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

Une instance opérationnelle répond au health check avec {"status":"ok","version":"..."}. Dans tout autre cas, consultez docker compose -f docker/docker-compose.yml logs -f octop avant d’utiliser le navigateur.

Donnez maintenant un nom explicite à l’image que vous venez de construire, car le prochain --build écrasera octop:latest et vous ne pourrez plus distinguer les deux :

docker image tag octop:latest octop:0.9.19

Au premier démarrage, octop init est exécuté et les identifiants initiaux sont écrits dans le volume de données :

docker exec -it octop cat /data/.octop/credential.txt

Les valeurs par défaut sont admin / octop et elles ne sont appliquées que lors de la première initialisation. C’est ce qui explique une question fréquente : modifier OCTOP_DEFAULT_PASSWORD après le premier démarrage du conteneur ne change rien, car le compte existe déjà. Modifiez plutôt le mot de passe dans le dashboard.

Ne publiez pas le port 8088

La ligne ports: ci-dessus se lie à toutes les interfaces du VPS. Dès que le conteneur démarre, le dashboard est accessible depuis Internet en clair, avec un mot de passe par défaut. La valeur par défaut de OCTOP_BIND_HOST dans Octop est 127.0.0.1 ; le fichier Compose la remplace par 0.0.0.0, car le processus doit accepter le trafic provenant de l’extérieur de son propre espace de noms réseau. Cette modification est correcte. C’est la publication du port qui vous expose.

Modifiez la ligne ports: dans docker/docker-compose.yml afin que le mapping écoute uniquement sur la loopback :

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

N’essayez pas de corriger cela avec un simple fichier override. Compose concatène les listes ports provenant de plusieurs fichiers au lieu de les remplacer. Vous publiez donc les deux mappings, et le second ne parvient pas à se lier. Si vous voulez conserver le fichier upstream intact, utilisez le tag !override sur la séquence. C’est la méthode documentée pour remplacer une séquence au lieu de l’ajouter. L’explication de la fusion de plusieurs fichiers Compose couvre les autres règles de fusion.

La liaison à la loopback résout également un problème que vous rencontreriez sinon avec le firewall. Docker écrit les règles de publication des ports dans la table nat, avant les chaînes gérées par ufw. Par conséquent, ufw deny 8088 n’empêche pas l’accès à un port de conteneur publié. Un port lié à 127.0.0.1 n’est jamais accessible depuis l’extérieur, quel que soit le comportement de ufw. C’est pourquoi cette solution est la bonne, et non une solution de second choix.

Placez TLS devant le service avec un reverse proxy

Caddy est la solution la plus simple, car il demande lui-même le certificat via ACME (automatic certificate management environment) et relaie les WebSockets sans configuration supplémentaire :

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx demande davantage d’attention, car Octop transmet le chat via un WebSocket :

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

Chaque ligne a une fonction. Le chat utilise WS /agents/{id}/chat/ws. Sans proxy_http_version 1.1 et les deux en-têtes de mise à niveau, nginx répond à la tentative de mise à niveau avec 400 Bad Request : le tableau de bord se charge normalement, mais chaque message envoyé reste bloqué indéfiniment, sans erreur dans la page. proxy_buffering off est nécessaire, car l’endpoint de reprise human-in-the-loop renvoie text/event-stream. Les SSE (server-sent events) placés dans le buffer d’un proxy arrivent alors en un seul bloc à la fin, au lieu d’être transmis progressivement. proxy_read_timeout couvre les exécutions longues des outils, car la valeur par défaut de 60 secondes interrompt un agent au milieu de sa tâche et inscrit upstream timed out (110: Connection timed out) dans les journaux.

Comportement de l’authentification JWT derrière le proxy

Octop s’authentifie avec un bearer token, et non avec un cookie. POST /api/auth/login renvoie {access_token, role, user, ...}, puis les appels suivants transmettent Authorization: Bearer <access_token>. Pour un reverse proxy, c’est une bonne nouvelle : il n’y a ni domaine de cookie, ni attribut Secure, ni règle SameSite à configurer incorrectement. Une session qui fonctionne sur http://127.0.0.1:8088 se comporte donc de la même manière sur https://octop.example.com.

Deux conséquences sont importantes à connaître avant d’y connecter de vrais utilisateurs.

Le WebSocket transmet le token dans l’URL. L’endpoint est WS /agents/{id}/chat/ws?token=<jwt>, car le JavaScript du navigateur ne peut pas définir d’en-tête Authorization lors du handshake WebSocket. TLS protège ce token pendant son transport. En revanche, TLS ne le protège pas de vos propres journaux : nginx écrit par défaut la ligne de requête complète, chaîne de requête comprise, dans access_log. Un token valide associé à un utilisateur réel se retrouve donc dans un fichier en clair sur le serveur. Journalisez le chemin sans les arguments. $uri correspond au chemin normalisé, avec la chaîne de requête déjà supprimée. Ajoutez donc ceci au bloc http, puis référencez-le depuis le serveur :

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

Il n’existe pas de déconnexion par session. OCTOP_ACCESS_TOKEN_TTL vaut 86400 par défaut. Un token reste donc valide pendant 24 heures après la connexion. La seule méthode documentée pour en invalider un est octop admin rotate-jwt-secret. Cette commande renouvelle la clé de signature stockée dans ~/.octop/secrets/jwt_secret et invalide immédiatement tous les tokens encore valides, pour tous les utilisateurs. Lorsqu’une personne quitte l’équipe, procédez donc dans cet ordre : supprimez l’utilisateur, renouvelez le secret, puis demandez aux autres utilisateurs de se reconnecter. Si ce comportement est trop contraignant, réduisez la durée de validité. Pensez également à ajouter la variable à la liste environment: ainsi qu’à .env :

OCTOP_ACCESS_TOKEN_TTL=28800

La protection contre la brute force est intégrée : OCTOP_LOGIN_MAX_ATTEMPTS vaut 5 échecs par défaut et OCTOP_LOGIN_LOCKOUT_SECONDS vaut 900. Un utilisateur bloqué doit donc simplement attendre quinze minutes ; il ne s’agit pas d’une installation défectueuse. Octop possède son propre store utilisateurs et ne documente pas la prise en charge d’OIDC dans la version v0.9.19. Si vous avez besoin d’un véritable single sign-on, placez un proxy d’authentification devant Octop. C’est le rôle que peut jouer un serveur Authentik auto-hébergé.

Configurer Octop avec un backend de modèle

Les fournisseurs sont configurés pour chaque agent dans le dashboard, et octop provider list vous montre la configuration active. Octop fournit des presets pour les API compatibles avec OpenAI, DashScope (Qwen) et Ollama. Les identifiants sont stockés dans la table providers de votre propre base SQLite. Ce choix détermine ce que vous payez et les données qui quittent le serveur.

Un modèle local avec Ollama. Rien ne quitte le serveur, et vous payez en RAM plutôt qu’en tokens. Le point de configuration qui pose souvent problème est le suivant : un conteneur ne peut pas accéder à l’Ollama de l’hôte via 127.0.0.1:11434, car cette adresse correspond à la loopback du conteneur lui-même. Ajoutez une entrée de passerelle vers l’hôte au service :

    extra_hosts:
      - "host.docker.internal:host-gateway"

Définissez ensuite l’URL de base du fournisseur sur http://host.docker.internal:11434/v1, qui est le chemin compatible avec OpenAI d’Ollama, et saisissez une chaîne non vide dans le champ de clé API. Ollama l’ignore, mais les clients OpenAI refusent d’envoyer une clé vide. Ollama doit également écouter au-delà de la loopback pour que cela fonctionne. Cela signifie configurer OLLAMA_HOST=0.0.0.0:11434 dans son unité systemd. C’est la partie risquée : Ollama n’a pas d’authentification. Un port 11434 ouvert sur une IP publique devient donc un serveur de modèles gratuit pour le premier qui le trouve avec un scan. Autorisez uniquement la plage privée de Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, et refusez le reste. Exécuter Ollama sur un VPS explique comment dimensionner le modèle. La comparaison entre Ollama et vLLM indique également dans quels cas Ollama n’est plus le bon serveur.

Autre avertissement concernant les modèles locaux, car le problème ressemble à un bug d’Octop alors que ce n’en est pas un. Les agents fonctionnent en appelant des outils. Le prompt système, les définitions des outils et l’historique forment un prompt volumineux. Ollama utilise une fenêtre de contexte modeste par défaut. Le début du prompt, qui contient les définitions des outils, sort donc de la fenêtre. Le modèle cesse alors d’appeler les outils ou en invente qui n’existent pas. Augmentez num_ctx à 16k ou 32k et choisissez un modèle réellement performant pour les appels de fonctions.

Une gateway auto-hébergée. Placez une gateway LiteLLM auto-hébergée entre Octop et tous les autres services. Vous obtenez ainsi une seule URL de base, une clé distincte par utilisateur, des limites de dépense et un journal unique. Vous pouvez également changer le modèle en arrière-plan sans modifier la configuration d’Octop.

Une API payante. La qualité est meilleure, avec un compromis évident : le contenu des conversations quitte votre serveur et est transmis au fournisseur. Cela concerne pourtant l’essentiel de la raison pour laquelle vous avez choisi l’auto-hébergement. La clé va dans docker/.env sous la forme OPENAI_API_KEY, que le fichier Compose transmet déjà.

Quel que soit votre choix, le fichier Compose transporte également OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY et LANGFUSE_BASE_URL. Vous pouvez ainsi envoyer les traces vers votre propre instance Langfuse et voir ce que font réellement les agents au lieu de le déduire de la fenêtre de chat.

Utilisateurs, rôles et bibliothèque d’agents partagée

Le compte administrateur créé lors du premier démarrage crée et gère les autres comptes. Chaque utilisateur dispose de ses propres agents, de son espace de travail et de ses identifiants. Cette isolation repose sur le token conservé par le navigateur. En parallèle, un pool partagé de skills et de sous-agents est accessible à tous. C’est ce qui rend cette solution intéressante pour une famille : une personne crée une fois un agent de recherche efficace, et les autres n’ont pas besoin de le recréer.

Soyez prudent avec les outils. Octop propose l’approbation des outils et des garde-fous pour les commandes shell, et ces deux mécanismes sont bien réels. Toutefois, un agent qui exécute des commandes shell les exécute dans le conteneur Octop, avec votre volume de données monté. Les garde-fous limitent ce qu’un prompt imprudent peut faire. Ils ne constituent pas une limite de sandbox. Laissez donc l’approbation des outils activée pour les personnes auxquelles vous ne donneriez pas directement accès à un shell. Si vous comparez cette solution à d’autres options, le comparatif des agents IA auto-hébergés explique comment chacune gère ce point.

Mettre à niveau un projet dont les versions sortent aussi vite

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

Voici les dates des tags du dépôt, relevées au 7 August 2026. 4 versions taguées sont sorties en neuf jours, avec un intervalle minimal de 1 jour, puis v0.9.19 est arrivé 3 jours après le tag précédent. Cette cadence est un bon signe pour le projet, mais une mauvaise raison d’exécuter latest. Lisez les changements avant de les appliquer :

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

Commencez toujours par effectuer une sauvegarde, car les migrations de base de données s’exécutent au démarrage. Si une migration échoue sur un projet antérieur à la version 1.0, c’est à vous de résoudre le problème :

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

Récupérez ensuite le nouveau tag et reconstruisez avec docker compose -f docker/docker-compose.yml up -d --build. En cas de problème, récupérer l’ancien tag et reconstruire permet de restaurer le code, mais seul le tarball permet de restaurer la base de données.

Ce tarball contient octop.db, config.json, le secret de signature JWT et credential.txt. Il est donc aussi sensible que le serveur lui-même. Conservez-le avec le mode 600 et gardez une copie hors du serveur. Pour une installation plus importante, le projet fournit également docker/docker-compose.postgres.yml, qui exécute PostgreSQL avec pgvector au lieu de SQLite.

Modes de défaillance et messages affichés

Le health check ne répond jamais. curl http://127.0.0.1:8088/api/health se bloque ou refuse la connexion. Consultez docker compose -f docker/docker-compose.yml logs -f octop. Un conteneur qui s’arrête pendant la première initialisation ne peut généralement pas écrire dans le répertoire de données. Vérifiez donc le propriétaire du chemin défini dans OCTOP_DATA.

Le dashboard se charge, mais le chat se bloque. Aucune erreur ne s’affiche dans la page et aucune réponse n’arrive. Ouvrez la console du navigateur et recherchez une connexion échouée vers wss://octop.example.com/agents/.../chat/ws. Le proxy ne transmet pas la requête d’upgrade. Ajoutez les en-têtes proxy_http_version 1.1, Upgrade et Connection.

La réponse complète apparaît d’un seul coup, après plusieurs secondes. Le streaming fonctionne, mais la mise en tampon est activée. Définissez proxy_buffering off.

bind: address already in use. Un autre processus utilise déjà 8088. sudo ss -tlnp | grep 8088 permet d’identifier ce processus. Ce message apparaît aussi si vous avez ajouté une seconde entrée ports dans un fichier d’override au lieu de modifier l’entrée originale.

Le mot de passe correct est refusé. Cinq tentatives incorrectes déclenchent un verrouillage de 900 secondes. Attendez la fin du verrouillage au lieu de réinstaller.

Le nouveau mot de passe défini dans .env n’a eu aucun effet. Ces identifiants ne s’appliquent que lors de la première initialisation. Modifiez le mot de passe dans le dashboard.

L’agent répond, mais n’exécute jamais d’outil. Il s’agit presque toujours d’un problème lié au modèle local : la context window est trop petite pour les définitions des outils, ou le modèle gère mal les function calls. Augmentez num_ctx et essayez un modèle conçu pour l’utilisation d’outils.

FAQ

Octop remplace-t-il Open WebUI ?

Seulement si vous avez besoin de ses fonctionnalités supplémentaires. Open WebUI est une interface de chat devant un modèle. Elle convient bien à une personne seule ou à un foyer de confiance. Octop ajoute des comptes avec un rôle d’administrateur, des espaces de travail et des identifiants propres à chaque utilisateur, ainsi qu’une bibliothèque sélectionnable d’agents spécialisés. Plusieurs personnes peuvent ainsi partager un serveur sans partager le même historique. Si un seul compte vous suffit, Open WebUI est le choix le plus simple et le plus mature.

Pourquoi ne dois-je pas utiliser le script d’installation curl d’Octop ?

Le script est servi depuis un bucket Tencent Cloud Object Storage, et non depuis le dépôt. Il n’est donc couvert par aucun tag ni commit git. Vous ne pouvez pas comparer son comportement actuel avec celui de la semaine dernière. De plus, le transmettre à bash l’exécute avant que vous l’ayez lu. Il s’installe aussi directement sur l’hôte avec son propre environnement Python 3.12, en dehors de votre gestionnaire de paquets. Téléchargez-le et lisez-le d’abord, ou déployez Octop avec Docker Compose depuis un tag récupéré dans le dépôt.

Octop peut-il utiliser un modèle local au lieu d’une API payante ?

Oui. Octop utilise des API compatibles avec OpenAI et fournit un preset Ollama. Il suffit donc de le pointer vers http://host.docker.internal:11434/v1 après avoir ajouté extra_hosts: ["host.docker.internal:host-gateway"] au conteneur et défini OLLAMA_HOST=0.0.0.0:11434 sur l’hôte. Limitez le port 11434 à la plage d’adresses de Docker, car Ollama ne fournit aucune authentification native. Prévoyez d’augmenter la valeur de num_ctx d’Ollama à 16k ou plus. Les prompts des agents contenant des définitions d’outils dépassent sinon la fenêtre de contexte par défaut, et le modèle cesse alors d’appeler les outils.

Ai-je besoin d’un reverse proxy, ou puis-je ouvrir le port 8088 ?

Vous avez besoin du proxy. Le fichier Compose fourni avec Octop publie 8088 sur toutes les interfaces, sans TLS. Les mots de passe et les bearer tokens traverseraient donc Internet en clair. Remplacez le port publié par 127.0.0.1:8088:8088 et placez Caddy ou nginx devant, avec un certificat. Avec nginx, transmettez les en-têtes de mise à niveau WebSocket et définissez proxy_buffering off. Sinon, la page se chargera, mais le chat ne répondra jamais, sans afficher d’erreur.

Octop est-il prêt pour la production ?

Octop est en version antérieure à 1.0 et publie plusieurs releases taguées par semaine en août 2026. Considérez-le donc comme prometteur, mais pas encore stabilisé. Il peut convenir à une famille ou à une petite équipe interne si vous épinglez un tag exact, consultez l’historique des commits avant chaque mise à niveau et sauvegardez le volume de données avant chaque reconstruction. Ne l’exécutez pas sur latest et n’y stockez pas encore de données client.