Déployer Claude Code dans un environnement réglementé ne consiste pas seulement à ajouter davantage de règles de sécurité.
Il faut rendre le système :
- contrôlable ;
- auditable ;
- prévisible ;
- administrable à l’échelle de l’organisation.
Une intégration qui convient parfaitement à une équipe de développement classique peut devenir insuffisante dans un contexte soumis à des exigences de conformité.
Le module met particulièrement en avant quatre dimensions :
- identity et least privilege ;
- enterprise managed configuration ;
- audit logging avec les Hooks ;
- data residency.
L’objectif n’est pas d’empêcher Claude Code d’être utile.
Il s’agit de s’assurer que ses capacités restent compatibles avec les contraintes de l’organisation.
Une permission est une décision de risque
Le module rappelle un principe essentiel :
Permission mode is a risk decision, not a speed decision.
Il peut être tentant de relâcher les permissions pour éviter les demandes de confirmation.
Par exemple, un mode très permissif peut rendre un workflow plus fluide.
Mais il augmente également le blast radius d’une mauvaise action.
Il faut donc inverser le raisonnement.
La question n’est pas :
« Quel mode me fera gagner le plus de temps ? »
mais :
« Quel niveau d’autonomie est acceptable compte tenu des conséquences possibles ? »
Le danger de bypassPermissions
Le module fournit un exemple de configuration problématique :
{
"permissions": {
"defaultMode": "bypassPermissions"
}
}
Le problème est évident dans un environnement sensible.
Ce mode réduit fortement les barrières entre la décision du modèle et l’exécution réelle.
Cela peut être acceptable dans certains environnements contrôlés ou temporaires, mais ce n’est pas un choix à faire uniquement pour supprimer les prompts de confirmation.
Le niveau de permission doit être aligné sur :
impact potentiel
+
réversibilité
+
sensibilité des données
+
niveau de confiance
Évaluer le blast radius
Avant d’autoriser une action, il faut se demander :
Que peut-il se passer si cette action est mauvaise ?
Prenons deux commandes.
Lire un fichier de documentation
et :
Modifier une configuration de production
Ces deux actions n’ont pas le même impact potentiel.
Le niveau de contrôle ne devrait donc pas être identique.
On peut raisonner ainsi :
Action réversible
+
faible impact
↓
plus d'autonomie possible
Action irréversible
+
fort impact
↓
contrôle humain renforcé
C’est l’un des principes les plus importants pour concevoir des workflows Claude Code en production.
Les deny rules comme garde-fous
Une organisation peut empêcher certains accès indépendamment des instructions données au modèle.
Par exemple, le fichier source mentionne une règle destinée à empêcher la lecture d’un fichier de production sensible.
Conceptuellement :
Claude Code
↓
tentative d'accès
↓
deny rule
↓
blocked
L’intérêt est important :
Claude n’a pas seulement reçu l’instruction de ne pas accéder à la ressource.
Le système applique une restriction.
On retrouve à nouveau la distinction :
Instruction
→ comportement souhaité
Restriction
→ comportement autorisé
En environnement réglementé, les règles critiques doivent être déterministes
Une instruction dans CLAUDE.md peut être très utile pour indiquer :
- les conventions ;
- les procédures ;
- les contraintes du projet ;
- les pratiques attendues.
Mais pour des exigences de conformité critiques, cela peut être insuffisant.
Le module distingue clairement les mécanismes de contexte et les mécanismes d’enforcement.
Par exemple :
CLAUDE.md
→ "Do not access production secrets"
contre :
deny rule / Hook
→ access physically blocked
Dans un audit, cette différence est fondamentale.
Pourquoi les enterprise managed settings sont importants
Dans une petite équipe, chacun peut configurer localement Claude Code.
Mais dans une organisation réglementée, cela pose une question :
Qui contrôle réellement la politique de sécurité ?
Si chaque développeur peut modifier :
- ses MCP servers ;
- ses permissions ;
- ses règles ;
- son authentification ;
alors l’entreprise ne peut pas garantir un comportement uniforme.
Le module associe ce besoin aux enterprise managed settings.
Le modèle devient :
Security / IT
↓
managed settings
↓
Claude Code installations
↓
policy commune
Configuration locale vs configuration administrée
Comparons les deux architectures.
Configuration individuelle
Dev A → config A
Dev B → config B
Dev C → config C
Chaque personne peut avoir un setup différent.
Configuration enterprise
IT / Security
↓
managed configuration
/ | \
↓ ↓ ↓
Dev A Dev B Dev C
L’organisation peut alors imposer une base commune.
Pourquoi centraliser certaines règles
La centralisation est particulièrement utile pour les contrôles qui ne doivent pas dépendre du bon vouloir du développeur.
Par exemple :
- MCP servers autorisés ;
- règles de sécurité ;
- restrictions d’accès ;
- exigences d’audit ;
- politiques de permission.
Le principe est :
Une règle d’organisation critique ne doit pas dépendre uniquement d’une configuration individuelle modifiable localement.
L’audit des tool calls
Un environnement réglementé doit souvent pouvoir répondre après coup à une question simple :
Qu’est-ce que Claude Code a réellement fait ?
Il faut pouvoir distinguer :
ce que l'utilisateur a demandé
de :
ce que Claude a proposé
et de :
ce qui a effectivement été exécuté
Cette dernière information est essentielle.
Utiliser PostToolUse pour l’audit
Le module propose un mécanisme précis :
PostToolUse hook
Ce Hook intervient après l’utilisation d’un tool.
Conceptuellement :
Claude
↓
tool_use
↓
tool exécuté
↓
PostToolUse
↓
audit log
Cela permet d’enregistrer les opérations exécutées.
Pourquoi l’audit ne doit pas dépendre du modèle
Une mauvaise architecture consisterait à demander à Claude :
« Pense à journaliser chacune de tes actions. »
Cette approche dépend du comportement du modèle.
Un Hook fournit une garantie plus déterministe :
Tool exécuté
↓
Hook déclenché
↓
trace produite
L’agent n’a pas besoin de décider s’il faut enregistrer l’événement.
Que doit permettre une trace d’audit ?
Le fichier source ne définit pas un format complet de log.
Il soutient toutefois l’idée qu’un PostToolUse hook peut journaliser les tool calls et leurs paramètres dans un audit store.
Conceptuellement, l’objectif est de pouvoir reconstituer :
qui
+
quelle opération
+
sur quelle ressource
+
avec quels paramètres
selon les exigences de l’organisation.
Audit et observabilité ne sont pas exactement la même chose
Une trace technique peut servir à diagnostiquer un bug.
Un audit cherche plutôt à répondre à des questions de gouvernance.
Par exemple :
Le tool a-t-il été appelé ?
Quelle action a été réalisée ?
L'accès était-il autorisé ?
Peut-on reconstituer la séquence ?
Dans un contexte réglementé, cette capacité peut être aussi importante que le fonctionnement du tool lui-même.
Le cas d’un MCP server de security scanning
Le module propose un scénario représentatif :
Un security-scanning MCP server doit être déployé par l’IT sur toutes les installations Claude Code des développeurs.
La combinaison proposée est :
HTTP
+
Enterprise managed settings
Pourquoi ?
Le serveur est :
- distant ;
- partagé ;
- imposé par l’organisation.
L’entreprise ne veut pas seulement rendre le serveur disponible.
Elle veut garantir son utilisation dans le setup prévu.
Architecture conceptuelle
Security / IT
↓
Enterprise configuration
↓
Claude Code clients
↓
HTTP
↓
Security-scanning MCP server
C’est très différent d’un MCP server déclaré librement dans la configuration personnelle d’un développeur.
Identity et least privilege restent essentiels
Centraliser la configuration ne suffit pas.
Il faut également contrôler l’identité utilisée pour accéder aux services.
Le module distingue :
Remote + user identity
→ OAuth
Remote + service identity
→ API key / environment variable
Local
→ file-system permissions
Mais dans tous les cas :
l’identité doit disposer uniquement des permissions dont elle a besoin.
C’est le principe du least privilege.
Pourquoi le least privilege est encore plus important avec un agent
Un credential trop puissant est déjà dangereux dans une application classique.
Dans un système capable d’enchaîner des tools, le risque peut augmenter.
Prenons un credential permettant :
read
write
delete
admin
alors que le workflow ne nécessite que :
read
Le système possède inutilement un pouvoir supplémentaire.
Le bon choix est :
besoin
↓
permissions minimales
et non :
permissions maximales
↓
Claude devrait ne pas les utiliser
Une autorisation technique ne signifie pas qu’une action doit être autonome
C’est un autre point important.
Même si un tool dispose techniquement de la permission d’exécuter une action, cela ne signifie pas que l’agent doit toujours pouvoir la déclencher sans validation.
Pour une action sensible, on peut avoir :
Claude propose
↓
human approval
↓
application exécute
Le principe général du module est de conserver des barrières adaptées au niveau de risque.
Human approval pour les actions à fort impact
Dans les scénarios de modernisation et d’intégration enterprise, le document insiste sur :
- le blast radius ;
- les approvals ;
- l’audit.
Une action irréversible ou particulièrement sensible doit conserver une validation humaine adaptée.
Il faut distinguer :
Claude peut suggérer l'action
de :
Claude est autorisé à provoquer directement l'action
Ce sont deux décisions différentes.
Data residency : où vont les données ?
Une autre exigence des environnements réglementés concerne la data residency.
La question devient :
Dans quelle région les données sont-elles traitées ?
Un système peut être parfaitement sécurisé du point de vue des credentials et rester non conforme si ses données traversent une infrastructure ou une région non autorisée.
Le module présente donc la data residency comme une contrainte d’architecture à prendre en compte avant le déploiement.
MCP et data residency
Un MCP server distant introduit un flux supplémentaire de données.
Par exemple :
Claude Code
↓
HTTP
↓
MCP server
↓
service cible
Il faut pouvoir déterminer où chaque composant s’exécute.
L’organisation doit comprendre le chemin réel suivi par les données.
Utiliser l’endpoint approprié
Le module indique que la data residency peut être prise en compte via :
- un endpoint HTTP dans la région appropriée ;
- une plateforme de déploiement configurée pour maintenir le traitement dans cette région.
Conceptuellement :
Utilisateurs EU
↓
EU endpoint
↓
MCP server EU
↓
services autorisés EU
Le simple fait d’utiliser HTTP n’est donc pas suffisant.
Il faut contrôler où pointe cet endpoint.
La data residency doit être vérifiable
Dans un audit, une réponse vague comme :
« Normalement les données restent en Europe »
n’est pas suffisante.
L’organisation doit pouvoir relier :
configuration
+
infrastructure
+
endpoint
à une localisation de traitement conforme aux exigences applicables.
Le document traite donc la data residency comme une exigence à identifier dès la conception.
Le danger de découvrir ces exigences trop tard
Le module insiste sur un problème classique :
Les exigences enterprise deviennent coûteuses lorsqu’elles sont découvertes pendant la security review finale.
Imaginons une intégration déjà terminée.
Elle utilise :
- une API key hardcodée ;
- aucune trace d’audit ;
- un endpoint dans une région non validée ;
- une configuration modifiable par chaque développeur.
Le système fonctionne techniquement.
Mais il doit alors être profondément remanié avant d’être autorisé en production.
Concevoir avec les contraintes enterprise dès le départ
Le raisonnement préférable est :
Requirements
↓
Architecture
↓
Implementation
↓
Security review
plutôt que :
Implementation
↓
Security review
↓
découverte des exigences
↓
refonte
Cela ne signifie pas qu’un prototype doit implémenter toutes les fonctionnalités enterprise.
Mais les contraintes futures doivent être connues suffisamment tôt.
Prototype et production n’ont pas besoin du même niveau de contrôle
Le module nuance ce point.
Un proof of concept sans données sensibles ne nécessite pas nécessairement :
- enterprise managed settings ;
- audit complet ;
- data residency complexe.
Il faut conserver une architecture proportionnée.
Mais certaines pratiques coûtent peu dès le départ :
pas de credentials hardcodés
+
permissions raisonnables
+
séparation des environnements
Elles évitent une dette de sécurité inutile.
Modernisation de code : même logique de contrôle
Les principes réglementaires rejoignent également ceux du workflow de modernisation présenté dans le module.
Claude Code doit suivre :
Explore → Plan → Code → Verify
Pourquoi ?
Parce qu’il faut contrôler le blast radius avant de modifier un système existant.
Le modèle devient :
Explore
↓
comprendre le système
Plan
↓
définir le changement
Code
↓
modifier
Verify
↓
tester et auditer
Plan mode avant les modifications sensibles
Le document recommande d’utiliser Plan mode avant des modifications complexes ou potentiellement risquées.
Cela permet de séparer :
analyse
de :
modification
Avant d’autoriser des changements, l’équipe peut examiner :
- les fichiers concernés ;
- les dépendances ;
- les risques ;
- le plan de migration.
Cela réduit le risque de changements trop larges ou inattendus.
Explore avant Code
Pour une codebase legacy, demander immédiatement :
« Modernise ce système »
peut conduire à des modifications avec un blast radius mal compris.
Le module privilégie :
Explore
↓
architecture
dépendances
tests
conventions
↓
Plan
Puis seulement :
Code
Cette méthode favorise la maîtrise du changement.
Verify : ne pas confondre génération et validation
Le fait que Claude ait produit une modification cohérente ne prouve pas qu’elle soit correcte.
Le workflow se termine donc par :
Verify
Cela peut inclure selon le projet :
- tests ;
- build ;
- validation ;
- revue des modifications.
Le point essentiel est :
Le travail de Claude doit être vérifié par le système approprié.
Le rôle de l’audit dans un workflow de changement
Dans un environnement sensible, il peut également être nécessaire de conserver une trace des opérations.
On obtient :
Explore
↓
Plan
↓
approval
↓
Code
↓
audit
↓
Verify
Ce type de workflow est plus contrôlé qu’une autonomie complète accordée dès le départ.
Une architecture de contrôle en plusieurs couches
Les différents mécanismes du module peuvent être combinés.
CLAUDE.md
→ instructions
Rules
→ restrictions ciblées
PreToolUse
→ contrôle avant action
Permissions
→ niveau d'autonomie
PostToolUse
→ audit
Managed settings
→ politique organisationnelle
Chaque mécanisme répond à un besoin différent.
Ils ne sont pas interchangeables.
CLAUDE.md
Utilisé pour transmettre un contexte durable au projet.
Par exemple :
conventions
architecture
commandes
restrictions
pratiques
Rules
Permettent d’appliquer des instructions ciblées à certains contextes ou fichiers selon le mécanisme utilisé.
Elles servent à fournir un contexte plus spécifique.
Hooks
Ils introduisent un comportement déterministe autour des événements de Claude Code.
Le module cite notamment :
PreToolUse
PostToolUse
UserPromptSubmit
Stop
Dans le contexte réglementé, PreToolUse et PostToolUse sont particulièrement importants.
Subagents
Les subagents permettent de déléguer une tâche dans un contexte séparé.
Le module rappelle qu’ils commencent avec leur propre contexte.
Ils ne doivent donc pas être supposés disposer automatiquement de tous les éléments implicites de la session principale.
Cette séparation peut être utile pour isoler certaines tâches, mais elle impose également de fournir explicitement le contexte nécessaire.
Ce qu’il faut retenir pour la certification
Quel permission mode choisir ?
Celui qui correspond au niveau de risque, pas celui qui supprime le plus de confirmations.
Pourquoi bypassPermissions est-il risqué ?
Parce qu’il réduit les barrières avant l’exécution et augmente le blast radius potentiel.
Comment imposer une politique à toute l’organisation ?
Avec une configuration administrée au niveau enterprise lorsque le contexte le nécessite.
Comment auditer les tool calls ?
Le module recommande un PostToolUse hook pour journaliser les opérations.
Pourquoi un Hook est-il plus robuste qu’une instruction d’audit ?
Parce que son déclenchement est déterministe et ne dépend pas du choix du modèle.
Pourquoi appliquer le least privilege ?
Pour limiter les conséquences d’une erreur ou d’une compromission.
Quand une human approval devient-elle importante ?
Pour les actions sensibles, à fort impact ou irréversibles.
Qu’est-ce que la data residency ?
L’exigence de contrôler la région dans laquelle les données sont traitées.
Comment la prendre en compte avec un MCP server distant ?
En utilisant une infrastructure et un endpoint conformes à la région requise.
Piège d’examen
Scénario :
Une banque veut utiliser Claude Code avec plusieurs MCP servers internes. Toutes les installations des développeurs doivent utiliser les mêmes serveurs, les actions doivent être auditées, les développeurs ne doivent pas pouvoir contourner facilement la configuration et les données doivent rester dans une région autorisée.
Une réponse insuffisante serait :
« Ajouter les règles dans CLAUDE.md. »
Pourquoi ?
Parce que CLAUDE.md fournit des instructions au modèle mais ne résout pas à lui seul :
- le contrôle centralisé ;
- l’audit déterministe ;
- la data residency ;
- l’enforcement des permissions.
Le raisonnement attendu doit combiner plusieurs mécanismes :
Enterprise managed settings
+
least privilege
+
permission controls
+
PostToolUse audit
+
regional MCP endpoint
La meilleure architecture est celle qui rend les exigences techniquement vérifiables.
Le principe général : instruction, permission, enforcement, audit
Pour raisonner rapidement, utilisez cette grille.
Instruction
Que devrait faire Claude ?
CLAUDE.md
Rules
Permission
Que peut-il faire ?
permission mode
deny rules
Enforcement
Quelles actions doivent être techniquement bloquées ou contrôlées ?
PreToolUse
policies
managed configuration
Audit
Que s’est-il réellement passé ?
PostToolUse
audit store
Cette séparation évite de demander à une seule couche de résoudre tous les problèmes de sécurité.
Conclusion
Claude Code peut être utilisé dans des environnements exigeants, mais l’architecture doit dépasser le simple niveau du prompt.
Il faut penser en plusieurs couches :
Identity
↓
Least privilege
Permissions
↓
Blast radius
Managed settings
↓
Central control
Hooks
↓
Enforcement + Audit
Infrastructure
↓
Data residency
Human approval
↓
Sensitive actions
Le principe essentiel est le suivant :
Les exigences de sécurité importantes doivent être traduites en contrôles techniques vérifiables, et pas uniquement en instructions données au modèle.
Dans un environnement réglementé, la question n’est donc pas seulement :
« Claude Code peut-il réaliser cette tâche ? »
Il faut également demander :
Sous quelle identité ? Avec quelles permissions ? Sous quel contrôle ? Avec quelles traces ? Dans quelle région ? Et avec quelle validation humaine lorsque l’impact l’exige ?
C’est cette approche qui transforme un assistant de développement performant en composant utilisable dans une architecture enterprise gouvernée.
Dans la suite de la série
Moderniser un code legacy avec Claude Code sans perdre le contrôle
Nous verrons comment appliquer Explore → Plan → Code → Verify, utiliser Plan mode avant les changements importants, contrôler le blast radius et intégrer tests, audit et approvals dans un workflow de modernisation.
