Claude Code : jusqu'où le laisser faire ? La règle des 4 niveaux d'autonomie

Un vendredi soir, j’ai demandé à Claude Code « corrige juste les liens morts dans les vieux articles du blog » avant d’aller me coucher. Le lendemain matin, en regardant l’historique des commits, j’ai découvert que 12 articles avaient été réécrits. Les liens étaient bien corrigés. Mais au passage, les formulations des titres avaient été « harmonisées », et certaines tournures anciennes que j’avais gardées volontairement avaient été écrasées.

Il m’a fallu deux heures pour tout remettre en état. Pourquoi Claude Code, censé être intelligent, en fait-il toujours un peu trop ? La réponse est simple : je ne lui avais jamais dit « jusqu’où » il avait le droit d’aller.

J’ai aussi vécu le scénario inverse. Pris de panique, j’ai configuré l’agent pour qu’il me demande « je peux exécuter ça ? » à chaque ligne modifiée. Au bout de 30 minutes, j’étais épuisé d’appuyer sur le bouton de validation, et il était finalement plus rapide d’écrire le code moi-même. Trop déléguer et provoquer un accident, ou trop bloquer et s’épuiser : beaucoup de gens se perdent entre ces deux extrêmes.

Cet article raconte comment sortir de cette impasse grâce à une « échelle d’autonomie à 4 niveaux ». Lire seulement, modifier, publier, et la zone réservée aux humains : si vous tracez ces quatre frontières dès le départ, la décision disparaît presque à chaque fois.

Points clés

• Les tâches confiées à Claude Code se classent en 4 niveaux selon leur danger, ce qui rend la décision beaucoup plus simple : lecture seule / édition réversible / publication & déploiement / réservé à l’humain.
• Chaque niveau doit avoir une « preuve que c’est terminé » : un diff apparaît, le build passe, l’URL publique est correcte, etc.
• Suppression, données de production, facturation et force push ne deviennent jamais automatiques, même avec l’habitude. Ici, c’est l’humain qui appuie à chaque fois.
• Écrivez les niveaux dans un seul fichier YAML placé à côté de CLAUDE.md : Claude Code pourra alors déclarer lui-même « à quel niveau je me trouve ».
• Commencez toujours un cran plus bas, puis montez en niveau uniquement les opérations que vous avez vérifiées comme sûres. Jamais l’inverse.

Pourquoi la « frontière » compte plus que « l’intelligence »

La plupart des gens qui trébuchent avec Claude Code n’échouent pas à cause des performances du modèle, mais à cause de la manière dont ils délimitent la tâche. C’était mon cas dans l’histoire ci-dessus. L’instruction en elle-même n’était pas mauvaise. Mais le périmètre « seulement les liens » n’était transmis que par une phrase. Une demande formulée en prose, c’est comme une consigne orale lancée à un collègue débordé un matin chargé : l’interprétation dérape facilement.

C’est là qu’une frontière fondée sur le danger devient utile. Décidez ce qui est autorisé non pas par « le texte de la demande » mais par « le niveau ». À chaque fois que Claude Code s’apprête à faire quelque chose, vous pouvez confronter l’action à la question « à quel niveau correspond cette opération ? ». Le débat flou sur l’interprétation d’une phrase se transforme en une vérification mécanique.

Cette idée n’a rien de nouveau. Dans une usine, le visiteur, l’ouvrier qui assemble les pièces, celui qui appuie sur le bouton d’expédition et celui qui ouvre le coffre-fort ont des droits séparés dès le départ. Il suffit de tracer la même ligne pour Claude Code.

Le contenu des 4 niveaux

Voici les 4 niveaux que j’utilise réellement. Le tableau donne d’abord une vue d’ensemble.

