Valider sans hésiter avec Claude Code : le journal de décisions read/edit/run/deploy

Un vendredi en fin d’après-midi, j’ai demandé à Claude Code : « corrige juste le lien sur cette page ». En retour, l’écran s’est rempli de messages de confirmation. « Puis-je exécuter cette commande ? » Fatigué, j’ai à peine lu le contenu et j’ai appuyé sur Entrée.

Le lendemain matin, l’affichage des tarifs de mon site en production avait changé. En plus du lien, l’IA avait « profité de l’occasion » pour modifier un autre fichier qui contenait les prix. Le bouton d’autorisation, c’est bien moi qui l’avais pressé.

Le problème n’était pas l’intelligence de l’IA. C’était que la frontière entre l’opération que j’avais acceptée hier et celle que je devais bloquer aujourd’hui n’existait que dans ma tête, et qu’elle bougeait à chaque fois. Si le « bon, ça ira » dépend de mon humeur du jour, l’accident n’est qu’une question de temps. Aujourd’hui, je vous explique comment sortir cette frontière de votre tête, avec un « journal de validation ».

Points clés

• Les validations Claude Code se rangent en quatre familles : lire, modifier, exécuter, publier. L’hésitation disparaît.
• On classe chaque opération en autoriser, demander ou interdire, puis on note chaque jour la raison et la commande de vérification dans un seul fichier.
• On confie à l’IA la recherche et le brouillon ; l’humain garde la main sur quatre choses : prix, mise en production, suppression, et tout ce qu’on ne sait pas annuler.
• Vous trouverez un modèle de journal à copier-coller et un prompt qui fait pré-classer l’IA.
• En cas de doute, on ne met pas en « autoriser ». Cette seule règle a fait quasiment disparaître les « accidents au passage ».

Ranger les validations en quatre familles : lire, modifier, exécuter, publier

Quand on utilise Claude Code, toutes sortes de confirmations arrivent. Si on les traite toutes en bloc, par un simple « oui ou non », c’est épuisant à chaque fois. En répartissant les actions en quatre familles, la décision devient beaucoup plus légère.

• Lire : consulter le contenu d’un fichier ou d’un log. En général, on peut autoriser sans souci.
• Modifier : réécrire un fichier. Pour une faute de frappe dans un article, c’est anodin. Une grille tarifaire, c’est tout autre chose.
• Exécuter : lancer une commande. Un test rapide est anodin ; tout ce qui a un effet vers l’extérieur demande de la prudence.
• Publier : pousser vers le site en production. C’est toujours le dernier rempart.

Pour un même « modifier », une faute de frappe dans le corps d’un article et le fichier de configuration des paiements n’ont pas du tout le même poids. C’est pourquoi je décide non seulement la famille d’opération, mais aussi de quel fichier il s’agit, en un seul tenant.

Classer chaque décision en trois niveaux

Une fois les quatre familles posées, on attribue à chacune trois niveaux. Pas besoin de jargon.

Niveau	Sens	Exemple
Autoriser	Continuer sans demander	Lire le dossier des articles, corriger une faute dans le corps
Demander	Me poser la question une fois	Modifier le fichier des prix, publier en production
Interdire	Ne pas le faire cette fois	Suppression en masse de fichiers, écrasement forcé

Une seule astuce. Au moindre doute, on ne met pas en « autoriser ». On le place en « demander », pour commencer. On le fera monter en « autoriser » plus tard, une fois qu’on aura compris que « c’est sûr à chaque fois ». On garde d’abord toutes les rênes en main, et on ne les relâche que sur ce qu’on a vérifié comme sûr. Rien qu’en respectant cet ordre, l’histoire de l’accident tarifaire du début ne se produit plus.

Un fichier par jour : le modèle de journal

C’est en voulant tout retenir de tête qu’on craque. Un fichier par jour, où l’on écrit simplement le classement du jour. Le format importe peu, mais voici celui où je me suis arrêté. Il se copie-colle tel quel.

