Vérifier du code qu'on ne lit pas

Tu as demandé une fonctionnalité. Trois cents lignes plus tard, c’est annoncé comme fait, et tu sais déjà que tu ne les liras pas. Ce n’est pas de la paresse : tu ne les aurais pas lues il y a six mois non plus, et le projet a doublé depuis.

Reste la question, entière et sans réponse : est-ce que ça marche ?

Cette leçon ouvre le niveau 2, et c’est le seul endroit du parcours où le mot sert, donc autant le dire une fois. Les seize leçons sont rangées en trois paliers : le niveau 0 pour comprendre et démarrer, le niveau 1 pour les mécanismes qu’on ajoute quand un moment se présente, le niveau 2 pour la vérification et ce qui va avec. Tu n’as rien à faire de cette information, sinon savoir que tu changes de registre ici. C’est cette leçon qui pose la question dont les cinq suivantes sont les réponses. Elle ne va pas te demander de mieux relire. Elle part de l’inverse : tu ne relis pas, beaucoup de gens travaillent comme ça, et ça peut tenir — à une condition, qui est tout le sujet.

Ce qui se passe vraiment

Il s’arrête quand le travail a l’air fini. La leçon 2 l’a posé en une phrase : s’il n’existe rien, dans ta session, qui renvoie réussi ou échoué, « ça a l’air fini » est le seul signal dont il dispose pour décider qu’il a terminé — et la boucle de vérification, c’est toi. Ce mécanisme porte un nom dans la documentation, et il vaut d’être appris parce qu’il revient partout : la verification loop. Voici sa définition officielle, entière, parce que ce sont ses clauses intermédiaires qui décident de cette leçon :

Comment une session sait que le travail est réellement fini plutôt que simplement plausible. Tu donnes à Claude un contrôle qu’il peut lancer : une suite de tests, une construction, une comparaison de captures. Et Claude recommence jusqu’à ce que le contrôle passe, au lieu de s’arrêter après un seul essai. Une verification loop est le préalable de /goal, des exécutions non surveillées et des workflows dynamiques : sans elle, la seule chose qui décide que l’agent a terminé est l’agent lui-même.

La chute de cette phrase est la thèse de tout ce parcours, écrite par la source. Mais la définition suppose un contrôle qu’il peut lancer : le cas où le contrôle, c’est toi, la documentation ne l’a jamais nommé — elle le suppose partout et ne le défend nulle part. C’est le trou que cette leçon vient boucher.

Un contrôle, ce n’est pas forcément une suite de tests. La leçon 2 en a donné la liste : tout ce qui renvoie un verdict — tests, code de sortie d’une compilation, analyseur de code, script qui compare une sortie à un modèle, capture d’écran comparée à une maquette. Le tout se range en deux colonnes :

Ce qu’il boucle tout seul	Ce que tu constates toi
le verdict arrive dans la conversation, il peut relancer jusqu’à ce que ça passe	le verdict est sur ton écran, c’est toi qui le lis

Cette leçon part de la seconde colonne, et sa quatrième section montre à quel prix on rejoint la première. La seconde n’est pas la colonne du pauvre : c’est celle du client.

Le client mange le plat

La leçon 3 t’a donné l’image du cuisinier qui goûte son plat pendant qu’il le fait : il goûte, il rectifie, il regoûte, et il ne sert pas sans avoir goûté. C’est la boucle interne, et elle est réelle. Ici, c’est l’autre bout de la table. Le client mange. Il ne relit pas la recette, il ne saura jamais si le sel était de Guérande — mais il saura si c’est mangeable, et c’est la question qui compte au moment de servir.

Ce qui relie les deux images est le cœur du parcours : celui qui cuisine ne peut pas être le seul à juger. Le cuisinier s’habitue à son propre assaisonnement ; un plat peut être goûté et raté quand même. Se servir de la fonctionnalité soi-même est le seul contrôle de ce parcours dont le verdict soit prononcé par un humain. Il en existe un autre dont le verdict ne sort pas de la conversation en cours — le second avis, un relecteur lancé en contexte neuf, leçon 12. Mais celui-là reste une machine à qui on a raconté quelque chose. Toi, personne ne t’a raconté le travail avant que tu le voies. Tu es le juge.

