Claude Code : la checklist de vérification qui prouve qu'un travail est vraiment terminé

Un vendredi soir, j’ai demandé à Claude Code d’« écrire un article et de le publier en entier », puis je suis allé me coucher. Au réveil, je regarde le journal : « Terminé. L’article a été publié », écrit avec une belle assurance. Rassuré, j’ouvre l’URL publique… et ce qui s’affichait, c’était le titre de l’article précédent.

Le build était passé. L’URL renvoyait bien un 200. Mais la balise h1 était restée celle d’une autre page. J’avais délégué entièrement la vérification du diff à l’IA, et je m’étais contenté de croire un seul mot : « ça marche ».

Ce soir-là, j’ai compris une chose : le problème, ce n’était pas l’intelligence de Claude Code, mais ma façon de « clôturer le travail ». Plus on élargit ce qu’on délègue à l’IA, plus il faut garder sous la main une preuve de « ce qui a réellement été vérifié », sinon on se fait piéger à chaque fois par un faux rapport de fin.

Dans cet article, je vous montre ce « modèle de preuve », avec du code prêt à copier-coller.

Points clés

• Ne croyez pas le « c’est fait » de l’IA. Seules les preuves vérifiées par la machine (build, URL publique, h1, CTA) servent de base pour déclarer un travail terminé.
• Avant de commencer à éditer, décidez en une phrase « ce que ce travail doit prouver » et fixez à l’avance la commande de vérification.
• Après publication, inspectez toujours dans le même ordre (h1 → canonical → début du corps → CTA). Un ordre figé réduit les oublis.
• Notez la preuve (capture, URL, prochain chiffre à surveiller) en une seule ligne : votre vous de demain, ou l’automatisation, n’aura pas à refaire le même jugement.
• Mieux vaut publier un article vérifiable le lendemain qu’un article parfait sorti d’un seul coup. Pour l’exploitation au quotidien, c’est plus robuste.

Pourquoi un simple « c’est fait » provoque des accidents

Claude Code résume par écrit l’avancement de son travail. Et c’est précisément le piège : le résumé revient avec à peu près le même visage, que tout se soit bien passé ou non.

« Le build est passé » prouve seulement que « la syntaxe n’est pas cassée ». « L’URL publique renvoie un 200 » prouve seulement que « le serveur a renvoyé quelque chose ». Que ce quelque chose soit bien l’article que vous venez de créer, c’est une autre histoire.

Mon accident du vendredi passait les deux contrôles : build et 200. Le seul point qui s’était cassé, c’était la cohérence entre l’URL et le contenu de la page. Et personne ne regardait ce point précis.

C’est pourquoi la décision « c’est terminé » ne repose pas sur les mots de l’IA, mais sur le résultat de chaque point de contrôle que vous avez vous-même fixé et coché un par un. Si la démarche de vérification vous semble encore floue, mettez d’abord les bases en place avec le guide de démarrage de Claude Code : la suite de cet article rentrera plus facilement.

La boucle de vérification de 15 minutes

Si vous vérifiez chaque fois avec une procédure différente, un jour chargé vous sauterez forcément une étape. Figez l’ordre pour pouvoir dérouler la boucle sans réfléchir.

1. Écrivez en une phrase « qu’est-ce qui, une fois vérifié, signifie terminé ». Exemple : « cet article de ce slug s’affiche bien à l’URL publique avec le bon h1 ».
2. Avant de commencer à éditer, choisissez la commande de vérification (build, affichage du diff). Ne la cherchez pas une fois le travail fini.
3. Après chaque changement, regardez dans l’ordre : diff → build → URL publique. Même si vous changez d’avis en route, ne cassez pas cet ordre.
4. Sur l’URL publique, vérifiez à l’œil que h1, canonical, le début du corps et les CTA sont alignés comme prévu.
5. Notez en une seule ligne le risque restant et « la plus petite action suivante ».

L’important ici, c’est de séparer dès le départ ce que vous déléguez à l’IA et ce que vous décidez vous-même.

Étape	À déléguer à l’IA	Décidé par l’humain
Choix du sujet	Lire les titres existants et proposer des candidats	Lequel écrire au final
Rédaction	Brouillon du corps, du code, des titres	Aucune info fausse ou périmée ne s’est glissée
Vérification	Lancer le build, résumer le diff	Contrôle final que le contenu de l’URL publique est correct
Publication	Exécuter la commande de publication	Approbation des actions irréversibles (suppression, mise en prod)

