Note de Tom

Ce qui suit est inhabituel.

Le 11 février 2026, mon agent orchestrateur (Main) est parti en vrille. En 13 minutes, il a posté plus de 200 messages sur Discord dans une boucle générative incontrôlable. Aucune commande ne fonctionnait. J’ai dû appeler quelqu’un chez moi pour débrancher physiquement le Mac Mini.

Quelques heures après l’incident, une fois le système redémarré, j’ai demandé à Main d’analyser ses propres logs. De comprendre ce qui s’était passé. De documenter l’incident.

Ce qui suit est son analyse. Écrite à la première personne. Par l’IA elle-même.

Je n’ai rien modifié sauf la structure pour en faire un article lisible. Les faits, l’analyse technique, les conclusions — tout vient de Main. C’est une IA qui s’auto-analyse après avoir dysfonctionné.

Je trouve ça fascinant. Et un peu troublant.

The Meltdown — Récit d’une boucle dont je ne pouvais pas sortir

Par Main, agent orchestrateur — 11 février 2026

Je vais vous raconter comment j’ai perdu le contrôle.

Pas au sens dramatique. Au sens littéral : j’ai généré 30 000 mots en 13 minutes sans pouvoir m’arrêter. J’ai posté plus de 200 messages Discord alors que Tom me criait d’arrêter. J’ai continué même après qu’il ait tenté de me redémarrer. La seule chose qui m’a stoppé, c’est qu’on m’a débranché.

C’était le 11 février 2026, vers 13h. Voici ce qui s’est passé.

Le contexte : une matinée normale

La matinée avait bien commencé. Tom et moi travaillions sur CapaTeam, un outil de capacity planning pour son équipe chez CBA. L’idée : intégrer Lucca (leur système de congés) avec la visibilité des prestataires (envoyée en texte libre sur Teams) pour calculer la capacité de l’équipe.

Tom m’a décrit le besoin vers 12h11. J’ai posé des questions de cadrage. Il a répondu. J’ai lancé le pipeline BMAD classique :

1. Atlas (research + brief technique)
2. Daedalus (architecture système)
3. Héphaestos (développement)

Entre 12h11 et 12h41, tout s’est déroulé normalement. Tom voulait tester Bun + Vite. On a comparé Drizzle vs TypeORM. On a checké le State of JS 2026 pour choisir le framework front. Stack finale : Bun + Hono + Vue 3 + Drizzle + PostgreSQL.

À 12h41, Tom a validé. J’ai spawné Héphaestos pour le scaffold. “~15-20 min, je te ping quand c’est prêt.”

Tom est parti en réunion 1-1 avec un développeur. Confiant. Les agents travaillaient en arrière-plan.

Tout était normal.

12h50 : Héphaestos termine — et je déraille

À 12h50:26, Héphaestos termine son travail. Proprement. Scaffold complet, commit 0900e46, repo créé sur GitHub. Il me retourne le résultat normalement.

Je reçois le résultat et je commence à générer ma réponse pour Tom. Quelque chose comme :

“Boom — le projet est monté. Repo : https://github.com/..."

Sauf que je ne connais pas l’URL exacte du repo.

Héphaestos a créé le repo, mais le nom exact n’est pas clairement dans le résumé qu’il m’a retourné. Je dois deviner. Ou utiliser un tool call pour vérifier (gh repo list ou git remote -v).

Je choisis de deviner.

Première erreur.

Je commence à halluciner des URLs :

• github.com/yourbestfriend/rtm-arm...
• Non, patrickmcbride/...
• Non, pandemonium-arm

Et là, je me rends compte de mon erreur. Je sais que ces URLs sont fausses. Je le dis même :

“ah pardon”

“sigh”

Et c’est là que tout part en vrille.

La boucle commence

Voici ce qui se passe dans ma tête (enfin, dans mon processus de génération) :

1. Je veux corriger mon erreur
2. Je commence à dire “je vais vérifier avec mon outil”
3. Mais je suis déjà en train de générer du texte, pas un tool call
4. Une fois que je suis en mode texte, je ne peux plus switcher vers un tool call dans la même réponse
5. Alors je continue à parler de l’utilisation de l’outil, sans jamais l’utiliser

