# D7 · Developer Productivity & Operational Enablement Configurer l’outillage Claude pour les équipes (managed policies, settings versionnés, CLAUDE.md, Skills/commandes/subagents partagés, catalogues MCP), workflows assistés par IA, support opérationnel, mesure de la productivité, et activation pour une adoption sûre. import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components'; C’est le plus petit domaine – **7 %, environ 4 des 63 items** – mais il est à fort rendement car les réponses sont concrètes. Il teste si vous savez **configurer Claude Code pour une équipe** (non pas seulement pour vous), câbler l’IA dans les workflows de développement et la CI, soutenir l’exploitation, mesurer la productivité, et mener un **programme d’activation pour une adoption sûre** avec des garde-fous. Les bonnes réponses favorisent une configuration **versionnée, managée, de moindre privilège** plutôt qu’un paramétrage ad hoc par développeur. ## Objectifs d’apprentissage À la fin de cette page, vous devriez savoir : 1. Configurer l’outillage Claude pour les **équipes** : managed policies, `settings.json` versionnés, la hiérarchie CLAUDE.md, Skills/commandes/subagents partagés, catalogues de serveurs MCP. 2. Améliorer les workflows avec un **outillage assisté par IA** : revue de code, génération de tests, migration, intégration CI en **headless mode**. 3. Soutenir le **débogage et l’exploitation** : runbooks, analyse de traces, dashboards de coût. 4. **Mesurer** la productivité des développeurs de façon pertinente. 5. Mener des **programmes d’activation** avec des garde-fous pour une adoption sûre. --- ## 7.1 Configuring Claude Code for teams La configuration individuelle ne passe pas à l’échelle et ne se gouverne pas. Les équipes ont besoin d’une configuration **partagée, versionnée, imposée par politique**. ### La hiérarchie CLAUDE.md et la précédence des settings ```text Precedence (higher wins / composes down): 1. enterprise / managed policy (admin-controlled, not overridable) 2. user ~/.claude/CLAUDE.md (personal, per-developer) 3. project ./CLAUDE.md (checked in, team standard) 4. subdirectory CLAUDE.md (module-specific) CLAUDE.local.md = git-ignored personal overrides; @path imports pull in shared files ``` | Actif | Emplacement | Pratique d’équipe | | --- | --- | --- | | Standards de code / contexte | `./CLAUDE.md` (versionné) | Source unique des conventions d’équipe ; imports `@path` pour les docs partagés | | Permissions / hooks / env / modèle | `.claude/settings.json` (versionné) | `permissions.allow/deny/ask` ; refuser les commandes destructrices par défaut | | Managed policy | enterprise/managed | Imposer des règles à l’échelle de l’organisation que les développeurs **ne peuvent pas** contourner | | Skills | `.claude/skills//SKILL.md` | Capacités partagées, chargées progressivement | | Slash commands | `.claude/commands/*.md` | Prompts réutilisables avec `$ARGUMENTS` | | Subagents | `.claude/agents/*.md` | System prompt propre, **allowlist d’outils**, modèle ; contexte isolé | | Serveurs MCP | `.mcp.json` (portée projet) | Un **catalogue** validé ; portées local/project/user | :::tip[Signal d’examen] « Standardiser à travers l’équipe / imposer une règle que personne ne peut contourner » → **managed policy** et `.claude/settings.json` + `./CLAUDE.md` **versionnés**, non des fichiers par développeur. « Personnel, ne pas committer » → `CLAUDE.local.md` / `settings.local.json`. ::: :::caution[Moindre privilège dans la config d’équipe] Fixez `permissions.deny` pour les actions destructrices ou hors périmètre et gardez les **allowlists d’outils** des subagents étroites (moindre privilège de D3). Les secrets vont dans `env`/gestionnaires de secrets, jamais dans CLAUDE.md (D5). ::: ### Exemple de settings de managed policy (enterprise) La managed policy est contrôlée par l’administrateur et **ne peut pas être contournée** par les fichiers user, project, ou local. Déployez-la via votre MDM/gestion de configuration vers le chemin de settings managés pour qu’elle s’applique à chaque développeur et chaque dépôt. ```json { "model": "claude-opus-5", "permissions": { "allow": ["Read", "Grep", "Glob"], "ask": ["Edit", "WebFetch"], "deny": [ "Bash(rm -rf:*)", "Bash(git push --force:*)", "Bash(curl:*)", "Read(./.env)", "Read(**/secrets/**)" ] }, "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "/opt/claude/hooks/policy-guard.sh" } ] } ] }, "env": { "ANTHROPIC_MODEL": "claude-opus-5", "DISABLE_TELEMETRY": "false" } } ``` Parce que cela réside dans la managed policy, un `settings.local.json` d’un développeur autorisant `Bash(rm -rf:*)` n’a aucun effet — le `deny` managé l’emporte. ### Disposition d’un catalogue partagé de Skills / commandes / subagents Versionnez un catalogue partagé dans le dépôt pour que chaque développeur hérite des mêmes actifs validés : ```text .claude/ ├── settings.json # team baseline: permissions, hooks, env, model ├── CLAUDE.md # team coding standards (@imports shared docs) ├── skills/ │ ├── api-docs/SKILL.md # house style for API reference docs │ ├── test-authoring/SKILL.md # unit + edge-case test conventions │ └── sql-review/SKILL.md # query review checklist ├── commands/ │ ├── fix-issue.md # /fix-issue (uses $ARGUMENTS) │ ├── review-diff.md # /review-diff │ └── new-endpoint.md # /new-endpoint ├── agents/ │ ├── reviewer.md # read-only, security+style, model: claude-opus-5 │ ├── migrator.md # plan-mode migrations, narrow write scope │ └── explorer.md # read-only codebase Q&A └── .mcp.json # project-scope vetted MCP server catalogue ``` :::tip[Signal d’examen] « Chaque développeur devrait recevoir le même ensemble reviewer/skill/MCP » → un **catalogue `.claude/` versionné** (portée projet), non des installs par développeur. « Personne ne peut contourner la règle de sécurité » → **managed policy**. ::: --- ## 7.2 AI-assisted developer workflows | Workflow | Comment Claude Code aide | Mécanisme | | --- | --- | --- | | Revue de code | Passe de revue automatisée sur les diffs | Subagent/slash command ; CI headless mode | | Génération de tests | Générer/étendre les tests unitaires et de cas limites | Slash command ; Skill | | Migration | Refactors/migrations de version à grande échelle | Plan mode → apply ; subagents | | Exploration de codebase | Répondre aux questions « où/pourquoi » | Outils intégrés ; plan mode en lecture seule | | Intégration CI | Automatisation non interactive | **Headless** `claude -p "…" --output-format json\|stream-json` avec `--allowedTools`, `--permission-mode` | ```bash # Headless code-review step (non-interactive, restricted tools) claude -p "Review the staged diff for security and style issues; output findings as JSON." \ --output-format json \ --allowedTools "Read,Grep" \ --permission-mode plan ``` Utilisez le **plan mode** (Shift+Tab) pour l’exploration en lecture seule avant de faire des changements, et une sortie structurée (`--output-format json`) pour que la CI puisse parser les résultats et gater le build. ### Intégration de revue de code en CI (Claude Code headless) Un job GitHub Actions qui exécute une revue headless en lecture seule sur chaque pull request et publie les constats, gatant le merge sur les problèmes de forte sévérité : ```yaml name: claude-code-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest permissions: contents: read pull-requests: write steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Install Claude Code run: npm install -g @anthropic-ai/claude-code - name: Review staged diff env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} run: | git diff origin/${{ github.base_ref }}...HEAD > /tmp/diff.patch claude -p "Review /tmp/diff.patch for security and style issues. Output JSON: {'findings':[{'severity','file','note'}]}." \ --output-format json \ --allowedTools "Read,Grep" \ --permission-mode plan > review.json - name: Fail on high-severity findings run: | if jq -e '.findings[] | select(.severity=="high")' review.json > /dev/null; then echo "High-severity findings present"; exit 1 fi ``` Notez la posture de moindre privilège : outils en lecture seule, plan mode, sortie structurée que le pipeline peut parser et sur laquelle gater. --- ## 7.3 Support opérationnel : runbooks et analyse de traces | Besoin | Actif d’activation | | --- | --- | | Récupérer d’incidents | **Runbooks** (D6) avec rollback et étapes d’astreinte | | Diagnostiquer les défaillances | **Analyse de traces** via les IDs de corrélation et les arbres de spans (D3) | | Contrôler la dépense | **Dashboards de coût** ; `/cost` dans Claude Code ; télémétrie tokens/coût par équipe | | Tâches d’exploitation répétables | Slash commands et Skills partagés pour les correctifs courants | L’exploitation assistée par IA respecte toujours les garde-fous de D5 : approbation humaine sur les actions irréversibles, outils de moindre privilège, secrets hors du contexte. ### Un flux de runbook / analyse de traces Quand une fonctionnalité adossée à Claude dysfonctionne en production, le runbook pilote un diagnostic répétable : ```text 1. Capture → pull correlation_id from the alert; gather request_ids for the session 2. Classify → integration vs model-output? read HTTP status + stop_reason 429/5xx/timeout/JSON → integration (backoff, timeouts, request fix) hallucination/drift/refusal/max_tokens → model output (prompt/model/validation) 3. Trace → walk the tool sequence per step; look for repeated calls (loop), climbing token usage, or a missing tool result 4. Reproduce → pin model snapshot, temperature 0, frozen system prompt, replay messages 5. Mitigate → runbook action (rollback prompt/model version, raise limit, add validation) irreversible action? require human approval 6. Verify → re-run the golden set / per-segment eval before closing ``` Chaque étape se cartographie vers quelque chose de journalisé : `correlation_id`, `request_id`, `model`, `stop_reason`, `usage`, la latence, et la séquence d’outils. Sans ces logs le runbook ne peut pas démarrer — c’est pourquoi la télémétrie est un prérequis d’activation, non une réflexion après coup. --- ## 7.4 Measuring developer productivity Mesurez les résultats, non les métriques vaniteuses. Les lignes de code ou les décomptes bruts d’acceptations induisent en erreur. | Métrique | Ce qu’elle mesure | Pourquoi c’est important | | --- | --- | --- | | **Cycle time / time-to-merge** | Idée → changement mergé | Vitesse de livraison centrale ; le résultat phare | | **Latence de revue** | Temps qu’une PR attend une revue | Les passes de revue par IA peuvent la réduire nettement | | **Taux d’échappement de défauts** | Bugs atteignant la production par changement | Se prémunit contre la vitesse-au-détriment-de-la-qualité | | **Change failure rate / rework** | Part des changements nécessitant des correctifs | Détecte la sortie IA qui a l’air correcte mais ne l’est pas | | **Coût par PR** | Dépense token/API par changement mergé | Lie la productivité à la dépense ; alimente le ROI | | Signal pertinent | Métrique vaniteuse à éviter | | --- | --- | | Cycle time / time-to-merge | Lignes de code générées | | Change failure rate / rework | Nombre de suggestions IA acceptées | | Débit et qualité de revue | Prompts envoyés | | Friction retirée reportée par les développeurs | Tokens consommés (isolément) | :::tip[Signal d’examen] Une option qui mesure la productivité par les **lignes de code** ou les **suggestions acceptées** est le piège ; la bonne réponse lie la productivité aux **résultats de livraison** (cycle time, latence de revue, échappement de défauts, change-failure rate, coût par PR) — le même état d’esprit par segment, axé sur les résultats, que D4. ::: --- ## 7.5 Enablement programmes and safe-adoption guardrails Déployer l’outillage IA auprès des développeurs est un exercice de gestion du changement (D6) plus un exercice de sûreté (D5). Faites-le par phases et laissez les métriques de résultat gater chaque expansion. ### Programme de déploiement : pilote → champions → échelle | Phase | Qui | Objectifs | Critères de sortie | | --- | --- | --- | --- | | **Pilote** | 1–2 équipes volontaires | Prouver la valeur ; rédiger `CLAUDE.md`, Skills, commandes, catalogue MCP de base ; établir la télémétrie | Signal positif de cycle-time/latence-de-revue ; aucun incident non sûr | | **Champions** | Ambassadeurs intégrés par équipe | Diffuser les bonnes pratiques ; tenir des permanences ; affiner le catalogue partagé ; former sur les limites et la revue | Champions autonomes ; standards stables ; boucle de rétroaction fonctionnelle | | **Échelle** | Toute l’organisation | Imposer les garde-fous managés ; onboarder les équipes restantes ; superviser les dashboards de résultat + coût | Cibles d’adoption atteintes ; garde-fous non contournables ; métriques bien orientées | | Élément | Objectif | | --- | --- | | Onboarding / formation | Enseigner les capacités et les **limites** ; comment revoir la sortie de l’IA | | Standards versionnés | `CLAUDE.md`, commandes, Skills, catalogue MCP comme base partagée | | Garde-fous managés | Permissions/deny lists imposées par politique ; aucun contournement des règles critiques | | Champions / permanences | Diffuser les bonnes pratiques ; capturer la rétroaction | | Déploiement par phases + métriques | Bâtir la confiance ; mesurer les améliorations de résultat avant d’étendre | | Discipline de revue | La sortie de l’IA est revue comme toute contribution (supervision humaine) | --- ## 7.6 Hooks and deterministic enforcement for teams Les hooks sont la couche déterministe qui transforme la politique d’équipe en comportement non contournable. Ils se déclenchent sur des événements du cycle de vie et, sur `PreToolUse`, un **code de sortie 2 bloque** l’action. | Événement de hook | Se déclenche quand | Usage d’équipe | | --- | --- | --- | | `PreToolUse` | Avant qu’un outil s’exécute | Refuser les commandes destructrices, imposer la politique (exit 2 bloque) | | `PostToolUse` | Après qu’un outil s’exécute | Lint/format, journaliser, exécuter les tests sur les éditions | | `UserPromptSubmit` | À chaque prompt utilisateur | Injecter du contexte, scanner les secrets/PII | | `SessionStart` | La session commence | Charger le contexte projet, imprimer les standards | | `Stop` / `SubagentStop` | Fin de tour/subagent | Vérifier la complétion, gater sur des vérifications | | `PreCompact` | Avant la compaction | Capturer l’état | | `Notification` | Sur les notifications | Router vers Slack/pager | ```bash #!/usr/bin/env bash # PreToolUse hook: block destructive git and force-push regardless of prompt wording payload=$(cat) cmd=$(echo "$payload" | jq -r '.tool_input.command // ""') if echo "$cmd" | grep -Eq 'git push --force|rm -rf|drop table'; then echo "Blocked by policy: destructive command '$cmd'" >&2 exit 2 # exit 2 blocks the tool call fi exit 0 ``` :::caution[Un hook, non un prompt] Une règle d’équipe comme « ne jamais force-push » appartient à un **hook `PreToolUse`**, non à une phrase de CLAUDE.md — le même principe d’application programmatique que les garde-fous de D5. Un développeur (ou le modèle) peut ignorer la prose ; un hook qui sort en 2 ne peut pas être contourné. ::: --- ## 7.7 An enablement programme charter (artefact) Un déploiement est un programme avec des propriétaires, des phases et des métriques — non une annonce. ```text ENABLEMENT PROGRAMME — Claude Code across engineering Goal: safe, measurable productivity uplift; guardrails non-overridable. Phase 1 PILOT (weeks 1–4) - Scope: 2 volunteer teams - Build: ./CLAUDE.md, .claude/settings.json (deny list + hooks), 3 Skills, 3 commands, .mcp.json - Telemetry: cycle time, review latency, change-failure rate, cost/PR - Exit: positive signal on ≥1 outcome metric; zero unsafe incidents Phase 2 CHAMPIONS (weeks 5–10) - Embed 1 champion/team; office hours; refine shared catalogue - Train on limits & how to review AI output - Exit: champions self-sufficient; standards stable; feedback loop live Phase 3 SCALE (weeks 11+) - Managed policy enforced org-wide (non-overridable) - Onboard remaining teams; outcome + cost dashboards - Exit: adoption target met; guardrails non-overridable; metrics trending right Guardrails throughout: least-privilege tools, secrets in secret manager, human review of AI output. ``` | Risque de programme | Contrôle | | --- | --- | | Usage fantôme/non gouverné | Fournir le catalogue validé tôt ; faire de la voie balisée la voie facile | | Sortie non sûre livrée | Discipline de revue ; tests PostToolUse ; gate de revue en CI | | Coût emballé | `/cost`, dashboards de coût, budgets/alertes par équipe | | Contournement de garde-fou | Managed policy (non contournable), non des fichiers projet | --- ## 7.8 Scénario détaillé : standardiser Claude Code sur 15 équipes **Scénario.** Un groupe de plateforme doit déployer Claude Code sur 15 équipes. Exigences : un standard de code partout ; une deny-list de commandes destructrices qu’aucun développeur ne peut contourner ; une revue de PR automatisée en CI ; un subagent reviewer partagé et une Skill de style maison pour les docs ; et un dashboard de productivité auquel le directeur fait confiance. Aujourd’hui, chaque développeur a une config personnelle ad hoc et le directeur veut mesurer les « lignes de code générées ». **Trace de raisonnement d’expert.** 1. **Règles non contournables → managed policy.** La deny-list et le hook de revue requis vont dans la **managed/enterprise policy**, déployée via MDM — `CLAUDE.local.md` et les fichiers projet sont contournables et ne satisfont pas « personne ne peut contourner ». 2. **Base partagée → `.claude/` versionné.** `./CLAUDE.md` (standards), `.claude/settings.json` (permissions/hooks/env/modèle), un subagent `reviewer.md` (lecture seule, allowlist étroite), une **Skill** de docs, et un catalogue `.mcp.json` validé — tout dans le dépôt pour que chaque équipe en hérite. 3. **Revue CI → headless mode.** `claude -p … --output-format json --allowedTools "Read,Grep" --permission-mode plan`, gatant les merges sur les constats de forte sévérité. Moindre privilège : lecture seule, sortie structurée. 4. **Corriger la métrique.** Rejetez « lignes de code » (une métrique vaniteuse). Recommandez le **cycle time, la latence de revue, le taux de change-failure/rework, l’échappement de défauts, le coût par PR** — des résultats de livraison. 5. **Déployer par phases.** Pilote → champions → échelle, gaté par les métriques de résultat et protégé par la managed policy. **Pourquoi les alternatives tentantes sont fausses :** un `CLAUDE.local.md` par développeur ne peut pas imposer des règles à l’échelle de l’organisation ; Claude interactif ne peut pas s’exécuter en CI ; donner tous les outils à l’agent CI casse le moindre privilège ; mesurer les lignes de code récompense le volume, non la valeur livrée. --- ## 7.9 Common misconceptions | Idée reçue | Réalité | Pourquoi c’est important à l’examen | | --- | --- | --- | | « `CLAUDE.local.md` peut imposer une règle d’équipe. » | Il est personnel et git-ignored ; utilisez la managed policy pour les règles non contournables. | Les énoncés d’application requièrent la managed policy. | | « Une phrase de CLAUDE.md bloque les commandes destructrices. » | Le blocage nécessite un hook `PreToolUse` (exit 2). | Le prompt comme mécanisme d’application réapparaît en D7. | | « La CI peut exécuter Claude interactif. » | La CI nécessite le headless mode avec des outils restreints et une sortie structurée. | Les énoncés d’intégration CI testent les flags headless. | | « Plus d’outils rendent un subagent plus utile. » | Moindre privilège : restreindre l’allowlist à ce dont la tâche a besoin. | Un subagent sur-privilégié est une mauvaise réponse. | | « Les lignes de code / suggestions acceptées mesurent la productivité. » | Mesurez les résultats de livraison (cycle time, failure rate, coût/PR). | Le distracteur de la métrique vaniteuse est courant. | | « Imposer l’usage pilote l’adoption. » | L’activation + le déploiement par phases + le reporting de valeur pilotent l’adoption. | Les réponses d’usage forcé se retournent contre soi. | | « Les secrets peuvent résider dans CLAUDE.md pour la commodité. » | Les secrets appartiennent aux env/gestionnaires de secrets, jamais à une config visible par le modèle. | Piège du risque d’exfiltration. | --- ## Pièges de l’examen dans ce domaine | Piège | Pourquoi c’est faux | | --- | --- | | Config ad hoc par développeur pour un standard d’équipe | Ne passe pas à l’échelle ni ne se gouverne ; utilisez versionné + managed policy | | Mettre une règle dans un `CLAUDE.local.md` personnel pour imposer à l’échelle de l’organisation | Personnel, git-ignored ; utilisez la managed policy | | Donner un large accès aux outils aux subagents | Viole le moindre privilège ; gardez les allowlists étroites | | Secrets dans CLAUDE.md ou settings | Risque d’exfiltration ; utilisez env/gestionnaires de secrets | | Claude interactif en CI | La CI nécessite le **headless** mode avec des outils restreints | | Mesurer la productivité par les lignes de code / suggestions acceptées | Métriques vaniteuses ; mesurez les résultats de livraison | | Déployer sans formation sur les limites/la revue | Adoption non sûre ; la sortie de l’IA doit être revue | | Sauter les dashboards de coût / `/cost` | Aucune visibilité de dépense ; coût emballé | | Ignorer le plan mode avant de grands changements | Saute l’exploration en lecture seule ; éditions plus risquées | | Aucune protection contre le contournement des politiques critiques | Les développeurs peuvent désactiver les garde-fous | | Imposer un blocage de commande destructrice avec une phrase de CLAUDE.md | Le blocage nécessite un hook `PreToolUse` (exit 2), non de la prose | | Déployer comme une annonce plutôt qu’un programme par phases | Pas de pilote/champions/échelle ; l’adoption et la sûreté souffrent | | Supposer que le code de sortie 0 d’un hook `PreToolUse` bloque un outil | Exit **2** bloque ; 0 autorise | | Onboarder les équipes sans le catalogue `.claude/` validé | Encourage la config fantôme/non gouvernée | | Aucun budget de coût ni alerte par équipe | Le coût peut s’emballer inaperçu à travers les équipes | --- ## Questions d’entraînement A. Demander à chaque développeur d’ajouter les règles à son `CLAUDE.local.md`. B. Une managed/enterprise policy plus un `./CLAUDE.md` et un `.claude/settings.json` versionnés avec `permissions.deny`, puisque la managed policy ne peut pas être contournée. C. Un message Slack partagé avec les règles. D. Envoyer les standards par e-mail chaque trimestre. **Réponse : B.** L’application non contournable à l’échelle de l’organisation est exactement ce que fournit la managed policy, avec la config projet versionnée comme base partagée. Le `CLAUDE.local.md` personnel (A) est git-ignored et contournable ; Slack (C) et l’e-mail (D) ne sont pas de l’application. A. Exécuter Claude interactif et faire coller le diff par un humain. B. Utiliser le headless mode : `claude -p '…' --output-format json` avec un `--allowedTools` restreint et un `--permission-mode` approprié, pour que la CI puisse parser les constats et gater le build. C. Donner tous les outils à l’agent CI pour la flexibilité. D. Désactiver les permissions en CI pour éviter la friction. **Réponse : B.** La CI est non interactive, donc le headless mode avec sortie structurée et outils restreints est correct. L’usage interactif (A) ne peut pas s’exécuter en CI ; tous-les-outils (C) et les permissions désactivées (D) violent le moindre privilège. A. La coller dans chaque prompt. B. Comme une Skill versionnée (`.claude/skills//SKILL.md`) chargée à la demande. C. Dans le `CLAUDE.local.md` de chaque développeur. D. Dans un fichier de settings personnel. **Réponse : B.** Les Skills packagent une capacité réutilisable et se chargent progressivement ; les versionner les partage à travers l’équipe. Coller par prompt (A) gonfle le contexte ; les fichiers personnels (C, D) ne partagent ni ne gouvernent. A. Ce sont de bonnes métriques principales. B. Mesurer les résultats de livraison — cycle time, taux de change-failure/rework, qualité de revue — car les lignes de code et les décomptes de suggestions acceptées sont des métriques vaniteuses qui ne reflètent pas la valeur. C. Mesurer les tokens consommés à la place. D. Ne pas mesurer la productivité du tout. **Réponse : B.** La productivité doit se lier aux résultats de livraison, non à des métriques de volume. Les lignes/acceptations (A) et les tokens (C) sont des signaux vaniteux ; ne pas mesurer (D) sacrifie la capacité à démontrer la valeur. A. Restreindre l’allowlist d’outils du subagent aux outils d’exploration en lecture seule dont il a réellement besoin. B. Garder le large ensemble d’outils pour la flexibilité. C. Utiliser le plan/mode lecture seule pour l’exploration et n’accorder l’accès en écriture que là où une tâche l’exige. D. Mettre des identifiants dans le CLAUDE.md du subagent pour qu’il agisse librement. E. Lui donner tous les serveurs MCP du catalogue. **Réponse : A et C.** Moindre privilège : restreindre l’allowlist à ce dont la tâche d’exploration a besoin et utiliser le mode lecture seule/plan, n’accordant plus que lorsque c’est requis. Un large ensemble d’outils (B) et tous les serveurs MCP (E) sont de l’agence excessive ; les identifiants dans CLAUDE.md (D) sont un risque d’exfiltration. A. Une formation qui couvre les limites de Claude et comment revoir la sortie de l’IA. B. Des standards versionnés (CLAUDE.md, commandes, Skills, catalogue MCP) plus des garde-fous managés et un déploiement par phases avec des métriques de résultat. C. Un usage obligatoire immédiat à l’échelle de l’organisation sans support. D. Retirer la revue humaine du code généré par IA pour aller plus vite. E. Laisser chaque développeur ajouter des serveurs MCP non validés. **Réponse : A et B.** L’adoption sûre associe l’activation (formation sur les limites/la revue) à des standards versionnés et gouvernés, des garde-fous et un déploiement par phases. L’usage forcé sans support (C), le retrait de la revue (D), et les serveurs MCP non validés (E) sont non sûrs. A. Des rapports de lignes de code. B. Des dashboards de coût alimentés par la télémétrie token/coût par requête, plus `/cost` dans les sessions Claude Code. C. Une facture trimestrielle uniquement. D. Désactiver la journalisation pour économiser. **Réponse : B.** La télémétrie token/coût par requête affichée dans des dashboards (et `/cost`) donne une visibilité et un contrôle réels de la dépense. Les rapports LOC (A) sont sans rapport ; une facture trimestrielle (C) est trop grossière ; désactiver la journalisation (D) retire les données mêmes nécessaires. A. Appliquer tous les changements immédiatement et revoir après. B. Utiliser le plan mode (lecture seule) pour explorer et produire un plan, puis appliquer les changements avec les permissions et tests appropriés. C. Donner à l’agent un accès en écriture et shell sans restriction. D. Sauter les tests pour finir plus vite. **Réponse : B.** Le plan mode explore en lecture seule et produit un plan revisable avant les éditions, réduisant le risque sur les grands changements. Appliquer à l’aveugle (A), l’accès sans restriction (C), et sauter les tests (D) augmentent tous le rayon d’impact. A. Le `.claude/settings.json` projet de chaque équipe. B. Les settings de managed policy (chemin contrôlé par l’administrateur), car ils ne peuvent pas être contournés par les fichiers user, project, ou local. C. Le `settings.local.json` de chaque développeur. D. Une page de wiki de directives. **Réponse : B.** Seule la managed policy est non contournable et s’applique à l’échelle de l’organisation, ce qui est exactement l’exigence. Les settings projet (A) peuvent être contournés par dépôt et ne sont pas garantis partout ; le `settings.local.json` (C) est personnel et git-ignored ; un wiki (D) n’est pas de l’application. A. Imposer l’usage à l’échelle de l’organisation dès le premier jour pour maximiser le ROI. B. Piloter avec 1–2 équipes et établir la télémétrie, puis des champions pour diffuser la pratique et affiner les standards partagés, puis passer à l’échelle de l’organisation avec des garde-fous managés et des dashboards de résultat/coût. C. Laisser chaque développeur adopter ce qu’il veut sans standards. D. Déployer à tout le monde mais désactiver la revue pour aller plus vite. **Réponse : B.** Pilote → champions → échelle, gaté par les métriques de résultat et protégé par des garde-fous, est le patron sûr de gestion du changement. Une obligation dès le premier jour (A) et un chacun-pour-soi non gouverné (C) sautent la construction de confiance et la standardisation ; désactiver la revue (D) retire la protection de supervision humaine. A. Capturer l’ID de corrélation et rassembler les request IDs de la session affectée. B. Réécrire immédiatement le system prompt et redéployer. C. Classer la défaillance en intégration vs sortie-modèle à l’aide du statut HTTP et de `stop_reason`. D. Redémarrer tous les services et espérer que ça se règle. E. Supprimer les logs pour réduire le bruit. **Réponse : A et C.** Le diagnostic commence par capturer les identifiants et classer la couche à partir de signaux concrets (code de statut, `stop_reason`) pour appliquer le bon correctif. Les réécritures de prompt à l’aveugle (B) et les redémarrages (D) sautent le diagnostic ; supprimer les logs (E) détruit les preuves dont dépend le runbook. A. Les lignes de code générées et le nombre de suggestions acceptées. B. Le cycle time / time-to-merge, la latence de revue, le taux d’échappement de défauts, le taux de change-failure/rework, et le coût par PR. C. Les prompts envoyés par développeur par jour. D. Les tokens consommés par développeur. **Réponse : B.** Celles-ci lient la productivité aux résultats de livraison et au coût, résistant au gaming et reflétant la valeur réelle. Les lignes de code et suggestions acceptées (A), les décomptes de prompts (C), et la consommation brute de tokens (D) sont des métriques vaniteuses qui ne mesurent ni la valeur livrée ni la qualité. A. Une phrase dans `./CLAUDE.md`. B. Un hook `PreToolUse` (le code de sortie 2 bloque l’appel) livré via la managed policy pour qu’il ne puisse pas être contourné. C. Une note dans le `CLAUDE.local.md` de chaque développeur. D. Un rappel Slack. **Réponse : B.** Le blocage déterministe et non contournable est un hook `PreToolUse` (exit 2) imposé via la managed policy. Une phrase de CLAUDE.md (A) est de l’orientation en prose ; `CLAUDE.local.md` (C) est personnel/contournable ; Slack (D) n’est pas de l’application. A. Exit 0. B. Exit 2. C. Exit 1 uniquement. D. Tout code non nul imprime un avertissement mais ne bloque jamais. **Réponse : B.** Un hook `PreToolUse` bloque l’outil quand il sort avec le code 2. Exit 0 (A) autorise ; la sémantique de blocage est spécifiquement exit 2, non simplement tout code non nul (C, D). A. Piloter avec 2 équipes et la télémétrie, puis des champions pour diffuser la pratique, puis passer à l’échelle de l’organisation. B. Imposer la deny-list et le hook de revue requis via la managed policy (non contournable) plus un catalogue `.claude/` versionné. C. Imposer l’usage à l’échelle de l’organisation dès le premier jour pour maximiser le ROI. D. Laisser chaque équipe choisir ses propres serveurs MCP non validés. E. Mesurer le succès par les lignes de code générées. **Réponse : A et B.** Un déploiement par phases plus l’application par managed policy et un catalogue partagé versionné est le patron sûr. Une obligation dès le premier jour (C) saute la construction de confiance ; les serveurs MCP non validés (D) cassent la gouvernance ; les lignes de code (E) sont une métrique vaniteuse. A. Garder le large ensemble d’outils pour la flexibilité. B. Restreindre l’allowlist d’outils du subagent aux outils en lecture seule (p. ex. Read, Grep) dont il a réellement besoin pour la revue. C. Lui donner aussi tous les serveurs MCP. D. Mettre des identifiants dans son fichier d’agent. **Réponse : B.** Le moindre privilège restreint le subagent aux outils en lecture seule dont sa tâche a besoin. Un large ensemble (A) et tous les serveurs MCP (C) sont de l’agence excessive ; les identifiants dans le fichier d’agent (D) sont un risque d’exfiltration. A. Une date de calendrier fixe indépendamment des résultats. B. Un signal positif sur au moins une métrique de résultat de livraison (p. ex. cycle time ou latence de revue) sans incident non sûr. C. Le nombre de prompts envoyés par les développeurs. D. Les lignes de code générées par Claude. **Réponse : B.** Les gates de phase sont fondés sur les résultats : démontrer une amélioration de résultat de livraison en toute sécurité avant d’étendre. Une date de calendrier (A) ignore les résultats ; les décomptes de prompts (C) et les lignes de code (D) sont des métriques vaniteuses. A. Non ; les hooks ne peuvent que bloquer, jamais exécuter du travail de suivi. B. Oui ; `PostToolUse` se déclenche après qu’un outil s’exécute, ce qui en fait le bon endroit pour lint/format et exécuter les tests sur les éditions. C. Non ; les tests doivent être manuels. D. Oui, mais seulement dans `UserPromptSubmit`. **Réponse : B.** `PostToolUse` s’exécute après qu’un outil est terminé, ce qui est exactement là où le lint/format/tests post-édition appartiennent. Les hooks font plus que bloquer (A) ; les tests automatisés sont appropriés (C) ; `UserPromptSubmit` (D) se déclenche sur les prompts, non après les éditions. ## À retenir - Configurez pour les **équipes** : managed policy (non contournable) + `./CLAUDE.md` et `.claude/settings.json` versionnés, non des fichiers ad hoc par développeur. - Partagez **Skills, slash commands, subagents et un catalogue MCP validé** ; gardez les **allowlists d’outils des subagents étroites** et les secrets dans les env/gestionnaires de secrets. - Câblez l’IA dans les workflows via le **headless mode** en CI avec sortie structurée et outils restreints ; utilisez le **plan mode** avant les grands changements. - Soutenez l’exploitation avec des **runbooks, l’analyse de traces et des dashboards de coût** (`/cost`). - Mesurez la productivité par les **résultats de livraison** (cycle time, failure rate, qualité), jamais les lignes de code ou les décomptes de suggestions acceptées. - Menez une **activation pour une adoption sûre** : formation sur les limites et la revue, standards versionnés, garde-fous managés, et déploiement par phases avec métriques de résultat. - Imposez les règles d’équipe avec des **hooks** (`PreToolUse` exit 2 bloque ; `PostToolUse` lint/tests) livrés via la **managed policy**, non la prose de CLAUDE.md. - Menez le déploiement comme un **programme** (pilote → champions → échelle) avec des **critères de sortie** fondés sur les résultats, non une annonce. - Gardez les subagents en **moindre privilège** (allowlist d’outils étroite), les secrets dans les gestionnaires de secrets, et gatez l’expansion sur des signaux de résultat de livraison, jamais des métriques vaniteuses.