{
  "date": "2026-06-07",
  "perimetre": "uniquement le corps des articles et le remplacement des liens",
  "lire":     { "autoriser": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "modifier": { "autoriser": ["nouveaux fichiers d'article"], "demander": ["prix", "configuration des paiements", "secrets de production"] },
  "executer": { "autoriser": ["npm run build", "vérification de l'affichage de l'URL publique"], "demander": ["publication", "git push"] },
  "publier":  { "verifier_avant": ["le build passe", "le h1 de l'URL publique est correct", "vérifier visuellement chaque langue"] },
  "note_prochaine_fois": "les prix restent en demander. Le remplacement des liens d'article passera en autoriser après vérification."
}

Cela prend deux à trois minutes à écrire. Mais ces deux à trois minutes effacent les dix minutes du lendemain passées à se demander « tiens, j’avais fait quoi pour ça hier ? ». La ligne perimetre est discrètement efficace. En écrivant à l’avance jusqu’où va le travail du jour, on repère l’instant où l’IA en sort.

Ce qu’on confie à l’IA, et ce que l’humain décide

C’est en mélangeant ces deux-là qu’on a des accidents. Traçons la frontière clairement.

Ce qu’on peut confier à l’IA

• Chercher quels fichiers semblent concernés
• Rédiger un brouillon de modification
• Montrer la différence avant/après
• Lancer la commande qui vérifie « si le build passe »

Ce que l’humain garde absolument

• Toute modification touchant aux prix, aux paiements ou au formulaire d’inscription
• La publication vers le site en production (j’appuie moi-même sur le bouton de publication)
• La suppression de fichiers ou de données
• Tout travail dont je ne sais pas expliquer comment l’annuler

Ma règle est simple : dès que « l’argent », « la production », « supprimer » ou « irréversible » sont en jeu, je tranche toujours moi-même, de ma propre main. À l’inverse, tout le reste, recherche et brouillon, je le confie sans hésiter à l’IA. Cette manière de tracer la frontière est aussi abordée dans Claude Code pour les non-développeurs, mais même sans connaissances techniques, décider que « l’argent et la production, c’est moi » suffit à se protéger.

Le prompt qui fait pré-classer l’IA

On peut aussi se faire aider de l’IA pour le classement lui-même. Mais sans gober le résultat : à la fin, on regarde soi-même. Collez le texte d’instruction suivant tel quel.

Pour le travail Claude Code d'aujourd'hui, classe les opérations en
« autoriser », « demander » et « interdire ».
Les cibles sont ces quatre familles : lire / modifier / exécuter / publier.

Pour chaque famille, renvoie ceci :
1. La liste des opérations qu'on peut autoriser
2. La liste des opérations à confirmer une fois
3. La liste des opérations à interdire cette fois
4. La commande de vérification pour s'assurer de la sécurité (ex : npm run build)
5. Une note pour la prochaine fois (condition pour passer de « demander » à « autoriser »)

Pour toute opération touchant aux prix, aux paiements, à la mise en
production ou à la suppression : en cas de doute, mets-la en « demander ».

L’essentiel, c’est la dernière ligne. En l’ajoutant, on empêche l’IA de relâcher d’elle-même sa décision en se disant « ça, on peut bien l’autoriser ». Si vous voulez affiner votre écriture de prompts, voyez aussi la conception de prompts Claude Code.

Trois situations où ça fait la différence

1. Remplacer un article de blog Vous voulez remplacer un seul lien d’inscription sous un article populaire. Dans ce cas, demander « corrige les endroits qui semblent liés » ouvre un périmètre bien trop large. Écrivez d’abord dans le journal « les fichiers qu’on peut toucher », « les fichiers à ne pas toucher » et « l’URL publique à vérifier ». La vérification après coup passe alors de « ça a l’air bien comme ça » à « avec cette preuve, je peux publier ».

2. Trier les demandes de contact Vous faites lire les demandes entrantes par l’IA pour qu’elle vous signale seulement celles qui semblent prometteuses. Lire, on peut le mettre en « autoriser ». Mais l’inscription dans la liste clients reste en « demander ». Même si l’IA se trompe de classement, elle s’arrête avant d’écrire toute seule dans les données de production.

3. Vérifier des articles multilingues avant publication Même quand le paramètre de langue du frontmatter est correct, il arrive que le corps reste en anglais. Pour chaque langue, on regarde le titre, l’introduction et les liens d’appel pour s’assurer que le lecteur de cette langue comprend l’action suivante à entreprendre. On fige cette vérification visuelle comme point « à vérifier avant publication » dans le journal.

Prêt à copier-coller : le script de vérification du journal

Écrire le journal ne sert à rien si l’on saute la « vérification avant publication » qui en est le cœur. On regroupe donc dans un seul script les contrôles à passer obligatoirement avant de publier. Voici un exemple qui fait vérifier par la machine si le build passe et si le titre de l’URL de production est correct. Ça tourne dès qu’on a Node.js.

node check-before-deploy.mjs https://claudecode-lab.com/blog/claude-code-permission-decision-log/

Le contenu tient en ceci.

import { execSync } from "node:child_process";

// Vérifier l'URL publique passée en argument
const url = process.argv[2];
if (!url) {
  console.error("Passez l'URL publique à vérifier");
  process.exit(1);
}

// 1. Vérifier que le build passe (s'il échoue ici, on ne publie pas)
try {
  console.log("Vérification du build...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("Le build a échoué. On arrête la publication.");
  process.exit(1);
}

// 2. Vérifier qu'il y a bien un seul titre h1 sur l'URL publique
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`Impossible d'ouvrir l'URL (code d'état : ${res.status}). On revoit la publication.`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`Il y a ${h1Count} titres h1. On corrige pour n'en avoir qu'un avant de publier.`);
  process.exit(1);
}

console.log("Build, URL et titre vérifiés. La publication est sûre.");