Ce que le client goûte, et ce qui rend ce mode fragile

Un test répond à « est-ce que ça fait ce que le test dit ». Se servir de la fonctionnalité répond à « est-ce que ça fait le travail ». Ce parcours attrape le vrai chemin, celui que prend un utilisateur et pas celui qu’on avait en tête ; les vraies données, avec leurs accents, leurs champs vides et leurs cas tordus ; et le résultat tel qu’il se présente : le bouton qui n’est pas là, l’écran qui reste blanc, le message d’erreur en anglais au milieu d’une page en français. Rien de tout ça ne se lit dans une ligne de code, et deux de ces trois choses ne se lisent pas non plus dans une suite de tests verte. Et si ton projet n’a pas d’écran (une API, un traitement planifié, une bibliothèque, un outil en ligne de commande), s’en servir comme un utilisateur veut dire être ton propre client : tu lances l’appel toi-même, avec ta charge à toi, et tu lis la réponse telle qu’elle arrive.

Reste ce qui sépare ce mode d’un simulacre, et c’est un seul mot : délibéré. Se servir de la fonctionnalité après coup, en cliquant au hasard jusqu’à ce que ça ait l’air d’aller, ce n’est pas une vérification, c’est un soulagement. Le critère décidé après avoir vu le résultat s’adapte au résultat — sans mauvaise foi, simplement parce qu’on ne cherche pas ce qu’on n’a pas pensé à chercher.

À retenir — se servir de la fonctionnalité comme un utilisateur est un contrôle à part entière, et le seul dont le verdict soit prononcé par un humain. Ce qui le disqualifie, ce n’est pas son manque de rigueur : c’est de décider après coup ce qu’on allait vérifier.

Ce qu’on fait

Quatre gestes, puis une question de fermeté. Les trois premiers ne demandent rien à installer et se pratiquent aujourd’hui.

1. Écrire le parcours avant de demander

Trois lignes, dans ton fichier de notes ou dans un coin de ton éditeur, avant de formuler la demande :

les gestes — ce que tu vas faire, dans l’ordre : j’ouvre telle page, je tape ça, je clique là ; ou, sans écran : j’appelle telle route, avec telle charge ;
les données — les vraies, et de préférence celles qui ont déjà cassé quelque chose ;
ce que tu dois voir — en français, en une phrase, avec le résultat exact quand tu le connais.

Ce n’est pas une lubie maison. Le modèle de demande recommandé par la documentation donne les cas d’exemple avant l’implémentation, avec des valeurs dont on connaît déjà la réponse. Transpose sans test, et ces cas deviennent ton parcours : « avec l’adresse de ma collègue, l’inscription aboutit et le mail arrive ; avec une adresse déjà prise, l’écran affiche un message et rien n’est créé ». C’est aussi ce que la documentation dit d’un bon cahier des charges — les plus utiles se terminent par une vérification de bout en bout qui prouve que la fonctionnalité marche.

Ces trois lignes sont un plancher, pas un plafond. Elles se font d’abord et sans négociation : c’est ça, délibéré. Une fois passées, tu es libre de cliquer à côté du chemin prévu — c’est même souvent là que se trouvent les bugs. Ce qui est interdit, ce n’est pas d’errer, c’est de n’avoir rien écrit avant ; et ce que tu trouves en errant entre dans le parcours de la fois suivante.

2. Le dire dans la demande

La leçon 2 t’a donné les trois morceaux : ce que tu veux, comment il devra te le prouver, ce qu’il n’a pas le droit de toucher. Ce qui s’ajoute ici, c’est l’étape finale :

<ce que tu veux, précisément>. Ne modifie que <les fichiers concernés>. Termine
par une vérification de bout en bout : dis-moi exactement quoi lancer et quoi
ouvrir pour vérifier moi-même. Traite la cause, ne supprime pas l'erreur.
Donne-moi la liste des fichiers que tu as touchés.

