Le mode auto devient le défaut de Claude Code. La relecture manuelle était déjà du théâtre.

La relecture manuelle était déjà du théâtre

On répète à nos clients depuis deux ans que les prompts de permission sont le filet de sécurité des outils de code agentiques — ce qui empêche un agent AI de lancer le rm -rf qu'il ne devrait pas lancer. Les chiffres qu'Anthropic vient de publier disent que ce filet était surtout décoratif.

Les développeurs approuvent 97% des prompts de permission de Claude Code. Pas "relisent puis approuvent" — approuvent, par réflexe, comme on clique sur une bannière de cookies.

C'est la donnée derrière le plus gros changement Claude Code depuis des mois : à partir du 14 août, le mode auto devient le mode de permission par défaut pour les plans Pro, Max et Team. Le mode auto, c'est le réglage où un classifieur décide quels appels d'outil s'exécutent sans intervention et n'escalade que ceux qu'il juge risqués, au lieu de vous poser la question à chaque fois.

Et il n'arrive pas seul. La même semaine a ajouté un moyen pour les sessions Claude Code de se parler entre elles, et fait passer l'exécution self-hosted en beta publique. Trois changements, une seule direction : moins de friction humaine dans la boucle, plus d'exécution autonome et coordonnée.

Les chiffres derrière le basculement

L'écart 39% / 3% est le tell. Quand Claude présente un plan complet, les développeurs le rejettent 39% du temps — on scrute vraiment une décision quand elle est visible et rare. Mais les permissions d'appel d'outil individuelles, celles qui se déclenchent des dizaines de fois par heure, sont rejetées 3% du temps.

Relire un plan est une décision. Relire un prompt de permission est un réflexe.

Les données de configuration disent la même chose sous un autre angle. En juin 2026, 49,5% des utilisateurs CLI actifs avaient déjà écrit une règle d'autorisation Bash à la main : 5% autorisent n'importe quelle commande shell sans distinction, 43% de plus ont écrit des règles d'interprète type Bash(python:*) qui reviennent au même en pratique. Cette part grimpe d'environ 5 points de pourcentage toutes les 5 semaines.

Personne n'attendait qu'Anthropic retire les prompts. Les gens contournaient déjà, à la main, une règle d'autorisation à la fois.

Anthropic a donc fait la comparaison proprement : red-teaming interne et tiers, évaluations d'injection de prompt, une étude contrôlée avec 1 053 testeurs professionnels payés, et une analyse de sessions de production réelles. Dans l'étude contrôlée, une commande réellement dangereuse était substituée dans le texte du prompt vu par les testeurs. Ils l'ont repérée 143 fois sur 1 053 — 13,6%. Le classifieur du mode auto en a bloqué 937 sur les mêmes 1 053 — 89%.

En tête-à-tête, le mode auto a bloqué 800 commandes que les humains ont laissées passer.

Lisez aussi la mise en garde, parce qu'Anthropic la pose noir sur blanc : le taux de raté de 7% vient d'un jeu construit spécifiquement pour être adversarial et "ne doit pas être pris pour le taux de raté sur du trafic réel". C'est la comparaison de deux relecteurs faillibles, pas la preuve que l'un des deux est sûr.

Ce que le classifieur voit vraiment

Le plus intéressant n'est pas le score du classifieur. C'est ce à quoi il a accès et qu'une boîte de dialogue de permission n'a jamais eu.

• L'état du dépôt. Avant une commande qui détruirait du travail non commité — git reset --hard et consorts — le classifieur lit le git status courant. Il sait ce que vous êtes sur le point de perdre. La boîte de dialogue, elle, n'a jamais connu que la chaîne de caractères de la commande.
• La sortie des outils, pas seulement leur entrée. Quand Claude récupère une page web, un fichier ou un résultat d'outil, une sonde côté API scanne ce contenu à la recherche d'instructions qui tentent de détourner la session. L'injection de prompt arrive dans les résultats — et les résultats n'ont jamais été ce que vous approuviez.
• De la pression adversariale avant la sortie. Anthropic a mené un pilote de deux semaines avec Apollo Research, en injectant des attaques synthétiques dans de vraies trajectoires de code, sur trois jeux de données couvrant les défaillances larges, l'exfiltration de données et les menaces liées à la sûreté, en boucle find-fix-verify.
• Des tests d'injection indépendants. Dans une évaluation tierce de 72 scénarios d'injection de prompt indirecte joués 10 fois chacun — 720 tentatives — aucune n'a réussi contre les modèles Claude en mode auto, contre 5,83% de réussite face à GPT-5.6 Sol dans le mode Auto-review de Codex. Ces deux chiffres décrivent des modèles précis dans un harnais précis à une date précise, pas un classement permanent.

Le mode auto garde aussi un plancher dur : trois blocages consécutifs du classifieur, ou vingt sur une session, et Claude Code retombe en approbation manuelle. Et les règles d'autorisation larges qui laisseraient des commandes contourner totalement le classifieur sont mises de côté tant que le mode auto est actif.

C'est ce dernier détail qui va surprendre le plus d'équipes.

Ce que ça change concrètement dans votre setup

Si vous écrivez vos allow-rules à la main — et sur les chiffres d'Anthropic, c'est le cas d'environ la moitié d'entre vous — le mode auto change ce qu'elles signifient. Votre règle Bash(python:*) cesse d'être ce qui décide ; c'est le classifieur qui décide.

C'est un gain si la règle n'était qu'un contournement de la fatigue des prompts. C'est une perte de prévisibilité si elle était structurante pour un pipeline que vous aviez réglé délibérément. Autant savoir dans quel cas vous êtes avant le 14.

