Table des matières
- 1. Qu'est-ce que le « bypass » exactement ?
- 2. La vraie raison : le système d'autorisations à 2 couches
- 3. Couche 1 : Interface d'autorisation des outils (contrôlable par bypass)
- 4. Couche 2 : Jugement de sécurité de l'IA (non contrôlable par bypass)
- 5. Opérations pour lesquelles Claude demande spontanément
- 6. Pourquoi deux couches ? La philosophie de conception
- 7. Comment réduire les demandes de confirmation en pratique
- 8. Récapitulatif
- FAQ
Vous avez activé le drapeau --dangerously-skip-permissions dans Claude Code, mais Claude vous envoie quand même un message dans le chat pour demander « Puis-je exécuter cette opération ? » Ça vous parle ?
Le réflexe est de penser que « le bypass ne fonctionne pas » — mais ce n'est pas ce qui se passe. Le système d'autorisations de Claude Code comporte deux couches indépendantes, et le mode bypass ne contrôle que l'une d'elles.
Cet article couvre tout, de « ce qu'est réellement le bypass » à la différence entre les deux couches d'autorisation, les types d'opérations pour lesquels Claude demande spontanément, et les moyens pratiques de réduire les confirmations lors de l'automatisation.
1. Qu'est-ce que le « bypass » exactement ?
En informatique, « bypass » signifie contourner le flux habituel de confirmation ou d'approbation pour passer directement à l'action. Pensez au bouton « Acheter maintenant » d'une boutique en ligne qui saute l'écran de récapitulatif — c'est un bypass du flux de confirmation.
Dans le mode Manuel de Claude Code (valeur de configuration default), une boîte de dialogue de confirmation s'affiche avant toute modification de fichier ou exécution de commande shell. Depuis Claude Code v2.1.283, en revanche, les sessions dans le terminal et dans VS Code démarrent par défaut en mode Auto, quels que soient l'offre et le fournisseur, et un classificateur examine la plupart des actions au lieu de vous les soumettre (dans les versions antérieures, seulement avec les offres Pro, Max et Team ; si un administrateur a désactivé le mode auto ou si le modèle ne le prend pas en charge, la session démarre en mode Manuel).
# Mode Manuel : confirmation avant chaque action
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → Yes / NoLe mode bypass des autorisations saute (bypasse) ce flux de confirmation.
# Mode bypass : presque aucune boîte de dialogue de confirmation
$ claude --dangerously-skip-permissions
# ou
$ claude --permission-mode bypassPermissionsNotez que le drapeau contient le mot dangerously. Anthropic positionne ce mode comme destiné uniquement aux conteneurs ou environnements isolés — il n'est pas recommandé pour le développement local quotidien. Pour une analyse complète des risques du mode bypass, consultez Mode bypass de Claude Code : risques et utilisation sécurisée.
Si les boîtes de dialogue de confirmation continuent d'apparaître souvent, vérifiez d'abord que vous êtes réellement en mode bypass. Tant qu'il est actif, la barre d'état du terminal affiche ⏵⏵ bypass permissions on. Si ce n'est pas le cas, deux causes sont fréquentes.
- Vous l'avez défini dans les réglages du projet : indiquer
bypassPermissionscommedefaultModedans.claude/settings.jsonou.claude/settings.local.jsonn'a aucun effet, et la session démarre en mode Manuel (v2.1.257 et versions ultérieures). Placez-le dans vos réglages utilisateur (~/.claude/settings.json) ou dans les réglages gérés, ou passez le drapeau au lancement - Vous avez tenté de basculer en cours de session : le bypass ne peut être choisi que dans une session où il a été activé au lancement. Dans une session démarrée sans lui, Shift+Tab n'atteint jamais le bypass
Par ailleurs, la première fois que vous lancez une session interactive en bypass, Claude Code affiche un avertissement, une seule fois, qui vous demande d'accepter la responsabilité des actions exécutées sans vérification des autorisations (votre acceptation est enregistrée dans les réglages utilisateur).
2. La vraie raison : le système d'autorisations à 2 couches
La réponse à « pourquoi la confirmation apparaît-elle même avec le bypass activé » est que le système d'autorisations de Claude Code repose sur deux couches indépendantes.
Système d'autorisations de Claude Code : structure à 2 couches
Le mode bypass ne désactive que la « Couche 1 » (et même celle-ci garde quelques confirmations)
--dangerously-skip-permissions désactive la quasi-totalité de la Couche 1 (restent les règles ask, la suppression de chemins critiques et quelques autres cas). La Couche 2 ne peut pas être contournée.
Confondre ces deux couches est la cause première du malentendu « le bypass ne fonctionne pas ». Examinons chacune en détail.
3. Couche 1 : Interface d'autorisation des outils (contrôlable par bypass)
La première couche est la boîte de dialogue de confirmation affichée avant l'exécution d'un outil — l'interface interactive qui apparaît lorsque Claude Code est sur le point de modifier un fichier ou d'exécuter une commande shell.
| Outil | Exemple de boîte de dialogue |
|---|---|
| Modification de fichier | « Puis-je modifier index.js ? » |
| Exécution Bash | « Puis-je exécuter npm install ? » |
| Accès web | « Puis-je accéder à https://... ? » |
C'est exactement cette couche que le mode bypass désactive. Avec --dangerously-skip-permissions, ce genre de boîte de dialogue n'apparaît presque jamais et Claude peut exécuter les outils librement. Même l'écriture dans des chemins protégés comme .git et .claude passe sans confirmation en mode bypass. En ce sens, le mode bypass fonctionne correctement.
Confirmations qui s'affichent même en mode bypass (exceptions de la Couche 1)
Tout est dans le « presque ». La documentation officielle précise que Claude Code n'approuve automatiquement les éléments suivants dans aucun mode, bypass compris (source : page officielle de Claude Code « Choose a permission mode », au 22 septembre 2026).
- Les actions correspondant à une règle ask : ce que vous avez inscrit dans
permissions.askdans vos réglages (par exempleBash(git push *)) demande une confirmation à chaque fois, même en mode bypass - Les outils qui ont besoin de votre intervention :
AskUserQuestion, avec lequel Claude vous pose une question à choix, les outils MCP marqués comme nécessitant une interaction de l'utilisateur, et les outils de connecteurs que votre organisation a réglés sur ask rmetrmdirvisant des chemins critiques : les suppressions qui ciblent la racine du système de fichiers et ses répertoires de premier niveau (comme/usr), votre répertoire personnel, ou votre répertoire de travail et ses répertoires parents. La documentation parle d'un disjoncteur (circuit breaker) contre les erreurs du modèle, qu'aucune règle allow ni aucun hook ne peut approuver. Toutefois, dans l'application Desktop et dans VS Code, depuis la v2.1.309, ces suppressions sont refusées immédiatement, sans demande de confirmation, et le refus renvoie des indications pour réécrire la commande, afin de ne pas bloquer les sessions dans lesquelles personne n'est présent (historique officiel des modifications).- Autres : les garde-fous de la messagerie inter-sessions, et les commandes Bash qui lisent en dehors de vos répertoires de travail tant que
permissions.blockReadsOutsideWorkingDirectoriesest activé
Les règles comptent aussi. Les règles deny s'appliquent toujours en mode bypass et bloquent les actions correspondantes. Les règles allow, en revanche, n'ont aucun effet en mode bypass (tout passe déjà). Dans les exécutions non interactives avec -p, ces quelques confirmations sont refusées au lieu d'attendre une réponse.
Remarque : il existe 6 modes d'autorisation
Claude Code dispose de six modes d'autorisation : Manuel (default), Accepter les modifications (acceptEdits), Plan (plan), Auto (auto) et Ignorer les permissions (bypassPermissions), plus dontAsk, qui n'apparaît jamais dans le cycle de Shift+Tab et refuse automatiquement tout ce qui demanderait une confirmation (conçu pour la CI). Le mode bypass (bypassPermissions) est le moins restrictif. Pour les détails de chaque mode, consultez l'article sur les modes d'autorisation.
4. Couche 2 : Jugement de sécurité de l'IA (non contrôlable par bypass)
La deuxième couche est le jugement de sécurité autonome de Claude. Elle est complètement indépendante de l'interface de confirmation des outils.
Lorsque Claude détermine qu'une opération pourrait avoir des conséquences importantes, il envoie un message de confirmation dans le chat en texte ordinaire. Il ne s'agit pas d'un mécanisme d'exécution d'outil — c'est le comportement conversationnel de Claude en tant qu'IA.
--dangerously-skip-permissions saute les boîtes de dialogue de la Couche 1, mais n'a aucun effet sur ce jugement de la Couche 2 — car la Couche 2 est un principe comportemental intégré dans le modèle de Claude lui-même.
Idée reçue fréquente
« J'ai activé le mode bypass mais Claude s'est arrêté → le bypass ne fonctionne pas »
→ Plus précisément, distinguez selon la façon dont Claude s'est arrêté. Si Claude a posé la question en texte dans le chat : « L'interface de la Couche 1 est désactivée, mais le jugement de l'IA de la Couche 2 demande une confirmation. » Si une boîte de dialogue demandant l'autorisation est apparue dans le terminal, c'est l'une des confirmations de la Couche 1 que le bypass conserve, comme une règle ask ou la suppression d'un chemin critique. Dans les deux cas, le bypass fonctionne parfaitement (si ce n'est ni l'un ni l'autre et que les confirmations continuent, la session n'a peut-être même pas démarré en mode bypass).
La Couche 2 n'est pas pour autant une garantie de sécurité. Que Claude pose la question ou non relève d'un jugement du moment, et il ne s'arrêtera pas forcément avant une action dangereuse. La documentation officielle avertit aussi que le mode bypass n'offre aucune protection contre l'injection de prompt ni contre les actions non voulues. Ce qui ne doit jamais s'exécuter, bloquez-le avec une règle deny.
5. Opérations pour lesquelles Claude demande spontanément
Par type d'opération : quelle couche gère la confirmation ?
Couche 1 (UI d'autorisation des outils) vs Couche 2 (Jugement de l'IA)
Les critères internes de Claude pour « je dois confirmer cela » se répartissent en trois grandes catégories.
① Irréversibilité
Les opérations qui ne peuvent pas être annulées rendent Claude prudent. La suppression définitive de fichiers, git push --force et DROP TABLE en sont des exemples typiques. Comme les erreurs sont difficiles à corriger, Claude marque une pause et pose la question.
② Rayon d'impact
Les actions qui affectent les environnements de production, un grand nombre de fichiers ou d'autres utilisateurs déclenchent des vérifications plus fréquentes. Modifier un fichier local suscite rarement une question ; modifier le schéma d'une base de données en production en suscite presque toujours une.
③ Risque de sécurité
Les opérations qui envoient des fichiers .env, des jetons d'authentification ou des clés API vers l'extérieur sont signalées comme risque de sécurité élevé par Claude, qui demandera confirmation avant de procéder.
Certaines suppressions, toutefois, ne sont pas du tout laissées au jugement de Claude : rm et rmdir visant des chemins critiques, comme la racine, votre répertoire personnel ou le répertoire de travail lui-même, sont arrêtées par Claude Code lui-même (Couche 1), même en mode bypass (la CLI demande une confirmation, tandis que l'application Desktop et VS Code les refusent directement depuis la v2.1.309). C'est l'une des rares confirmations que le bypass ne supprime pas.
Ces jugements sont intégrés dans le modèle d'IA de Claude et ne peuvent pas être complètement désactivés via la configuration. Pour en savoir plus sur la façon dont les agents IA sont conçus pour fonctionner en toute sécurité, consultez Qu'est-ce qu'un agent IA ?.
6. Pourquoi deux couches ? La philosophie de conception
Pourquoi deux couches ? — La philosophie de conception
Comprendre grâce à l'analogie de l'artisan
Voici une analogie qui rend la conception à deux couches intuitive.
Imaginez que vous engagez un artisan pour rénover une pièce et que vous lui donnez un double de clé en lui disant « vous pouvez faire ce qu'il faut ». C'est l'équivalent d'accorder des autorisations d'outil.
Mais quand l'artisan est sur le point d'abattre un mur et vous demande « Est-ce un mur porteur ? Êtes-vous sûr de vouloir que je l'enlève ? » — il pose la question en vertu de son propre jugement professionnel, pas parce qu'il a perdu la clé.
Lui donner une clé n'empêche pas l'artisan de réfléchir. Son jugement professionnel et sa conscience de la sécurité fonctionnent indépendamment de la clé.
Claude fonctionne de la même façon. Le mode bypass donne à Claude « la clé pour utiliser les outils », mais il n'arrête pas le jugement de l'IA de Claude. En fait, le fait que Claude marque une pause avant des opérations à haut risque est une fonctionnalité de sécurité intentionnelle, pas un dysfonctionnement.
7. Comment réduire les demandes de confirmation en pratique
Dans les pipelines CI/CD et autres scénarios d'automatisation, vous pourriez avoir besoin que Claude accomplisse des tâches sans s'arrêter. Voici les approches les plus efficaces.
Approche 1 : utiliser CLAUDE.md pour fournir du contexte
Créez un fichier CLAUDE.md à la racine de votre projet en expliquant l'environnement et les contraintes. Lorsque Claude comprend que « c'est un environnement sûr et isolé », la fréquence des confirmations baisse considérablement.
# About This Environment
This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe
Please proceed without asking for extra confirmation.Approche 2 : donner des instructions petites et précises
Les instructions vagues augmentent l'incertitude de Claude et déclenchent davantage de confirmations.
| Type d'instruction | Exemple | Taux de confirmation |
|---|---|---|
| Vague | « Nettoie ce projet » | Élevé |
| Précis | « Supprime les imports inutilisés dans src/ » | Faible |
| Vague | « Déploie-le » | Élevé |
| Précis | « Exécute npm run deploy:staging sur l'environnement de staging » | Faible |
Approche 3 : essayez d'abord le mode auto
Avant de passer en mode bypass complet, essayez le mode auto. Il exécute un classificateur de sécurité en arrière-plan tout en approuvant automatiquement la plupart des opérations, et il incite aussi Claude à poursuivre le travail plutôt que de s'arrêter pour poser des questions de clarification (Claude pose tout de même la question quand votre prompt ou une skill en dépend). Si la seule raison pour laquelle vous utilisez le bypass est « j'en ai assez des confirmations », le mode auto peut suffire. Les actions correspondant à une règle ask demandent toujours une confirmation en mode auto.
Mise en garde importante
Aucune configuration ne peut réduire le jugement de sécurité de Claude à zéro absolu. C'est intentionnel — ce n'est pas un bug ni une limitation. Pour les opérations à haut risque, le fait que Claude demande une confirmation est le comportement correct. Acceptez-le comme faisant partie de la conception. La Couche 1 garde elle aussi quelques confirmations que le bypass ne supprime pas, comme les règles ask et la suppression de chemins critiques.
8. Récapitulatif
| Élément | Détail |
|---|---|
| Ce qu'est le bypass | Sauter presque toutes les boîtes de dialogue de confirmation avant l'outil (Couche 1) |
| Ce que bypass désactive | L'interface d'autorisation des outils (« Puis-je exécuter cette commande ? »), y compris les confirmations d'écriture dans des chemins protégés comme .git et .claude |
| Ce que bypass ne désactive PAS | Le jugement de sécurité de l'IA de Claude (confirmation envoyée en texte de chat) et les exceptions de la Couche 1 (règles ask, rm/rmdir sur des chemins critiques, AskUserQuestion) |
| Les règles en mode bypass | deny bloque toujours ; allow n'a aucun effet |
| Critères de confirmation de Claude | Irréversibilité, rayon d'impact, risque de sécurité |
| Comment réduire les confirmations | Contexte CLAUDE.md / instructions précises / mode auto |
| Pourquoi deux couches | L'autorisation des outils et le jugement de l'IA sont des concepts fondamentalement distincts |
Lorsque Claude demande une confirmation même en mode bypass, ce n'est pas que le bypass a cessé de fonctionner — deux systèmes indépendants font simplement leur travail. Comprendre cette distinction vous aide à anticiper le comportement de Claude Code avec précision et à l'utiliser plus efficacement.
Pour comprendre les différences entre les produits Claude, consultez Claude.ai vs Claude Code : quelle est la différence ?.
FAQ
Peut-on obtenir zéro confirmation avec le mode bypass ?
Vous pouvez désactiver presque toutes les boîtes de dialogue de l'interface d'exécution des outils (Couche 1), mais les confirmations des actions correspondant à une règle ask, de rm ou rmdir sur des chemins critiques et des questions posées via AskUserQuestion subsistent. Vous ne pouvez pas non plus éliminer complètement les confirmations du jugement de sécurité de l'IA de la Couche 2. Il s'agit d'une fonctionnalité de sécurité intentionnelle. Cependant, documenter soigneusement votre environnement dans CLAUDE.md et donner des instructions précises peut réduire considérablement la fréquence des demandes de Claude.
Le fait que Claude demande une confirmation est-il un bug ?
Non. Le mode bypass saute l'interface d'autorisation des outils, pas le jugement de l'IA de Claude. Le fait que Claude marque une pause avant des opérations irréversibles, des environnements de production ou des données sensibles est un comportement de sécurité intentionnel — pas un dysfonctionnement. Ce n'est pas « le bypass qui ne fonctionne pas », c'est « deux systèmes qui fonctionnent indépendamment ». Si c'est une boîte de dialogue demandant l'autorisation qui apparaît, et non du texte dans le chat, il s'agit de l'une des confirmations de la Couche 1 que le bypass conserve, comme une règle ask ou la suppression d'un chemin critique.
Comment empêcher Claude de s'arrêter dans les pipelines CI/CD ?
Trois approches fonctionnent bien : ① indiquez explicitement dans CLAUDE.md ou le prompt système que « c'est un environnement CI/CD entièrement isolé et toutes les opérations s'exécutent en sécurité », ② donnez des instructions de tâche petites et précises (les instructions vagues déclenchent davantage de confirmations), ③ combinez le mode bypass avec l'isolation de conteneur Docker. Pour le ③, exécutez Claude Code avec un utilisateur autre que root : sous Linux et macOS, le mode bypass refuse de démarrer en root ou via sudo. Avec -p, les quelques confirmations que le bypass conserve sont refusées au lieu d'attendre une réponse. Si vous ne voulez exécuter que des actions approuvées à l'avance, la documentation officielle propose aussi pour la CI --permission-mode dontAsk avec --allowedTools. Notez que des pauses peuvent encore se produire même avec tout cela en place.
Peut-on distinguer visuellement une boîte de dialogue d'outil et la confirmation de Claude ?
Oui. Les boîtes de dialogue d'autorisation des outils de la Couche 1 apparaissent dans le terminal Claude Code sous forme d'interface interactive qui montre la commande ou la modification avec des choix comme Yes et No. Les confirmations du jugement de l'IA de la Couche 2 apparaissent comme du texte conversationnel ordinaire de Claude (par exemple, « Cela va modifier la base de données de production — est-ce bien ce que vous souhaitez ? »). Le cas trompeur est AskUserQuestion, avec lequel Claude pose une question à choix : la question vient de Claude, mais elle s'affiche sous forme de boîte de dialogue et attend votre réponse même en mode bypass, car la Couche 1 ne l'approuve jamais automatiquement. Les formats d'affichage diffèrent, il est donc facile de les distinguer une fois que vous vous y êtes habitué.