Ce que tu ne lui demandes pas, c’est ce que tu dois voir. Ça, tu l’as écrit à l’étape 1, et c’est ton travail. Le lui demander, ce serait refaire produire le critère de succès par celui qu’on contrôle — le piège de la leçon 2, remonté d’un cran. Tu peux demander sa version en plus, jamais à la place : l’écart entre son attendu et le tien est une information, et c’est souvent là qu’un malentendu se voit avant de coûter cher.

Si tu ne sais pas quoi écrire dans le crochet des fichiers (le cas normal quand le projet a dépassé ce qu’on tient dans sa tête), écris le périmètre en français : « ne touche qu’à la page d’inscription et à ce qui l’alimente ». Ou demande-lui d’abord, dans un message séparé, où ça se passe, et reprends sa réponse comme périmètre. La phrase interdit le débordement silencieux, elle n’exige pas que tu connaisses l’arborescence.

« Ne supprime pas l’erreur » mérite sa glose, parce que la formule officielle se lit de travers en français. Supprimer veut dire ici faire taire : masquer le message, attraper l’exception et ne rien en faire, désactiver l’avertissement — pas « ne corrige pas le bug », qui est l’inverse exact.

3. Faire le parcours, puis décider selon ce que tu as vu

Tu fais le parcours que tu avais écrit, en entier, avant d’aller cliquer ailleurs. S’il passe : tu regardes la liste des fichiers touchés, geste de la leçon 2 qui ne coûte rien et ne demande pas de savoir lire du code. Un fichier de test ou de configuration là où tu n’attendais qu’une source, ça se voit.

S’il rate (bouton absent, écran blanc, mauvaise valeur), le geste est calqué sur celui que la documentation prescrit pour une construction qui échoue : coller l’erreur et demander la cause plutôt que le silence. Traduit à ton parcours :

J'ouvre <telle page>, je tape <telle donnée>, je clique sur <tel bouton>.
J'attends <ce que tu avais écrit à l'étape 1>. J'obtiens <ce que tu as vu,
mot pour mot, message d'erreur collé si tu en as un>. Traite la cause, ne
supprime pas l'erreur, puis redis-moi quoi refaire pour vérifier.

Puis tu refais le parcours entier, pas seulement l’étape qui avait cassé : une correction déplace souvent le problème d’un cran. Et si le même parcours rate une deuxième fois, arrête d’empiler des réparations : reviens à l’état d’avant avec /rewind, leçon 7, et redemande en une seule fois, avec le parcours et ce que tu as vu échouer.

Reste le point que tout le monde escamote. Ce que tu n’as pas pu essayer ne devient pas bon pour autant. La documentation formule la règle pour ses propres agents vérificateurs : quand ils ne peuvent pas contrôler une affirmation, le rapport la range en non vérifiée plutôt que de la compter pour réfutée. Retourne la phrase et tu as ta discipline du jour : non essayé n’est pas validé. Écris-le quelque part : c’est la leçon 11.

4. Quand la machine peut refaire le parcours à ta place

Ton parcours vit dans la seconde colonne : c’est toi qui regardes. Quatre voies le font passer dans la première. Leurs conditions ne sont pas de même nature : la première demande une version minimale de Claude Code, v2.1.145 pour les trois skills — claude --version te donne la tienne. Les autres demandent une seconde installation avec sa propre version minimale, une offre payante ou un système précis. Le détail est sur les pages liées en fin de leçon, parce que ce genre de liste périme vite ; ce qui suit garde ce qu’elles ne mettent pas en avant.

La voie	Pour quel projet	Ce qu’il faut en plus
`/run` et `/verify`	tout projet qui se lance en ligne de commande	rien, tant que le lancement est standard
Comparer deux captures	une interface, avec une maquette ou un avant/après	de quoi rendre et capturer une page
Claude in Chrome	une application web	une seconde installation et une offre payante directe
computer use	une application native, quand rien d’autre ne marche	macOS, Pro ou Max, un compte claude.ai

