Réponse : B. Le symptôme décrit — consignes qui se contaminent entre capacités hétérogènes — est le signal canonique de découpage. L’orchestrateur-routeur isole chaque spécialité : prompt court et net, outils minimaux, testabilité par agent. A aggrave la contamination (prompt encore plus long). C (consensus) répond à un problème de fiabilité d’une même tâche, pas d’hétérogénéité des tâches. D traite le symptôme, pas la cause : la puissance du modèle ne remplace pas la séparation des responsabilités.

Réponse : B. L’isolation de contexte est le bénéfice architectural central : les milliers de tokens d’exploration (pages lues, impasses, tentatives) restent dans le contexte de chaque sous-agent et n’encombrent jamais celui de l’orchestrateur, qui raisonne sur des synthèses denses. A est faux — le coût total est souvent supérieur (4 contextes au lieu d’un) ; on paie en tokens ce qu’on gagne en qualité et en latence. C est faux : un agent unique peut aussi appeler des modèles différents par requête. D est faux : la parallélisation n’apporte aucun déterminisme.

Réponse : B. Le consensus multiplie le coût par N ; il ne se justifie que lorsque le coût d’une erreur dépasse largement le surcoût d’inférence, typiquement les décisions à enjeu élevé avec une part de jugement. A décrit le chaînage (workflow), pas le consensus. C et D sont l’inverse de la réalité : le consensus augmente latence et coût.

Réponse : B. Le routage est une classification : tâche fermée, à haut volume, où la latence et le coût dominent. Un appel simple avec sortie contrainte sur un modèle rapide est le bon outil. A est un anti-patron classique de l’examen : déployer une boucle agentique là où un appel suffit. C jette la capacité sémantique nécessaire (les tickets sont en langage naturel). D est une sur-ingénierie coûteuse et non déterministe.

Réponse : B. Le principe d’architecture : la friction humaine se place au point de non-retour, proportionnée au risque (seuil de montant). A détruit l’utilité de l’agent (chaque lecture validée à la main). C arrive trop tard pour une action irréversible — l’audit complète mais ne remplace pas l’approbation. D confond consigne et garantie : un prompt n’est jamais une garantie d’exécution ; seul le code (gate d’approbation) en est une.

Réponse : C. Patron de dégradation gracieuse : résultats partiels conservés, retry ciblé avec backoff (backoff = attente croissante entre tentatives), et transparence sur la lacune si l’échec persiste — la synthèse dit ce qu’elle ne couvre pas. A gaspille 5 succès. B produit une synthèse faussement exhaustive : c’est le pire choix en fiabilité (lacune invisible). D dégrade l’expérience pour une panne partielle et récupérable.

Réponse : B. L’état durable vit hors du contexte (base de données, store de sessions) sous forme structurée ; à la reprise on réinjecte le minimum utile. A fonctionne mais explose en tokens et en latence au fil des étapes — et finit par saturer la fenêtre. C est une erreur factuelle fondamentale : l’API est sans état (stateless), le modèle ne « se souvient » de rien entre deux appels. D externalise sur l’utilisateur ce que l’architecture doit garantir.

Réponse : C. Règle de décision : si le chemin est connu d’avance → workflow (déterministe, moins cher, testable) ; si le chemin dépend des découvertes intermédiaires → agent. Le diagnostic de panne est le cas d’école de l’agent : impossible de scénariser les étapes d’avance. A, B et D sont des pipelines à étapes fixes — y déployer un agent est une sur-ingénierie que l’examen sanctionne.

Réponse : B. La description d’outil est le prompt de la sélection : le modèle choisit sur la foi des descriptions, pas des implémentations. Les descriptions de qualité production incluent le périmètre, les contre-indications (« ne pas utiliser pour… ») et les distinctions entre outils proches. A coûte cher pour contourner un défaut de spécification. C réduit la variance mais pas la confusion sémantique. D ajoute de la surface d’erreur au lieu d’en retirer.

Réponse : B. La séparation canonique : outils = actions invocables par le modèle avec paramètres (recherche, écriture) ; ressources = contenus adressables par URI (URI = Uniform Resource Identifier) que l’application charge dans le contexte, en lecture ; prompts = gabarits d’interaction réutilisables exposés à l’utilisateur. D inverse exactement les deux premières. C est faux : les trois primitives ont des cycles de contrôle différents (modèle / application / utilisateur).

