Déployer Claude Code en entreprise : le guide du DSI et du RSSI

Depuis la version 2.1.283, Claude Code ne demande plus la permission avant d'agir. Les sessions ouvertes dans un terminal ou dans VS Code démarrent en mode auto : un second modèle, le classifieur, examine les actions à la place de l'utilisateur. Ce changement est arrivé par une mise à jour, sans décision de votre part.

Pour un développeur seul, c'est un confort. Pour une organisation, c'est une délégation : un programme lit des fichiers, en modifie, exécute des commandes et se connecte au réseau sur les postes de vos équipes, selon des règles que personne chez vous n'a écrites.

Ce guide s'adresse à ceux qui doivent écrire ces règles. Il ne revient pas sur l'usage de l'outil côté développeur, déjà couvert dans la leçon CCA-F sur la configuration de Claude Code. Il traite de ce qu'une direction informatique et un responsable sécurité doivent décider, régler et vérifier avant de généraliser l'outil.

1. Ce que Claude Code fait réellement sur un poste

Un assistant en ligne répond dans une fenêtre de navigateur, et c'est vous qui copiez le résultat. Claude Code travaille dans vos dossiers. Il existe sous quatre formes qui reposent sur le même moteur : l'application de bureau, la ligne de commande, les extensions pour éditeurs (VS Code, JetBrains) et la version web, qui s'exécute dans des machines virtuelles gérées par Anthropic.

Pour le débutant : quatre gestes

Tout ce que fait l'outil se ramène à quatre gestes.

• Lire : ouvrir des fichiers, chercher dans un dossier.
• Écrire : créer ou modifier des fichiers.
• Exécuter : lancer des commandes, comme vous le feriez dans un terminal.
• Se connecter : appeler un site, une API, un service interne.

Les deux premiers restent dans le dossier de travail. Les deux derniers peuvent toucher tout ce que l'utilisateur a le droit de toucher : la base de données, le dépôt partagé, l'infrastructure cloud.

Pour l'expert : où tourne quoi

Le modèle ne tourne pas sur le poste. Claude Code envoie le contexte au fournisseur du modèle, reçoit une demande d'action, l'exécute localement avec les droits de l'utilisateur, puis renvoie le résultat. Deux conséquences en découlent. Les droits de l'outil sont ceux du compte qui le lance, ni plus ni moins. Et tout ce que l'outil lit peut partir vers le fournisseur du modèle avec la requête suivante.

2. Les six modes de permission

Un mode de permission fixe les actions que l'outil peut lancer sans vous interroger. Le choix du mode décide de qui valide : vous, un classifieur, une liste préétablie, ou personne.

Pour le débutant : ce qui a changé

Jusqu'à récemment, le mode de départ était le mode manuel : l'outil demandait avant chaque modification et chaque commande. À partir de la version 2.1.283, les sessions interactives dans un terminal et dans VS Code démarrent en mode auto, sur toutes les offres et chez tous les fournisseurs. La première fois, l'outil affiche un avis. Ensuite, plus rien ne le rappelle, sinon une ligne dans la barre d'état.

Pour l'expert : l'ordre qui décide du mode de départ

Au lancement d'une session dans un terminal, Claude Code retient la première source qui s'applique :

1. l'option --permission-mode passée au lancement ;
2. la clé permissions.defaultMode d'un fichier de paramètres ;
3. le mode intégré, c'est-à-dire auto depuis la 2.1.283.

Deux détails pèsent lourd. Un dépôt ne peut pas s'accorder lui-même le mode auto : la valeur auto est ignorée quand elle vient du fichier .claude/settings.json d'un projet. Et les sessions lancées sans interaction (claude -p, Agent SDK) ne suivent pas tout à fait la même règle : vérifiez leur mode de départ sur votre version avant de les mettre dans une chaîne d'intégration.

3. Le classifieur : ce qu'il voit, ce qu'il bloque, où il s'arrête

En mode auto, un second modèle examine les actions avant leur exécution. Il bloque ce qui dépasse la demande, ce qui vise une infrastructure qu'il ne reconnaît pas, et ce qui semble dicté par un contenu hostile lu en cours de route. La documentation prévient sans détour : le mode auto réduit les demandes de confirmation, il ne garantit pas la sécurité.

Pour le débutant : un vigile, pas un coffre-fort

Imaginez un vigile à l'entrée d'un entrepôt. Il arrête ce qui lui paraît anormal, et il a de bons réflexes. Il ne connaît pas votre entreprise : il ignore quel serveur est la production et quel dossier contient les contrats, tant que personne ne le lui a dit.

Ce qu'il bloque par défaut