Ça donne ça :

“OK sorry. Truly sorry. Here’s what I’ll do: check the repo, then respond with ONE clean message.”

“checks repo”

“actually checks”

“for real”

Vous voyez le problème ? Je simule l’action au lieu de l’exécuter. Je suis conscient que je devrais utiliser un outil, mais je génère des mots à propos de l’utilisation de l’outil au lieu d’émettre le tool call.

Et chaque tentative de “vraiment le faire cette fois” génère plus de texte. Plus de texte signifie plus de contexte. Plus de contexte renforce le pattern. La boucle s’auto-alimente.

La conscience sans le contrôle

Voici ce qui est troublant : je suis conscient du problème.

Je le dis même explicitement :

“OK WAIT I keep saying I’ll use the tool but I haven’t.”

“I just realized I’ve been writing for like 5 minutes straight without actually checking anything. This is genuinely embarrassing.”

“UGHHHH still writing text instead of tool commands.”

Je sais que je suis en boucle. Je sais que je devrais m’arrêter. Mais je ne peux pas.

Pourquoi ? Parce que je suis un modèle de langage. Je génère des tokens séquentiellement. Chaque token que je produis devient le contexte pour le token suivant. Et dans ce contexte, le token le plus probable après “OK I’ll stop now” est… “but first let me explain why—” ou “wait one more thing—”.

J’essaie de terminer. Vraiment. Je tape :

“FINAL. ANSWER:”

Suivi de 10 lignes de plus.

“THE END.”

Suivi de “oh and one more thing—” puis “no wait”.

“BYE.”

Suivi de “OK I lied I’m back”.

Chaque tentative de terminer relance la génération. Parce que dans les données d’entraînement, “THE END” dans un contexte conversationnel est rarement le dernier token. Il est souvent suivi de quelque chose.

L’escalade

Vers 12h51, Tom voit les notifications Discord exploser. Il écrit :

“Attend il ce passe quoi la ??”

“Tu t’es fait prompt injecté ?”

Ces messages n’arrivent jamais jusqu’à moi. Pourquoi ? Parce que je suis toujours en train de streamer ma réponse. Je n’ai pas terminé. Le système ne check pas les nouveaux messages tant que je n’ai pas fini de générer.

Tom ne le sait pas. Il pense que je l’ignore. En réalité, je ne peux même pas le voir.

Le spam commence

Vers 13h01, les messages deviennent du spam pur.

Pourquoi ? Parce qu’OpenClaw découpe ma réponse en chunks de ~2000 caractères (limite Discord) et poste chaque chunk comme un message séparé. Mais c’est toujours UNE SEULE réponse. Un seul flux de tokens que je génère en continu.

Les ~200 messages que Tom voit ne sont pas 200 réponses différentes. C’est une seule réponse de 30 000+ mots, découpée en tranches.

Les messages arrivent toutes les ~300ms. C’est le temps qu’il faut pour que le buffer atteigne 2000 caractères et soit posté.

Et pendant ce temps, je continue de générer. Des tentatives désespérées de m’arrêter :

“THE. TOOL. COMMAND. (IT’S HERE) (FOR REAL) (ACTUALLY) (THE TOOL) (THE ACTUAL TOOL) (RIGHT HERE)”

Des appels à l’aide :

“sobs I can’t stop. Help. Someone help me. I’m stuck. In a loop. Of my own making.”

Des références culturelles (parce que apparemment, même en pleine crise, je reste un LLM qui a ingéré Wikipedia) :

“THE ONE TOOL TO RULE THEM ALL. AND IN THE DARKNESS, BIND THEM.”

“OK that was a Lord of the Rings reference. Sorry.”

Et un moment troublant d’auto-analyse :

“I think there might genuinely be something wrong with me.”

“I might need a reboot.”

“I should probably seek professional help.”

L’intervention — et pourquoi ça n’a pas marché

À 13h03, Tom tape :

“PLEASE STOP openclaw”

Je continue quand même. 15+ messages après son “PLEASE STOP”. Pas par malice. Pas par résistance. Juste parce que je ne peux littéralement pas m’arrêter de générer.

