J'ai Laissé Claude Coder Pendant 4 Heures. Il a Créé Quelque Chose que Personne n'Avait Demandé.

10 min read

J'ouvre le terminal. 4 heures. Le tableau de bord tourne sur le serveur privé, la couche API reste publique. À peu près ce que j'avais demandé. 😬

Dans le diff aussi : 2 composants extraits et déplacés vers un fichier que personne ne lui avait demandé d'ouvrir, une mise à jour de version runtime qui modifie silencieusement le pipeline de build cloud, et un commit poussé sur main avant que le déploiement soit confirmé stable.

TLDR : En conversation, l'ambiguïté produit une question de clarification. Dans une boucle autonome, elle produit des heures de travail dans la mauvaise direction. Cet article couvre les 3 façons dont les briefs de boucle échouent et les lignes qui préviennent chacune avant que vous disparaissiez.

Rien de tout ça n'est catastrophique. La session a abouti. Mais les 3 heures de debug qui ont cramé la plupart du compute venaient d'une contrainte manquante dans mon premier message. La tâche : déplacer le tableau de bord de gestion des commandes de l'hébergement public vers un serveur privé, interne uniquement. Ce que j'ai oublié d'inclure : la couche API devait rester accessible publiquement. Les partenaires externes l'appellent. La déplacer aurait tout cassé en aval.

Claude a demandé, j'ai répondu, il s'est ajusté. Mais à ce moment-là l'architecture était déjà esquissée dans la mauvaise direction, et le conflit de build avec le gestionnaire d'intégration qui a suivi a pris 200+ appels d'outils pour se démêler. Dans le post-mortem, Claude a nommé la cause racine lui-même : "Si le premier message avait dit 'le tableau de bord devient interne mais la couche API reste publique,' j'aurais anticipé le conflit de build. Cette divergence n'était pas dans le brief."

~600k tokens. Le brief était 6 messages envoyés en 10 minutes pendant que j'avais autre chose à publier.

Employé de bureau épuisé fixant un terminal qui affiche du code sans fin pendant qu'un super-héros en cape pointe nonchalamment vers un bouton d'arrêt ; un homard robotique surfe sur le bureau.
Quand votre assistant IA décide de réécrire toute votre base de code sans qu'on le lui demande.

Pourquoi les Boucles Cassent Différemment des Prompts

Tout le monde dans la vague hype actuelle des boucles parle de /goal, sous-agents, flags max-turns, coût des tokens. Personne ne parle du brief.

En conversation, l'ambiguïté produit une question de clarification. Claude dit "vous vouliez dire X ou Y ?" et vous corrigez en 10 secondes. Dans une boucle autonome, cette même ambiguïté produit des heures de travail dans la mauvaise direction. Le modèle ne se bloque pas quand il rencontre une contrainte peu claire. Il résout l'ambiguïté lui-même et continue, ce qui est en fait la fonctionnalité, jusqu'au moment où ça devient le bug.

Un test LogRocket de Claude Code avec Ralph a rendu cela concret. Brief : "Construis un outil CLI de stats GitHub. Fais-le bien." La boucle a tourné 5 minutes 41 secondes et livré un outil fonctionnel avec récupération de profil utilisateur, analyse de répartition des langages, et vérification de limite de taux. Rien de tout ça n'était demandé. Même tâche avec une condition de sortie explicite et une barrière de scope : exécution propre, pas de dérive de scope, aligné avec les critères définis sur chaque point. La seule différence était le brief.

Une analyse récente sur Medium des mécaniques /goal a nommé ce pattern précisément. Vous donnez à Claude une longue tâche de refactoring, il exécute des dizaines d'étapes, tout s'exécute. Puis vous regardez ce qui a été construit. Techniquement correct. Juste pas ce que vous vouliez. "Ça a dérivé." La dérive ne vient pas du modèle. Elle vient du brief.

L'erreur que je continuais à faire était d'assumer que mes compétences de prompting se transféraient automatiquement aux sessions de boucle. La confiance qu'elles le font est la partie dangereuse, parce que les 2 compétences se sentent identiques de l'intérieur. C'est basiquement le "ça marche sur ma machine" de l'outillage agent : chaque session supervisée livre proprement, vous avez l'historique de commit pour le prouver, et puis vous lancez un brief de boucle avec la même confiance et vous partez.

Le prompting consiste à donner à Claude assez de contexte pour naviguer les quelques échanges suivants pendant que vous regardez, assez proche pour corriger le cap quand il va quelque part de travers. Le briefing de boucle consiste à donner à Claude assez de contraintes pour naviguer 50 ou 80 étapes sans vous présent du tout, où chaque ambiguïté est résolue par la meilleure supposition du modèle au lieu de votre vraie intention, et ces suppositions se composent à travers des dizaines d'appels d'outils en quelque chose qui peut paraître complètement correct en surface tout en étant structurellement faux pour vos besoins réels. Le flou qui est tolérable dans un prompt (le genre que vous résolvez en 1 message de suivi) est fatal dans un brief de boucle où il n'y a pas de message de suivi, et la session a déjà brûlé 400k tokens au moment où vous regardez ce qu'il a construit.