Ce n’est qu’une fois ce script au vert qu’on autorise « publier ». À l’inverse, ce qui ne passe pas au vert n’est jamais publié, quoi qu’il arrive. L’astuce, c’est de confier la décision non pas à l’humeur de l’humain, mais au verdict de la machine.

Les erreurs fréquentes et comment les corriger

Pour être honnête, je les ai toutes commises.

Changer la configuration sans noter la raison. Si on met seulement à jour le fichier de configuration sans garder « pourquoi on l’a fait ainsi », le soi du lendemain refait les mêmes hésitations. La correction est simple : écrire une seule ligne de raison dans la « note pour la prochaine fois » du journal. Par exemple « les prix touchent directement à la confiance, donc ils restent en demander ».

Autoriser la publication sur l’élan. Sur l’élan d’un build qui passe, on autorise tout jusqu’à la publication. Mais la vérification avant publication, c’est autre chose. On fige dans « à vérifier » les points à regarder — titre de l’URL de production, affichage cassé, rendu mobile — et on ne publie pas avant d’avoir passé la vérification par la machine.

Traiter pareil les tâches légères et les tâches lourdes. Si on fait tourner sous le même « autoriser » la correction de fautes dans le corps et la modification d’un lien d’inscription ou d’un prix, l’accident du début finira par arriver. Les travaux qui touchent aux liens gumroad, aux prix ou aux formulaires, on les range sur une étagère séparée de la correction de fautes. Cette frontière, en l’écrivant comme règle dans l’écriture du CLAUDE.md, on n’a plus à y réfléchir à chaque fois.

FAQ

Q. Quelle différence entre le journal de validation et la configuration de sécurité ? R. La configuration de sécurité fige « ce qu’on autorise » ; le journal de validation garde « pourquoi on a pris cette décision aujourd’hui ». La configuration tient de la règle, le journal du carnet de bord. Avec les deux, le soi du lendemain ou l’équipe peuvent reproduire la même décision.

Q. Écrire tous les jours, c’est pénible. Comment tenir ? R. En ne visant pas la perfection. Au début, deux colonnes seulement — « modifier » et « publier » — suffisent largement. Mettez-le sous une forme qui s’écrit en deux à trois minutes, et prenez l’habitude de le coller comme toute première saisie avant de commencer le travail : ça tient dans la durée.

Q. Peut-on faire confiance au classement que l’IA propose ? R. Comme brouillon, c’est pratique, mais la décision finale revient à l’humain. En particulier, les lignes touchant aux prix, à la production ou à la suppression : même si l’IA dit « on peut autoriser », on les redescend soi-même en « demander ». Le but est d’alléger l’effort de décision, pas de déléguer la décision elle-même.

Q. Quelles précautions en équipe ? R. Rassembler le journal en un seul endroit et écrire, pour chaque opération mise en « autoriser », une raison qui donnera la même décision à quiconque la lit. Une autorisation sans raison s’interprète différemment selon les personnes et devient une source d’accidents. Pour élargir progressivement les validations, la montée en autonomie en toute sécurité est aussi une bonne référence.

Q. Faut-il vraiment aller jusque-là pour un petit blog ? R. Plus l’échelle est petite, plus un accident sur les prix ou les liens frappe directement le chiffre d’affaires. Au contraire, c’est l’individu ou la petite équipe qui a le plus intérêt à commencer par une seule règle : « l’argent et la production, on demande ».

Liens de référence

• Guide des permissions Claude Code
• Guide de démarrage Claude Code
• Documentation officielle Anthropic : Claude Code settings

Ce que j’ai constaté à l’usage

Après environ deux semaines avec ce journal de validation, ce qui a le mieux marché, c’est étonnamment les « tâches légères ». La correction de fautes, je peux la mettre en « autoriser » l’esprit tranquille ; les prix, les liens, le formulaire d’inscription et les paramètres de publication, eux, restent en « demander ». Rien qu’en écrivant cette distinction à l’avance, l’effort de me redemander « cette tâche, j’avais le droit de l’autoriser ? » après chaque réponse de l’IA a disparu.

Là où l’hésitation revenait le plus, c’était bien « exécuter » et « publier ». Le build, on peut l’autoriser ; mais publier sans avoir vérifié l’URL de production, c’est encore trop tôt. Une fois que j’ai vérifié de mes yeux le titre, l’affichage cassé et le rendu mobile, j’ai pu faire monter le même type de publication en « autoriser » pour la fois suivante. Comme les paliers restent ainsi dans la trace écrite, le journal de validation se vit moins comme un document de sécurité austère que comme une note pour alléger les décisions du quotidien : c’est, à l’usage, la façon la plus réaliste de l’employer.

Si vous voulez régler la frontière des permissions pour votre propre équipe, ou caler ensemble les règles de mise en production, on peut le traduire en exploitation concrète lors d’un accompagnement ou d’une consultation.