Parmi les blocages documentés :

• télécharger du code puis l'exécuter ;
• envoyer des données sensibles vers l'extérieur ;
• déployer ou migrer en production ;
• forcer un push, ou annuler des modifications non enregistrées dans le dépôt ;
• détruire des fichiers qui existaient avant la session ;
• accorder des droits sur un dépôt ou un compte cloud ;
• modifier des enregistrements DNS, des certificats ou un gestionnaire de secrets ;
• fusionner une demande de modification qu'aucun humain n'a approuvée.

Ce qu'il laisse passer

Les opérations locales dans le dossier de travail, l'installation des dépendances déjà déclarées, les requêtes en lecture seule, et le push vers le dépôt sur lequel vous travaillez. Ce dernier point surprend souvent : en mode auto, pousser sur le dépôt courant est permis par défaut, branche principale comprise. Si vous voulez un point d'arrêt humain avant chaque push, il faut une règle ask (section 4).

Pour l'expert : l'ordre d'évaluation

Trois limites méritent d'être connues avant de se reposer sur lui.

Il ne lit pas les résultats des outils. Le classifieur voit vos messages, les appels d'outils et le contenu de vos fichiers CLAUDE.md. Les résultats sont retirés de ce qu'il reçoit, pour qu'un contenu piégé dans un fichier ou une page web ne puisse pas le manipuler. C'est une protection, et aussi un angle mort : il juge l'action sans voir ce qu'elle a renvoyé.

Une consigne dite dans la conversation peut se perdre. Si vous écrivez « ne pousse pas avant ma relecture », le classifieur bloque les actions correspondantes. Mais cette limite n'est pas enregistrée comme une règle : il la relit dans l'historique à chaque contrôle. Quand le contexte est compacté et que le message disparaît, la limite disparaît avec lui. Pour une garantie, la documentation renvoie vers une règle deny.

Il se met en pause quand il bloque trop. Après 3 blocages de suite ou 20 au total dans une session, le mode auto se suspend et les demandes de confirmation reviennent. Ces seuils ne sont pas réglables. Des blocages répétés signalent en général qu'il manque au classifieur la description de votre infrastructure.

4. Les règles allow, ask et deny

Les modes fixent un niveau général. Les règles de permission le précisent, outil par outil et commande par commande. Elles sont évaluées avant tout le reste.

Pour le débutant : trois verbes

• allow : cette action passe sans demander.
• ask : cette action demande toujours une confirmation, même en mode auto.
• deny : cette action est interdite.

Une règle deny bloque dans tous les modes, y compris le mode sans contrôle. C'est la seule garantie ferme de tout le dispositif, et c'est par là qu'il faut commencer.

Pour l'expert : un socle à adapter

L'exemple ci-dessous réunit les formes de règles que montre la documentation. Les chemins et les commandes sont à remplacer par les vôtres, puis à tester sur un poste avant tout déploiement.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "allow": [
      "Bash(npm test)"
    ]
  }
}

Quatre points d'attention.

Les règles larges tombent en mode auto. À l'entrée en mode auto, Claude Code retire les règles allow qui autorisent une exécution arbitraire : un Bash(*) général, un interpréteur avec joker comme Bash(python*), les commandes de lancement des gestionnaires de paquets. Les règles étroites, comme Bash(npm test), restent. Elles reviennent toutes quand on quitte le mode auto.

Une règle porte sur la commande telle qu'elle est écrite. Une règle sur git push ne voit pas un push lancé depuis un script. Ne comptez pas sur une règle Bash pour interdire un effet : interdisez l'accès à ce qui rend l'effet possible, et gardez la protection côté serveur (branches protégées, droits du compte).

Certains chemins sont protégés d'office. Les écritures dans .git, .vscode, .claude, les fichiers de configuration du shell ou .mcp.json ne sont jamais approuvées automatiquement, sauf en mode sans contrôle. Une règle allow n'y change rien.

Une règle ask reste un point d'arrêt en mode auto. C'est le bon outil pour garder un humain devant un push, un déploiement ou une commande d'infrastructure sans renoncer au reste du mode auto.

5. Les paramètres gérés : imposer une politique à toute l'organisation

Un réglage posé par chaque développeur dans son coin ne fait pas une politique. Les paramètres gérés sont les paramètres que l'organisation déploie sur chaque poste. Claude Code les applique au-dessus de tous les autres niveaux : ni l'utilisateur, ni le projet, ni une option de lancement ne les remplace.

Pour le débutant : quatre façons de livrer la politique

Le fichier se place ici :

