D7 · Developer Productivity & Operational Enablement

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/<name>/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.