Tu as commenté STRUCTURE. Voici ce que la vidéo ne donne pas : comment on provoque une erreur utile, comment on lit le symptôme pour savoir quelle couche recadrer, quoi écrire au retour de cadrage, et à quel moment un cycle est fini. Un système d'agents qui tient ne se télécharge pas. Il s'éprouve, compartiment par compartiment.
<aside> ⚠️
Tu n'as pas encore Claude Code ?
La boucle de cette page ne dépend d'aucun outil précis, tu peux la lire en entier sans rien installer. Si tu veux l'appliquer dans un terminal, copie ce prompt dans ton IA (Claude, ChatGPT, un autre assistant) :
Aide-moi à installer Claude Code sur mon ordinateur.
Avant de commencer, va lire la documentation officielle Anthropic
https://code.claude.com/docs/en/setup sans te fier à tes seules connaissances
pré-entraînement : elle porte la procédure exacte selon mon système
(Mac / Windows / Linux), la dernière version, et le type de compte requis.
Ensuite, donne-moi les étapes une par une. Je n'ai jamais utilisé un terminal.
Ton IA va te guider pas à pas. Reviens ici après.
</aside>
<aside> ✅
Tu l'as installé mais tu l'utilises encore peu ? Tu es exactement au bon endroit, et c'est le bon moment. Cette page ne suppose aucune maîtrise : elle se lit du début à la fin et chaque partie s'utilise telle quelle. La boucle d'épreuve est justement ce qui transforme un débutant en quelqu'un dont le système tient, parce qu'elle te fait apprendre sur tes propres erreurs au lieu d'attendre d'avoir tout compris. Continue.
</aside>
<aside> 💡
Tu utilises un autre outil que Claude Code ?
Ce que tu lis ici ne dépend pas de Claude Code. C'est le tronc commun de tous les assistants qui travaillent en autonomie sur un projet : un fichier d'instructions lu à chaque session, des règles qui ne valent que dans une zone, des procédures réutilisables, un mandat par acteur. Sur Codex (OpenAI), sur Cursor, sur Copilot CLI, sur Antigravity CLI, sur OpenClaw, le principe est identique. Seul le nom du fichier change, et AGENTS.md est devenu le format partagé par plusieurs de ces outils (voir agents.md). Attention : Claude Code, lui, lit CLAUDE.md.
Copie ce prompt dans ton outil pour transposer :
J'utilise [nom de mon outil]. Je veux appliquer ce principe : quand mon agent
se trompe, je ne corrige pas sa sortie, je remonte recadrer la couche de
documentation qui l'a mal guidé.
Avant de répondre, va lire la documentation officielle de mon outil si elle
existe, pour ne pas te baser sur des suppositions.
Dis-moi ensuite, chez moi : où vivent les instructions permanentes du projet,
où vivent les règles qui ne s'appliquent qu'à un dossier, où vivent les
procédures réutilisables, et où se définit le mandat d'un acteur.
Ne présume rien. Si l'un des quatre n'a pas d'équivalent chez moi, dis-le
clairement au lieu d'inventer une correspondance.
Liste des outils vérifiée le 2026-09-17.
</aside>
<aside> 🧭
Tu ne codes pas ? Lis quand même.
Rien ici n'est réservé aux développeurs. Ce que cette page appelle « la documentation des spécifications », chez toi ce sont tes procédures métier : la façon dont tu qualifies un dossier client, dont tu montes une offre, dont tu relances un impayé. Un cabinet qui confie la rédaction de ses notes à une IA, un indépendant qui lui fait préparer ses devis, un e-commerce qui lui fait écrire ses fiches produit : tous vivent exactement le même problème. La sortie est correcte mais ce n'est pas ce qu'ils voulaient, et ils la recorrigent chaque fois au lieu d'écrire une bonne fois ce qu'ils attendaient. La boucle est la même, seuls les exemples changent.
</aside>
La vidéo dit quoi faire : provoquer les erreurs, remonter au cadrage, itérer par cycles courts. Elle ne dit pas comment, parce que ça ne tient pas en 90 secondes.
Cette page est le comment. Elle te donne les épreuves à provoquer en premier, le routeur qui transforme un symptôme en couche à recadrer, le test qui sépare une correction d'une vraie spécification, la condition de sortie d'un cycle, et le prompt qui fait tourner la boucle avec toi.
Tout système d'agents fait passer ton intention par quatre étages avant de produire quoi que ce soit.
flowchart LR
A["Ton intention"] --> B["La documentation<br>des spécifications"]
B --> C["Les plans"]
C --> D["Les exécutions"]
D --> E["Les livrables"]
E -. "un livrable décevant<br>se répare un cran plus haut" .-> B
Chaque étage ne peut être que moins fidèle que le précédent. Si ta documentation capte 60 % de ton intention, aucun plan et aucune exécution ne rattrapera les 40 % manquants : ils seront devinés, et bien devinés parfois, ce qui est encore plus trompeur.
D'où la seule lecture qui sert à quelque chose quand tu es déçu : un livrable raté n'est presque jamais un problème de livrable. Il se répare un cran plus haut. C'est exactement ce que dit la discipline du développement piloté par les spécifications, qui fait de la spécification la source de vérité du système : « When something doesn't make sense, you go back to the spec » (GitHub, Spec-driven development with AI, Den Delimarsky, 2 septembre 2025).
flowchart TD
S["1. Provoquer<br>une erreur choisie"] --> T["2. Lire le symptôme"]
T --> U["3. Recadrer LA couche<br>en cause, pas la sortie"]
U --> V["4. Re-provoquer<br>exactement le même cas"]
V -- "le symptôme revient" --> T
V -- "le symptôme ne revient pas" --> W["Cycle fermé :<br>compartiment suivant"]
Le temps 4 est celui que tout le monde saute. Sans lui tu n'as pas éprouvé ton système, tu as juste écrit une ligne de plus en espérant.