# Examen blanc — Niveau Avancé, Session 10 # « Examen blanc & projet final » **Programme :** Applied AI — Yann Isola **Format :** 30 QCM (QCM = Questionnaire à Choix Multiples), conditions d'examen — une seule réponse correcte par question **Durée :** 45 minutes (soit 90 secondes par question, le rythme réel de l'examen ⚠) **Seuil :** 22/30 (≈ 72 %, aligné sur le seuil de la certification ⚠) **Pondération par domaine (alignée sur l'examen officiel ⚠) :** | Domaine | Poids examen ⚠ | Questions ici | |---|---|---| | D1 — Architecture & orchestration d'agents | 27 % | Q1–Q8 (8) | | D2 — Conception d'outils & intégration MCP | 18 % | Q9–Q13 (5) | | D3 — Configuration & workflows Claude Code | 20 % | Q14–Q19 (6) | | D4 — Prompt engineering & sortie structurée | 20 % | Q20–Q25 (6) | | D5 — Gestion du contexte & fiabilité | 15 % | Q26–Q30 (5) | > ⚠ **Volatilité :** le format d'examen (60 questions, 90 minutes, seuil 720/1000 ≈ 72 %), les pondérations de domaines et les comportements d'API décrits reflètent la documentation au moment de la rédaction. Vérifier la page officielle de la certification Anthropic avant de réserver l'examen. > **Consigne d'utilisation :** faire cet examen blanc **en conditions réelles** — chronomètre lancé, aucune documentation, toutes les questions répondues (aucune pénalité pour une mauvaise réponse). Corriger ensuite avec les explications, et reporter le score par domaine dans le tableau de bord de préparation (page web de la session). --- ## Domaine 1 — Architecture & orchestration d'agents (Q1–Q8) ### Q1 — Agent unique ou orchestrateur ? Une fintech construit un assistant de support qui doit : (1) répondre aux questions sur les frais, (2) analyser des relevés PDF pour détecter des anomalies, (3) rédiger des courriers de réclamation réglementaires. Chaque capacité exige un prompt système long et des outils différents. Un agent unique commence à confondre les consignes. Quelle évolution d'architecture est la plus justifiée ? - A. Fusionner les trois prompts systèmes en un seul, plus détaillé, avec des sections XML - B. Un orchestrateur-routeur qui classifie la demande puis délègue à trois agents spécialisés, chacun avec son prompt et ses outils propres - C. Trois instances du même agent en parallèle, avec vote majoritaire sur la réponse finale - D. Augmenter `max_tokens` et passer au modèle le plus puissant disponible **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. --- ### Q2 — Isolation de contexte des sous-agents Un agent de recherche documentaire lance 4 sous-agents en parallèle, chacun explorant une source différente, puis synthétise leurs rapports. Quel est le bénéfice **principal** de cette architecture par rapport à un agent unique qui explorerait les 4 sources séquentiellement ? - A. Le coût total en tokens est toujours inférieur avec des sous-agents - B. Chaque sous-agent travaille dans un contexte propre et isolé ; l'orchestrateur ne reçoit que les synthèses, pas les tokens d'exploration bruts - C. Les sous-agents peuvent utiliser des modèles différents, ce qui est impossible autrement - D. La parallélisation garantit des résultats déterministes **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. --- ### Q3 — Patron de consensus Dans quel cas le patron « N agents évaluent indépendamment, puis vote/agrégation » est-il le **mieux** justifié ? - A. Pour découper une tâche longue en étapes séquentielles - B. Pour une décision à fort enjeu et critères subjectifs — p. ex. valider qu'une réponse réglementaire ne contient aucune affirmation risquée — où une erreur isolée coûte cher - C. Pour réduire la latence d'une tâche simple - D. Pour économiser des tokens sur des tâches à haut volume **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. --- ### Q4 — Routeur : classifieur ou agent ? Un routeur doit orienter chaque ticket entrant vers l'une de 5 files. Le trafic est de 80 000 tickets/jour. Quelle implémentation privilégier ? - A. Un agent complet avec outils et boucle de raisonnement, pour une flexibilité maximale - B. Un appel unique, prompt court avec définitions des 5 classes + exemples few-shot, sortie structurée contrainte, modèle rapide et économique - C. Un système de règles regex uniquement, l'IA étant trop coûteuse à ce volume - D. Un orchestrateur multi-agents où chaque file possède son agent qui « réclame » les tickets **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. --- ### Q5 — Placement de l'humain dans la boucle Un agent de gestion de remboursements peut : consulter un dossier (lecture), calculer un montant (calcul), émettre un virement (action irréversible). Où placer la validation humaine obligatoire ? - A. Avant chaque appel d'outil, sans exception — sécurité maximale - B. Uniquement avant l'action irréversible (virement), avec un seuil de montant au-delà duquel l'approbation est requise - C. Après le virement, sous forme d'audit a posteriori - D. Nulle part : si le prompt système interdit les erreurs, la validation est redondante **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. --- ### Q6 — Reprise sur incident dans un fan-out parallèle Un orchestrateur lance 6 sous-agents en parallèle. Le sous-agent n°4 échoue (timeout d'un outil externe). Quelle stratégie de production est la plus robuste ? - A. Annuler les 6 branches et relancer l'ensemble depuis zéro - B. Ignorer silencieusement la branche 4 et synthétiser sur 5 résultats sans le mentionner - C. Collecter les 5 résultats valides, relancer uniquement la branche 4 avec backoff, et si l'échec persiste, synthétiser en signalant explicitement la lacune - D. Faire échouer toute la requête utilisateur avec l'erreur brute du timeout **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. --- ### Q7 — État et reprise de session (Agent SDK) Un agent d'onboarding conduit un parcours en 12 étapes qui peut s'étaler sur plusieurs jours. L'utilisateur revient à l'étape 7. Quelle approche est correcte ? - A. Rejouer l'historique complet des messages des étapes 1–6 dans le contexte à chaque reprise - B. Persister un état structuré (étape courante, données validées, décisions prises) hors du contexte, et réhydrater à la reprise un résumé compact + l'état structuré - C. Compter sur la mémoire implicite du modèle entre deux appels API - D. Demander à l'utilisateur de résumer lui-même où il en était **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. --- ### Q8 — Workflow ou agent ? Parmi ces quatre tâches, laquelle justifie une **boucle agentique autonome** (l'agent décide de ses prochaines actions) plutôt qu'un workflow à étapes fixes ? - A. Extraire les champs d'une facture et les écrire dans une base — schéma stable, étapes connues - B. Traduire chaque nouveau billet de blog en 3 langues, tous les jours - C. Diagnostiquer une panne dont la cause est inconnue, en explorant logs, métriques et code, où chaque indice détermine la prochaine investigation - D. Générer un rapport hebdomadaire à partir des mêmes 4 sources de données **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. --- ## Domaine 2 — Conception d'outils & intégration MCP (Q9–Q13) ### Q9 — Le levier n°1 de la sélection d'outils Un agent dispose de 12 outils et en choisit régulièrement un inadapté. Les schémas JSON des paramètres sont corrects. Quel est le levier de correction le plus efficace en premier ? - A. Passer à un modèle plus puissant - B. Réécrire les **descriptions** des outils : cas d'usage précis, quand l'utiliser ET quand ne pas l'utiliser, distinctions explicites entre outils voisins - C. Réduire la température à 0 - D. Ajouter un outil supplémentaire de « désambiguïsation » **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. --- ### Q10 — MCP : outils, ressources, prompts Dans MCP (MCP = Model Context Protocol, protocole ouvert de connexion entre applications IA et systèmes externes), un serveur expose trois primitives. Quelle affectation est correcte pour un serveur « base de connaissances interne » ? - A. Outil = lire un document ; Ressource = exécuter une recherche ; Prompt = le document lui-même - B. Outil = `rechercher(requête)` (action à paramètres, déclenchée par le modèle) ; Ressource = contenu d'un document identifié par URI, chargé dans le contexte ; Prompt = gabarit réutilisable « résume ce document pour un client » - C. Outil, ressource et prompt sont interchangeables — le choix est purement stylistique - D. Ressource = toute fonction avec effets de bord ; Outil = données en lecture seule **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). --- ### Q11 — Granularité des outils Un serveur MCP interne expose 22 outils, dont `get_client_name`, `get_client_email`, `get_client_phone`, `get_client_address`… L'agent multiplie les appels et sature son contexte. Quelle refonte est la meilleure ? - A. Conserver les 22 outils mais documenter chacun davantage - B. Consolider en outils orientés tâche — p. ex. `get_client_profile(client_id, champs?)` — qui retournent en un appel ce que l'agent consommait en quatre - C. Supprimer tous les outils et donner à l'agent un accès SQL brut à la base - D. Créer un outil unique `do_anything(action, params)` totalement générique **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. --- ### Q12 — Choix du transport MCP Une équipe hésite entre transport stdio et transport HTTP (streamable) pour ses serveurs MCP. Quelle affirmation est correcte ? - A. stdio convient aux serveurs locaux lancés comme sous-processus de l'application hôte ; HTTP convient aux serveurs distants, partagés, avec authentification - B. HTTP est toujours préférable car plus moderne - C. stdio permet le partage d'un même serveur entre plusieurs machines distantes - D. Le transport modifie les primitives disponibles : les ressources n'existent qu'en HTTP **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. --- ### Q13 — Erreurs d'outil : qui doit les voir ? Un outil `reserver_salle` échoue car la salle est déjà prise. Quelle conception permet à l'agent de **récupérer** au lieu d'échouer ? - A. Lever une exception côté serveur : l'appel API échoue et l'application affiche une erreur 500 - B. Retourner à l'agent un résultat d'outil marqué comme erreur, avec un message actionnable — « Salle B occupée de 14 h à 15 h ; salles A et C libres sur ce créneau » — pour qu'il ajuste sa stratégie - C. Retourner une chaîne vide pour ne pas perturber le modèle - D. Retourner `succès: true` avec une note interne, pour que la conversation reste fluide **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. --- ## Domaine 3 — Configuration & workflows Claude Code (Q14–Q19) ### Q14 — Rôle du CLAUDE.md Que doit contenir en priorité le fichier `CLAUDE.md` à la racine d'un dépôt pour une équipe de 12 développeurs ? - A. La documentation utilisateur complète du produit - B. Les conventions non déductibles du code : commandes de build/test exactes, style et interdits de l'équipe, architecture des dossiers, pièges connus du dépôt - C. Une copie du README destiné aux humains - D. L'historique des décisions de sprint **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. --- ### Q15 — Mode headless en CI Dans un pipeline CI (CI = Continuous Integration, intégration continue), quelle invocation est correcte pour une revue automatique non interactive dont la sortie sera parsée par un script ? - A. `claude` en mode interactif, avec un développeur qui répond aux questions - B. `claude -p "Analyse ce diff et liste les problèmes" --output-format json` avec des permissions d'outils explicitement bornées pour l'environnement CI - C. `claude --dangerously-skip-permissions` systématiquement, pour éviter tout blocage - D. Copier le diff dans l'interface web et coller la réponse dans le pipeline **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. --- ### Q16 — Commandes slash vs CLAUDE.md Quelle information appartient à une **commande slash** (fichier dans `.claude/commands/`) plutôt qu'au `CLAUDE.md` ? - A. La convention de nommage des branches, utile en permanence - B. Une procédure à la demande et paramétrable — p. ex. `/release-notes v2.3` qui génère les notes de version selon un gabarit précis - C. La commande pour lancer les tests unitaires - D. La liste des dossiers à ne jamais modifier **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. --- ### Q17 — Mode plan Dans quel cas le mode plan de Claude Code (exploration et proposition **sans modification** de fichiers) apporte-t-il le plus de valeur ? - A. Corriger une coquille dans un commentaire - B. Un refactoring qui touche 14 fichiers et une migration de schéma de base de données, où l'on veut valider l'approche complète avant la première écriture - C. Ajouter un test unitaire à un fichier de tests existant - D. Renommer une variable locale dans une fonction **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. --- ### Q18 — Permissions d'équipe Une équipe veut que Claude Code, sur le dépôt partagé, puisse toujours lancer les tests et le linter, mais jamais `git push` sans validation. Quel mécanisme est le bon ? - A. Le dire dans `CLAUDE.md` : « Ne jamais pousser sans demander » - B. Un fichier de permissions partagé versionné dans le dépôt (`.claude/settings.json`) avec allowlist explicite (commandes de test, lint) et exigence d'approbation pour le reste - C. Chaque développeur configure ses permissions locales à sa convenance - D. Interdire complètement l'outil Bash **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. --- ### Q19 — Automatisation de revue de PR Pour une revue automatique de chaque PR (PR = Pull Request, proposition de fusion de code), quelle intégration est la plus adaptée ? - A. Un développeur lance Claude Code interactivement sur chaque PR et copie ses conclusions - B. Un job CI déclenché à l'ouverture de la PR : mode headless, contexte = diff + description de la PR + consignes de revue, sortie structurée postée en commentaire, permissions en lecture seule - C. Donner à l'agent le droit de fusionner automatiquement les PR qu'il juge bonnes - D. Faire relire l'intégralité du dépôt à chaque PR pour un maximum de contexte **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. --- ## Domaine 4 — Prompt engineering & sortie structurée (Q20–Q25) ### Q20 — Prefilling + stop_sequences Vous terminez la requête par le message `{"role": "assistant", "content": ""}` et passez `stop_sequences: [""]`. Le modèle génère « conforme et je précise… ». Que reçoit votre application dans le texte de la réponse ? - A. `conforme` - B. `conforme` — avec `stop_reason: "stop_sequence"` - C. `conforme et je précise…` - D. `conforme` — avec `stop_reason: "end_turn"` **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. --- ### Q21 — Chain of Thought contre-productif Sur quelle tâche l'ajout d'un raisonnement pas à pas (CoT — Chain of Thought, chaîne de pensée) risque-t-il de **dégrader** la performance ? - A. Un calcul de plan d'amortissement en 6 étapes - B. La copie verbatim d'un numéro de contrat depuis un document vers un champ JSON - C. Un diagnostic différentiel entre trois causes de panne possibles - D. La planification d'une migration en plusieurs phases **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. --- ### Q22 — Garantir un JSON conforme au schéma Votre pipeline aval plante au moindre JSON invalide. Quelle approche donne la **garantie la plus forte** de conformité structurelle ? - A. Écrire « Réponds UNIQUEMENT en JSON valide » en majuscules dans le prompt - B. Définir la structure attendue comme un outil avec schéma JSON (input_schema) et forcer son appel (tool_choice) : les arguments générés sont contraints par le schéma ; valider ensuite côté code - C. Ajouter 10 exemples few-shot de JSON bien formés - D. Faire relire la sortie par un second appel LLM qui corrige le JSON **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. --- ### Q23 — Composition d'un jeu few-shot Avec un budget de 5 exemples few-shot pour un classifieur de conformité, quelle composition est la plus efficace ? - A. 5 cas nominaux parfaits du cas le plus fréquent - B. 1 cas nominal, 3 cas limites ambigus tranchés avec justification, 1 cas hors périmètre montrant le refus attendu - C. 5 cas choisis au hasard dans les données de production - D. 5 variantes du même exemple avec des formulations différentes **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. --- ### Q24 — Contexte long : placement Vous soumettez un contrat de 80 pages et une question précise. Quelle organisation du prompt maximise la qualité de réponse ? - A. Question d'abord, puis le document, pour que le modèle sache quoi chercher - B. Le document long en tête de prompt (idéalement dans des balises structurantes), la question **à la fin**, et demander d'abord au modèle d'extraire les citations pertinentes avant de répondre - C. Découper le contrat en 40 messages utilisateur successifs - D. Mettre le contrat dans le prompt système et la question dans le message utilisateur, l'ordre interne étant sans effet **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. --- ### Q25 — Concevoir un harnais d'évaluation Pour évaluer en continu un pipeline d'extraction de données facturier, quel harnais est le mieux conçu ? - A. Un jeu doré (golden set) de 50 factures annotées, vérifications programmatiques champ par champ (égalité exacte, tolérances numériques), exécution automatique à chaque changement de prompt, suivi des scores dans le temps - B. Demander chaque semaine à un LLM « ce pipeline te semble-t-il bon ? » - C. Tester manuellement 3 factures après chaque modification - D. Mesurer uniquement la latence et le coût, la qualité étant subjective **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. --- ## Domaine 5 — Gestion du contexte & fiabilité (Q26–Q30) ### Q26 — Agent long : gérer la saturation du contexte Un agent d'analyse tourne depuis 2 heures ; son contexte approche de la limite. Quelle stratégie de production est la plus adaptée ? - A. Laisser l'API tronquer silencieusement les messages les plus anciens - B. Compacter : synthétiser l'historique en un résumé structuré (décisions prises, état courant, tâches restantes), persister les détails hors contexte, et repartir sur un contexte frais contenant le résumé - C. Arrêter l'agent et tout recommencer depuis le début - D. Supprimer aléatoirement un message sur deux **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. --- ### Q27 — Prompt caching : invalidation Votre application utilise le cache de prompt (prompt caching : réutilisation tarifée à prix réduit ⚠ des préfixes de prompt déjà traités). Quelle modification **invalide** le cache d'un préfixe marqué ? - A. Changer un mot dans le prompt système, situé avant le point de cache - B. Ajouter un nouveau message utilisateur après le préfixe mis en cache - C. Réutiliser le même préfixe dans les 5 minutes ⚠ - D. Envoyer la même requête depuis une autre machine du même compte **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. --- ### Q28 — Réduire les hallucinations en système RAG Un assistant documentaire (RAG — Retrieval-Augmented Generation, génération augmentée par récupération) invente parfois des références. Quelle combinaison de mesures est la plus efficace ? - A. Baisser la température à 0 — cela supprime les hallucinations - B. Autoriser explicitement « je ne sais pas » quand les documents ne couvrent pas la question, exiger des citations tirées des documents fournis, et vérifier programmatiquement que chaque citation existe dans les sources - C. Ajouter « Ne jamais halluciner » dans le prompt système - D. Augmenter le nombre de documents récupérés à chaque requête **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é). --- ### Q29 — Résilience aux erreurs API Votre service reçoit des erreurs 429 (limite de débit) et 529 (surcharge ⚠) aux heures de pointe. Quelle stratégie cliente est correcte ? - A. Réessayer immédiatement en boucle serrée jusqu'au succès - B. Retry avec backoff exponentiel et jitter (jitter = aléa ajouté aux délais pour désynchroniser les clients), plafond de tentatives, respect de l'en-tête `retry-after` s'il est présent, et file d'attente amont pour lisser les pics - C. Basculer définitivement toutes les requêtes vers un autre fournisseur au premier 429 - D. Augmenter le timeout client à 10 minutes **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. --- ### Q30 — Traçabilité et provenance en production Pour un système IA soumis à audit réglementaire, que faut-il journaliser au minimum pour reconstituer **pourquoi** le système a produit une réponse donnée ? - A. Uniquement la réponse finale envoyée à l'utilisateur - B. Pour chaque requête : identifiant de version du prompt, modèle et paramètres exacts, contexte fourni (ou son empreinte + référence), outils appelés avec arguments et résultats, réponse produite, horodatage — avec les données personnelles protégées (minimisation, rétention bornée) - C. Tout le trafic réseau brut, indéfiniment - D. Rien : les sorties d'un modèle ne sont pas reproductibles, l'audit est donc impossible **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é. --- ## Grille de correction rapide | Q | R | Domaine | | Q | R | Domaine | | Q | R | Domaine | |---|---|---|---|---|---|---|---|---|---|---| | 1 | B | D1 | | 11 | B | D2 | | 21 | B | D4 | | 2 | B | D1 | | 12 | A | D2 | | 22 | B | D4 | | 3 | B | D1 | | 13 | B | D2 | | 23 | B | D4 | | 4 | B | D1 | | 14 | B | D3 | | 24 | B | D4 | | 5 | B | D1 | | 15 | B | D3 | | 25 | A | D4 | | 6 | C | D1 | | 16 | B | D3 | | 26 | B | D5 | | 7 | B | D1 | | 17 | B | D3 | | 27 | A | D5 | | 8 | C | D1 | | 18 | B | D3 | | 28 | B | D5 | | 9 | B | D2 | | 19 | B | D3 | | 29 | B | D5 | | 10 | B | D2 | | 20 | B | D4 | | 30 | B | D5 | > **Note pédagogique (formateur) :** la réponse correcte est volontairement souvent en position B dans ce document de correction — à l'examen réel, les positions sont aléatoires. Le simulateur web de la session **mélange les propositions** à chaque tentative : utiliser le simulateur pour l'entraînement, ce document pour la correction commentée. ## Interprétation du score | Score | Diagnostic | Action | |---|---|---| | 27–30 | Prêt·e. | Réserver l'examen. Réviser uniquement les domaines < 80 %. | | 22–26 | Au seuil — marge insuffisante. | Une semaine de révision ciblée sur les 2 domaines les plus faibles, puis second examen blanc. | | 17–21 | Fondations présentes, écarts significatifs. | Reprendre les sessions correspondant aux domaines < 60 % ; refaire les exercices pratiques (pas seulement la lecture). | | < 17 | Ne pas réserver l'examen. | Reprendre le parcours à partir des sessions faibles ; pratiquer avec de vrais appels API — la pratique bat la lecture. | **Calcul par domaine :** score du domaine = questions justes ÷ questions du domaine. Tout domaine < 60 % est une zone rouge, quel que soit le score global — l'examen réel pondère, et un domaine effondré peut coûter la certification.