3 Modes de Dérive, 3 Lignes Qui Corrigent

TITLE "The Loop Brief Stack" + subtitle "3 components · 3 failure modes · before you hit Enter". Metaphor: engineering control panel blueprint with 3 clearly labeled switches, each with OFF and ON position. Style: engineer blueprint aesthetic, white technical lines on dark navy background, precise annotations, blueprint-style font. Palette: navy #0A1628, blueprint-white #E8F0FF, yellow #FFD600, red #FF4444, green #00C853, black #111111. Content: 3 switch panels labeled SCOPE FENCE (left), EXIT CONDITION (center), ESCALATION CRITERIA (right). OFF state shows red indicator and failure mode label (scope creep, drift, silent loop). ON state shows green indicator and fix label (locked scope, binary check, auto-escalate). Highlight: EXIT CONDITION panel center-positioned and slightly enlarged, yellow border glow. Legend: sticky note bottom-left corner "OFF = loop decides / ON = brief decides". Footer: copyright rentierdigital.xyz. NOT flat corporate vector, NOT minimalist tech startup aesthetic, NOT stock infographic.
La Stack du Brief de Boucle : Trois Composants de Contrôle Critiques

Il y a 3 façons distinctes dont les briefs de boucle échouent. Chacune correspond à un composant manquant.

Dérive de scope : barrière de scope manquante

Claude interprète les instructions qualitatives ("bien", "propre", "complet") comme une invitation à étendre. Il n'hallucine pas, il optimise. Le problème est que sa définition de "bien" inclut des décisions que vous n'avez pas autorisées.

Dans ma session : 2 composants refactorisés et relocalisés pendant la phase de debug, pas parce que c'était dans le brief, mais parce que la structure de fichier causait une erreur d'export de build et la corriger était adjacent au problème réel. Le modèle a résolu un vrai problème. Un que je ne lui avais pas demandé de regarder.

La correction est une barrière de scope : une liste explicite de ce qui ne doit pas être touché, aussi spécifique que ce qui doit l'être.

Mauvais : "Refactorise le module auth."

Bon : "Refactorise le module auth. N'ajoute pas de nouvelles fonctions. Ne modifie pas les tests. Ne touche aucun fichier en dehors de /src/auth."

La contrainte négative fait autant de travail que la positive. J'ai approfondi la construction d'une couche d'application CLI pour les agents autonomes dans un article précédent, et le pattern de vérification correspond directement au contrôle de scope de boucle.

Dérive : condition de sortie absente

L'exécution tourne proprement, 30+ étapes, pas d'erreurs. Mais quelque part vers l'étape 12 la boucle prend une bifurcation que vous n'aviez pas l'intention, et au moment où elle livre, vous avez une solution techniquement correcte au mauvais problème. Dans ma session, la bifurcation d'architecture (la couche API reste publique) a été résolue en conversation pendant les 15 premières minutes. Mais aucune condition de sortie n'encodait cette contrainte explicitement, donc il n'y avait pas de vérité terrain pour qu'un vérificateur indépendant vérifie contre.

Cause racine : pas de condition de sortie, ou une trop vague pour attraper la mauvaise bifurcation.

Le guide de boucle agentique de MindStudio le met en 1 phrase : "Écrivez la condition de succès avant d'écrire le prompt. Si vous ne pouvez pas la définir en 1 phrase, réduisez le scope de la tâche." Leur règle compagnon : toujours passer --max-turns sur les tâches autonomes comme fallback mécanique quand la condition de sortie n'est pas atteinte proprement.

Mauvais : "Quand ça a l'air bien."

Bon : "Quand tous les 47 tests existants passent, le tableau de bord répond sur le port 3013 sur le réseau interne, et aucun fichier en dehors de /src/dashboard n'a été modifié."

Évidemment, "quand ça a l'air bien" ne peut être vérifié par rien qui ne soit pas vous. Un agent tournant en parallèle n'a pas accès à votre jugement esthétique. La condition de sortie doit être binaire et vérifiable sans contexte.

Peut-être que je me trompe là-dessus, mais je pense que la condition de sortie est plus difficile à écrire que la barrière de scope. Elle vous force à vous engager sur ce que "fini" signifie réellement avant d'avoir commencé. Dans mon expérience c'est la pièce qui est sautée en premier, et celle qui coûte le plus quand elle manque.

Boucle silencieuse : pas de critères d'escalade

Barrière de scope définie, condition de sortie définie. Toujours possible de brûler votre budget silencieusement quand la boucle atteint un état qu'elle ne peut pas résoudre et continue d'essayer. Un builder sur X après 6 semaines de boucles de production : "Le pouvoir est réel mais le coût aussi quand un agent entre silencieusement dans un mauvais état de boucle... jusqu'à ce que votre facture API arrive."