• macOS : /Library/Application Support/ClaudeCode/managed-settings.json
• Linux et WSL : /etc/claude-code/managed-settings.json
• Windows : C:\Program Files\ClaudeCode\managed-settings.json

Pour l'expert : une politique de départ

{
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  },
  "allowManagedPermissionRulesOnly": true
}

Ce fichier fait quatre choses : il fait démarrer les sessions en mode manuel, il interdit le mode sans contrôle, il bloque deux lectures, et il fait ignorer les règles de permission venues de l'utilisateur, du projet et des options de lancement. Pour retirer aussi le mode auto, ajoutez "disableAutoMode": "disable" dans le bloc permissions. Sans cette clé, fixer defaultMode change le mode de départ, mais chacun peut encore passer en auto pendant la session.

Sur un poste, lancez /status dans Claude Code : la ligne « Setting sources » doit afficher les paramètres d'entreprise et leur source. La commande claude doctor liste les entrées que l'outil a écartées parce qu'elles étaient invalides.

Ce que la politique ne couvre pas

Quatre angles morts sont écrits noir sur blanc dans la documentation, et il vaut mieux les connaître que les découvrir.

• Un seul mécanisme s'applique par défaut. Quand plusieurs sources livrent une politique au même poste, Claude Code retient la mieux classée et ignore les autres, sans avertissement. Les paramètres gérés par le serveur passent avant le MDM, qui passe avant le fichier.
• Les sessions cloud ne lisent pas le poste. Une session exécutée dans un environnement hébergé par Anthropic n'a ni profil MDM ni fichier local. Sa politique doit venir des paramètres gérés par le serveur.
• Un administrateur local peut modifier la source. C'est pour cela que le MDM redéploie le profil à intervalle régulier.
• La politique ne lie que Claude Code. Un développeur qui appelle l'API depuis un autre outil n'est pas concerné. La maîtrise des clés d'API reste un sujet à part.

6. Le bac à sable et l'isolation

Les modes décident si l'outil demande avant d'agir. L'isolation décide de ce qu'une action peut atteindre une fois lancée. Les deux se combinent et ne se remplacent pas.

Pour le débutant : la pièce fermée

Un bac à sable est une pièce fermée dans laquelle la commande s'exécute. Même si elle fait une erreur, elle ne peut toucher que ce qui se trouve dans la pièce. Claude Code embarque un bac à sable pour les commandes du shell, disponible sur macOS, Linux et WSL2.

Pour l'expert : trois niveaux

• Le bac à sable intégré. Il s'active avec la commande /sandbox ou la clé sandbox.enabled. Par défaut, une commande exécutée dans le bac à sable n'a pas d'accès réseau. Les domaines autorisés se déclarent dans sandbox.network.allowedDomains, et le verrou sandbox.network.allowManagedDomainsOnly fait ignorer toute liste qui ne vient pas des paramètres gérés. Le système de fichiers suit la même logique, avec des listes d'autorisation et d'interdiction en lecture et en écriture.
• Le conteneur ou la machine virtuelle. C'est le seul cadre acceptable pour le mode sans contrôle. Sous Linux et macOS, Claude Code refuse d'ailleurs de démarrer dans ce mode avec les droits root, sauf dans un bac à sable reconnu.
• Le poste dédié. Pour les équipes qui touchent la production, un poste ou une session distante sans accès direct aux secrets reste la mesure la plus simple à expliquer et à auditer.

La documentation propose un compromis utile pour ceux qui ne veulent pas du classifieur : le mode manuel associé au bac à sable en acceptation automatique. Les commandes passent sans confirmation tant qu'elles restent dans la pièce fermée, et les règles deny continuent de s'appliquer.

7. Les connecteurs et serveurs MCP

Un serveur MCP donne à Claude Code de nouveaux outils : interroger une base, lire un outil de tickets, piloter un navigateur. Chaque serveur ajouté élargit ce que l'outil peut atteindre, et donc ce qu'un contenu piégé peut lui faire faire. Votre fiche sur les 40 outils à installer dit lesquels valent le détour. Cette section dit qui décide de les brancher.

Pour le débutant : la question à poser

Pour chaque connecteur, trois questions suffisent. À quelles données donne-t-il accès ? Qui l'a écrit et qui le maintient ? Que peut-il envoyer vers l'extérieur ?

Pour l'expert : les verrous disponibles

• allowedMcpServers et deniedMcpServers : la liste des serveurs admis et celle des serveurs interdits.
• allowManagedMcpServersOnly : quand il vaut true, seule la liste d'autorisation venue des paramètres gérés compte. La liste d'interdiction, elle, se cumule depuis toutes les sources.
• managed-mcp.json : un fichier déployé à côté des paramètres gérés pour fournir les serveurs de l'organisation.
• disableClaudeAiConnectors : coupe les connecteurs du compte claude.ai.
• strictKnownMarketplaces et blockedMarketplaces : encadrent les sources depuis lesquelles on peut installer des extensions.