Lancer l’application et la piloter. Trois skills (une fiche réutilisable, du savoir ou une procédure, leçon 4) sont fournis avec l’outil et travaillent ensemble : /run pilote ton application, /verify la construit et la lance pour confirmer qu’un changement fait ce qu’il doit « plutôt qu’en se fiant aux tests ou au contrôle de types », /run-skill-generator leur apprend à construire et lancer ton projet. C’est le geste de cette leçon, outillé. Trois réserves : /verify ne se déclenche jamais tout seul, tu l’invoques ; les deux premiers devinent comment lancer ton projet, et la documentation dit elle-même que cette déduction « devient peu fiable » dès qu’il faut une base de données, un fichier d’environnement, une session graphique ou une construction en plusieurs étapes — dès qu’il s’agit de ton projet réel, donc, et c’est là que le troisième sert ; enfin ils peuvent être absents chez toi, disableBundledSkills coupant tous les skills fournis. Tape /skills pour savoir ce dont tu disposes.

Piège — quand /verify doit construire et piloter ton application sans recette enregistrée, il écrit ce qui a marché dans .claude/skills/verify/SKILL.md, depuis la v2.1.200. À la racine du dépôt, ce fichier remplace le skill fourni : une commande lancée pour vérifier une modification vient de changer ce que « vérifier » voudra dire les fois suivantes. Le signe visible est celui que tu regardes déjà. Le fichier apparaît dans la liste des fichiers touchés du geste 3. Quand tu l’y vois, tranche : tu le gardes et tu le commites, ce que la documentation présente comme le cas normal ; ou tu l’effaces et tu lances /run-skill-generator, qui enregistre la recette délibérément au lieu de la ramasser en chemin.

Comparer deux images. Sur une interface, c’est le contrôle le moins discutable qui existe, et le catalogue de prompts donne la formule : « implémente ce design, puis prends une capture du résultat, compare-la à l’original, et corrige les différences ». Mais elle exige ce que le terminal n’a pas : de quoi rendre la page et la capturer, donc l’extension Chrome ou un serveur MCP Playwright — le MCP étant le branchement vers un service extérieur, leçon 4, et la page de démarrage MCP liée plus bas donnant sa ligne d’installation.

Ce que brancher un serveur MCP engage, et la documentation ouvre là-dessus. Un serveur MCP est un programme tiers qui tourne à côté du tien et dont les résultats entrent dans ce que Claude lit. Celui-là va chercher des pages : il ramène donc dans la boucle du contenu que personne n’a écrit pour toi — le cas type de la prompt injection de la leçon 1. La consigne officielle tient en une ligne, vérifie à qui tu fais confiance avant de brancher, et le critère se pose en deux questions : qui publie ce serveur, et est-ce qu’il ne fait que ce pour quoi tu l’installes. Ne compte pas sur une figure d’autorité pour y répondre : Anthropic contrôle les connecteurs qu’elle liste dans son annuaire au regard de ses propres critères, mais elle n’audite la sécurité d’aucun serveur MCP et n’en gère aucun. C’est écrit dans sa page sécurité, et c’est à toi.

Piloter un vrai navigateur, ou une application native. Claude in Chrome agit dans une fenêtre Chrome que tu vois en temps réel ; computer use fait la même chose sur les applications natives, en dernier recours par conception puisqu’il est « le plus large et le plus lent ». Leurs conditions d’accès sont sur leurs pages ; deux points méritent de figurer ici. Claude in Chrome partage l’état de connexion de ton navigateur : il atteint tous les sites où tu es déjà identifié, et la parade est dans l’extension, dont les autorisations se règlent site par site. Et computer use est la voie la plus fermée des quatre — research preview, c’est-à-dire livré pour essai et susceptible de changer, macOS seulement, Pro ou Max et pas Team ni Enterprise, authentification claude.ai, session interactive obligatoire.

Ce que tu échanges en passant à la machine. Le parcours devient reproductible et se termine sans toi. Mais le juge redevient le jugé : c’est celui qu’on contrôle qui lance l’application et raconte ce qu’il a vu. Tu ne perds pas la vérification, tu perds l’indépendance du verdict — et c’est le second avis, dernière ligne du tableau qui suit, qui la rachète en partie.

Le contrôle existe d’abord, la fermeté se décide ensuite

