Quand il dit « fait » et que ce n'est pas vrai

Ce que c'est et pourquoi ça compte

Vous lui demandez une modification. Au bout d'un moment, Claude écrit « fait ». Vous ouvrez l'app et ça ne marche pas, ou ça ne marche qu'à moitié. Au début, ça arrive souvent, et la première réaction est de penser qu'il vous a menti.

Ce n'est pas le cas. Claude s'arrête quand le travail a l'air fini, et pour lui le travail se termine souvent quand il a écrit le code. Si personne ne lui a demandé de le tester, « ça a l'air fait » est le seul signal qu'il a. Le contrôle vous retombe donc dessus, après coup, quand vous pensez peut-être déjà à autre chose.

La solution tient en une seule ligne, dans le fichier que Claude Code lit au début de chaque session : le CLAUDE.md. Cette ligne change le sens de « fait ». Ça ne veut plus dire « j'ai écrit le code », ça veut dire « je l'ai vu fonctionner et je vous montre la preuve ». Moi, j'appelle ça le reçu.

Ça compte parce qu'un reçu se vérifie vite. Refaire vous-même tous les tests à chaque fois prend beaucoup plus de temps, et à la longue vous arrêtez de le faire.

1. La ligne dans le CLAUDE.md

Le CLAUDE.md est un fichier texte qui contient les règles que vous voulez que Claude garde à chaque session. Celui du projet se trouve dans le dossier principal du projet : CLAUDE.md, ou .claude/CLAUDE.md. S'il n'existe pas, créez-le.

Le plus simple, c'est depuis Claude Code : tapez /memory. Vous voyez les fichiers de mémoire, y compris ceux qui n'existent pas encore. Choisissez celui du projet : s'il n'existe pas, il est créé et s'ouvre dans votre éditeur. Si le projet n'a pas encore de CLAUDE.md, vous pouvez aussi lancer /init : Claude regarde le code et vous en prépare un de départ. Ensuite, vous y ajoutez la ligne.

Ne dis jamais "fait" sans preuve : les tests que tu as lancés avec leur résultat, une capture d'écran s'il y a une interface, la commande que tu as utilisée pour vérifier. Si tu n'as pas pu vérifier, écris-moi "non vérifié" et pourquoi.

Chaque morceau a sa raison :

• Les tests avec le résultat : il vous dit ce qu'il a contrôlé et comment ça s'est passé, pas seulement qu'il les a lancés.
• La capture d'écran s'il y a une interface : un test peut passer même avec un bouton qui a fini hors de l'écran.
• La commande qu'il a utilisée : vous pouvez ainsi refaire exactement le même test vous-même.
• « Non vérifié » et pourquoi : c'est la porte de sortie. Sans elle, vous le poussez à dire « fait » quand même. Avec elle, vous savez tout de suite où vous devez regarder.

À propos de la capture : Claude Code peut regarder des images, mais pour en faire une lui-même, il lui faut un moyen de voir l'app, par exemple un navigateur connecté à Claude Code ou un simulateur. S'il n'en a pas, il écrira « non vérifié » pour cette partie. C'est très bien comme ça : au moins, vous le savez.

2. Comment je la vérifie

Une nouvelle session et une question

J'enregistre le fichier et j'ouvre une nouvelle session, parce que le CLAUDE.md est lu au début de la session. Puis je demande :

Pour toi, quand est-ce qu'une chose est faite ? Réponds-moi avec les règles que tu as dans le CLAUDE.md.

S'il ne répète pas la règle, ce n'est pas le bon fichier ou il n'est pas dans le dossier du projet. Pour vérifier, tapez /context : sous Memory files, vous voyez quels fichiers de mémoire il a chargés. Si votre CLAUDE.md n'y est pas, Claude ne le voit pas.

Un petit travail

Je lui donne quelque chose de petit et facile à vérifier, par exemple :

Corrige le message d'erreur de la connexion quand l'e-mail est vide.

Quand il dit « fait », je vérifie que les trois choses sont là : tests et résultat, capture d'écran, commande. S'il en manque une et qu'il n'y a pas « non vérifié » avec la raison, le reçu est incomplet.

Je relance sa commande

Je copie la commande qu'il a écrite et je la lance moi-même dans le terminal. Si j'obtiens un résultat différent, le reçu ne vaut rien. Pas besoin de le faire à chaque fois, mais les premières fois, oui : c'est comme ça que vous savez si vous pouvez faire confiance à ses reçus.

Je regarde la capture d'écran

Elle doit montrer le bon écran, pas une page quelconque. Dans l'exemple de la connexion : le champ e-mail vide et le message d'erreur en dessous. Si elle montre la page d'accueil, elle ne prouve rien.

3. Si le projet n'a pas de tests

Sans tests, la première partie du reçu n'existe pas. Avant tout, demandez-lui ceci :

Écris un test pour ce que tu viens de faire, lance-le et montre-moi qu'il passe. Ensuite, casse le code exprès et montre-moi que le test échoue.

C'est la deuxième partie qui compte. Un test qui n'échoue jamais ne prouve rien : il passe que le code marche ou non. Si le test devient rouge quand le code est cassé, alors il contrôle vraiment quelque chose.

Ensuite, faites-lui remettre le code en état :

Maintenant, remets le code comme il était, relance le test et montre-moi qu'il passe de nouveau.

Et pour qu'il n'ait pas à deviner la prochaine fois comment lancer les tests, faites-le écrire dans le CLAUDE.md :

Ajoute au CLAUDE.md la commande exacte pour lancer les tests de ce projet.

4. S'il dit « fait » sans preuve

Ça arrive même avec la règle. Répondez simplement :

Preuve ?

En général, ça suffit. Si ça se reproduit :

Relis les règles du CLAUDE.md et redonne-moi le "fait", avec le reçu.

S'il continue à la sauter, regardez la longueur de votre CLAUDE.md. Dans un fichier rempli de règles, les importantes se perdent : gardez-le court et enlevez ce que Claude comprend tout seul en lisant le code. Si une seule ligne continue à lui échapper, vous pouvez la mettre en évidence, par exemple en écrivant IMPORTANT devant. Seulement celle-là : si vous mettez tout en évidence, plus rien ne ressort.

Les erreurs les plus courantes

• Mettre la règle dans un fichier que Claude ne lit pas, comme le README ou une note à part. Elle va dans le CLAUDE.md du projet, et /context vous dit s'il est chargé.
• Enlever « non vérifié » pour avoir toujours un « fait ». Laissez-le : c'est la partie qui le rend honnête quand il n'arrive pas à tester.
• Lire le reçu sans le vérifier. Les premières fois, relancez vous-même la commande et regardez attentivement la capture d'écran.
• Accepter des tests qui passent toujours. Faites-lui casser le code exprès et regardez le test échouer.
• S'attendre à ce que la règle s'applique tout de suite dans la session déjà ouverte. Ouvrez une nouvelle session et posez la question de contrôle.
• Remplir le CLAUDE.md de règles jusqu'à ce que celle sur la preuve se perde. Gardez-le court et concret.

Check-list

• La ligne est dans le CLAUDE.md du projet
• Dans une nouvelle session, Claude répète la règle
• Chaque « fait » arrive avec tests et résultat, capture d'écran et commande
• J'ai relancé sa commande moi-même au moins une fois
• Le test échoue quand le code est cassé
• Quand il ne peut pas tester, il écrit « non vérifié » et pourquoi

Questions fréquentes