Jusqu'où laisser Claude Code aujourd'hui ? La feuille des 4 niveaux d'approbation

Un vendredi en fin d’après-midi, je voulais juste pousser une petite correction sur l’environnement de préproduction.

Je lui avais seulement demandé : « Corrige la faute de frappe dans la doc, et au passage vérifie que le build passe. » Claude Code a corrigé la faute, puis a mis à jour deux dépendances de son propre chef, et a même réécrit la référence à .env.production. Comme le build local passait, lui (l’IA) affichait un air tranquille : « C’est terminé. »

Ce qui m’a glacé, c’est de ne m’en être rendu compte qu’en lisant le diff jusqu’au bout. Ce n’est pas que l’IA soit fautive : je n’avais jamais mis en mots « jusqu’où elle avait le droit d’aller ».

À l’inverse, un autre jour, le « Autoriser ? Oui/Non » est apparu une trentaine de fois d’affilée, et j’ai épuisé toute mon énergie rien que pour créer un seul commit. Trop large, et ça déraille ; trop serré, et ça n’avance plus. Cet article parle d’une feuille unique pour tracer la bonne ligne entre les deux.

Points clés

• On découpe le travail confié à Claude Code en 4 niveaux : « juste lire », « juste corriger », « publier », « toucher à des informations sensibles ».
• Pour chaque niveau, on décide à l’avance « qui donne le dernier feu vert » et « quelle preuve permet de dire que c’est sûr ».
• Les niveaux 0 et 1 sont confiés à l’IA, le niveau 2 demande une validation humaine, le niveau 3 reste entre les mains de la personne responsable.
• Déclarer le matin, en une phrase, « aujourd’hui on va jusque-là » fait chuter d’un coup le nombre d’approbations.
• Un registre prêt à copier-coller et un gabarit qui se décide en une minute chaque matin.

Pourquoi décider d’abord son « budget d’approbation »

Ce qui vous épuise dans les approbations, ce n’est pas la performance de Claude Code. C’est de démarrer sans avoir décidé jusqu’où on l’autorise aujourd’hui.

Sans décision claire, on bascule dans l’un des deux excès. Par flemme, on appuie sur « Autoriser » à tout, et un jour on laisse passer une opération dangereuse. Ou bien on devient trop prudent, on glisse une confirmation jusque sur les corrections de fautes, et le travail n’avance plus. Dans les deux cas, on confie la décision à « l’humeur du moment ».

D’où l’idée du « budget d’approbation ». Comme un budget en euros : on fixe à l’avance que jusqu’à cette voie c’est libre aujourd’hui, au-delà c’est l’humain qui tranche. Avec ce cadre, plus besoin d’avoir le cœur qui bat à chaque réponse de l’IA. Ce qu’il faut regarder, ce n’est pas « l’IA est-elle intelligente ? » mais « à quelle voie s’est-elle arrêtée ? ».

Mettre les critères de décision en mots évite aussi les frictions en équipe. On ne dit plus « j’ai arrêté parce que ça m’inquiétait vaguement », mais « c’est du niveau 2, donc c’est au tour de l’humain de vérifier ». La logique de conception des permissions est abordée dans le guide de démarrage Claude Code, mais ici on se concentre sur quelque chose de plus terre à terre : « la ligne du jour ».

Découper le travail confié en 4 niveaux

D’abord, on trie le travail qu’on veut confier à Claude Code selon son danger, en 4 niveaux. Pas besoin de se compliquer la vie : on classe uniquement selon « est-ce réversible ? », « est-ce publié ? », « est-ce que ça touche à l’argent ou aux secrets ? ».

Niveau	Exemple de travail	Qui donne le feu vert	Preuve que c’est sûr
0	Lire des fichiers, comprendre la structure	Confié à l’IA	Liste de ce qui a été lu
1	Corriger 1 fichier réversible	L’IA (l’humain lit le diff)	Diff et résultat du build
2	Mettre en ligne sur le site public	L’humain décide	URL publiée et procédure de rollback
3	Toucher secrets, facturation, données clients	Le responsable uniquement	Approbation écrite

Le cœur de ce tableau, ce sont les deux colonnes de droite. « Qui donne le feu vert » et « quelle preuve permet de dire que c’est sûr », on les décide avant de commencer. Si on décide après coup, on se laisse emporter par l’élan du « C’est terminé » de l’IA et on saute la vérification.

Le point clé du niveau 1, c’est « réversible ». Une faute corrigée ou un commentaire ajouté, même mal fait, ça se rétablit aussitôt. Donc on le confie à l’IA et l’humain n’a qu’à jeter un œil au diff. En revanche, la mise à jour de dépendances passe au niveau 2. Ça paraît anodin, mais on ne mesure pas l’étendue de son impact. Mon incident du début venait précisément de l’avoir traité comme du niveau 1.

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

Précisons un peu plus la ligne. Ce qu’on peut confier à l’IA, ce sont les tâches où une erreur se repère vite et se rétablit vite. Ce que l’humain doit décider, ce sont les tâches qui, une fois exécutées, ont un impact vers l’extérieur.