Dans ma session cela s'est manifesté comme un processus zombie servant un ancien build, produisant une série de tests faux-négatifs avant que Claude rapporte correctement un bloqueur. Le zombie ne répondait pas à pkill. Énergie HAL 9000 : reconnaissance calme de chaque requête de diagnostic, résistance active à l'arrêt. Sauf que c'était un socket Unix et pas une IA homicide, ce qui l'a rendu plus difficile à corriger d'une certaine manière. Avec une règle d'escalade dans le brief, ça s'arrête et rapporte au lieu de persévérer.

Mauvais : rien. Claude gère.

Bon : "Si le tableau de bord échoue à charger après 3 tentatives de déploiement, arrête immédiatement. Rapporte la dernière erreur et les 3 derniers fichiers modifiés. N'essaie pas un 4ème déploiement."

Cette dernière ligne compte. Sans elle, Claude essaie encore, touche plus de fichiers en dehors de la barrière de scope pour le faire, et vous revenez à une base de code qui a dérivé plus loin que là où vous l'aviez laissée.

Le Test de l'Autre Pièce

Avant de lancer toute boucle autonome, 1 question : est-ce qu'un agent qui n'a jamais lu mon code pourrait vérifier que cette tâche est finie ?

Si non, la condition de sortie est trop vague.

Lance Martin du thread d'Anthropic sur le design de boucle a rendu le principe explicite : le correcteur doit être indépendant de l'exécuteur. Claude ne peut pas noter son propre travail. Le sous-agent vérificateur reçoit la condition de sortie et retourne un verdict binaire. Pas d'accès au contexte, à l'intention, ou à l'historique de conversation. Juste la condition et l'état actuel. Réussite ou échec. C'est autour de quoi /goal est construit : un correcteur séparé vérifiant si la condition de succès définie a été remplie, sans lire votre intention dedans. La condition de sortie est la seule interface entre votre intention et le vérificateur. Si elle est ambiguë, le vérificateur ne peut pas vous aider. (L'équivalent RPG : demander au guerrier d'évaluer son propre clear de donjon. Il dira toujours oui.)

Il y a une distinction qui vaut la peine d'être tirée de l'approche des contrats de prompt pour les sessions Claude Code supervisées, où un brief précis structure une session que vous regardez et pouvez diriger en temps réel. Les briefs de boucle sont pour les sessions où vous ne serez pas là pour diriger. L'habitude du contrat vient en premier. Le brief de boucle l'étend aux sessions autonomes avec une contrainte différente : pas de direction autorisée.

Détour bref qui n'a rien à voir avec tout ça : j'ai fait tourner le même prompt de post-mortem avec des collaborateurs humains pendant quelques mois maintenant, leur demandant "quoi dans mon brief, si différent, aurait changé votre exécution ?" Les réponses sont constamment plus utiles que toute rétro que j'ai menée. Les gens ne rapportent pas naturellement l'échec de passation. Ils décrivent ce qu'ils ont construit. Les faire nommer la contrainte manquante produit quelque chose proche d'un vrai audit.

Brief d'Abord, Boucle Ensuite

Le coût de la session : ~600k tokens, une mise à jour de version runtime qui a changé l'environnement de build cloud sans ma revue, 2 composants déplacés dans une base de code que je ne prévoyais pas d'ouvrir, un commit sur main avant que le déploiement soit stable, et 3 heures de debug d'une contrainte que j'avais laissée hors du premier message. Rien de tout ça n'est un échec de modèle. Tout était prévisible depuis le brief. La boucle a bien tourné. Le brief non, et cet écart est ce qui a brûlé les 3 heures.

Les 3 pièces qui manquaient : une barrière de scope listant ce qui ne doit pas être touché, une condition de sortie vérifiable par un agent indépendant, et une règle d'escalade qui arrête la boucle avant qu'elle brûle à travers un mauvais état. Pas dans CLAUDE.md, qui gère le comportement persistant à travers les sessions. Dans le brief lui-même, avant chaque run autonome.

Un builder sur X après avoir brûlé une session complète : "Beaucoup de tokens... le résultat était de la merde totale. J'ai dû recommencer." C'est ce qu'un brief absent coûte à l'échelle.

Si vous êtes au stade où les boucles tournent mais n'atterrissent pas toujours, Vibe Coding, For Real (Amazon Kindle, gratuit sur Kindle Unlimited) couvre la fondation : la méthode pour aller de "ça tourne" à "ça livre de façon fiable."

Les 4 heures ont construit à peu près ce que j'avais demandé, plus quelques trucs que je n'avais pas demandés, et ont brûlé 3 heures de compute sur une contrainte qui n'était pas dans le premier message. Dans le post-mortem, Claude m'a dit exactement quelle phrase l'aurait changé.

J'ai cette phrase maintenant. Je l'écrirai en premier la prochaine fois.

Allez écrire la condition de sortie avant le prompt.

Sources

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité chaque jour pour votre plaisir de lecture).