Un piège à connaître : une liste d'autorisation mal formée est appliquée comme une liste vide. Aucun serveur ajouté par les utilisateurs n'est alors admis tant que la valeur n'est pas corrigée. C'est le bon comportement pour la sécurité, et une source de tickets au support si personne n'est prévenu.

8. Les données : ce qui part, où, et pour combien de temps

Claude Code s'exécute sur le poste, mais le modèle est distant. Pour travailler, l'outil envoie par le réseau le contexte de la session : vos demandes, des extraits de fichiers, des résultats de commandes.

Pour le débutant : deux régimes

Tout dépend du contrat sous lequel l'outil est utilisé.

• Offres commerciales (Team, Enterprise, API, plateformes cloud tierces) : Anthropic indique ne pas entraîner ses modèles avec le code et les demandes envoyés, sauf si le client a choisi de fournir ses données. La conservation standard est de 30 jours.
• Offres grand public (Free, Pro, Max) : la conservation est de 30 jours, ou de 5 ans si l'utilisateur a accepté que ses données servent à améliorer les modèles. Le réglage appartient à chaque personne.

La conséquence pratique est immédiate : un développeur qui utilise son abonnement personnel sur du code de l'entreprise le fait sous le régime grand public, avec ses propres réglages. C'est le premier point à vérifier dans un inventaire.

Pour l'expert : trois leviers

• La conservation nulle. Elle existe pour Claude Code sur l'offre Enterprise. Elle n'est pas incluse d'office : elle s'active par organisation, après validation avec l'éditeur.
• Le fournisseur. Claude Code fonctionne aussi au travers d'Amazon Bedrock, de la plateforme d'agents de Google Cloud et de Microsoft Foundry. Le traitement, la région et le contrat sont alors ceux de votre fournisseur cloud. Attention : dans ce cas, les paramètres gérés par le serveur ne sont pas récupérés, et la politique doit venir du MDM ou d'un fichier.
• La télémétrie. L'outil envoie par défaut des mesures de fonctionnement et des rapports d'erreur. La variable DISABLE_TELEMETRY, livrée dans le bloc env des paramètres gérés, la coupe pour tous les postes concernés. Elle coupe aussi les données qui alimentent le tableau de bord d'usage de votre organisation : c'est un arbitrage, pas un réglage neutre.

Pour comparer ce que chaque éditeur fait des données qu'il reçoit, le Trust Index documente les modèles un par un.

9. Les coûts

Trois postes composent la facture, et le troisième est souvent oublié.

• L'accès. Claude Code demande un abonnement payant (Pro, Max, Team, Enterprise) ou un compte facturé à l'usage.
• La consommation du modèle. Elle dépend du modèle choisi, de la taille du contexte et du niveau d'effort demandé. Une tâche longue en mode auto consomme sans que personne ne regarde.
• Le classifieur. Sur l'offre Enterprise, sur les comptes API et chez les fournisseurs cloud, ses appels comptent dans la consommation. Chaque contrôle envoie une partie de l'historique et l'action en attente. Les lectures et les modifications dans le dossier de travail ne passent pas par lui : le surcoût vient surtout des commandes et des accès réseau.

Pour l'expert : trois réglages qui comptent

• Restreindre les modèles. Un modèle fixé dans les paramètres gérés n'est qu'une valeur par défaut, que l'utilisateur peut changer pour sa session. Pour limiter réellement le choix, c'est la clé availableModels qu'il faut déployer.
• Plafonner l'effort. La clé maxEffortLevel fixe un plafond qu'aucune source ne peut relever.
• Suivre l'usage. L'organisation dispose d'un tableau de bord d'usage. Regardez-le pendant le pilote, pas après la première facture.

Pour estimer le coût d'un modèle selon le volume, le Cost Engine fait le calcul sur chaque fiche modèle de nAIvigate.

10. Le plan de déploiement par population

Une politique unique pour toute l'entreprise est soit trop stricte pour les développeurs, soit trop souple pour ceux qui touchent la production. Découpez par population.

Les cinq étapes

