# Anatomie d’une question

Comment les items basés sur des scénarios sont construits, comment les distracteurs sont rédigés, et une technique reproductible pour y répondre.

import { Accordions, AccordionItem } from '@prosefly/astro-components';

## Le modèle d’item

Presque chaque item de ces examens suit le même squelette :

```text
[Contexte]     Une équipe / entreprise / rôle et ce qu'ils cherchent à accomplir.
[Contrainte]   Une ou deux contraintes explicites : coût, latence, conformité, échelle,
               fiabilité, taille d'équipe, stack existante.
[Signal]       Un détail qui pointe vers le bon principe
               (par ex. « du jour au lendemain », « ne doit jamais », « 10 000 documents », « sûr mais faux »).
[Question]     « Quelle approche est la MEILLEURE… », « Que doit faire l'architecte EN PREMIER… »,
               « Quelles DEUX actions… » (les items à réponses multiples indiquent le nombre).
[Options]      3–4 options plausibles. Habituellement :
               • le bon arbitrage
               • une option qui sonne juste mais sur-conçue
               • une option qui ignore la contrainte
               • une option qui viole un principe énoncé (un anti-pattern)
```

## Comment les distracteurs sont rédigés

Les rédacteurs d’items produisent les mauvaises réponses en appliquant des transformations prévisibles à la bonne. Apprenez à les reconnaître :

| Type de distracteur | Exemple | Pourquoi il échoue |
| --- | --- | --- |
| **Aveugle à la contrainte** | Recommande une API temps réel alors que l’énoncé dit « du jour au lendemain, le coût compte » | Ignore le signal |
| **Sur-conçu** | Système multi-agents pour une tâche linéaire en trois étapes | Viole « la chose la plus simple qui fonctionne » |
| **Prompt comme moyen d’application** | « Ajoutez au system prompt : ne jamais émettre de remboursements au-delà de 500 USD » | Les règles critiques exigent des hooks programmatiques |
| **Confiance sur l’auto-évaluation** | « Escalader quand la confiance auto-évaluée de Claude est inférieure à 0,7 » | La confiance auto-déclarée n’est pas calibrée |
| **Échec silencieux** | « Renvoyer une liste vide si l’outil échoue » | Masque le contexte de diagnostic |
| **Mémorisation seule** | Définition correcte, mauvaise situation | Les examens testent l’application, pas la définition |
| **Métrique agrégée** | « L’exactitude globale est de 96 %, on livre » | Masque les échecs par segment |
| **Sentiment = complexité** | « Escalader les clients en colère » | Le sentiment ≠ la complexité |

## Une technique reproductible

1. **Lisez d’abord la phrase de la question** (la dernière ligne avant les options). Notez le qualificatif : MEILLEURE, EN PREMIER, le PLUS économique, DEUX.
2. **Lisez l’énoncé et soulignez la contrainte et le signal.** Il y a presque toujours exactement un détail décisif.
3. **Prédisez le principe** avant de regarder les options (« c’est une question batch ou temps réel »).
4. **Éliminez les options aveugles à la contrainte et les anti-patterns** – généralement deux sur quatre.
5. **Entre les deux restantes, choisissez la plus simple qui satisfait pleinement la contrainte.** La sur-conception est un pattern de distracteur, pas une vertu.
6. **Réponses multiples :** le nombre est donné. Chaque option correcte doit être juste indépendamment ; ne choisissez pas des options qui ne sont justes qu’« ensemble ».
7. **Marquez et passez** après ~2,5 minutes. Revenez avec le temps restant.

## Exemple travaillé

> Une équipe de services financiers construit un agent de support avec Claude. Les remboursements supérieurs à 500 USD ne doivent jamais être émis sans approbation humaine. L’équipe propose d’ajouter la règle au system prompt. Que doit recommander l’architecte ?
>
> A. Garder la règle dans le system prompt et ajouter des exemples few-shot de refus corrects.
> B. Mettre en place un hook pre-tool-use qui bloque l’outil `issue_refund` quand le montant > 500 sauf si un jeton d’approbation est présent.
> C. Demander au modèle de produire un score de confiance et n’émettre les remboursements que lorsque la confiance > 0,9.
> D. Abaisser la température à 0 pour que le modèle suive l’instruction de façon déterministe.

<Accordions>
  <AccordionItem title="Afficher la réponse et le raisonnement">
    **B.** Le signal est « ne doit jamais » plus un seuil financier : une règle métier critique. L’application par prompt (A, D) est au mieux au meilleur effort, pas une garantie – la température 0 ne rend pas le suivi d’instruction déterministe. La confiance auto-déclarée (C) n’est pas calibrée. Les hooks programmatiques appliquent la règle de façon déterministe en dehors du modèle. Cela renvoie à l’anti-pattern 3 (« application par prompt pour des règles métier critiques ») et à l’anti-pattern 4 (« confiance auto-déclarée »).
  </AccordionItem>
</Accordions>

## Budget temps

| Examen | Items | Secondes par item | Premier passage suggéré | Réserve |
| --- | --- | --- | --- | --- |
| CCAO-F | 60 | 120 | 95 min | 25 min |
| CCDV-F | 53 | 136 | 95 min | 25 min |
| CCAR-F | 60 | 120 | 95 min | 25 min |
| CCAR-P | 63 | 114 | 100 min | 20 min |

La réserve est pour les items marqués et une vérification finale qu’aucun item n’est laissé vide (pas de pénalité pour une réponse au hasard).