C’est l’ordre que donne la documentation, et il évite l’erreur la plus coûteuse : choisir un dispositif avant d’avoir un contrôle. Une précision avant le tableau : les degrés 2 et 3 supposent un contrôle de la première colonne — la définition citée plus haut pose la verification loop en préalable de /goal et des exécutions non surveillées, et un hook Stop ne bloque à bon escient que s’il a un verdict à lire. Quand il lance un script, c’est le script qui le produit ; dans sa variante sans script (une consigne qu’un modèle évalue), le verdict se rend sur ce que la conversation montre, exactement comme /goal, que la documentation décrit d’ailleurs comme le raccourci intégré vers un hook Stop de cette forme, limité à la session en cours. La leçon 13 démonte les deux. Si ton contrôle est encore dans la seconde colonne, tu as les degrés 1 et 4, et la section précédente est le chemin pour atteindre les autres.

#	Le degré	Ce qui referme la boucle	Ce que ça demande	Où c’est traité
1	Dans une seule demande	ta phrase : lance le contrôle et recommence jusqu’à ce qu’il passe	rien	leçon 2, tu l’as déjà
2	Sur toute une session	`/goal` : un évaluateur séparé relit la condition après chaque tour	un contrôle que Claude peut lancer, une condition écrite, et le mode automatique pour tourner sans toi	ici, ci-dessous
3	En barrière automatique	un hook `Stop` qui empêche le tour de se terminer tant que le contrôle échoue	un script qui rend un verdict, ou une consigne qu’un modèle évalue, et un réglage	leçon 13
4	Par un second avis	un relecteur en contexte neuf, qui essaie de réfuter le résultat	un ordre de mission	leçon 12

Le hook de la troisième ligne, c’est le déclenchement automatique attaché à un événement de la leçon 5 ; ici l’événement est la fin d’un tour, et le hook qui s’y attache s’appelle Stop. Ce qui sépare les degrés 2 et 3 n’est donc pas la nature du dispositif mais sa portée : /goal se tape et vaut pour la session en cours, le hook que tu écris vit dans un fichier et vaut pour toutes les sessions de sa portée. Chaque marche échange de la mise en place contre de l’attention : la première marche sur n’importe quelle tâche dès aujourd’hui, les deux suivantes permettent à une session non surveillée de se terminer correctement sans toi.

L’objectif de session mérite quelques lignes, parce que c’est le degré que personne ne connaît. La condition se tape à la suite de la commande, sans guillemets :

/goal all tests in test/auth pass and the lint step is clean

L’exemple est celui de la documentation ; poser l’objectif démarre un tour immédiatement, et il n’y en a qu’un à la fois. Après chaque tour, un évaluateur séparé (un petit modèle rapide, le small fast model de tes réglages) relit la conversation et la condition, et rend un verdict sur trois : pas encore atteint, atteint, ou impossible. Il existe aussi une quatrième sortie qui n’est pas un verdict : si Claude répond à l’évaluateur sans utiliser d’outil pendant plusieurs tours, Claude Code arrête la boucle et te rend la main avec l’objectif toujours posé.

Sa limite est décisive : l’évaluateur ne lance aucune commande et ne lit aucun fichier. Il juge ce que Claude a fait remonter dans la conversation, donc un objectif est vérifié sur le récit de l’agent, pas sur le monde. D’où la règle d’écriture que donne la documentation : la condition doit être quelque chose que la sortie de Claude peut démontrer. « Tous les tests de test/auth passent » marche, dit-elle, parce que Claude lance les tests et que le résultat atterrit dans la conversation où l’évaluateur le lit. Une bonne condition a trois morceaux : un état final mesurable, un contrôle énoncé et les contraintes qui comptent. Le contrôle énoncé, c’est comment Claude doit le prouver, « npm test sort en 0 » par exemple.

Ce que ça ne fait pas

Ce que le client ne goûte pas

Un plat peut être mangeable et le four s’être éteint hier. Se servir de la fonctionnalité te dit qu’elle fait le travail aujourd’hui, pour le parcours que tu as fait, avec les données que tu as prises. Cinq angles morts, et ils ordonnent la suite du parcours.