• À confier à l’IA : lire, chercher, rédiger un brouillon, corriger 1 fichier réversible, lancer les tests.
• À faire trancher par l’humain : publier, modifier des données de production, s’inscrire à un service externe, mettre à jour des dépendances, supprimer.

En cas de doute, on monte d’un niveau. Retenez juste ça et vous ne vous tromperez pas gravement. Seules les opérations dont on est devenu certain de la sûreté, on les redescend d’un cran ensuite pour les automatiser. L’astuce, c’est de ne pas viser le tout-automatique dès le départ. Cette logique de « promotion progressive » se marie bien avec les bonnes pratiques CLAUDE.md : notez votre ligne dans le fichier de règles du projet pour la rejouer à l’identique.

Un registre d’approbation prêt à copier-coller

Avec des mots seuls, on finit par oublier. Alors on met les 4 niveaux sous une forme lisible par la machine, pour pouvoir afficher « jusqu’où aujourd’hui » avec un filtre. Si Node.js est installé, ça tourne tel quel.

// Registre d'approbation : chaque action porte son « niveau de danger », son responsable et sa preuve
const approvalBudget = [
  { action: "Lire des fichiers",            level: 0, owner: "IA",            proof: "Liste de ce qui a été lu" },
  { action: "Corriger 1 fichier réversible", level: 1, owner: "IA (humain vérifie)", proof: "Diff et résultat du build" },
  { action: "Mettre en ligne sur le site",  level: 2, owner: "Humain",        proof: "URL publiée et procédure de rollback" },
  { action: "Toucher secrets ou facturation", level: 3, owner: "Responsable uniquement", proof: "Approbation écrite" },
];

// Plafond du jour. 0 = juste lire ; 1 = on confie à l'IA jusqu'aux corrections réversibles
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`Plafond confié à l'IA aujourd'hui : niveau ${todayMax}`);
console.table(allowedToday);
console.log("Travail à faire trancher par l'humain :");
console.table(needsHuman);

L’exécution se résume à ceci. La variable d’environnement permet de basculer le « plafond du jour ».

# Aujourd'hui, on confie jusqu'aux « corrections réversibles »
APPROVAL_MAX=1 node approval-budget.mjs

# Aujourd'hui, on se contente de lire
APPROVAL_MAX=0 node approval-budget.mjs

Gardez les noms de colonnes tels quels, et adaptez le contenu de action et proof à votre propre projet. Donnez ce code à Claude Code en lui demandant « remplis les valeurs pour mon dépôt », et vous aurez une première version tout de suite.

Le gabarit de prompt qui se décide en une minute chaque matin

Une fois le registre prêt, avant de commencer, vous transmettez à l’IA « le cadre du jour ». Copiez le texte suivant et remplissez les blancs.

Je fixe d'abord le cadre du travail d'aujourd'hui.

- Objectif du jour : (ex : corriger fautes et liens cassés sur 1 article de blog)
- Périmètre de lecture autorisé : uniquement site/src/content/blog/
- Périmètre de correction autorisé : un seul fichier ci-dessus (modifications réversibles uniquement)
- Commandes autorisées : npm run lint, lancer les tests
- À ne pas toucher : .env, déploiement en production, mise à jour de dépendances, suppression

Règles :
- Pour tout niveau 2 ou plus (publication, données de prod, mise à jour de dépendances, suppression), arrête-toi et demande-moi confirmation.
- Après correction, montre à la fin le diff et le résultat du build comme « preuve ».
- Ne te contente pas d'un « C'est terminé » : écris avec quelle commande tu as vérifié.

Cette simple phrase suffit pour que l’IA arrête le « je fais tout, tant qu’à faire » et reste dans le cadre. Une fois à l’aise, déplacez ce contenu dans le fichier de règles du projet selon les bonnes pratiques CLAUDE.md, et la corvée de coller le texte chaque matin disparaît.

Là où ça fait la différence (3 cas)

1. Le contrôle de la production en série d’articles ou de supports Avec un simple « corrige l’article », l’IA réécrit d’un bloc le texte, les chemins d’images et les liens. Avec le registre, en séparant « les fautes du texte = niveau 1, la mise en ligne = niveau 2 », vous confiez le texte tout en gardant le bouton de publication dans votre main. Exigez le diff et le résultat du build comme preuve, et la relecture du soir devient nettement plus légère.

2. Le tri des demandes entrantes Lire une demande reçue et la classer, c’est du niveau 0 : on peut le confier à l’IA. Mais l’enregistrer dans le fichier clients, c’est du niveau 3. Même si l’IA juge « ça sent l’opportunité commerciale », l’écriture dans la base de production reste en attente jusqu’à ce que le responsable appuie sur le bouton. Imposez ça via le registre, et l’incident du client mal classé enregistré tout seul disparaît.

3. La respiration avant le déploiement La mise en ligne va toujours au niveau 2. On ne déclare pas « terminé » juste parce que le build local passe : on s’arrête jusqu’à avoir vérifié l’URL publiée, le titre et la procédure de rollback. Mon dérapage du début, la « mise à jour de dépendances sans prévenir », se serait forcément arrêté à la vérification humaine si le niveau 2 avait été explicite.