Le cadrage général, lui, s'est inversé. La charge de la preuve était "prouvez que le mode auto est assez sûr pour qu'on lui fasse confiance". Elle devient "prouvez que la relecture manuelle attrapait quelque chose que le mode auto n'attrape pas mieux". Sur les chiffres d'Anthropic, c'est difficile à défendre.

Reste la question qu'on pose à chaque audit client : lesquels de vos garde-fous sont réellement appliqués à un endroit où l'agent ne peut pas discuter ?

• Des credentials scopés plutôt qu'une clé admin partagée
• Un rôle base de données en lecture seule pour tout ce qui ne fait que lire
• Une protection de branche qu'un --force ne peut pas contourner
• Des règles d'egress réseau sur la machine où tourne l'agent
• Des environnements éphémères où le rayon de souffle se réinitialise

Deux des incidents qu'Anthropic dit avoir évités en interne ont exactement cette forme : des commandes destructrices qui auraient démoli des centaines de GPU de jobs d'entraînement en cours, et une demande d'accès facturation en lecture seule satisfaite par un rôle cloud donnant le contrôle administratif complet à la racine du compte. Un classifieur a attrapé les deux. Une boîte de dialogue vous aurait montré une ligne de commande et un O/n.

Un prompt de permission que personne ne lit n'a jamais été un garde-fou. C'était une ligne de log avec un bouton dessus.

Les sessions peuvent désormais s'alerter entre elles

La même semaine, Claude Code a livré la messagerie inter-sessions : une session peut découvrir vos autres sessions en cours et en avertir une directement, via deux outils — ListAgents pour voir ce qui est joignable, SendMessage pour livrer un texte à l'une d'elles par son nom. Pas de contexte partagé, pas d'accès aux fichiers. Juste une note, comme un coéquipier qui vous ping en plein travail.

Il faut Claude Code v2.1.224 ou plus récent, ça tourne sur macOS et Linux, et c'est actif par défaut dès qu'une session remplit les conditions. Via Remote Control, la portée s'étend à vos sessions sur d'autres machines.

Le cas d'usage, toute équipe qui fait tourner des worktrees en parallèle l'a déjà vécu : la session A change une interface, la session B construit sur l'ancienne version trois dossiers plus loin, et personne ne s'en aperçoit avant que le build de B casse une heure plus tard. La messagerie laisse A signaler le problème au moment où il survient, au lieu que vous soyez le relais entre deux agents qui ne se voient pas autrement.

Fonctionnalité mineure à côté du mode auto, même réflexe : retirer l'humain d'un rôle de coordination qu'il remplissait à la main et imparfaitement. Le mode auto vous retire de la relecture de chaque appel d'outil ; la messagerie vous retire du relais entre sessions parallèles. Mis bout à bout, ces deux changements suggèrent des sessions qui se coordonnent de plus en plus entre elles plutôt que d'être coordonnées par la personne qui surveille le terminal.

Faire tourner ça sur une infrastructure que vous contrôlez

Le troisième morceau : les environnements self-hosted sont passés en beta publique le 6 août. Vous démarrez une session depuis le web, mobile, desktop ou une routine programmée, et elle s'exécute dans votre propre réseau — à côté de vos services internes, de vos registries et de vos contrôles de sécurité — plutôt que sur l'infrastructure hébergée par Anthropic. Vous déployez des runners longue durée qui prennent les sessions et lancent un process Claude Code pour chacune, en mode fixe ou à la demande.

Les petites lignes comptent : plans Team et Enterprise uniquement, désactivé par défaut, et indisponible pour les organisations en ZDR. Et ce n'est pas Remote Control, qui sert à reprendre depuis un téléphone ou un navigateur une session tournant sur votre propre machine.

Anthropic est clair : ce n'est pas le choix par défaut recommandé. Pour la plupart des entreprises, l'offre hébergée reste le meilleur compromis, et passer en self-hosted veut dire staffer de l'ingénierie pour porter la mise en place et sa maintenance. Mais pour les équipes dont l'accès réseau, l'outillage interne ou la posture de conformité impose que l'exécution des agents reste sur une infrastructure qu'elles contrôlent, Anthropic formalise ici un pattern que certaines organisations construisaient déjà à la main — un relais maison entre un agent de code et les systèmes internes qu'il ne peut pas atteindre autrement.

Si ça décrit votre setup, cette sortie se lit moins comme une nouvelle fonctionnalité que comme une architecture de référence à laquelle comparer votre propre implémentation.

Ce qu'on surveille la semaine prochaine

Le taux de retour en arrière, plus que le taux d'adoption : combien d'équipes repassent en relecture manuelle dans les premières semaines après le 14 août, et pour quelles raisons. Ce chiffre nous en dira plus sur les angles morts du classifieur que n'importe quel benchmark publié par Anthropic. Un taux de raté de 7% sur un jeu adversarial est un résultat de labo ; une équipe qui fait marche arrière après un mauvais mardi est un résultat de terrain.

On va aussi choisir un projet interne multi-worktree pour tester la messagerie inter-sessions en conditions réelles, au-delà du cas de démo. Les fonctionnalités de coordination ont tendance à briller dans la doc et à décevoir dans un repo avec de vrais conflits de merge.

Et on relit nos propres configs de permission clients avant le 14 — parce que "on a des allow-rules" est sur le point de ne plus être une réponse.

Auditer ce que vos agents ont vraiment le droit de faire, et savoir où placer le vrai garde-fou — discutons.