La faille de sécurité. Ton inscription marche, tu as reçu le mail, tu t’es connecté. Rien dans ce parcours ne dit que la nouvelle adresse est protégée, ni que le contrôle d’authentification a été posé sur toutes les routes ajoutées. La réponse documentée est une relecture qui cherche ça et rien d’autre : /security-review analyse l’écart entre ta branche courante et la branche par défaut de origin, et signale injections, problèmes d’authentification et fuites de données. Leçon 12.
L’ancien chemin resté en vie à côté du nouveau. L’écran affiche la bonne valeur ; il ne dit pas d’où elle vient. En juillet 2026, sur l’audit d’un système d’alerte pour écoles en production dont la leçon 6 raconte le reste, les libellés d’alerte étaient rangés dans une table prévue pour ça — et réécrits en dur à deux autres endroits qui ignoraient la table. En s’en servant, tout paraît juste ; le jour où la table change, un tiers du produit suit. /code-review attrape ce genre de chose : leçon 12, là encore.
Le contrôle automatique qui ne s’exécute plus. Un garde-fou installé au mauvais endroit ne se plaint pas : il ne s’exécute simplement jamais, et il te rend confiant pendant ce temps. Ça s’est produit sur un projet en production d’avril à juin 2026 : c’est la leçon 13.
La donnée qui gonfle en silence. Une table qui prend une ligne à chaque passage et que rien ne vide, un fichier de journal qui n’est jamais tourné. Là on quitte le terrain de la documentation : c’est un constat, pas un comportement documenté de l’outil. Il n’en est pas moins réel, et il a la propriété qui compte — son coût grandit tout seul pendant que tout marche. Le reconnaître est le sujet de la leçon 11.
Ce qui marchait et ne marche plus. Le seul des cinq qui grandit avec le projet, et celui que ce mode crée lui-même : un parcours fait à la main ne s’accumule pas. La fonctionnalité validée en mars et cassée en mai n’est repassée par personne, parce que chaque ajout ajoute un parcours à refaire et que le nombre de parcours dépasse le temps disponible bien avant qu’on ne le remarque. C’est la propriété qu’a un test et que ta main n’a pas : il se rejoue indéfiniment sans t’user. La réponse est la première colonne — la section 4 en est le chemin, le degré 3 en est la fermeté.

La rareté n’est pas la fiabilité

« Les modèles sont devenus très bons, ça rate rarement. » C’est exact, et il faut le dire. Mais la rareté n’est pas la fiabilité : plus l’échec est rare, moins on le surveille, et plus il coûte quand il arrive. Le constat est la raison d’avoir des filets, jamais la raison de s’en passer.

La documentation nomme le défaut correspondant, the trust-then-verify gap — l’écart entre faire confiance et vérifier : Claude produit une implémentation d’apparence plausible qui ne traite pas les cas limites. Et son remède tient en une phrase, qu’on peut coller au-dessus de son écran : si tu ne peux pas le vérifier, ne le mets pas en production.

Les garde-fous cèdent, et c’est par conception

Aucun des quatre degrés n’est absolu, et ce n’est pas un défaut caché : les points de rupture sont écrits noir sur blanc. La barrière automatique est passée outre après huit blocages consécutifs sans progrès — la leçon 13 démonte le mécanisme. L’objectif de session s’arrête quand la progression s’arrête et te rend la main avec l’objectif toujours posé, ce qui ressemble beaucoup à une session finie. Et le mode automatique cède avec des seuils non configurables, sujet de la leçon 8. Retiens la forme générale : la fin d’un tour n’est pas une preuve. Elle peut vouloir dire « le contrôle est passé » comme « le dispositif a laissé passer ».

Ce que ça ne remplace pas

Le second avis. Toi qui te sers de la fonctionnalité, tu sais ce que tu voulais — et c’est précisément ce qui t’empêche de voir ce que tu n’as pas demandé. Un relecteur lancé dans un contexte neuf ne voit que la modification et les critères qu’on lui donne, pas le raisonnement qui l’a produite. C’est la leçon 12, avec son revers qui vaut d’être annoncé ici : un relecteur à qui on demande de trouver des manques en trouvera, même quand le travail est sain. Et la vérification que ces dispositifs sont encore vivants est un travail à part, celui de la leçon 13.