Pièges fréquents et comment les corriger

Le plus courant : vouloir tout boucler en une seule demande, et produire un diff géant que personne ne peut vérifier. La correction est simple : limiter chaque demande à « un seul livrable à la fois ». Un article, une PR, un réglage. En découpant petit, on lit le diff jusqu’au bout.

Vient ensuite : considérer le travail terminé sur la seule réussite du build local. Sur le site public, c’est une autre page ou l’accueil qui s’affiche, mais on se rassure en ne voyant que le HTTP 200. Inscrivez « vérifier l’URL publiée et le titre » dans la colonne preuve, et vous vous arrêterez ici.

Le troisième : ne garder aucune trace de ce qu’on a essayé. Le lendemain, on refait la même décision de zéro. Une seule ligne de note (voir plus bas) suffit pour que le vous du lendemain n’hésite plus. Pour hausser d’un cran la façon même de demander à Claude Code, lisez aussi la conception de prompts en pratique : la manière de transmettre le cadre s’affine encore.

FAQ

Q. Faut-il découper les niveaux d’approbation plus finement ? Au début, 4 niveaux suffisent. Plus on en ajoute, plus l’exploitation se complique, et au final plus personne ne les respecte. Faites tourner, et ne ramifiez ensuite que les endroits que vous trouvez « trop grossiers ».

Q. Le « réversible » du niveau 1, comment le repérer ? Sur deux critères : « est-ce que git le rétablit en une commande ? » et « est-ce que ça a un impact vers l’extérieur ? ». Une édition de fichier se rétablit, mais un déploiement, une facturation, un envoi d’e-mail ou une suppression ne se rétablissent pas. En cas de doute, on monte au niveau 2.

Q. En équipe, qui décide les niveaux ? La personne qui commence le travail le déclare le matin, et on a désigné à l’avance les décideurs des niveaux 2 et plus. Si le responsable est absent, on décide de ne pas faire de niveau 3 ce jour-là : c’est plus sûr.

Q. Coller le prompt à chaque fois est pénible. Une fois le cadre stabilisé, déplacez-le dans le fichier de règles du projet (CLAUDE.md). L’IA le lit à chaque fois, donc le copier-coller devient inutile.

Q. Cette feuille marche-t-elle même pour les non-développeurs ? Oui. Sans même lancer le code, le tableau des 4 niveaux et le gabarit de prompt suffisent à tracer la ligne. Pour les usages hors développement, voyez aussi Claude Code pour les non-développeurs.

Une note pour la transmission

Garder en une ligne la décision du jour évite que le vous du lendemain ou l’équipe ne refasse les mêmes hésitations. Copiez le format suivant et remplissez-le.

- Date : 2026-06-07
- Objectif du jour : corriger fautes et liens cassés sur 1 article de blog
- Plafond du jour : niveau 1 (jusqu'aux corrections réversibles)
- Preuve : diff, log de npm run build, vérification du titre sur l'URL publiée
- Où l'humain a arrêté : mise à jour de dépendances (en attente car niveau 2)
- À transmettre pour la suite : grouper les mises à jour de dépendances un autre jour, en niveau 2

Avec cette note, la vérification après publication devient simple aussi. Le HTTP 200 ne suffit pas : sur l’URL publiée, on vérifie que le titre, l’URL canonique (canonical), la vignette et le début du texte correspondent bien à cet article. Si c’est un autre article ou l’accueil qui s’affiche, on considère l’article comme non publié et on relance build et déploiement. La logique officielle de conception des permissions se vérifie aussi dans la documentation officielle d’Anthropic.

Ce que j’ai constaté en l’essayant

J’ai appliqué cette feuille à la gestion de mon propre blog pendant deux semaines.

Ce qui a le plus marché, c’est de coller le matin la phrase « aujourd’hui on va jusqu’au niveau 1 ». Rien que ça, et le « Autoriser ? » par commit a ressenti comme divisé par deux au moins. Quand l’IA s’apprête à franchir le niveau 2, elle s’arrête bien selon la règle du gabarit et me pose la question. Les incidents du genre « tiens, les dépendances ont été mises à jour » comme au début : zéro depuis.

À l’inverse, j’ai compris que le tableau des niveaux, juste créé, on ne s’en sert pas. C’est en lançant vraiment le code du registre pour afficher à l’écran « le travail confié aujourd’hui » avant de démarrer que la probabilité de tenir la ligne monte. Plutôt que de chercher une IA plus intelligente, tracer d’abord un cadre où l’on peut se relever après une chute. C’est discret, mais c’est ce qui me permet aujourd’hui de déléguer avec le moins de stress.

Pour étendre cette ligne à toute l’équipe ou à l’exploitation en production, on peut affiner ensemble la conception concrète des voies en formation et conseil. Pour commencer, essayez dès demain matin de coller la phrase « aujourd’hui on va jusqu’au niveau 1 ».