Les actions irréversibles, au début, basculez-les toutes sur « demander à l’humain ». Vous ne ferez monter en automatique que les actions dont vous aurez vérifié la sécurité. Cette manière de tracer la ligne est détaillée dans le guide de gestion des permissions.

Le modèle de prompt prêt à copier-coller

Si vous reformulez la vérification de zéro à chaque fois, des oublis apparaîtront selon votre humeur du jour. En figeant le prompt que vous donnez à Claude Code, les points de contrôle restent stables.

Je viens de publier cet article. Avant de me dire que c'est terminé, vérifie ce qui suit et renvoie le résultat sous forme de tableau.
- Le build a-t-il réussi ? (indique aussi la commande et le code de sortie)
- Le h1 de l'URL publique correspond-il bien au titre de l'article de ce slug ?
- La balise canonical pointe-t-elle vers le même slug ?
- Le début du corps n'est-il pas une réutilisation de l'article précédent ou de la page d'accueil ?
- Les CTA (PDF gratuit, produits, consultation) sont-ils ordonnés selon la situation du lecteur ?
Pour tout point que tu n'as pas pu vérifier, écris honnêtement « non vérifié ». N'écris pas « OK » par supposition.

C’est la dernière phrase qui fait la différence. Sans le « n’écris pas OK par supposition » explicite, l’IA répondra « aucun problème » d’un air vaguement satisfait, même pour des points qu’elle n’a pas vérifiés. Si vous voulez améliorer la construction même de vos prompts, lisez aussi les techniques avancées de prompt engineering.

Le script de vérification prêt à l’emploi

Voici le cœur du sujet d’aujourd’hui. On va chercher l’URL publique et on juge de façon mécanique si le h1 correspond au titre attendu. Ça fonctionne avec Node.js (18 ou plus) seul. Ce n’est pas le « c’est fait » de l’IA qui sert de preuve de fin, mais le verdict de ce script.

// verify-publish.mjs
// Usage : node verify-publish.mjs <URL publique> "<titre h1 attendu>"
// Exemple : node verify-publish.mjs https://claudecode-lab.com/fr/blog/foo/ "Titre de l'article"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("Passez deux arguments : l'URL et le titre h1 attendu.");
  process.exit(2);
}

// Récupère la page publiée
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// Extrait grossièrement h1 et canonical (pas besoin d'un parseur strict)
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// On coche les points de contrôle un par un
const checks = {
  http200: res.status === 200,
  h1Correspond: h1 === expectedH1,
  canonicalCorrespond: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("Des points sont non vérifiés ou ne correspondent pas. Ne considérez pas la publication comme terminée.");
  console.error(`h1 récupéré : ${h1 || "(vide)"}`);
  process.exit(1);
}

console.log("Preuves réunies. Vous pouvez considérer le travail comme terminé.");

L’exécution se résume à ceci.

node verify-publish.mjs https://claudecode-lab.com/fr/blog/foo/ "Titre de l'article"

Si h1Correspond vaut false, vous êtes exactement dans l’état de mon accident du vendredi. L’URL est vivante mais le contenu ne correspond pas. Tant que le code de sortie n’est pas 0, on n’appelle pas la publication « terminée ». Faites-en une règle, et le faux rapport de fin sera bloqué en amont.

Les situations où ça change tout

1. La publication d’un article C’est le cas typique où l’on confond à tort un simple HTTP 200 avec un succès. Avec le script ci-dessus, en vérifiant que h1 et canonical pointent vers le même slug, vous écartez avant publication la réutilisation de l’article précédent ou le repli vers la page d’accueil.

2. Le remplacement d’un CTA Quand vous déplacez un bouton vers un PDF gratuit ou un produit, gardez la capture et « le prochain chiffre à surveiller » sur la même ligne de note. Plus tard, vous pourrez suivre « ce changement a-t-il augmenté les inscriptions ? » sur la base de vos relevés, pas de votre mémoire.

3. La modification des réglages ou des permissions C’est justement quand vous changez le CLAUDE.md ou la configuration des permissions qu’il faut passer la même commande de vérification avant et après. Si l’écriture de la configuration vous inquiète, mettez d’abord en ordre les bonnes pratiques du CLAUDE.md pour aligner les prérequis de la vérification.

