Automatisation des mises à niveau d'OpenClaw avec un agent IA : un guide éprouvé sur le terrain

Les mises à niveau d'OpenClaw sont notoirement connues pour casser des choses — migrations de configuration héritée, changements silencieux de capacités, et cas limites de gestion de processus. Un développeur en a eu assez de redécouvrir les mêmes problèmes et a appris à son agent Hermes à gérer tout le processus de mise à niveau. Résultat : la récente mise à niveau 2026.7.1 → 2026.8.1 ('OpenClaw 2.0') est passée de « plusieurs heures de dépannage éprouvant » à « exécutez le playbook, rencontrez deux problèmes connus, tous deux auto-diagnostiqués en moins d'une minute chacun ».

La configuration

L'auteur gère une petite flotte : un serveur passerelle EC2 et deux Macs (un MacBook Pro et un Mac mini), chacun exécutant à la fois le CLI OpenClaw et l'application native. Tous pointent vers le même backend. Cette configuration multi-hôtes rend le « redémarrez et voyez » impraticable.

L'idée centrale : la mémoire de votre agent est le produit

Tout agent peut exécuter doctor --fix et lire la sortie. La vraie valeur vient quand il :

• Consigne ce qu'il a trouvé dans un format interrogeable.
• Met à jour ses connaissances procédurales (une compétence / un runbook) afin que la prochaine mise à niveau parte de « voici ce que nous savons ».
• Recoupe un magasin de mémoire interrogeable pour les incidents passés.

L'auteur utilise trois composants :

• Fichier de compétence : Une procédure structurée avec les pièges, construite sur ~9 mois de mises à niveau.
• Magasin de mémoire sémantique : MemPalace (github.com/mempalace/mempalace) indexe les comptes rendus d'incidents passés pour une recherche floue comme « conflit d'identité de périphérique application ».
• Fichier de contexte partagé : Lu aussi par l'agent côté OpenClaw, afin que les leçons apprises par Hermes ne restent pas cloisonnées.

Ce qui a réellement mal tourné dans 2026.8.1

Trois problèmes spécifiques, et pourquoi ils ne devraient pas vous surprendre deux fois :

1. doctor --repair n'est pas une opération en une seule fois. Sur une installation mature multi-agents, attendez-vous à le lancer plusieurs fois — chaque passage nettoie un niveau de configuration/état hérité et révèle le suivant. L'auteur a eu besoin de 11 passages sur la passerelle seule avant une sortie propre. Abandonner après le passage 2 mène à un mauvais diagnostic.
2. Les passerelles multi-agents ont besoin d'une propriété explicite. Si vous exécutez plus d'un personnage d'agent par passerelle, la nouvelle version exige de déclarer lequel « possède » les opérations au niveau du système/ambiant. Deux modes de déclaration existent — strict et simple. Le mode strict a causé une boucle de crash cryptique ; le simple est plus sûr à moins d'avoir cartographié chaque cas limite.
3. Un fichier de configuration hérité peut bloquer tout le pipeline de réparation. Un fichier JSON obsolète (exec-approvals) a silencieusement empêché toutes les autres corrections de s'appliquer jusqu'à ce qu'il soit spécifiquement résolu.

Rien de tout cela n'est spécifique à OpenClaw — c'est juste « donnez à l'agent un endroit pour écrire les choses et une habitude de le faire ». La même approche fonctionne avec Claude Code, Codex, ou tout agent avec des outils.