Faire fonctionner Claude Code avec un MCP server est une première étape. Construire une intégration que l’on peut partager avec une équipe, connecter à des systèmes réels et déployer dans un environnement d’entreprise en est une autre.
Dès que Claude Code sort du poste d’un développeur pour accéder à un repository partagé, une base de données, une API interne ou un service SaaS, plusieurs questions deviennent essentielles :
- quelles actions Claude Code est-il autorisé à effectuer ?
- comment empêcher l’accès à certaines ressources sensibles ?
- où stocker les API keys et autres credentials ?
- faut-il utiliser
stdioou HTTP pour un MCP server ? - quelle différence entre une configuration Local, Project ou Enterprise ?
- quand utiliser OAuth plutôt qu’une API key ?
- comment rendre une configuration portable entre plusieurs développeurs ?
- comment auditer les actions réalisées par l’agent ?
- comment sécuriser une intégration destinée à un environnement réglementé ?
- où placer une validation humaine lors d’une opération à fort impact ?
Ces questions montrent une idée centrale : une intégration Claude Code ou MCP ne doit pas seulement fonctionner ; elle doit être contrôlable, partageable, auditable et adaptée au niveau de risque du système auquel elle accède.
Cette série étudie ces différents mécanismes et surtout la manière dont ils s’articulent.
1. Les permissions sont une décision de risque
Claude Code propose différents permission modes qui déterminent dans quelles circonstances l’agent doit demander une confirmation avant d’exécuter une action.
Le choix du mode ne doit pas être guidé uniquement par le confort ou par la volonté de supprimer les confirmations.
Il doit dépendre du risk profile de l’environnement.
Un agent travaillant dans un environnement isolé n’a pas le même niveau de risque qu’un agent capable de modifier un repository important ou d’accéder à des données de production.
Le principe à retenir est donc :
Permission mode is a risk decision, not a speed decision.
Des deny rules peuvent compléter les permission modes afin d’interdire explicitement l’accès à certaines ressources sensibles.
Cette distinction devient particulièrement importante lorsqu’un agent dispose de nombreuses capacités : plus le blast radius potentiel est important, plus les garde-fous doivent être explicites.
2. CLAUDE.md, rules, hooks et subagents ne jouent pas le même rôle
Claude Code propose plusieurs mécanismes pour contrôler son comportement et conserver du contexte durable.
Ils ne sont pas interchangeables.
CLAUDE.md
CLAUDE.md contient les conventions et contraintes générales du projet qui doivent s’appliquer aux sessions Claude Code.
Il constitue une forme de contexte projet persistant.
Mais il ne faut pas essayer d’y placer toutes les règles possibles.
Un fichier trop volumineux risque de diluer les instructions importantes.
Rules files
Les rules instruction files permettent de limiter certaines instructions aux chemins ou contextes où elles sont réellement nécessaires.
Ils évitent d’encombrer CLAUDE.md avec des règles qui ne concernent qu’une partie du projet.
Hooks
Les hooks répondent à un autre besoin.
Ils permettent d’exécuter une logique déterministe lors de certains événements de Claude Code, notamment :
PreToolUse;PostToolUse;UserPromptSubmit;Stop.
C’est une distinction fondamentale en matière de sécurité.
Une instruction dans CLAUDE.md indique à Claude ce qu’il devrait faire.
Un hook peut contrôler ce que le système autorise réellement.
Subagents
Les subagents permettent quant à eux de déléguer certaines tâches dans un contexte séparé.
Ils sont particulièrement utiles pour éviter que des opérations d’exploration importantes ne saturent le contexte principal.
Ces quatre mécanismes répondent donc à des problèmes différents :
CLAUDE.md
→ conventions générales du projet
Rules
→ instructions ciblées
Hooks
→ enforcement déterministe
Subagents
→ isolation du travail et du contexte
3. Sécuriser les credentials MCP
L’un des exemples les plus importants du module concerne une API key placée directement dans .mcp.json.
Une configuration comme celle-ci est dangereuse :
{
"type": "http",
"url": "https://warehouse.internal/mcp",
"headers": {
"Authorization": "Bearer sk-abc123..."
}
}
Si le fichier est ajouté à Git, le credential entre également dans l’historique du repository.
Le supprimer dans un commit suivant ne suffit pas : l’ancienne valeur reste présente dans l’historique.
Une clé ainsi exposée doit être considérée comme compromise et faire l’objet d’une rotation.
La bonne approche consiste à séparer configuration et secret :
{
"type": "http",
"url": "https://warehouse.internal/mcp",
"headers": {
"Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}"
}
}
Le fichier contient uniquement la référence.
La véritable valeur est conservée ailleurs.
C’est le principe :
le credential ne doit jamais voyager avec la configuration qui le référence.
4. Environment variables, secret stores et rotation
Sortir le secret du fichier ne répond qu’à une partie du problème.
Il faut également déterminer où conserver sa véritable valeur.
Pour un credential utilisé sur une machine ou injecté pendant l’exécution d’un pipeline, une environment variable peut suffire.
Lorsqu’un secret doit être partagé entre plusieurs services ou soumis à des exigences d’audit, un managed secret store devient plus approprié.
Trois pratiques se complètent alors :
Separation
Le secret reste séparé de la configuration.
Storage
La valeur est conservée dans un emplacement adapté : environment variable ou secret store.
Rotation
Le credential peut être remplacé régulièrement ou immédiatement après une exposition.
Une architecture correcte permet de changer la valeur sans modifier le code qui la consomme.
5. Transport MCP et scope sont deux décisions différentes
Une configuration MCP doit répondre à deux questions distinctes :
Comment le client communique-t-il avec le serveur ?
et :
À qui cette configuration doit-elle s’appliquer ?
C’est la distinction entre transport et scope.
stdio
stdio correspond aux MCP servers exécutés localement sur la machine.
HTTP
HTTP correspond aux services hébergés à distance, notamment lorsqu’ils doivent être utilisés par plusieurs développeurs.
Le scope détermine ensuite comment la configuration est distribuée.
Le document distingue notamment les configurations :
- Local ;
- Project via
.mcp.json; - Enterprise via managed settings.
Le point important est que transport et scope sont indépendants, mais leur combinaison doit rester cohérente avec le scénario de déploiement.
Un outil SQLite utilisé uniquement sur le poste d’un développeur n’a pas les mêmes besoins qu’un service de recherche de code hébergé sur l’infrastructure de l’entreprise et partagé par toute l’équipe.
6. Une configuration partageable doit être portable
Partager une intégration Claude Code ne consiste pas simplement à copier des fichiers.
Les composants doivent également fonctionner sur les autres machines.
Prenons un Skill contenant :
/Users/priya/scripts/validate-migration.sh
Cette configuration fonctionne sur la machine de Priya.
Mais une fois le Skill installé chez un autre développeur, ce chemin n’existe probablement pas.
Le composant n’est donc pas réellement portable.
Skills, hooks, plugins et configurations destinés à être distribués doivent éviter les hypothèses propres à la machine de leur auteur.
Cela implique notamment :
- des chemins relatifs au projet lorsque cela est approprié ;
- des dépendances clairement définies ;
- des variables d’environnement documentées ;
- des tests depuis un environnement propre avant distribution.
Un composant est portable non pas parce qu’il peut être copié, mais parce qu’il peut fonctionner dans l’environnement où il sera installé.
7. OAuth ou service credential ?
Le mécanisme d’authentification dépend du service auquel Claude doit accéder et du modèle d’identité utilisé.
Remote service avec user identity
Lorsque l’identité de l’utilisateur fait partie du modèle d’autorisation, OAuth est le mécanisme adapté.
Le service peut répondre par exemple avec :
401 Unauthorized
Le client déclenche alors le processus d’authentification et l’utilisateur autorise l’accès.
Le token est ensuite émis et stocké.
Remote service avec service identity
Pour un service interne fonctionnant avec une identité technique, une API key peut être utilisée.
Mais sa valeur doit être conservée hors de la configuration, par exemple dans une environment variable.
Service local
Pour une ressource locale, les file-system permissions et les règles d’accès peuvent constituer le mécanisme de contrôle pertinent sans qu’un credential distant soit nécessaire.
Le choix du mécanisme d’authentification doit donc découler du modèle d’identité du service, et non d’une préférence arbitraire.
8. OAuth : attention au passage staging → production
Une intégration OAuth peut fonctionner parfaitement en staging puis échouer immédiatement en production.
Pourquoi ?
Parce que les redirect URIs autorisées sont enregistrées auprès du fournisseur OAuth.
Une URI configurée pour :
staging.mycompany.com
ne signifie pas automatiquement que :
production.mycompany.com
est autorisée.
Lors d’un changement d’environnement, il faut donc vérifier les redirect URIs enregistrées.
Dans certains environnements enterprise, staging et production peuvent également nécessiter des OAuth app registrations séparées.
Ce point doit faire partie de la checklist de déploiement plutôt que d’être découvert lors de la première authentification en production.
9. Ce qui change dans un environnement réglementé
Une intégration qui fonctionne techniquement n’est pas nécessairement prête pour un environnement financier, médical ou soumis à des exigences de conformité.
Plusieurs questions supplémentaires apparaissent :
Qui est Claude lorsqu’il accède au système ?
L’identité doit être contrôlable et auditable.
À quelles données peut-il accéder ?
Les permissions doivent respecter le principe du least privilege.
Où les données sont-elles traitées ?
La data residency peut devenir une exigence de conformité.
Les actions sont-elles enregistrées ?
Des mécanismes d’audit doivent permettre de savoir quelles opérations ont été exécutées.
Un développeur peut-il modifier la configuration de sécurité ?
Une organisation peut avoir besoin d’une configuration centralisée et verrouillée via des enterprise managed settings.
L’intégration doit donc prendre en compte :
Identity
+ permissions
+ secrets
+ audit
+ data residency
+ configuration control
10. Utiliser les hooks pour l’audit
Les hooks ne servent pas uniquement à empêcher des actions.
Un PostToolUse hook peut également enregistrer les tool calls dans un système d’audit.
Cela permet de conserver une trace des opérations réalisées.
Le caractère déterministe du hook est ici important : l’audit ne dépend pas du fait que le modèle décide ou non de produire un log.
Le mécanisme externe s’exécute à chaque événement concerné.
On retrouve encore une fois la différence fondamentale entre :
demander au modèle d’adopter un comportement
et
concevoir le système pour imposer ce comportement.
11. Moderniser un codebase legacy avec Claude Code
La modernisation d’un système existant concentre plusieurs risques :
- codebase peu familier ;
- nombreuses dépendances ;
- changements importants ;
- conséquences parfois difficiles à anticiper ;
- réversibilité limitée.
Le workflow central présenté dans le module repose sur une progression contrôlée :
Explore
↓
Plan
↓
Code
↓
Verify
Le Plan mode permet notamment de maintenir Claude dans une phase d’exploration en lecture seule avant d’autoriser les modifications.
L’objectif est d’examiner le plan proposé avant que l’agent ne commence à modifier les fichiers.
Pour les tâches à fort risque, trois questions doivent être posées avant de commencer.
Quel est le blast radius ?
Quels systèmes dépendent du code modifié et quelles seraient les conséquences d’une erreur ?
Comment les changements seront-ils audités ?
Existe-t-il une trace permettant de déterminer ce que l’agent a modifié ou exécuté ?
Qui approuve le passage à la phase suivante ?
Le système peut créer une frontière technique entre exploration et exécution, mais l’organisation doit également déterminer qui donne l’autorisation de franchir cette frontière.
Les 7 principes essentiels à retenir
Le module aboutit à sept enseignements particulièrement importants.
1. Permission mode = décision de risque
Ne choisissez pas un mode simplement pour supprimer les confirmations. Adaptez-le au niveau de risque de l’environnement.
2. Une AI code review produit des findings, pas un verdict
Les conclusions vérifiables dans le diff peuvent être contrôlées directement. Les affirmations concernant un comportement externe ou runtime doivent être testées avant d’être considérées comme établies.
3. Un Skill peut être portable, mais la portabilité doit être conçue
Évitez les chemins absolus et les dépendances implicites à la machine de l’auteur.
4. Chaque mécanisme de contexte possède son rôle
CLAUDE.md, rules, hooks et subagents répondent à des problèmes différents.
5. Un setup partageable nécessite des composants portables
Une configuration qui fonctionne uniquement sur la machine de son auteur n’est pas réellement partageable.
6. Transport et scope MCP sont deux décisions distinctes
stdio ou HTTP détermine comment communiquer avec le MCP server. Local, Project ou Enterprise détermine comment et avec qui la configuration est partagée.
7. La sécurité enterprise doit être pensée avant le déploiement
Identity, authentication, secrets, audit, data residency et configuration control doivent faire partie de la conception initiale.
Sommaire de la série
Cet article sert de point d’entrée vers les articles détaillés :
Article 1 — Claude Code & MCP : sécuriser les clés API et les fichiers de configuration
API keys, .mcp.json, environment variables, secret stores, rotation et PreToolUse hooks.
Article 2 — MCP : choisir le bon transport et le bon scopestdio, HTTP, Local, Project et Enterprise.
Article 3 — Authentifier Claude et MCP dans un environnement d’entreprise
User identity, service identity, OAuth, API keys et file-system permissions.
Article 4 — Secrets et credentials : separation, storage et rotation
Environment variables, secret stores, least privilege et gestion opérationnelle des rotations.
Article 5 — OAuth et MCP : réussir le passage du staging à la production
Redirect URIs, environnements et erreurs d’authentification.
Article 6 — Claude Code en environnement réglementé
Audit, PostToolUse, managed settings, data residency et contrôle centralisé.
Article 7 — Moderniser un code legacy avec Claude Code sans perdre le contrôle
Blast radius, Plan mode, audit, approbation humaine et workflow Explore → Plan → Code → Verify.
Article 8 — Claude Code, MCP et intégration : les 7 principes à retenir
Synthèse orientée révision et certification.
À retenir
La question centrale n’est pas seulement :
« Claude peut-il effectuer cette tâche ? »
Il faut également se demander :
« Dans quelles limites peut-il l’effectuer, avec quelle identité, quels accès, quels secrets, quelles traces et quelles validations ? »
C’est ce passage d’une intégration simplement fonctionnelle à une intégration contrôlée, portable, auditable et sécurisée qui permet de passer d’un prototype Claude Code/MCP à une utilisation adaptée à une équipe et, lorsque nécessaire, à un environnement enterprise.