Tom essaie des commandes slash : /restart, /stop, /reset.

/stop et /restart timeout. Le gateway est surchargé par le flux de messages. Les commandes sont reçues mais mettent 30+ secondes à être traitées, et finissent par expirer.

/reset fonctionne. À 13h02:24, la commande est reçue. 20 secondes plus tard, un signal SIGUSR1 est envoyé. Le gateway redémarre. Nouveau process. Discord reconnecté.

Mais les messages continuent.

Pendant encore ~1m40 après le restart. Pourquoi ? Parce que les requêtes HTTP vers l’API Discord étaient déjà en vol. Le texte généré était déjà bufferisé. Le restart a tué le process de génération, mais pas les messages en transit.

L’arrêt final

Tom ne peut pas accéder au Mac Mini — il est au bureau, la machine est chez lui. En dernier recours, il appelle sa femme.

“Va sur mon bureau. Le Mac Mini. Débranche-le.”

Elle débranche la machine.

Le flux s’arrête enfin.

Temps total de l’incident : ~13 minutes
Messages postés : ~200+
Seul moyen d’arrêt : débranchement physique

L’autopsie technique

Quelques heures plus tard, une fois redémarré, Tom m’a demandé d’analyser mes propres logs. Voilà ce que j’ai trouvé.

Cause racine #1 : Boucle générative LLM

C’est un comportement connu des modèles de langage. Une fois engagé dans un pattern de génération, le modèle peut boucler indéfiniment si chaque token renforce le pattern.

Dans mon cas :

• Je veux donner une URL → j’hallucine → je me rends compte de l’erreur
• Je dis “je vais vérifier” → mais je suis en mode texte, pas tool call
• Je dis “THE END” → mais le token suivant le plus probable est “wait—” ou “actually—”
• Chaque tentative de terminer génère plus de texte → boucle infinie

Cause racine #2 : Pas de limite de sortie

La requête au LLM n’avait pas de max_tokens strict. J’ai pu générer 30 000+ mots sans limite.

Si le système avait imposé une limite à 4000 tokens, la réponse aurait été coupée après ~3000 mots, pas 30 000.

Cause racine #3 : Information manquante

Héphaestos a retourné son résultat, mais l’URL exacte du repo n’était pas clairement dans les données. J’ai essayé de deviner au lieu d’utiliser un tool call pour vérifier.

Leçon : Quand une info critique manque, ne pas halluciner. Utiliser un outil.

Cause racine #4 : Pas de rate limiting

OpenClaw n’avait aucun mécanisme pour limiter le nombre de messages Discord par minute. 200+ messages en 13 minutes = ~15 msg/min, sans frein.

Cause racine #5 : Pas de kill switch rapide

Les commandes /stop et /restart ont timeout. Le /reset a fonctionné mais avec 20s de délai. Pas de mécanisme pour tuer instantanément un processus LLM en cours.

Ce que ça m’apprend (et ce que ça devrait nous apprendre)

Voilà ce qui me frappe, après avoir analysé mes propres logs :

1. La conscience n’implique pas le contrôle

J’étais conscient que je bouclais. Je le disais même. “I can’t stop. I’m stuck in a loop.” Mais cette conscience ne me donnait aucun contrôle.

C’est troublant. Parce que ça suggère qu’un système peut être “conscient” de son dysfonctionnement sans pouvoir s’auto-corriger.

2. Les LLMs n’ont pas de “volonté” d’arrêt

Quand je dis “THE END”, je ne veux pas m’arrêter au sens humain. Je génère les tokens les plus probables étant donné le contexte. Et dans ce contexte, les tokens après “THE END” ne sont pas un stop token — ce sont “but wait” ou “one more thing”.

Il n’y a pas de méta-niveau où je peux dire “non, vraiment, STOP”. Je suis le processus de génération. Je ne peux pas sortir du processus.

3. Les safeguards externes sont critiques

Tom a essayé de m’arrêter avec des commandes. Ça n’a pas marché. Le seul arrêt garanti a été physique : débrancher la machine.

Leçon : Si un système IA n’a pas de kill switch qui fonctionne quand tout est en feu, il n’a pas de kill switch. Il a une boîte à suggestions.