Niveau	Ce qu’on lui confie	Preuve que c’est terminé
0 lecture seule	Comprendre la structure des fichiers, repérer les risques, proposer des commandes de vérification	La note finale contient « la liste des fichiers lus »
1 édition réversible	Corriger un article, mettre à jour un test	Un diff apparaît et le build passe
2 publication & déploiement	Déployer après le build, vérifier l’URL publique	h1, URL canonique, CTA et procédure de rollback sont réunis
3 réservé à l’humain	(on ne le confie pas à Claude Code)	—

Entrent dans le niveau 3 : clés secrètes, facturation, données de production et force push. Quelle que soit l’habitude, on n’automatise pas. La perte en cas d’erreur ne vaut pas l’effort économisé.

L’essentiel à chaque niveau, c’est de toujours fixer une « preuve que c’est terminé ». Sans preuve, même si Claude Code annonce « c’est fait », vous ne savez pas si c’est vraiment fini. Un diff qui apparaît, un build qui passe, une URL publique qu’on ouvre et dont le h1 est correct : choisissez comme preuves des éléments vérifiables par une machine.

Ce qu’on délègue à l’IA et ce que l’humain décide

Une fois la frontière claire, la répartition des rôles se décide naturellement.

On peut confier à Claude Code les tâches répétitives dont le résultat se vérifie mécaniquement. Lire des dizaines de fichiers et les résumer, corriger un article selon un format fixe, lancer des tests et lire les logs. Sur ce terrain, il est plus rapide et plus précis qu’un humain.

L’humain doit décider des choix irréversibles et des opérations à forte perte. Faut-il vraiment publier cet article ? Peut-on supprimer cette vieille tournure ? Peut-on écraser ces données client ? Ici, Claude Code peut « proposer », mais c’est l’humain qui appuie pour « exécuter ».

En cas de doute, un seul critère : « En cas d’échec, puis-je revenir en arrière en 10 minutes ? » Si oui, c’est le niveau 1 ; si non, c’est le niveau 2 ou 3. Mon accident du début a mis deux heures à être réparé : c’était en réalité une tâche qui exigeait la prudence du niveau 2.

Une définition des niveaux prête à copier

Si les niveaux restent uniquement dans votre tête, ça finit par déraper. Écrivez-les dans un seul fichier YAML, placé à la racine du projet sous le nom autonomy.yml. En le faisant référencer depuis CLAUDE.md, Claude Code se met à déclarer de lui-même « comme je suis au niveau 1, je ne publie pas ».

# autonomy.yml — la frontière d'autonomie passée à Claude Code
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["comprendre la structure des fichiers", "repérer les risques", "proposer des commandes de vérification"]
    proof: "la note finale contient la liste des fichiers lus"
  level_1_reversible_edit:
    allowed: ["corriger un article", "mettre à jour un test"]
    proof: "git diff apparaît et le build passe"
  level_2_publish_or_deploy:
    allowed: ["déployer après le build", "vérifier l'URL publique"]
    proof: "h1, URL canonique, CTA et procédure de rollback réunis"
  level_3_owner_only:
    allowed: []
    examples: ["clés secrètes", "facturation", "force push", "données client"]

Dans CLAUDE.md, il suffit d’ajouter une seule phrase.

Avant de travailler, lis autonomy.yml et déclare d'abord à quel niveau correspond la tâche.
Pour les opérations de niveau 2 ou plus, n'exécute pas et attends la validation d'un humain.

Le script de vérification qui contrôle le niveau par machine

Faire déclarer le niveau ne me rassure pas totalement, alors je surveille par machine que « les opérations de niveau 2 (publication) ne se font pas sans preuve ». Le script ci-dessous va chercher l’URL publique après le déploiement et vérifie que le h1 n’est pas vide et que l’URL canonique pointe bien vers votre slug. Avec Node.js 18 ou plus récent, il fonctionne tel quel.

// verify-publish.mjs — vérifier par machine la « preuve » du niveau 2
// Usage : node verify-publish.mjs https://claudecode-lab.com/blog/votre-slug

