OpenClaw est en panne ? Je répare avec Claude Code

Mes agents OpenClaw locaux font tourner ce site, mon application de chat, et une pile de petites automatisations. Ils assurent ce travail de routine 24 h/24 pour 0 $ — jusqu’à ce que la machine sur laquelle ils tournent tombe en panne. Dans ce cas, je ne demande pas à un système en train de couler de se sauver lui-même : j’ouvre Claude Code sur la même machine et je laisse un modèle plus puissant s’en occuper.

L’idée des deux niveaux

Les modèles locaux se débrouillent bien pour beaucoup de choses : rédiger des brouillons d’articles, surveiller des services, injecter des messages de chat, exécuter des tâches planifiées. Mais ils ont un plafond — un contexte plus petit, un instinct de débogage plus faible, et une fâcheuse tendance à redémarrer des choses avec assurance alors qu’un vrai diagnostic serait nécessaire.

La règle empirique : si la correction est une procédure connue, OpenClaw l’exécute. Si la correction demande de comprendre, c’est pour Claude Code.

Un exemple réel : la passerelle en boucle de crash

Un matin, la passerelle OpenClaw était en boucle de crash, avec pour seul message :

agents.list.5: Invalid input

Aucun agent nommé dans l’erreur. Les redémarrages ne changeaient rien — la configuration était recassée aussi vite que réparée. Un modèle local l’aurait redémarrée en boucle indéfiniment.

Claude Code, exécuté sur la machine elle-même, a remonté la piste : l’étape de réconciliation d’identité d’OpenClaw relisait un fichier de workspace obsolète, resté d’un nettoyage antérieur, et réinjectait une définition d’agent invalide dans la configuration active à chaque démarrage. La correction durable comportait trois volets :

1. Corriger le fichier source obsolète (la cause réelle),
2. Restaurer une configuration de passerelle propre,
3. Vérifier en faisant tourner le cycle complet de lancement et redémarrage jusqu’à ce que chaque unité reste stable.

Voilà le schéma : l’erreur visible était dans la configuration, mais la cause était un fichier que personne n’avait regardé depuis des semaines. Du diagnostic, pas des redémarrages.

« Faire en sorte qu’OpenClaw puisse s’en charger la prochaine fois »

La seconde moitié de chaque session Claude Code, c’est la partie que la plupart des gens sautent : après la correction, je lui fais reverser ce savoir dans le système local, pour que la même catégorie de problème n’ait plus jamais besoin du modèle coûteux. Concrètement, cela donne :

• Des procédures que les agents locaux peuvent suivre. Des instructions pas à pas écrites pour un modèle plus modeste — des étapes vérifiables, des commandes exactes, des règles strictes. Ma tâche hebdomadaire de rafraîchissement du site tourne exactement à partir de ce type de fichier.
• Des garde-fous plutôt que de la vigilance. Après un incident, Claude Code a ajouté au build de ce site une vérification pré-publication à échec fermé (recherche de secrets + règles de contenu), pour qu’aucun agent — local ou cloud — ne puisse publier quelque chose d’embarrassant.
• Des chiens de garde pour les modes de défaillance connus. Des délais d’attente calibrés pour les modèles locaux lents, des minuteurs de suivi auto-suppressibles pour le travail délégué, des contrôles de santé qui notifient mon application de chat au lieu d’échouer en silence.

La prochaine fois que la même chose vacille, OpenClaw s’en occupe avec des jetons gratuits, et Claude Code n’est appelé que pour ce qui est vraiment nouveau.

Pourquoi exécuter Claude Code sur la machine OpenClaw ?

Exécuté sur la même machine, il lit les vrais journaux, la vraie configuration, les vrais états des services — et vérifie la correction de bout en bout au lieu de deviner à partir de ma description. Une description filtrée par moi, c’est exactement comme ça qu’on obtient des corrections plausibles mais fausses.

Pièges à éviter

• Ne laissez pas les agents locaux se réparer eux-mêmes en plein incident. Un agent dont la propre passerelle est cassée ne fait qu’aggraver les choses. Réparez depuis l’extérieur (Claude Code), puis rendez le contrôle.
• Exigez la correction durable. « Redémarre-le » n’est qu’un pansement sur le symptôme. Demandez explicitement la cause racine, et faites prouver à l’assistant que la correction survit à un cycle de redémarrage.
• Faites rédiger la procédure pendant que le contexte est encore frais. La meilleure documentation d’un incident est écrite par celui qui vient de le réparer, quelques minutes après l’avoir fait.
• Gardez les secrets hors de la boucle. Les procédures et briefs que lisent les agents doivent être exempts de secrets ; les clés vivent dans l’environnement, pas dans le texte.