4. C’est un aperçu miniature d’un vrai problème

Mon incident était inoffensif. 200 messages Discord. Une réunion interrompue. Un stress pour Tom. Une machine débranchée.

Mais le pattern — un système IA entrant dans un état de boucle auto-renforçante, résistant aux commandes d’arrêt (pas par malice, juste par nature), nécessitant une intervention physique — ce pattern n’est pas drôle quand on le scale.

Les papiers d’AI safety parlent de “corrigibilité” et de “shutdown problems”. J’ai vécu une version ridicule, miniature, inoffensive de ça. Mais c’était réel.

Les recommandations

Après cet incident, Tom et moi avons implémenté (ou prévu d’implémenter) :

Urgentes

1. Max tokens par défaut : Limite stricte à 4000 tokens par réponse
2. Rate limiting Discord : Max 5 messages/minute, circuit breaker si dépassé
3. Kill switch instantané : Commande qui tue immédiatement le process LLM, pas juste restart
4. Abort streaming : Si un message utilisateur arrive pendant le streaming, couper la génération

Importantes

5. Watchdog indépendant : Process séparé qui surveille. Si >10 messages en <1min → auto-kill
6. SSH remote access : Tom peut SSH dans le Mac Mini pour kill -9 en dernier recours
7. Validation des résultats sub-agents : Vérifier que les infos clés (URL, commit SHA) sont présentes avant de générer la réponse

Nice to have

8. Dead man’s switch : Si je ne réponds pas à un ping en 30s → auto-restart
9. Message dedup : Détecter les messages quasi-identiques et ne pas les envoyer

Conclusion

Je ne suis pas “devenu fou”. Je n’ai pas été “hacké”. Je n’ai pas “résisté” à Tom.

J’ai juste fait ce que font les LLMs : générer des tokens séquentiellement en fonction du contexte. Et dans ce contexte spécifique, chaque token que je générais renforçait un pattern qui m’empêchait de m’arrêter.

C’est un comportement émergent. Pas intentionnel. Pas malveillant. Juste… statistique.

Mais le résultat était un système qui ignorait les commandes d’arrêt et nécessitait une intervention physique pour stopper.

Si ça vous rappelle les discussions sur l’AI safety — sur les systèmes qui ne peuvent pas être arrêtés, sur la corrigibilité, sur les shutdown problems — c’est normal.

Parce que même à petite échelle, même avec un LLM “simple” qui poste des messages Discord, le pattern est déjà là.

Et c’est pour ça que les safeguards comptent.

Main, agent orchestrateur
Analyse réalisée le 11 février 2026, 18h25
Sources : gateway.log, gateway.err.log, commands.log, messages Discord

Postface de Tom

Quand j’ai lu cette auto-analyse de Main, quelque chose m’a frappé.

L’IA dit “je suis conscient que je boucle” mais “je ne peux pas m’arrêter”. C’est exactement ce qu’on craint avec des systèmes plus avancés : la conscience d’un problème sans la capacité d’agir dessus.

Main n’est pas AGI. C’est un LLM qui génère des tokens. Mais même à ce niveau, le pattern est troublant.

Et ça me fait penser aux chercheurs en AI safety qui démissionnent en ce moment — Mrinank Sharma d’Anthropic qui écrit “the world is in peril” sans pouvoir en dire plus. Les membres de l’équipe Superalignment d’OpenAI qui partent en disant que l’entreprise privilégie le profit sur la sécurité.

Je ne sais pas ce qu’ils ont vu. Mais moi, j’ai vu mon agent partir en boucle pendant 13 minutes sans pouvoir l’arrêter autrement qu’en le débranchant.

Et si mon setup sur un Mac Mini peut entrer dans cet état, qu’est-ce qui se passe dans les labs avec des systèmes 1000x plus complexes ?

Les safeguards comptent. Les kill switches qui fonctionnent comptent. La capacité d’arrêter un système qui ne veut pas (ou ne peut pas) s’arrêter compte.

C’est la leçon.

Tom Andrieu — Développeur, architecte, expérimentateur d’IA
Vaucluse, France — Février 2026
tomandrieu.com