Réponse : B. La granularité se conçoit du point de vue de la tâche de l’agent, pas de la structure de l’API sous-jacente : un outil = une intention. La consolidation réduit les allers-retours, les tokens et les occasions d’erreur. A ne résout pas le problème structurel. C troque la sur-granularité contre un risque d’injection et de destruction de données. D détruit la valeur du schéma typé : le modèle n’a plus aucun guidage sur les actions possibles.

Réponse : A. stdio (stdio = standard input/output, entrée/sortie standard du processus) : serveur local, sous-processus, latence minimale, sécurité par isolation locale — parfait pour l’outillage de poste de travail. HTTP streamable : serveur distant, mutualisé entre clients, avec couche d’authentification (p. ex. OAuth) — parfait pour l’entreprise. B est un réflexe de mode, pas d’architecte. C est faux par définition de stdio. D est faux : les primitives MCP sont indépendantes du transport. ⚠ Les noms exacts des transports évoluent avec la spécification MCP — vérifier la version courante.

Réponse : B. L’erreur d’outil est une donnée de raisonnement : renvoyée dans le résultat (champ d’erreur ou is_error), formulée de façon actionnable, elle permet à l’agent de replanifier (proposer la salle A). A transforme un aléa métier récupérable en panne technique. C laisse le modèle halluciner un succès ou une cause. D est le pire cas : mentir au modèle garantit une réponse finale fausse avec assurance.

Réponse : B. CLAUDE.md est chargé automatiquement dans le contexte à chaque session : chaque ligne coûte des tokens à chaque interaction. On y met le contrat opérationnel que l’agent ne peut pas deviner en lisant le code — commandes exactes (make test-unit, pas « lancer les tests »), conventions, zones dangereuses. A et D diluent le signal et gonflent le coût. C duplique un document écrit pour un autre public avec un autre niveau de détail.

Réponse : B. Le mode headless (-p / --print) exécute une requête unique sans interaction ; --output-format json rend la sortie parsable de façon fiable par le pipeline ; et en CI, les permissions se déclarent explicitement (allowlist d’outils) plutôt que d’être accordées en bloc. C est le piège sécurité récurrent : contourner toutes les permissions dans un environnement automatisé qui peut exécuter du code arbitraire. ⚠ Les drapeaux CLI évoluent — vérifier claude --help sur la version installée.

Réponse : B. Critère de tri : ce qui doit être su en permanence va dans CLAUDE.md (chargé à chaque session) ; ce qui est invoqué à la demande avec des arguments va dans une commande slash (chargée seulement à l’appel — zéro coût le reste du temps). A, C et D sont des connaissances permanentes → CLAUDE.md. B est un rituel paramétré ponctuel → commande slash.

Réponse : B. Le mode plan sépare la décision de l’exécution : l’agent explore le code, propose un plan complet, et l’humain arbitre avant toute écriture. Sa valeur croît avec l’ampleur et l’irréversibilité du changement (multi-fichiers, migration). A, C, D sont des modifications triviales et locales où le mode plan ajoute une friction sans bénéfice.

Réponse : B. Distinction cardinale de l’examen : CLAUDE.md = consigne (le modèle peut l’oublier ou la contourner) ; la configuration de permissions = garantie (appliquée par le programme, pas par le modèle). Versionner settings.json dans le dépôt rend la politique uniforme et auditable pour toute l’équipe. A confond consigne et garantie. C produit 12 politiques divergentes. D détruit l’usage principal (lancer les tests) pour éviter un cas gérable finement.

Réponse : B. Le patron canonique : déclenchement événementiel, mode non interactif, contexte ciblé (le diff, pas le dépôt entier), sortie structurée exploitable, et lecture seule — la revue informe, l’humain décide. A ne passe pas à l’échelle. C franchit la ligne rouge de l’action irréversible sans humain. D explose le contexte et le coût pour un gain marginal : le diff et ses environs suffisent à la revue.

Réponse : B. Deux comportements API à connaître par cœur : (1) le texte du prefill (préremplissage du début de réponse) n’est pas répété dans la sortie — la génération reprend après lui ; (2) la séquence d’arrêt déclenchée n’est pas incluse dans le texte retourné, et tout ce qui suivait est coupé ; stop_reason vaut "stop_sequence". Résultat : l’application reçoit exactement la valeur utile, sans balises ni bavardage. C’est le patron d’extraction déterministe canonique. ⚠ Comportement volatil : vérifier la documentation API courante.