Ce n’est pas un gain de temps. Écrire le parcours avant de demander prend du temps. Faire le parcours prend du temps. Installer de quoi le faire faire par la machine prend du temps et un plan payant. Ce que tu achètes n’est pas de la vitesse : c’est de savoir ce soir laquelle des deux phrases est vraie — « ça marche » ou « ça a l’air fini ».

Où c’est écrit

Donner à Claude de quoi vérifier son travail — le principe, les contrôles, les quatre degrés, les modèles de demande, the trust-then-verify gap ; et le glossaire, Verification loop pour la définition citée ;
/goal et comment se fait l’évaluation — les trois verdicts, l’arrêt pour absence de progrès, ce que l’évaluateur ne fait pas ; puis le hook Stop, le plafond de blocages et quand le mode automatique se replie ;
Lancer et vérifier ton application — les trois skills fournis, la recette enregistrée, les planchers de version ; catalogue de prompts pour la boucle capture-comparaison, et démarrer avec MCP pour Playwright ;
Claude in Chrome et computer use — les conditions complètes, les autorisations par site, et à qui ces voies sont fermées ;
Commandes et relire une modification localement — /security-review, /code-review, /skills.

Ces liens pointent vers les pages anglaises, et pour cette leçon c’est plus qu’une question de vocabulaire : la version française existe, /fr/ à la place de /en/, mais elle peut être en retard sur le fond. Au 18 août 2026, la page française de /goal décrit encore deux verdicts au lieu de trois et ne mentionne pas l’arrêt pour absence de progrès. Sur un fait, c’est la page anglaise qui fait foi.

Ce que cette leçon ajoute à ces pages : la légitimité du contrôle fait à la main, que la définition officielle exclut par construction puisqu’elle suppose un contrôle que Claude peut lancer ; l’ordre — le parcours s’écrit avant la demande, pas après le résultat ; et la carte des cinq angles morts, qui range les leçons suivantes au lieu de les empiler.

Le point de bascule

Tu as basculé le jour où, avant de demander quoi que ce soit, tu écris ce que tu iras regarder — et où, en voyant « c’est fait », ta première question n’est plus « est-ce que je le crois ? » mais « qu’est-ce que mon parcours n’a pas pu voir ? ». La première question n’a pas de réponse. La seconde en a cinq, et chacune a sa suite.

Vérifier que c’est passé

Tu poses un objectif de session : « la page de connexion doit fonctionner ». Une heure plus tard, l'objectif est marqué atteint. Qu'est-ce que ça prouve exactement ?

Que la conversation contient de quoi convaincre l’évaluateur, et rien de plus. L’évaluateur ne lance aucune commande et ne lit aucun fichier : un objectif est vérifié sur le récit de l’agent, pas sur le monde. C’est le problème du juge et du jugé, remonté d’un étage. D’où la règle d’écriture de la documentation : la condition doit être quelque chose que la sortie de Claude peut démontrer, et elle dit comment le prouver — « npm test sort en 0 ».

Ton application de facturation marche : tu crées une facture, elle s'affiche, le PDF se télécharge — tu as suivi le parcours écrit avant de demander. Six semaines et quatre fonctionnalités plus tard, un client signale que l'export comptable, auquel personne n'a touché, sort des lignes vides. Lequel des angles morts s'est refermé sur toi ?

Le cinquième : ce qui marchait et ne marche plus. Le parcours de l’export a été fait une fois, il y a six semaines, et personne ne l’a refait depuis — parce qu’un parcours à la main ne s’accumule pas, et que quatre fonctionnalités plus tard il y a plus de parcours à refaire que de temps pour les faire. Ce n’est pas une faute d’attention, c’est la propriété du mode, et le seul angle mort qui grandit avec le projet. La parade n’est pas d’en refaire plus : c’est de faire passer celui-là dans la première colonne, pour que la machine le rejoue, puis de lui donner la fermeté du degré 3.