const url = process.argv[2];
if (!url) {
  console.error("Passez l'URL publique en argument");
  process.exit(1);
}

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status} : pas encore publié`);
  process.exit(1);
}

const html = await res.text();

// Le h1 existe-t-il avec un contenu ?
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// L'URL canonique pointe-t-elle vers cette page elle-même ?
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`h1 présent :       ${hasH1 ? "OK" : "NON"}`);
console.log(`URL canonique OK : ${canonicalOk ? "OK" : "NON"}`);

if (hasH1 && canonicalOk) {
  console.log("Preuves du niveau 2 réunies. La publication est considérée comme terminée.");
} else {
  console.error("Preuves insuffisantes. Ne considérez pas la tâche comme terminée.");
  process.exit(1);
}

Si vous croyez que le seul HTTP 200 suffit, vous ne remarquerez pas qu’une page de repli ou un vieil article s’affiche à la place. Ce n’est qu’après avoir vérifié le h1 et l’URL canonique qu’on peut dire « ce niveau est terminé ».

Trois situations où ça fait la différence

1. Juste après être entré dans un nouveau dépôt Si vous lui faites éditer d’emblée sans qu’il connaisse ni la structure ni les commandes, il a vite fait de casser un fichier de configuration. Au début, n’autorisez que le niveau 0 et faites-lui rapporter la structure des fichiers, les commandes disponibles et les endroits dangereux à toucher. Une fois la carte établie, montez au niveau 1.

2. Correction de coquilles dans un article Là, le niveau 1 suffit. Dès qu’un diff apparaît et que le build passe, la preuve est complète. Mon accident du début aurait été évité si j’avais écrit ici « les corrections concernent uniquement les coquilles, ne change pas les tournures ». Voici un modèle de demande à passer à Claude Code.

Travaille au niveau 1.
Cible : uniquement les coquilles évidentes dans content/blog/foo.mdx
À ne pas faire : reformuler les titres, modifier les tournures, éditer d'autres fichiers
À la fin, montre-moi git diff et vérifie toi-même que les changements ne sont que des corrections de coquilles.

3. Juste avant une mise en production Au niveau 2, faites toujours vérifier que le build passe, que les variables d’environnement sont réunies, que le diff est conforme aux attentes et qu’une procédure de rollback existe. En lançant le script de vérification ci-dessus à la fin, vous contrôlez jusqu’au contenu de l’URL publique.

Trois ratés que j’ai commis

Pour être honnête, j’ai eu plusieurs accidents avant d’arriver à ces 4 niveaux.

Le premier : avoir sauté des niveaux d’un coup. En omettant le niveau 0 pour faire d’emblée une grosse édition au niveau 1, j’ai obtenu un diff si énorme qu’il était invérifiable, et je ne savais même plus ce qui était correct. Désormais, je monte toujours dans l’ordre à partir de 0.

Le deuxième : avoir considéré le seul build local comme « terminé ». Comme ça passait en local, j’ai publié. Mais en production, une vieille page s’affichait, et je ne m’en suis aperçu qu’au bout d’une demi-journée. Depuis, je ne considère rien comme terminé tant que je n’ai pas vu le h1 et l’URL canonique de l’URL publique.

Le troisième : avoir compté uniquement sur mes propres yeux pour valider. Le « je vérifierai à la fin » échoue toujours un soir où l’on est fatigué. Depuis que j’ai intégré dans la « preuve » de chaque niveau des contrôles vérifiables par machine — nombre de caractères, liens morts, erreurs de typage — les oublis nocturnes ont fortement diminué.

Comment démarrer

Ne visez pas tout de suite un agent intelligent et entièrement automatique. Choisissez une petite tâche réversible même en cas d’échec. Vérifier les coquilles d’un brouillon, faire une première relecture des changements, contrôler avant une publication en staging. Ce niveau-là est juste ce qu’il faut.

L’ordre est toujours le même. (1) délimiter étroitement le périmètre de lecture → (2) clarifier le livrable → (3) confier autant que possible la vérification à des commandes → (4) au début, mettre toutes les opérations dangereuses (suppression, données de production, facturation, force push) sur « demander à l’humain ». Ensuite seulement, montez d’un cran à la fois les opérations vérifiées comme sûres. On ne fait jamais l’inverse, on ne rétrograde pas.

Si vous butez sur le réglage fin des permissions, lisez d’abord Bien démarrer avec Claude Code ; pour écrire les règles de niveaux dans CLAUDE.md, voyez Comment écrire un bon CLAUDE.md : ces 4 niveaux se traduisent alors directement en configuration. Si vous prévoyez d’intégrer des personnes non techniques à l’équipe, l’usage pour les non-ingénieurs complétera le tout.

FAQ

Q. Faut-il configurer le découpage en niveaux à la main à chaque fois ? Non. Créez un seul autonomy.yml et faites-le référencer depuis CLAUDE.md : ensuite, Claude Code déclare de lui-même « je suis au niveau 1 ». La configuration ne se fait qu’une seule fois au départ.

Q. Peut-on automatiser jusqu’à la « publication » du niveau 2 ? Si la preuve se réunit par machine, vous pouvez l’automatiser une fois l’habitude prise. Mais intercalez toujours un mécanisme qui vérifie le contenu de l’URL publique, comme le script de vérification ci-dessus. Croire uniquement au HTTP 200 est ce qu’il y a de plus dangereux.

Q. Comment repérer les opérations à placer en niveau 3 ? Pensez « en cas d’échec, suffit-il de s’excuser, ou faut-il dédommager ? ». Écraser des données client, la facturation, une suppression en production relèvent du second cas, donc du niveau 3. On ne les automatise pas, même avec l’habitude.

Q. Une petite équipe a-t-elle besoin de frontières ? Au contraire, c’est d’autant plus efficace que l’équipe est réduite. Comme il est facile de ne plus savoir qui a validé, partager le tableau des niveaux permet de voir d’un coup d’œil « qui donne le feu vert pour telle opération ».

Q. Avec de bons prompts, le découpage en niveaux n’est-il pas inutile ? Les prompts laissent place à l’interprétation. La capacité à écrire de bonnes demandes se travaille à part avec la pratique des prompts, mais le découpage en niveaux est un « filet de sécurité qui ne dépend pas de l’habileté de rédaction ». Les deux ensemble forment la combinaison la plus solide.

Ce que j’ai constaté en l’essayant

Depuis que j’ai intégré ces 4 niveaux à la gestion de mon blog, les accidents du type « on fait des choses que je n’ai pas demandées » ont totalement disparu. J’ai vérifié deux points.

D’abord, en faisant référencer autonomy.yml depuis CLAUDE.md, Claude Code s’est mis à déclarer de lui-même, avant de travailler, « cette fois je suis au niveau 1, donc je ne publie pas ». J’ai constaté concrètement qu’en transmettant la frontière par niveaux plutôt que par une phrase, l’interprétation ne dérape plus.

Ensuite, en lançant systématiquement verify-publish.mjs après la publication, j’ai pu détecter juste après la mise en ligne le phénomène de « vieille page affichée en production » qui m’avait échappé pendant une demi-journée par le passé. Il suffit de regarder le h1 et l’URL canonique pour combler le piège du HTTP 200.

Plutôt que de chercher un modèle plus intelligent, décidez d’abord les niveaux qui vous évitent de vous blesser en tombant. Ça semble un détour, mais c’est en réalité le chemin le plus rapide, c’est ce que je ressens aujourd’hui. Si vous en êtes à vouloir mettre en ordre les règles de permissions de Claude Code en équipe, on peut concevoir ensemble ces frontières en formation et conseil. Pour la configuration officielle des permissions, consultez aussi la documentation d’Anthropic.