# Mise à niveau

> Mettre à jour une installation vers une nouvelle version, et ce qu'il faut modifier lors du passage de la 2.1.0 à la 2.2.0.

Une mise à jour remplace les images PentAGI et, lorsque la version les a modifiés, les fichiers compose. Vos `.env` et les volumes de données restent, et les migrations de base de données s’exécutent au démarrage de PentAGI.

## [Avant de commencer](https://pentagi.com/fr/docs/deployment/upgrade/#before-you-start)

* Lisez les [notes de version](https://pentagi.com/changelog/) de chaque version postérieure à celle que vous exécutez ; depuis la 2.1.0, elles incluent des notes de mise à niveau.
* Sauvegardez la base de données. Ni l’installateur ni PentAGI ne le font, et les migrations ne peuvent pas être annulées sans perte de données. Avec les valeurs par défaut `PENTAGI_POSTGRES_USER` et `PENTAGI_POSTGRES_DB` :

  ```bash
  docker exec pgvector pg_dump -U postgres -Fc pentagidb > pentagi-backup.dump
  ```

  Conservez également des copies de `.env` et des fichiers compose : l’installateur remplace les fichiers compose sans sauvegarde.
* Terminez les [flows](https://pentagi.com/fr/docs/glossary/#flow) dont vous n’avez plus besoin. Un [sandbox](https://pentagi.com/fr/docs/glossary/#sandbox) encore en cours d’exécution est réutilisé tel qu’il a été créé, avec les paramètres de la version qui l’a créé.
* Si vous venez de la version 2.1.0, effectuez les modifications décrites dans [De 2.1.0 à 2.2.0](#from-210-to-220) sur `.env` et les fichiers adjacents avant le démarrage de la nouvelle version. Avec la connexion via Google ou GitHub activée, videz dès maintenant `OAUTH_GOOGLE_CLIENT_ID` et `OAUTH_GITHUB_CLIENT_ID` ; la section explique pourquoi.

## [Docker Compose](https://pentagi.com/fr/docs/deployment/upgrade/#docker-compose)

1. Téléchargez les fichiers compose de la nouvelle version à côté de votre `.env` : `docker-compose.yml` et le fichier de chaque pile optionnelle que vous exécutez. Le conteneur PentAGI ne reçoit que les variables listées dans son fichier compose, donc les nouveaux paramètres dans `.env` n’ont aucun effet derrière un fichier plus ancien.

   ```bash
   cd ~/pentagi
   curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose.yml
   # and the file of each optional stack you run, for example:
   curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose-langfuse.yml
   ```

2. Tirez les images et redémarrez, avec les mêmes fichiers `-f` que vous utilisez pour démarrer la pile. Sans `pull`, `up -d` conserve les images déjà présentes sur l’hôte.

   ```bash
   docker compose pull && docker compose up -d
   ```

3. Actualisez l’image du sandbox sur l’hôte Docker qui exécute les flows, ce que `docker compose pull` ne fait pas. Les flows créés ensuite l’utilisent.

   ```bash
   docker pull vxcontrol/kali-linux
   ```

Le tag d’image `latest` suit la branche principale. Pour rester sur une seule version, définissez `PENTAGI_IMAGE=vxcontrol/pentagi:<version>` dans `.env`.

## [Installateur](https://pentagi.com/fr/docs/deployment/upgrade/#installer)

1. Téléchargez l’installateur de la nouvelle version depuis [Démarrage rapide](https://pentagi.com/fr/docs/getting-started/quickstart/) et exécutez-le avec votre `.env`. L’installateur 2.1.0 ne peut pas se mettre à jour lui-même.
2. Pour remplacer les fichiers compose, modifiez un paramètre afin que **Apply Changes** apparaisse dans le menu, sélectionnez-le et répondez `y` lorsque l’installateur liste les fichiers obsolètes.
3. Dans le menu de maintenance, exécutez **Update PentAGI** pour tirer les nouvelles images, et **Update Worker Image** lorsque cela vous est proposé. **Update PentAGI** seul conserve les anciens fichiers compose.

## [De la version 2.1.0 à la version 2.2.0](https://pentagi.com/fr/docs/deployment/upgrade/#from-210-to-220)

### [Fichiers](https://pentagi.com/fr/docs/deployment/upgrade/#files)

* Le fichier compose monte `example.bedrock.provider.yml` à côté de lui. L’installateur le crée ; lors d’une installation manuelle, créez-le vous-même, un fichier vide suffit : `touch example.bedrock.provider.yml`.
* Remplacez `docker-compose-langfuse.yml` si vous exécutez Langfuse : le fichier 2.1.0 nomme l’image `minio/minio`, qui n’est plus publiée, donc `docker compose pull` échoue avec celui-ci. Si votre `.env` définit `MINIO_IMAGE=minio/minio:…`, supprimez cette ligne.
* Pour le [knowledge graph](https://pentagi.com/fr/docs/glossary/#knowledge-graph), placez `examples/neo4j` depuis le dépôt à `./neo4j` — Graphiti a besoin de son plugin APOC — et consultez [Mémoire et connaissances](https://pentagi.com/fr/docs/concepts/memory/#knowledge-graph-optional) pour les préréglages de modèle. `GRAPHITI_MODEL_NAME` n’est plus lu.
* Huit migrations de base de données s’exécutent au premier démarrage. `docker compose logs pentagi` affiche « Database schema updated successfully » lorsqu’elles sont terminées.

### [Connexion et accès](https://pentagi.com/fr/docs/deployment/upgrade/#sign-in-and-access)

* Tout le monde doit se reconnecter : les sessions de la version 2.1.0 sont refusées. Les jetons API continuent de fonctionner, et les scripts se déconnectent avec `POST /api/v1/auth/logout`.
* Un jeton API reçoit une erreur 403 sur les routes REST `/users`, `/roles` et `/tokens` : gérez les comptes, les rôles et les jetons depuis une session de navigateur connectée.
* La connexion via Google et GitHub connecte désormais une adresse e-mail vérifiée par le [provider](https://pentagi.com/fr/docs/glossary/#provider) au compte existant ayant cette adresse, y compris les comptes locaux, avec le rôle de ce compte. La version 2.1.0 ne peut pas modifier l’e-mail d’un compte, donc si la connexion est activée, effectuez la mise à niveau avec `OAUTH_GOOGLE_CLIENT_ID` et `OAUTH_GITHUB_CLIENT_ID` vides, déplacez `admin@pentagi.com` vers une adresse que vous contrôlez sous **Settings → Account**, puis réactivez la connexion. Le **Reset Admin Password** de l’installateur trouve l’administrateur uniquement par `admin@pentagi.com`.
* Derrière un proxy inverse, définissez `TRUSTED_PROXIES`, sinon tous les utilisateurs partagent l’adresse du proxy et une rafale d’échecs de connexion verrouille tout le monde pendant 15 minutes — voir [Exposition réseau](https://pentagi.com/fr/docs/configuration/security/#network-exposure).

### [Sandboxes](https://pentagi.com/fr/docs/deployment/upgrade/#sandboxes)

* Avec `DOCKER_INSIDE=true` — le template `.env` par défaut de la version 2.1.0 et de l’installateur — la version 2.1.0 montait le socket Docker de l’hôte dans chaque sandbox. La version 2.2.0 donne aux [agents](https://pentagi.com/fr/docs/glossary/#agent) l’accès à Docker uniquement depuis un daemon séparé défini dans `DOCKER_INSIDE_HOST` ; sans cela, ils n’y ont pas accès, et le journal indique `sandbox DISABLED`. Avec `DOCKER_INSIDE_HOST`, laissez `DOCKER_SOCKET=` vide, sinon le `/var/run/docker.sock` du template est toujours monté. Consultez [Worker node](https://pentagi.com/fr/docs/deployment/worker-node/).
* Terminez les flows démarrés sur la version 2.1.0 : leurs sandboxes conservent l’ancien montage de socket et les capacités jusqu’à ce que le flow soit terminé.
* Laissez `TENANT_ID` vide : sur une installation existante, il pointe PentAGI vers un nouveau schéma vide.

### [Modèles et prompts](https://pentagi.com/fr/docs/deployment/upgrade/#models-and-prompts)

* Le provider personnalisé nécessite `LLM_SERVER_KEY` : avec une clé vide, il est désactivé, donc pour un serveur sans authentification, définissez n’importe quelle valeur non vide.
* `LLM_SERVER_LEGACY_REASONING` est supprimé. Le provider personnalisé envoie `reasoning_effort` et transforme un budget `reasoning.max_tokens` en niveau d’effort ; sur les modèles Kimi K2, GLM avant la version 5.2 et MiniMax M, un budget fait désormais échouer l’appel, donc supprimez-le de ces agents.
* Dans les fichiers de configuration des providers, une entrée d’agent qui laisse `max_tokens`, `temperature`, `top_p` ou `n` vide obtient désormais les valeurs par défaut du type de provider au lieu de n’envoyer rien.
* Les modèles par défaut intégrés ont changé pour chaque provider sauf Bedrock ; les providers enregistrés dans **Settings → Providers** conservent leurs modèles. Cinq configurations incluses dans l’image ont changé de modèles — `openrouter`, `deepinfra`, `ollama-cloud`, `moonshot` et `deepseek`. Si `LLM_SERVER_CONFIG_PATH` ou `OLLAMA_SERVER_CONFIG_PATH` pointe vers l’un d’eux sous `/opt/pentagi/conf/`, conservez le fichier 2.1.0 sur l’hôte et montez-le comme configuration personnalisée ou Ollama à la place.
* Avec `EMBEDDING_URL` sur un serveur autre que celui d’OpenAI, définissez `EMBEDDING_KEY` : `OPEN_AI_KEY` n’y est plus envoyé.
* Les agents recherchent via un seul outil `web_search`. Les prompts personnalisés avec `{{.GoogleToolName}}` et les autres variables par moteur sont ignorés, avec un avertissement dans le journal, jusqu’à ce qu’ils utilisent `{{.WebSearchToolName}}` ; rebasez les prompts personnalisés du searcher et du pentester sur les nouvelles valeurs par défaut.

### [Autres changements](https://pentagi.com/fr/docs/deployment/upgrade/#other-changes)

* Dans les deux minutes suivant le démarrage, puis toutes les trois heures, PentAGI signale sa version et un résumé de l’installation à `update.pentagi.com` ; [Vérification des mises à jour](https://pentagi.com/fr/docs/configuration/security/#update-check) liste ce qu’il envoie, et `UPDATE_CHECK_INTERVAL=0` le désactive.
* Le profiler n’écoute plus sur le port 7777 sauf si `PPROF_ADDR` est défini.
* Les nouveaux paramètres optionnels incluent [la bascule de provider](https://pentagi.com/fr/docs/configuration/llm-providers/#failover) avec `LLM_FALLBACK_PROVIDER`, `DOCKER_PORTS_BASE` pour [plusieurs instances](https://pentagi.com/fr/docs/deployment/production/#several-instances-tenant_id), `DOCKER_IMAGE_SELECTION_MODE` et `DOCKER_ALLOWED_IMAGES`, le moteur de recherche interne `WEB_SEARCH_INTERNAL_ENABLED`, ainsi que les clés Mistral, xAI, MiniMax et Firecrawl.

## [Sauvegarde et retour arrière](https://pentagi.com/fr/docs/deployment/upgrade/#back-up-and-roll-back)

PentAGI n’exécute jamais les migrations en sens inverse, et les exécuter manuellement supprime des données, donc le moyen de revenir à la version 2.1.0 est la sauvegarde. Arrêtez les services qui utilisent la base de données, recréez-la et restaurez le dump :

```bash
docker compose stop pentagi pgexporter
docker exec pgvector dropdb -U postgres pentagidb
docker exec pgvector createdb -U postgres pentagidb
docker exec -i pgvector pg_restore -U postgres -d pentagidb < pentagi-backup.dump
```

Ensuite, remettez les fichiers `.env` et compose sauvegardés, définissez `PENTAGI_IMAGE=vxcontrol/pentagi:2.1.0` et démarrez la stack. Conservez le nouveau `docker-compose-langfuse.yml` : l’image MinIO du fichier 2.1.0 ne peut plus être tirée.