Le module Claude Code, MCP & Integration ne se résume pas à une liste de fonctionnalités.
Il présente surtout une manière de raisonner.
Dans une question d’examen, plusieurs réponses peuvent sembler techniquement possibles.
La meilleure réponse sera généralement celle qui :
- limite le risque ;
- réduit le blast radius ;
- sépare clairement les responsabilités ;
- reste portable ;
- est auditable ;
- respecte le modèle d’identité ;
- choisit le mécanisme le plus simple adapté au contexte.
Le document se termine par sept enseignements majeurs.
Ce sont eux qu’il faut être capable de reconnaître dans un scénario.
1. Permission mode is a risk decision, not a speed decision
Le premier principe concerne les permissions de Claude Code.
Il peut être tentant de choisir un mode très permissif simplement pour éviter les confirmations.
Mais le document insiste sur un point :
Permission mode is a risk decision, not a speed decision.
La bonne question n’est donc pas :
« Comment éviter les prompts ? »
mais :
« Que peut-il se passer si Claude exécute une mauvaise action ? »
Penser en blast radius
Le niveau de permission doit dépendre du blast radius potentiel.
Par exemple :
Lecture de documentation
↓
impact faible
contre :
Modification de production
↓
impact élevé
Plus une action est :
- sensible ;
- difficile à inverser ;
- destructive ;
- liée à la production ;
plus les barrières doivent être fortes.
Le piège bypassPermissions
Un réglage comme :
{
"permissions": {
"defaultMode": "bypassPermissions"
}
}
peut être tentant pour accélérer le travail.
Mais l’utiliser par défaut uniquement pour supprimer les validations est un mauvais raisonnement.
Le module associe clairement le choix des permissions au risque.
Ce qu’il faut retenir
Permission
↓
Risk
↓
Blast radius
et non :
Permission
↓
Convenience
2. AI code review findings are findings, not verdicts
Deuxième principe :
An AI code review gives you a set of findings to triage, not a verdict to apply.
Claude peut détecter des problèmes intéressants.
Mais une revue générée par un modèle n’est pas automatiquement une preuve.
Tous les findings n’ont pas le même niveau de confiance
Un finding peut être directement visible dans le code.
Par exemple :
resource opened
+
no close visible
ou :
possible null dereference
Ce type de signal peut être inspecté facilement.
Mais Claude peut également faire une affirmation portant sur :
- le runtime ;
- l’infrastructure ;
- les dépendances externes ;
- le comportement réel en production.
Dans ce cas, une validation supplémentaire est nécessaire.
Le bon workflow
Claude trouve un problème
↓
triage
↓
preuve / test / inspection
↓
confirmed ?
/ \
yes no
↓ ↓
action reject
Le mauvais workflow serait :
Claude signale
↓
modification automatique
Pourquoi c’est important pour l’examen
Une réponse du type :
« Appliquer automatiquement toutes les recommandations de Claude »
est souvent trop agressive.
Le document recommande plutôt de traiter les sorties de code review comme des findings à examiner.
Le human gate devient particulièrement important lorsque la correction proposée est difficile à inverser.
3. Skills are portable only when they are designed to be portable
Troisième principe :
Skills are portable only when designed to be portable.
Un Skill peut parfaitement fonctionner sur la machine de son auteur et échouer partout ailleurs.
Le problème vient souvent de dépendances implicites.
Exemple classique : chemin absolu
Le document fournit un exemple de type :
/Users/priya/scripts/validate-migration.sh
Ce chemin peut fonctionner chez Priya.
Mais sur une autre machine :
/Users/priya/
n’existe pas.
Le Skill semble partageable parce que son fichier peut être versionné.
Mais il n’est pas réellement portable.
Shareable n’est pas portable
C’est une distinction importante :
shareable
≠
portable
Un fichier peut être distribué.
Cela ne signifie pas que ses dépendances existent sur toutes les machines.
Concevoir la portabilité
Un composant réellement portable doit éviter les hypothèses spécifiques à une machine.
Il faut notamment vérifier :
- chemins absolus ;
- scripts locaux ;
- packages installés manuellement ;
- variables d’environnement non documentées ;
- dépendances externes implicites.
Tester depuis un environnement propre
Le module recommande de tester l’installation sur une machine propre.
Pourquoi ?
Parce qu’une machine utilisée depuis longtemps peut contenir de nombreuses dépendances invisibles.
machine auteur
├── script local
├── package global
├── env var
└── config personnelle
Un environnement propre révèle ces hypothèses cachées.
4. Durable context mechanisms have different roles
Quatrième principe :
CLAUDE.md, Rules, Hooks et Subagents ne sont pas quatre façons de faire la même chose.
Ils remplissent des rôles différents.
Il faut savoir choisir le mécanisme adapté.
CLAUDE.md
CLAUDE.md fournit un contexte durable au projet.
Par exemple :
- conventions ;
- architecture ;
- procédures ;
- commandes utiles ;
- contraintes de développement.
Conceptuellement :
CLAUDE.md
↓
instructions persistantes
↓
Claude Code
Rules
Les Rules permettent d’appliquer des instructions plus ciblées.
Elles peuvent être associées à certains contextes ou zones du projet.
Leur rôle reste celui de l’instruction.
Hooks
Les Hooks permettent d’exécuter un comportement déterministe autour d’événements Claude Code.
Le module cite notamment :
PreToolUse
PostToolUse
UserPromptSubmit
Stop
Leur rôle est très différent.
Par exemple :
PreToolUse
→ contrôler avant l'exécution
PostToolUse
→ journaliser après l'exécution
Subagents
Les Subagents permettent de déléguer une tâche dans un contexte séparé.
Le document souligne qu’ils démarrent avec leur propre contexte.
Il ne faut donc pas supposer qu’ils héritent automatiquement de tout ce qui a été discuté dans la session principale.
La distinction fondamentale : instruction vs enforcement
C’est probablement l’une des distinctions les plus importantes du module.
CLAUDE.md / Rules
↓
instructions
contre :
Hooks / permissions
↓
enforcement
Dire :
« Ne fais jamais X »
n’est pas équivalent à empêcher techniquement X.
5. A shareable setup requires portable components
Cinquième principe :
A shareable setup requires portable components.
Ce principe dépasse les Skills.
Il concerne notamment :
- MCP configuration ;
- Hooks ;
- scripts ;
- plugins ;
- autres composants de projet.
.mcp.json n’est pas une garantie de portabilité
Un MCP server peut être déclaré dans :
.mcp.json
Le fichier peut être commité.
Tous les développeurs le récupèrent.
Mais si la configuration lance :
/Users/priya/bin/my-mcp-server
le setup ne fonctionne pas réellement chez les autres.
On obtient :
configuration partagée
✓
composant disponible
✗
Portabilité = configuration + dépendances
Il faut penser :
Shareable setup
=
shareable configuration
+
portable dependencies
Le test décisif est simple :
Une nouvelle personne peut-elle cloner le repository et faire fonctionner l’intégration avec uniquement les dépendances documentées ?
6. MCP transport and scope are independent decisions
Sixième principe :
Transport and scope are independent decisions with dependent consequences.
C’est un point central du module MCP.
Le transport répond à :
Comment le client atteint-il le MCP server ?
Le scope répond à :
À qui la configuration s’applique-t-elle ?
Transport
Le document distingue notamment :
local server
↓
stdio
et :
remote/shared server
↓
HTTP
Scope
Le module distingue :
Local
Project
Enterprise
Les deux axes doivent être séparés
Un raisonnement correct ressemble à :
1. Où tourne le serveur ?
↓
transport
2. Qui utilise la configuration ?
↓
scope
Il ne faut pas déduire automatiquement l’un à partir de l’autre.
Exemple : web scraper expérimental
Le module propose un serveur de scraping expérimental utilisé pendant une semaine sur un repository.
Le scope doit rester :
Local
Mais le transport pourrait être :
stdio
ou :
HTTP
selon l’endroit où tourne réellement le serveur.
C’est un bon exemple montrant l’indépendance des deux dimensions.
Tableau de rappel
| Scénario | Transport | Scope |
|---|---|---|
| SQLite personnel | stdio | Local |
| Code search partagé | HTTP | Project |
| Web scraper expérimental | stdio ou HTTP | Local |
| Security scanner organisationnel | HTTP | Enterprise |
Le raisonnement importe davantage que la mémorisation du tableau.
7. Enterprise integration requirements must be identified before deployment
Septième principe :
Enterprise integration requires security requirements before deployment.
Une intégration peut parfaitement fonctionner et être impossible à mettre en production.
Pourquoi ?
Parce que la production introduit des exigences qui ne sont pas toujours visibles pendant le prototype.
Les dimensions à vérifier
Le module cite notamment :
Identity
+
Authentication
+
Least privilege
+
Secret management
+
Rotation
+
Audit
+
Managed configuration
+
Data residency
Chacune peut devenir un bloqueur de production.
Identity
Première question :
Au nom de qui Claude agit-il ?
Le module distingue :
Remote + user identity
→ OAuth
Remote + service identity
→ API key / service credential
Local
→ file-system permissions
Le mécanisme d’authentification doit découler du modèle d’identité.
Least privilege
Le credential ou l’identité ne doit disposer que des droits nécessaires.
task needs read
↓
grant read
et non :
task needs read
↓
grant admin
L’objectif est de réduire le blast radius.
Secret management
Le module organise ce sujet autour de :
Separation
+
Storage
+
Rotation
Le credential ne doit pas voyager avec la configuration.
Audit
Dans un environnement réglementé, il faut pouvoir savoir ce qui a réellement été exécuté.
Le module propose notamment :
PostToolUse
↓
audit logging
Managed configuration
Lorsqu’une politique doit être imposée à toute l’organisation, elle ne doit pas dépendre uniquement des réglages individuels des développeurs.
Le module associe ce besoin aux enterprise managed settings.
Data residency
Il faut également pouvoir répondre à :
Où les données sont-elles traitées ?
Le choix des endpoints et de l’infrastructure doit correspondre aux exigences de la région concernée.
Le piège du prototype qui devient production
Une architecture peut commencer ainsi :
prototype
↓
API key locale
↓
MCP server
Puis être déployée sans revoir les exigences.
On découvre alors :
clé mal stockée
+
pas d'audit
+
permissions trop larges
+
configuration modifiable
+
mauvaise région
Le système fonctionne.
Mais il n’est pas prêt pour l’entreprise.
Identifier les exigences tôt
Le meilleur workflow est :
Requirements
↓
Architecture
↓
Implementation
↓
Validation
↓
Deployment
et non :
Implementation
↓
Deployment
↓
Security review
↓
redesign
Les 7 principes dans un seul tableau
| Principe | À retenir | Piège |
|---|---|---|
| Permissions | Décision basée sur le risque | Choisir le mode le plus permissif pour gagner du temps |
| AI code review | Findings à trier | Appliquer automatiquement les recommandations |
| Skills | Portabilité à concevoir | Chemins absolus et dépendances locales |
| Durable context | Chaque mécanisme a un rôle | Confondre instruction et enforcement |
| Shareable setup | Tous les composants doivent être portables | Croire qu’un fichier commité suffit |
| MCP transport/scope | Deux axes indépendants | Déduire automatiquement scope depuis transport |
| Enterprise integration | Exigences de sécurité avant production | Les découvrir pendant la security review |
Le modèle mental général du module
On peut résumer tout le chapitre par plusieurs chaînes de décision.
Pour une action Claude Code
Action
↓
Risk
↓
Blast radius
↓
Permission
↓
Approval si nécessaire
Pour une configuration MCP
MCP server
↓
où tourne-t-il ?
↓
Transport
Configuration
↓
qui l'utilise ?
↓
Scope
Puis :
Identity
↓
Authentication
↓
Secrets
↓
Authorization
Pour une opération sensible
Claude propose
↓
PreToolUse / permissions
↓
application autorise
↓
action exécutée
↓
PostToolUse
↓
audit
Ce modèle rappelle une distinction essentielle :
Claude peut demander une action ; l’application et ses contrôles décident si cette action est réellement exécutée.
La grande règle : ne pas confondre capacité et autorisation
Claude peut être capable de :
- supprimer un fichier ;
- appeler une API ;
- modifier du code ;
- exécuter une commande ;
- appeler un MCP tool.
Mais cette capacité ne signifie pas que l’action doit être autorisée.
On doit distinguer :
Can Claude do it?
de :
Should Claude be allowed to do it?
et de :
Under what controls?
Cette distinction revient régulièrement dans les sujets :
- permissions ;
- tool use ;
- MCP ;
- agents ;
- sécurité ;
- environnement enterprise.
Le pattern tool use à toujours garder en tête
Pour raisonner correctement sur Claude et les tools :
Application
↓
Claude
↓
tool_use
↓
Application / MCP layer
↓
authorization + validation
↓
tool execution
↓
tool_result
↓
Claude
↓
réponse
Le point essentiel est :
Claude demande l’utilisation du tool ; l’application reste responsable de l’autorisation et de l’exécution réelle.
Ce principe devient particulièrement important pour les actions :
- sensibles ;
- externes ;
- coûteuses ;
- irréversibles.
Principe d’architecture : choisir le mécanisme le plus simple suffisant
Le module conduit également à un raisonnement général.
Il ne faut pas automatiquement choisir la solution la plus sophistiquée.
Exemple :
service identity
+
API key correctement gérée
ne nécessite pas automatiquement :
OAuth
De même :
outil utilisé par une seule personne
ne nécessite pas automatiquement :
Enterprise managed configuration
La meilleure solution est celle qui répond au besoin avec le bon niveau de sécurité et de complexité.
Trois questions pour repérer les mauvaises réponses d’examen
Lorsqu’une réponse semble plausible, demandez-vous :
1. Augmente-t-elle inutilement le risque ?
Exemple :
bypassPermissions
uniquement pour supprimer les confirmations.
2. Ajoute-t-elle inutilement de la complexité ?
Exemple :
OAuth
pour corriger un simple problème de stockage d’une service API key.
3. Repose-t-elle uniquement sur le comportement du modèle ?
Exemple :
"Demande à Claude de toujours auditer ses actions"
au lieu d’un mécanisme déterministe lorsqu’un audit est obligatoire.
Ces trois tests permettent d’éliminer beaucoup de distracteurs plausibles.
Checkpoint final
Pour chaque scénario Claude Code / MCP, essayez mentalement de compléter cette grille :
1. Quel est l'objectif ?
2. Quel est le blast radius ?
3. Où tourne le MCP server ?
4. Qui reçoit la configuration ?
5. Quelle identité agit ?
6. Comment est-elle authentifiée ?
7. Où sont les credentials ?
8. Les permissions respectent-elles least privilege ?
9. Quels contrôles sont déterministes ?
10. Comment auditer l'exécution ?
11. Une human approval est-elle nécessaire ?
12. Le setup est-il réellement portable ?
13. Existe-t-il une contrainte enterprise ou data residency ?
Si vous savez répondre à ces questions, vous maîtrisez l’essentiel du raisonnement du module.
À retenir pour l’examen
Les sept idées centrales sont :
1. Les permissions sont une décision de risk, pas de confort.
2. Une AI code review produit des findings à vérifier, pas des verdicts.
3. Un Skill n’est portable que si ses dépendances le sont.
4. CLAUDE.md, Rules, Hooks et Subagents remplissent des fonctions différentes.
5. Une configuration partageable exige des composants réellement portables.
6. MCP transport et scope sont deux décisions indépendantes.
7. Les contraintes enterprise — identité, secrets, audit, contrôle et data residency — doivent être identifiées avant le déploiement.
Conclusion
Le point commun entre toutes les situations étudiées dans ce module est le contrôle.
Claude Code et MCP permettent de construire des intégrations puissantes.
Mais plus cette puissance augmente, plus il devient important de déterminer précisément :
ce que Claude sait
+
ce qu'il peut demander
+
ce qu'il est autorisé à faire
+
sous quelle identité
+
avec quelles permissions
+
avec quels secrets
+
avec quelles traces
+
avec quelles validations
Le raisonnement à retenir est donc :
Ne pas seulement demander si l’intégration fonctionne. Demander si elle est sûre, portable, auditable et adaptée à son contexte de déploiement.
C’est cette manière de raisonner qui permet de choisir correctement entre CLAUDE.md, Hooks, permissions, MCP transports, scopes, OAuth, service credentials, managed settings et human approvals.
Et c’est exactement le type de distinction qu’il faut savoir faire rapidement dans une question de certification.