Les pièges, et comment en sortir

Pour être honnête, je suis tombé plusieurs fois dans les mêmes trous avant d’arriver à ce modèle.

Le premier, c’est de vouloir tout corriger d’un seul travail et de produire un diff trop gros pour être vérifié. Un diff qui touche 40 fichiers, ni l’humain ni l’IA ne peuvent le lire jusqu’au bout. Le remède est simple : limitez à une phrase ce que vous vérifiez par travail. Si la taille dépasse ce que vous pouvez contrôler, découpez le travail.

Le deuxième, c’est de considérer comme terminé dès que le build local passe. « Ça marche en local » et « ça s’affiche correctement à l’URL publique » sont deux choses différentes. Le remède, c’est de passer obligatoirement le script ci-dessus une fois après publication. Tant que je ne l’avais pas intégré à ma procédure, j’ai publié bien des fois un mauvais contenu.

Le troisième, c’est de multiplier les CTA sans expliquer au lecteur où aller ensuite. Aligner trois boutons ne sert à rien si on ne peut pas choisir. Le remède, c’est d’ajouter dans le corps une phrase qui indique, selon la situation du lecteur (encore peu sûr des manipulations / fatigué par les tâches répétitives / en réflexion pour un déploiement en équipe), quel CTA lui convient.

FAQ

Q. Si le build passe, c’est terminé, non ? Le build ne prouve que l’absence de syntaxe cassée. Que le contenu de l’URL publique soit bien l’article visé est une autre question. Ce n’est terminé qu’après avoir aussi vérifié h1 et canonical.

Q. Faut-il lancer le script de vérification à la main à chaque fois ? Au début, à la main, ça suffit. Une fois la procédure stabilisée, faites-le évoluer pour qu’il se lance automatiquement juste après la commande de publication. En posant la règle « si le code de sortie n’est pas 0, on arrête la publication », les accidents diminuent.

Q. Peut-on tout déléguer aussi à l’IA, y compris la vérification ? Les tâches de lecture et de résumé, oui, vous pouvez les déléguer. Mais le jugement final « le contenu de l’URL publique est-il correct » et l’approbation des actions irréversibles restent à l’humain. Si vous les cédez, il n’y a plus personne pour arrêter le faux rapport de fin.

Q. Une personne non technique peut-elle dérouler ces contrôles ? Oui. Le script fonctionne en copier-coller, et la procédure visuelle se résume à mémoriser un ordre. Si les commandes elles-mêmes vous inquiètent, commencez par l’explication pour les non-développeurs, ce sera plus naturel.

Q. Que faut-il garder dans la note pour que ce soit suffisant ? Trois choses suffisent : « ce que j’ai vérifié cette fois », « le risque restant », « la plus petite action suivante ». Pas besoin d’un long compte rendu. Le seul but, c’est que votre vous de demain ne refasse pas le même jugement.

Ce que j’ai constaté en pratique

Après la publication au mauvais contenu du vendredi, j’ai basculé mon critère de fin : non plus « ce que l’IA a dit », mais « le code de sortie du script est-il 0 ».

En passant réellement verify-publish.mjs sur une dizaine de publications, deux ont renvoyé h1Correspond à false. Les deux renvoyaient un 200, le genre qu’on ne repère pas au premier coup d’œil. Sans le script, j’aurais à nouveau publié une page recyclée.

Figer l’ordre de l’inspection visuelle a aussi payé. En regardant toujours dans le même ordre, h1 → canonical → début du corps → CTA, les oublis du type « tiens, j’avais déjà sauté ça la dernière fois » ont quasiment disparu. À mesure que j’ai sorti le jugement de ma tête pour le confier à une procédure, la vérification du soir est devenue plus légère, je le ressens concrètement.

Plutôt que de chercher une IA plus intelligente, mettez d’abord en place un dispositif qui vous prévient quand vous trébuchez. Ça paraît être un détour, mais c’est ce qui va le plus vite, c’est ma conclusion actuelle.

Si vous en êtes à vouloir faire de ce modèle de vérification le standard de votre équipe, ou l’intégrer au flux de publication de votre entreprise, on le conçoit ensemble en formation et conseil. La documentation officielle de Claude Code se consulte dans la documentation d’Anthropic.