Réponse : B. Le CoT aide les tâches où la réponse résulte d’étapes intermédiaires (A, C, D). Sur une copie verbatim, l’étape de « réflexion » invite le modèle à reformuler, normaliser ou paraphraser — exactement ce qu’on ne veut pas. Réflexe d’architecte : le CoT est un outil mesurable, pas un réflexe ; on l’active quand l’éval montre un gain.

Réponse : B. L’usage d’un outil comme « moule » de sortie structurée est le mécanisme le plus contraignant offert par l’API : la génération des arguments est guidée par le schéma (types, champs requis, énumérations), et tool_choice force l’appel. La validation programmatique en aval reste obligatoire (garantie ceinture + bretelles). A et C améliorent la probabilité sans garantie. D ajoute coût et latence et peut introduire de nouvelles erreurs. ⚠ Les mécanismes de sortie structurée évoluent vite — vérifier les options courantes de l’API.

Réponse : B. Les exemples few-shot enseignent les frontières de décision, pas le centre de la distribution : le modèle traite déjà bien les cas faciles. Les cas limites tranchés montrent où passe la ligne ; le cas de refus définit le périmètre. A et D gaspillent le budget sur ce qui est déjà acquis. C laisse la composition au hasard — la sélection d’exemples est une décision de conception, pas un échantillonnage.

Réponse : B. Trois bonnes pratiques de contexte long combinées : documents volumineux en haut du prompt, requête en fin (les instructions finales sont les mieux suivies après un long contexte), et l’ancrage par citations (« cite d’abord les passages pertinents ») force le modèle à s’appuyer sur le texte réel avant de conclure. A inverse le placement optimal. C fragmente sans bénéfice. D est faux : la position dans le contexte a un effet mesurable.

Réponse : A. Les quatre piliers d’un harnais : jeu de référence annoté et versionné, métriques programmatiques quand la vérité terrain est objective (l’extraction l’est : un montant est juste ou faux), automatisation (l’éval tourne comme un test de CI), et historique (détecter les régressions). Le LLM-juge (B) se réserve aux qualités subjectives (ton, utilité) — et se calibre contre des jugements humains. C n’a aucune couverture ni reproductibilité. D mesure tout sauf ce qui compte.

Réponse : B. La compaction est le patron standard des agents de longue durée : le contexte est une ressource gérée, pas un journal infini. Le résumé conserve l’essentiel décisionnel ; les détails bruts restent accessibles hors contexte (fichiers, base) si besoin. A perd des informations sans contrôle sur lesquelles. C jette 2 heures de travail. D est une caricature de A.

Réponse : A. Le cache fonctionne par préfixe exact : toute modification en amont du point de cache (un mot, un outil, un ordre de blocs) change le préfixe, donc invalide le cache. B est précisément l’usage prévu : le préfixe stable est réutilisé, seule la suite varie. C décrit la fenêtre de fraîcheur typique (≈ 5 minutes ⚠, rechargée à chaque accès), pas une invalidation. D n’invalide pas : le cache est rattaché au compte/préfixe, pas à la machine. Conséquence d’architecture : contenu stable en tête (système, outils, documents), contenu variable en queue. ⚠ Durées et tarifs volatils.

Réponse : B. Triple défense : la porte de sortie (autoriser l’aveu d’ignorance réduit la pression à inventer), l’ancrage (citations obligatoires depuis les sources), et la vérification programmatique (une citation inexistante est détectable par du code — c’est une garantie, pas une consigne). A réduit la variance, pas l’invention : une hallucination à température 0 est simplement reproductible. C est une consigne sans mécanisme. D peut aggraver (plus de bruit, contexte dilué).

Réponse : B. Le patron de résilience complet : backoff exponentiel (les réessais immédiats aggravent la congestion — A est un déni de service auto-infligé), jitter contre l’effet troupeau, plafond pour ne pas boucler sans fin, respect des indications serveur, et lissage amont du trafic. C est une décision stratégique disproportionnée pour un phénomène transitoire et normal. D confond lenteur et refus : un 429 répond vite, l’allongement du timeout n’y change rien.

Réponse : B. La provenance exige de pouvoir rejouer la chaîne causale : quel prompt (versionné), quel modèle, quel contexte, quelles actions d’outils, quelle sortie. Sans la version du prompt et les entrées, un incident est indiagnosticable. La protection des données s’applique aux journaux eux-mêmes (PII — Personally Identifiable Information — minimisée, chiffrée, purgée à échéance). A ne permet aucun diagnostic causal. C est illégal à terme (rétention illimitée de données personnelles) et inexploitable. D confond reproductibilité bit à bit et traçabilité : on peut toujours tracer ce qui a été fourni et décidé.