AIREITERÀ partir de la semaine suivante, le mode automatique devait devenir le réglage par défaut des nouvelles sessions dans la plupart des apps Claude pour les forfaits Pro, Max et Team, annonçait Anthropic le 22 octobre. Les administrateurs Enterprise sont prévenus par e-mail en amont, tandis que l'API et les plateformes cloud restent en opt-in pour le moment.
Ce qui change le 22 octobre — et ce qui reste inchangé
La mise à jour du 22 octobre étend à la plupart des apps Claude un changement déjà appliqué à Claude Code. Depuis le 14 août 2026, les nouvelles sessions Claude Code des forfaits Pro, Max et Team s'ouvrent en mode automatique, avec une invite unique pour les utilisateurs qui avaient épinglé un autre mode par défaut. Dans la même annonce d'Anthropic, la note du 22 octobre précise que le déploiement du mode automatique comme réglage par défaut des nouvelles sessions commencera la semaine suivante dans la plupart des apps Claude pour les forfaits Pro, Max et Team. Les administrateurs Enterprise seront informés par e-mail avant le changement dans leur organisation.
Trois limites restent toutefois en place. Les administrateurs Team qui ont défini un mode par défaut dans les paramètres gérés ne verront aucun changement pour leurs utilisateurs. Enterprise, l'API Claude, Claude Platform sur AWS, Amazon Bedrock, Google Cloud's Agent Platform et Microsoft Foundry restent en opt-in, avec un passage prévu au mode automatique par défaut au cours du mois suivant. Les préférences personnelles épinglées sont elles aussi conservées, sauf si l'utilisateur accepte l'invite de bascule unique.
La version installée détermine également ce que l'utilisateur voit. D'après le suivi des notes de version, Claude Code v2.1.283 et les versions ultérieures utilisent automatiquement le mode auto pour les sessions interactives dans le terminal et VS Code lorsqu'aucun mode d'autorisation n'est configuré. Une nouvelle installation peut néanmoins démarrer en mode manuel au premier lancement si les indicateurs de fonctionnalité ne sont pas encore arrivés.
Comment Claude choisit quoi laisser passer en mode automatique
Selon l'annonce d'Anthropic, le mode automatique de Claude fait passer chaque appel d'outil par un classifieur distinct, au lieu de demander une validation à chaque étape. Celui-ci autorise les actions courantes et bloque celles qu'il juge irréversibles, destructrices ou dirigées vers l'extérieur de l'environnement de travail. Claude cherche alors une autre voie plus sûre ou pose directement la question. Après trois blocages consécutifs, ou vingt blocages au total dans une session, le système repasse aux validations manuelles.
Les règles d'autorisation explicites restent prioritaires sur le classifieur. Les entrées de permissions.deny bloquent systématiquement l'action, sans qu'aucun verdict du classifieur puisse les contourner, tandis que celles de permissions.ask déclenchent toujours une invite. Les règles allow très larges qui autorisent l'exécution arbitraire de code, comme Bash(python:*), sont mises de côté pendant l'utilisation du mode automatique afin qu'une commande ne puisse pas contourner complètement le classifieur.
Le classifieur ne se contente pas d'une liste statique d'autorisations. Anthropic indique qu'il vérifie la destination d'un push Git ou d'une pull request — privée, de confiance ou publique — avant l'exécution, ainsi que l'état actuel de Git avant les commandes destructrices comme git reset --hard.
Les contenus externes provenant de pages web, de fichiers ou de sorties d'outils passent par une détection des tentatives d'injection de prompt. Lorsqu'un contenu semble suspect, un avertissement est ajouté au contexte de Claude. L'exfiltration de données relève d'une catégorie de refus strict et ne peut pas être approuvée automatiquement : il faut changer de mode ou exécuter directement la commande.
Pourquoi Anthropic préfère le mode automatique aux clics sur « Approuver »
Anthropic présente ce changement comme une amélioration de l'ergonomie, étayée par des mesures concrètes. Les utilisateurs approuvent 97 % des demandes d'autorisation dans Claude Code, mais rejettent 39 % des plans présentés. Pour Anthropic, cet écart traduit surtout un clic réflexe sur les demandes individuelles plutôt qu'une véritable relecture. En juin 2026, 49,5 % des utilisateurs actifs de la CLI avaient écrit une règle Bash allow personnalisée, 62 % avaient utilisé bypassPermissions ou « don't ask again », et 25 % des sessions interactives avaient démarré en mode bypass.
Une étude contrôlée a permis de mesurer ce comportement. Anthropic a recruté 1 053 testeurs payants par l'intermédiaire d'un prestataire de recherche, remplacé une demande d'autorisation par session par une commande clairement dangereuse, puis enregistré leur réaction ; le texte dangereux n'a rien exécuté. Les humains ont détecté la commande dans 13,6 % des cas, soit 143 sur 1 053, contre 89 % pour le mode automatique, qui a bloqué 937 commandes sur 1 053.
En comparaison directe, le mode automatique a bloqué 800 commandes que les humains avaient approuvées. Les humains, eux, n'ont bloqué que 6 commandes autorisées par le mode automatique. Leur performance est passée d'environ 17 % au début à environ 5 % après 50 invites ou davantage, tandis que celle du mode automatique est restée stable.
Les données de production et de sources tierces vont dans le même sens, selon l'annonce d'Anthropic. Parmi les sessions signalées entre mai et juin 2026, 6,3 % des sessions approuvées manuellement contenaient un risque de niveau production que l'utilisateur n'avait pas explicitement demandé, contre 2,4 % des sessions en mode automatique. Trajectory Labs a exécuté 72 scénarios d'injection de prompt dix fois chacun : aucune des 720 tentatives n'a réussi contre Claude Fable 5, Opus 5 ou Sonnet 5 en mode automatique, contre un taux de réussite de 5,83 % face à GPT-5.6 Sol en mode Codex Auto-review.
Le red teaming mené par Apollo Research a fait passer le taux d'erreur du classifieur de 12 % à 7 % après un renforcement prenant en compte la visibilité du dépôt, l'état de Git et les règles de traitement des données. Anthropic mentionne également trois incidents évités en interne — un repli d'envoi hors réseau vers un site de paste public, l'arrêt massif d'environ 2 000 processus qui menaçait des tâches d'entraînement GPU et une élévation trop large d'un rôle de facturation — ainsi qu'environ 25 % de pull requests supplémentaires chez des utilisateurs Teams et Enterprise, notamment Adobe, Nuro, Gusto et Garner Health.
Les problèmes signalés après le passage au mode automatique
Les échanges entre utilisateurs font ressortir des irritants que l'annonce aborde peu. Les opérations courantes concentrent les critiques : commits, nettoyage de worktrees, tâches SSH et interventions sur des serveurs, mais aussi commandes de déploiement bloquées ou soumises à une nouvelle demande d'autorisation en mode automatique.
« le classifieur automatique demande une autorisation même pour les opérations les plus basiques, et refuse quand même de les exécuter après qu'on lui a donné explicitement l'autorisation. » — u/dfritter4 sur r/ClaudeCode
Le point le plus irritant est qu'une approbation ne suffit pas toujours à lever un refus. Plusieurs utilisateurs racontent avoir validé une action avant de voir le système la refuser malgré tout, les obligeant à repasser par le mode manuel ou par le terminal.
« Il m'est arrivé de devoir repasser en manuel, dire à l'agent de continuer, approuver manuellement, puis revenir en automatique. » — u/phoenixmatrix sur r/ClaudeCode
Les pannes du classifieur constituent un problème distinct des refus de sécurité. Lors d'un incident touchant plusieurs projets, les utilisateurs ont vu le message « The server-side auto mode classifier gave no verdict » sur plusieurs projets alors que la page de statut ne signalait aucun incident. La solution de contournement consistait à repasser en mode manuel jusqu'au rétablissement du service.
Les inquiétudes sur la qualité complètent le tableau, notamment dans la discussion sur le déploiement par défaut. Certains utilisateurs se préoccupent moins des commandes destructrices que de la tendance de Claude à sur-ingénieriser, à sortir du périmètre ou à proposer une architecture fragile lorsqu'il travaille de façon autonome. Ces frictions répétées poussent une minorité à revenir à --dangerously-skip-permissions, avec pour seules protections Git, les conteneurs et une revue avant fusion.
Conserver des points de contrôle sans quitter le mode automatique de Claude
Le réglage qui surprend le plus les développeurs est l'autorisation par défaut des push et de la création de pull requests en mode automatique, y compris vers la branche de travail et la branche par défaut. Les force push, la présence de secrets dans les commits et les réécritures d'historique restent bloqués provisoirement et nécessitent une intention explicite. Dire « nettoie le dépôt » n'autorise pas un force push ; nommer précisément l'action, en revanche, peut l'autoriser. Les branches qui désignent des cibles de déploiement, comme production, release ou gh-pages, sont évaluées comme des déploiements de production.
Pour conserver le mode automatique partout sauf pour les push et les PR, ajoutez des règles ask ciblées sur le contenu. Elles seront évaluées avant le classifieur :
{ "permissions": { "ask": ["Bash(git push *)", "Bash(gh pr create *)"] } }Lorsqu'une limite ne doit absolument pas être franchie, utilisez permissions.deny plutôt qu'une instruction dans le chat. Un « ne pousse rien avant ma revue » peut disparaître lors de la compression du contexte, alors qu'une règle ask ou deny persiste. Des refus répétés pour une destination connue indiquent généralement que le classifieur ne reconnaît pas l'infrastructure ; la déclarer dans autoMode.environment, dans les paramètres utilisateur ou gérés, peut aider.
Consultez les refus dans l'onglet Recently denied de /permissions, puis appuyez sur r pour en réessayer un. Vous pouvez vérifier la configuration avec claude auto-mode config, claude auto-mode defaults et claude auto-mode critique. Deux pièges sont à connaître : les règles allow étroites comme Bash(npm test) sont résolues avant le classifieur et peuvent laisser passer un argument destructeur sans contrôle ; activez autoMode.classifyAllShell à true sur la v2.1.193 ou une version ultérieure pour classifier chaque commande shell, au prix d'une certaine latence. Par ailleurs, les listes personnalisées allow, soft_deny, hard_deny ou environment remplacent entièrement les règles intégrées, sauf si elles conservent l'entrée littérale "$defaults".
Le désactiver quand la situation l'exige
Le changement de mode en cours de session ne demande qu'une action. Dans la CLI, appuyez sur Shift+Tab pour faire défiler les modes, utilisez le menu déroulant de l'application de bureau ou démarrez une session avec claude --permission-mode manual. Le changement ne concerne que la session en cours.
Pour imposer durablement le mode manuel, enregistrez-le comme réglage par défaut dans les paramètres utilisateur, à l'emplacement ~/.claude/settings.json :
{ "permissions": { "defaultMode": "manual" } }À partir de la v2.1.200, la valeur manual est un alias de default. Le fichier de dépôt .claude/settings.json ne peut ni accorder ni imposer le mode automatique : defaultMode: auto et bypassPermissions qui y seraient définis sont ignorés. L'opt-in ou l'opt-out doit donc être configuré dans les paramètres utilisateur ou gérés. Les administrateurs d'une organisation définissent le mode par défaut avec defaultMode dans les paramètres gérés, ou suppriment complètement le mode automatique avec permissions.disableAutoMode réglé sur "disable". Depuis la v2.1.251, cette désactivation s'applique même aux sessions déjà en cours. Le classifieur du mode automatique examine également les commandes shell pendant le mode plan lorsque useAutoModeDuringPlan est activé, ce qui est le réglage par défaut lorsque le mode automatique est disponible.
Le laisser activé ou imposer le mode manuel ?
Choisissez le mode en fonction de l'ampleur des dégâts possibles, pas de votre enthousiasme. Le mode automatique convient naturellement au travail exploratoire en solo, aux refactorings locaux isolés, aux mises à jour de dépendances, à la génération de tests et au nettoyage de documentation, avec une diff et la suite de tests comme garde-fous. Dans un dépôt partagé, une condition supplémentaire s'impose : définir avant le déploiement des chemins protégés, des refus stricts pour les secrets et les manifestes de déploiement, ainsi que des sandboxes ou des branches jetables.
| Workflow | Mode recommandé | Garde-fou à définir en premier |
|---|---|---|
| Exploration en solo, modifications réversibles | Mode automatique | Revue de Recently denied + réflexe d'utiliser r pour réessayer |
| Dépôt d'équipe, développement courant | Mode automatique avec points de contrôle sur les push | ask sur git push * et gh pr create * |
| Déploiements de production, IAM, secrets, réponse aux incidents | Mode manuel ou mode plan + revue humaine de la diff | Règles deny pour les limites infranchissables |
| Sessions réglementées ou éligibles HIPAA | Manuel (le mode automatique reste disponible pour basculer) | defaultMode géré + audit des personnes autorisées à le modifier |
Mettez la CLI et les intégrations d'éditeur sur la même ligne de version, définissez un mode par défaut géré, protégez les chemins sensibles et les refus stricts, effectuez les premiers essais dans des devcontainers ou des VM isolées avec des données fictives, puis conservez git diff, les exécutions de tests et une véritable revue comme étapes obligatoires avant la fusion. Selon Anthropic, environ 10 % des sessions depuis la mi-mai comportent un refus du classifieur.
FAQ
Le mode automatique de Claude consomme-t-il davantage de tokens ?
Aucun surcoût ne s'applique aux forfaits Pro, Max et Team, selon Anthropic, à compter du 7 août 2026. Les sessions Enterprise, API et cloud-platform comptabilisent toutefois les appels du classifieur côté client dans l'utilisation de tokens.
Que faire lorsque le mode automatique bloque une opération légitime ?
Ouvrez /permissions, consultez l'onglet Recently denied, puis appuyez sur r pour réessayer l'action refusée. Si la même destination est régulièrement bloquée, indiquez l'infrastructure de confiance dans autoMode.environment.
Pourquoi un push vers main est-il passé sans demande d'autorisation ?
En mode automatique, les push vers n'importe quelle branche du dépôt de travail, y compris la branche par défaut, sont autorisés par défaut. Ajoutez Bash(git push *) à permissions.ask pour imposer un point de contrôle, ou à permissions.deny pour créer une limite stricte.
Le mode automatique est-il adapté au travail de production ?
Anthropic présente le mode automatique comme plus sûr que les clics machinalement répétés, mais recommande toujours une revue humaine pour les changements à fort enjeu dans l'infrastructure de production. Réservez le mode automatique aux opérations réversibles et utilisez le mode manuel ou le mode plan pour les déploiements, les secrets et l'IAM.
Comment distinguer un refus de sécurité d'une panne du classifieur ?
Un refus de sécurité indique la raison du blocage et Claude propose généralement une autre approche. Lors d'une panne avec « no verdict », les écritures et les actions Bash sont bloquées simultanément dans plusieurs projets. Vérifiez /status pour consulter la ligne du serveur de mode automatique et repassez en mode manuel si une panne est probable.
Le mode automatique fonctionne-t-il de la même façon dans Claude Code et les apps Claude ?
Le mécanisme du classifieur est partagé, mais le calendrier de déploiement diffère : Claude Code a basculé en premier le 14 août, les apps Claude suivent la semaine suivante, tandis que les surfaces Enterprise et l'API restent en opt-in jusqu'à la notification des administrateurs.
À lire aussi : guide du mode automatique d'OpenAI Codex