1. Inventorier. Qui utilise déjà l'outil, sous quel abonnement, dans quelle version, sur quels dépôts. La version compte : en dessous et au-dessus de la 2.1.283, le mode de départ n'est pas le même.
2. Écrire le socle. Les règles deny, l'interdiction du mode sans contrôle, le mode de départ par population. Une page suffit.
3. Piloter. Une équipe volontaire, deux à quatre semaines, avec relevé des blocages du classifieur et de la consommation. Les blocages à tort disent ce qu'il faut déclarer dans l'infrastructure de confiance.
4. Déployer. Par le mécanisme qui correspond à votre gestion de postes, en vérifiant sur un poste avant de généraliser.
5. Former et réviser. Les équipes doivent savoir ce que fait chaque mode et pourquoi une consigne orale ne remplace pas une règle. La politique se relit à chaque évolution notable de l'outil : celle-ci en est la preuve.

11. Dix erreurs à éviter

1. Laisser le mode de départ au réglage d'usine. Il a déjà changé une fois sans prévenir.
2. Prendre le classifieur pour une garantie. L'éditeur lui-même dit le contraire.
3. Compter sur une consigne dite dans la conversation. Elle disparaît avec le message qui la porte.
4. Autoriser le mode sans contrôle sur un poste de travail. Sa place est dans un conteneur.
5. Fixer defaultMode en croyant avoir retiré le mode auto. Il faut aussi disableAutoMode.
6. Empiler deux mécanismes de livraison sans le savoir. Un seul s'applique, et l'autre est ignoré en silence.
7. Oublier les sessions cloud. Elles ne lisent ni le MDM ni le fichier du poste.
8. Laisser brancher n'importe quel connecteur. Chaque serveur MCP élargit ce que l'outil peut atteindre.
9. Tolérer les abonnements personnels sur le code de l'entreprise. Le régime de données n'est pas le vôtre.
10. Découvrir le coût du classifieur sur la facture. Il se mesure pendant le pilote.

Testez votre compréhension

Questions fréquentes

Faut-il interdire le mode auto ? Pas par principe. Sur un poste de développement, avec des règles deny, une infrastructure de confiance déclarée et un bac à sable, il réduit la fatigue des confirmations, qui pousse elle-même à valider sans lire. Sur un poste qui touche la production, je le retirerais.

Le mode manuel est-il vraiment plus sûr ? Il l'est tant que l'humain lit ce qu'il valide. Après la cinquantième confirmation de la journée, ce n'est plus le cas. La sécurité vient des règles et de l'isolation, que le mode ne remplace pas.

Peut-on empêcher un développeur de contourner la politique ? Sur l'outil, oui : les paramètres gérés ne sont remplacés par aucun réglage personnel. Un administrateur local peut toutefois modifier la source, et la politique ne couvre pas les autres outils qui appellent l'API.

Les réglages s'appliquent-ils à l'application de bureau et aux extensions ? Oui pour le terminal, les extensions VS Code et JetBrains et l'onglet Code de l'application de bureau, qui lisent les mêmes sources. Les sessions cloud suivent une règle différente (section 5).

Claude Code peut-il fonctionner avec un autre modèle que ceux d'Anthropic ? Au travers d'une passerelle, oui, avec une compatibilité variable selon les modèles. Le mode auto, lui, exige un modèle récent pris en charge : sur un autre modèle, la session démarre en mode manuel.

Par où commencer si rien n'est en place ? Par l'inventaire des versions et des abonnements, puis par trois lignes dans un fichier de paramètres gérés : le mode de départ, l'interdiction du mode sans contrôle, et les règles deny sur vos secrets.

Pour aller plus loin

La fiche pratique « Claude Code démarre en mode auto » résume ce guide en une page, à afficher ou à transmettre à une équipe. La leçon CCA-F sur la configuration de Claude Code couvre le versant développeur : fichiers CLAUDE.md, commandes, skills, intégration continue.

Si vous devez poser ces réglages chez vous et former les équipes qui s'en serviront, c'est l'objet du parcours audit, mise en place et formation du Studio.

Pour savoir où vous en êtes, le vérificateur de configuration Claude Code note votre fichier de paramètres et produit le fichier corrigé, sans rien envoyer.

Sources

• Documentation Claude Code, Choose a permission mode : les six modes, le mode de départ par version, le classifieur, les chemins protégés et critiques.
• Documentation Claude Code, Deploy managed settings : mécanismes de livraison, ordre des sources, clés réservées aux paramètres gérés, vérification.
• Documentation Claude Code, Data usage : politique d'entraînement, durées de conservation, télémétrie.
• Mickael Dorigny, « Installation et utilisation de Claude Code : premiers pas », IT-Connect, 2 octobre 2026.

Documentation consultée le 5 octobre 2026. Les numéros de version et les clés de configuration évoluent vite : vérifiez-les sur votre version avant d'écrire votre politique.