# D1 · Solution Design & Architecture
Traduire les problèmes métier en solutions Claude, architecture de référence de bout en bout, choix entre patrons workflow / agentique / augmented-LLM, placement cloud, planification de capacité, conception de la haute disponibilité et du repli, et ADR.
import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components';
Ce domaine pèse **17 % – environ 11 des 63 items** – et il pose le cadre de tout l’examen. Il vérifie si vous savez prendre un problème métier ambigu, en extraire les contraintes et les critères de réussite, et produire une architecture de bout en bout défendable. Les items ne présentent presque jamais une réponse « fonctionnalité » unique ; ils récompensent l’option qui **part de la valeur métier et raisonne sous contrainte**. Le mode de défaillance récurrent est la sur-ingénierie (recourir à l’orchestration multi-agents quand un workflow linéaire respecte le SLA à moindre coût et avec une plus grande fiabilité).
## Objectifs d’apprentissage
À la fin de cette page, vous devriez savoir :
1. Mener la **découverte** (discovery) : extraire le vrai problème, les critères de réussite et les contraintes fermes d’un brief de partie prenante.
2. Dessiner une **architecture de référence de bout en bout** (entrée → traitement → sortie → boucle de rétroaction) et nommer la responsabilité de chaque composant.
3. Choisir parmi les patrons **workflow, agentique et augmented-LLM** à l’aide de règles de décision fondées sur des signaux.
4. Décomposer le travail en **orchestration multi-agents** uniquement quand les signaux le justifient.
5. Aligner une conception sur les **piliers de valeur métier** (efficacité, coût, SLA de performance) et trancher un arbitrage **build-vs-buy**.
6. Choisir le **placement cloud** (API directe vs Bedrock vs Vertex vs Foundry) sur des critères de résidence des données, d’IAM et d’engagement.
7. Faire la **planification de capacité** face aux paliers de rate-limit et concevoir la **HA et le repli**.
8. Consigner les décisions sous forme d’**ADR**.
---
## 1.1 Discovery : du problème métier à une spécification résoluble
Les architectes reçoivent des *symptômes*, pas des spécifications. La discovery convertit « nous voulons utiliser l’IA pour le support » en un problème borné, doté de critères de réussite mesurables et de contraintes énumérées. Si vous sautez cette étape, chaque décision en aval est sans ancrage.
### Le jeu de questions de discovery
| Catégorie | Questions à poser | Pourquoi cela change la conception |
| --- | --- | --- |
| Problème & valeur | Quelle décision ou tâche automatise-t-on ? Quel est le pilier de valeur — efficacité, coût ou SLA ? | Détermine si c’est la latence, la justesse ou le coût unitaire qui domine |
| Critères de réussite | À quoi ressemble numériquement « suffisamment bon » (justesse, latence p95, taux de déflexion, coût par tâche) ? | Devient la cible d’éval et le point de décision go/no-go |
| Volume & forme | Requêtes par seconde, pic vs moyenne, synchrone vs asynchrone, tailles des charges utiles | Guide la planification de capacité et Batch vs temps réel |
| Données | Classe de sensibilité, résidence, obligations de rétention, sources, fraîcheur | Guide le placement cloud, la conception RAG, la conformité |
| Contraintes | Engagements cloud existants, IAM, plafond budgétaire, échéance, compétences de l’équipe | Restreint le build-vs-buy et le placement |
| Risque & réversibilité | Quel est le rayon d’impact d’une mauvaise réponse ? Quelles actions sont irréversibles ? | Détermine les points de contrôle humains et la profondeur des garde-fous |
| Intégration | Quels systèmes doit-il lire/écrire ? Quel modèle d’identité ? | Guide la conception des outils, MCP vs API, authn/authz |
:::tip[Signal d’examen]
Quand un énoncé vous donne un objectif vague plus un seul chiffre ferme (un SLA de latence, un budget mensuel, une exigence de résidence), la bonne réponse est celle qui **traite ce chiffre comme la contrainte contraignante** et rejette les options qui l’ignorent. « Aveugle à la contrainte » est le patron de mauvaise réponse le plus fréquent dans ce domaine.
:::
### Les critères de réussite doivent être mesurables et par segment
« Améliorer la qualité du support » n’est pas un critère de réussite. « Résoudre ≥ 60 % des tickets de facturation Tier-1 sans escalade, latence p95 sous 6 s, coût sous 0,05 $ par ticket résolu, sans régression sur les tickets liés aux remboursements » en est un. Notez la clause **par segment** — les cibles agrégées masquent les défaillances que l’examen veut vous faire repérer.
---
## 1.2 The end-to-end reference architecture
Toute solution Claude se décompose en quatre étapes plus des préoccupations transverses. Apprenez à placer n’importe quel composant dans ce squelette.
```text
INPUT PROCESSING OUTPUT FEEDBACK LOOP
┌───────────────┐ ┌───────────────────────┐ ┌───────────────┐ ┌───────────────────┐
│ user / event │ │ orchestration layer │ │ validation / │ │ evals (offline) │
│ API / webhook │──▶│ ┌─────────────────┐ │──▶│ structured │──▶│ online metrics │
│ queue / batch │ │ │ Claude model(s) │ │ │ output check │ │ traces + cost │
│ document │ │ │ + tools (MCP) │ │ │ human gate │ │ user thumbs / QA │
└───────────────┘ │ │ + retrieval/RAG │ │ └───────┬───────┘ └─────────┬─────────┘
│ └─────────────────┘ │ │ │
└───────────┬───────────┘ ▼ │
│ downstream systems │
cross-cutting: auth · secrets · guardrails · observability · caching ◀─────┘ (retrain prompts,
reroute models,
tune retrieval)
```
| Étape | Responsabilité | Décisions clés |
| --- | --- | --- |
| Input | Normaliser et admettre le travail | API synchrone vs webhook vs file vs Batch API ; validation de la charge utile |
| Processing | Raisonner et agir | Choix/routage de modèle, outils, récupération, patron d’orchestration |
| Output | Garantir la forme et la sûreté | Sorties structurées, validation-retry, point de contrôle humain sur les actions irréversibles |
| Feedback | Améliorer le système | Évals offline, métriques online, traces, télémétrie de coût réinjectées dans les prompts/modèles/récupération |
La **boucle de rétroaction n’est pas optionnelle** au niveau Professional. Une conception sans chemin des signaux de production vers les prompts, le routage et la récupération est incomplète — attendez-vous à des distracteurs qui l’omettent.
---
## 1.3 Choosing the pattern: workflow vs agentic vs augmented-LLM
C’est la décision la plus testée de D1. Le choix par défaut doit être le **patron le plus simple qui satisfait les critères**. N’escaladez vers l’agentique que lorsque la tâche exige réellement un flux de contrôle dynamique, piloté par le modèle.
| Patron | Ce que c’est | À choisir quand l’énoncé montre… | À éviter quand… |
| --- | --- | --- | --- |
| **Augmented LLM** | Un appel unique avec récupération + outils + sortie structurée | La tâche est une étape bornée ; entrées déterministes ; SLA latence/coût serré | La tâche nécessite plusieurs étapes dépendantes avec branchements |
| **Workflow (orchestré)** | Graphe d’étapes prédéfini ; le code possède le flux de contrôle ; les modèles remplissent les étapes | Les étapes sont connues et stables ; vous pouvez énumérer le DAG ; il faut de la reproductibilité et un débogage facile | Le chemin ne peut réellement pas être connu à l’avance |
| **Agentique** | Le modèle décide de l’action suivante dans une boucle jusqu’à `stop_reason` | Objectif ouvert ; nombre/ordre des étapes inconnu ; l’usage des outils est exploratoire | Un workflow fixe respecte le SLA plus économiquement et plus fiablement (la plupart des cas) |
```text
Is the sequence of steps knowable in advance?
├─ Yes → Can it be done in one call?
│ ├─ Yes → AUGMENTED LLM (retrieval + tools + structured output)
│ └─ No → WORKFLOW (orchestrated DAG; code owns control flow)
└─ No → Does the task truly need dynamic decisions AND is the cost/latency/reliability
hit justified by the value?
├─ Yes → AGENTIC (loop on stop_reason; bounded tools; guardrails)
└─ No → Re-decompose into a WORKFLOW
```
:::caution[Anti-patrons de flux de contrôle (favoris de l’examen)]
Une boucle agentique doit se terminer sur **`stop_reason`** (`end_turn` / `tool_use`), jamais en **analysant le langage naturel** à la recherche de « done », et jamais avec un **plafond d’itérations arbitraire comme arrêt principal**. Un plafond est un filet de sécurité, pas le mécanisme de contrôle. Les options qui utilisent le pattern-matching de chaîne ou un plafond seul sont fausses.
:::
---
## 1.4 Multi-agent orchestration and decomposition
Le multi-agent (coordinateur + sous-agents) est puissant et coûteux. Chaque sous-agent multiplie le coût en tokens et la latence, et ajoute de la surface de défaillance. Ne décomposez en plusieurs agents que lorsque les signaux sont présents.
| Signal pour le multi-agent | Signal contre (garder mono/workflow) |
| --- | --- |
| Sous-tâches réellement parallèles avec contexte indépendant | Les étapes sont séquentielles et partagent le contexte |
| Ensembles de compétences/outils distincts qui gonfleraient la liste d’outils d’un seul agent | Un seul ensemble d’outils sous ~5–7 outils suffit |
| Besoin d’isolation de contexte (un sous-agent explore sans polluer le coordinateur) | Le budget latence/coût est serré |
| Recherche/synthèse à long horizon où le fan-out/fan-in aide | La reproductibilité et le débogage facile sont prioritaires |
```text
┌──────────────┐
│ Coordinator │ owns plan, aggregates, applies guardrails
└──────┬───────┘
┌─────────┼─────────┐
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐ subagents: isolated context windows,
│ sub A │ │ sub B │ │ sub C │ narrow tool allowlists, own model tier
└───────┘ └───────┘ └───────┘ (e.g. Haiku for retrieval, Opus for synthesis)
```
Affectez des **modèles moins chers aux sous-agents étroits** (Haiku 4.5 pour l’extraction/le routage) et réservez **Opus 5** au coordinateur ou à l’étape de synthèse la plus difficile. C’est une décision de portefeuille, revue en D2.
---
## 1.5 Aligning to business value pillars
Toute conception sert un pilier dominant ; le nommer résout la plupart des arbitrages.
| Pilier | Métrique dominante | Leviers de conception | Posture modèle typique |
| --- | --- | --- | --- |
| Efficacité (débit / déflexion) | tâches automatisées, taux de déflexion | simplification du workflow, batching, caching | Sonnet 5 par défaut, Haiku pour le fort volume |
| Coût (économie unitaire) | coût par tâche | routage/cascades, prompt caching, Batch API, réduction de la sortie | Haiku 4.5 d’abord, escalade seulement en cas d’échec |
| SLA de performance (latence) | latence p50/p95 | fast mode, modèle plus petit, moins d’allers-retours d’outils, streaming | Haiku 4.5 / Sonnet 5, fast mode |
Quand deux piliers s’opposent (pas cher vs rapide, ou juste vs pas cher), le **critère de réussite énoncé tranche**. Si l’énoncé n’en donne aucun, la bonne réponse est généralement d’**aller le définir avec la partie prenante**, non de deviner.
---
## 1.6 Build vs buy
| Facteur | Pencher vers build | Pencher vers buy |
| --- | --- | --- |
| Différenciation | Cœur de l’avantage concurrentiel | Capacité de commodité |
| Capacité de l’équipe | Vous avez les compétences ML/infra pour l’opérer | Vous manquez de capacité d’exploitation |
| Time to value | Vous avez du temps devant vous | Vous en avez besoin maintenant |
| Coût total de possession | Le volume amortit le coût de build | Volume faible/incertain |
| Contrôle de conformité | Vous devez maîtriser tout le chemin de données | Les certifications du fournisseur suffisent |
Pour Claude en particulier, « buy » signifie souvent utiliser des **managed agents** (Anthropic héberge la boucle et le sandbox) ou un produit de plus haut niveau, tandis que « build » signifie l’**Agent SDK / Tool Runner** où vous hébergez la boucle. Choisissez le managé pour la rapidité et moins d’exploitation ; choisissez l’auto-hébergé quand il vous faut maîtriser l’environnement d’exécution, le chemin de données ou un outillage sur mesure.
---
## 1.7 Cloud placement: direct API vs Bedrock vs Vertex vs Foundry
Claude est disponible en direct et via **Amazon Bedrock**, **Google Vertex AI** et **Microsoft Foundry**. C’est une décision de conformité et d’engagement bien plus qu’une décision de capacité.
| Dimension | Direct (Anthropic API) | Amazon Bedrock | Google Vertex AI | Microsoft Foundry |
| --- | --- | --- | --- | --- |
| Résidence des données | Régions Anthropic | Régions AWS dont FedRAMP High | Régions GCP dont FedRAMP High | Régions Azure |
| IAM | Clés API Anthropic | AWS IAM / SigV4 / rôles | GCP IAM / comptes de service | Entra ID / Azure RBAC |
| Engagement existant | aucun | Engagement de dépense AWS / EDP | Engagement GCP | Engagement Azure / MACC |
| Conformité | Certifications Anthropic | Hérite d’AWS + FedRAMP High | Hérite de GCP + FedRAMP High | Hérite d’Azure |
| Dernières fonctionnalités d’abord | Généralement le plus tôt | Léger décalage | Léger décalage | Léger décalage |
:::tip[Signal d’examen]
« Les données doivent rester en région », « FedRAMP High », « nous avons déjà un EDP AWS », « l’identité doit passer par le SSO d’entreprise » → choisissez la **plateforme cloud dont vous possédez déjà l’IAM et la résidence** (Bedrock/Vertex/Foundry). « Nous voulons le modèle le plus récent le jour de sa sortie » et aucune contrainte de résidence → **API directe**. Ne choisissez pas l’API directe quand un signal de résidence ou d’engagement existant est présent.
:::
---
## 1.8 Capacity planning and rate-limit tiers
Les rate limits sont appliquées par modèle en **RPM** (requêtes/min), **ITPM** (tokens d’entrée/min) et **OTPM** (tokens de sortie/min), échelonnées par palier d’usage. La planification de capacité consiste à prouver que votre charge de pic tient dans le palier — ou à concevoir en la contournant.
1. Estimez le pic : `peak_RPM = peak_requests_per_sec × 60` ; `peak_ITPM = peak_RPM × avg_input_tokens` ; de même pour OTPM.
2. Comparez aux limites du palier du modèle (`client.models.retrieve(id)` et le palier du compte). Si vous dépassez l’une des trois, c’est celle-là qui vous limite.
3. Concevez en contournant les limites : basculez le travail tolérant à la latence vers la **Message Batches API** (remise de 50 %, résultats sous 24 h), étalez la charge, demandez une hausse de palier, ou routez le débordement vers un second modèle.
4. Gérez les 429 avec un **backoff exponentiel + jitter**, en respectant l’en-tête `retry-after`. Un 429 est attendu en cas de rafale, ce n’est pas une erreur à avaler.
```python
import time, random, anthropic
client = anthropic.Anthropic()
def call_with_backoff(**kwargs):
for attempt in range(6):
try:
return client.messages.create(**kwargs)
except anthropic.RateLimitError as e:
retry_after = float(getattr(e, "retry_after", 0) or 0)
sleep = retry_after or min(2 ** attempt + random.random(), 30)
time.sleep(sleep)
raise RuntimeError("exhausted retries")
```
---
## 1.9 High availability and fallback design
Les systèmes Claude de production doivent se dégrader gracieusement, non échouer brutalement. Réessayez `429/500/529` avec backoff ; en cas d’indisponibilité prolongée, **repliez sur un autre modèle ou fournisseur**.
```text
┌─────────────────────────┐
request ──▶ │ primary: claude-opus-5 │──✓──▶ response
└───────────┬─────────────┘
│ 529 overloaded / timeout (after backoff)
▼
┌─────────────────────────┐
│ fallback: claude-sonnet-5│──✓──▶ response (log degraded mode)
└───────────┬─────────────┘
│ still failing
▼
┌─────────────────────────┐
│ cross-provider: Bedrock │──✓──▶ response
│ or queued for retry │
└─────────────────────────┘
```
| Défaillance | Atténuation |
| --- | --- |
| Rate limit 429 | backoff + jitter, respecter `retry-after`, routage de débordement |
| 529 surchargé / 5xx | réessayer avec backoff ; replier sur un modèle/fournisseur secondaire |
| Panne régionale | multi-région via Bedrock/Vertex ; file et rejeu |
| Mauvaise forme de sortie | sorties structurées + validation-retry (D4) |
| Action irréversible | point de contrôle d’approbation humaine avant exécution |
:::caution[Un repli qui supprime silencieusement une capacité]
Les **thinking blocks de Fable 5.1 ne sont lisibles que par le modèle producteur ou plus récent** ; un repli silencieux vers un modèle plus ancien **supprime ces blocs** et peut corrompre une session agentique multi-tour. La conception du repli doit tenir compte de la parité fonctionnelle, pas seulement de la disponibilité. Ne masquez jamais un chemin dégradé en succès normal.
:::
---
## 1.10 Architecture Decision Records (ADRs)
Un ADR capture **une décision, son contexte, les options considérées, le choix et les conséquences**. À l’examen, la « meilleure » réponse reflète souvent la discipline ADR : elle énonce la contrainte, nomme l’alternative rejetée et pourquoi, et accepte un arbitrage explicite.
```markdown
# ADR-014: Retrieval layer for the policy-QA assistant
## Status: Accepted
## Context
Regulated (GDPR); 2M docs; answers must cite source clause; p95 < 8 s; budget $0.04/query.
## Decision
Hybrid retrieval (BM25 + dense) with reranking; Claude Sonnet 5 for synthesis on Vertex AI (EU residency).
## Alternatives considered
- Long-context stuffing (1M): rejected — cost per query > budget, no citation granularity.
- Fine-tuning: rejected — corpus changes weekly; retraining cadence infeasible.
- Direct API: rejected — EU data residency requires Vertex EU region.
## Consequences
+ Citations at clause level; cost within budget.
- Added reranker latency (~300 ms) and an index-refresh pipeline to operate.
```
---
## 1.11 Modélisation de capacité et de coût avec calcul
La planification de capacité au niveau Professional est un exercice de chiffres, pas d’intuition. Prouvez que la charge tient dans le palier et le budget *avant* la revue de conception.
### Modèle de capacité chiffré
Une charge de support : pic **20 requêtes/sec**, moyenne **8 req/s** ; chaque appel ~**6k d’entrée** + **1,5k de sortie** tokens sur Sonnet 5.
```text
peak_RPM = 20 req/s × 60 = 1,200 RPM
peak_ITPM = 1,200 × 6,000 = 7,200,000 input tokens/min
peak_OTPM = 1,200 × 1,500 = 1,800,000 output tokens/min
```
Vous êtes limité par celui de RPM / ITPM / OTPM que vous franchissez en premier. Si le palier plafonne l’ITPM à 4 000 000, l’ITPM est la limite contraignante à ~55 % du pic — donc ~45 % des requêtes de pic doivent basculer vers Batch, déborder vers un second modèle, ou vous demandez une hausse de palier.
### Modèle de coût chiffré (par mois)
Moyenne 8 req/s → `8 × 86,400 = 691,200 req/day ≈ 20.7M req/month`.
| Conception | Coût par requête | Mensuel (20,7 M req) |
| --- | --- | --- |
| Tout Sonnet 5 (6k in @ \$2, 1.5k out @ \$10) | 6k×\$2/1e6 + 1.5k×\$10/1e6 = \$0.012 + \$0.015 = **\$0.027** | **\$559k** |
| + prompt cache (80 % hit sur un préfixe stable de 4k, lecture 0,1×) | économise ~0,8×(4k×\$2×0,9)/1e6 = ~\$0.0058 → **\$0.021** | **\$435k** |
| Cascade : 70 % Haiku (\$0.0135), 30 % Sonnet (\$0.027) | 0.7×\$0.0135 + 0.3×\$0.027 = **\$0.0176** | **\$364k** |
| Cascade + cache + 30 % batchable à -50 % | ≈ **\$0.013** | **\$269k** |
:::tip[Signal d’examen]
Quand un énoncé donne le débit de requêtes, les tailles de tokens et un budget, la bonne réponse est la conception dont le **calcul passe sous le budget** — généralement cache + cascade + batch, pas « acheter un plus gros modèle » ou « espérer que le palier suffira ». Faites le calcul de tête : coût = (input_tokens × in_price + output_tokens × out_price) ÷ 1e6.
:::
| Levier | Économie typique | Précondition |
| --- | --- | --- |
| Prompt caching | 40–90 % du coût d’entrée sur le préfixe caché | Préfixe stable ≥ ~1024 tokens |
| Cascade / routage | 30–70 % au global | Une vérification de validation fiable pour escalader |
| Batch API | 50 % sur le trafic éligible | Tolérance de latence jusqu’à 24 h |
| Réduction de sortie / sortie structurée | 10–40 % du coût de sortie | Ne pas supprimer du contenu nécessaire |
---
## 1.12 Décomposition du budget de latence
Un SLA p95 est un *budget* à répartir sur le chemin de la requête. Si les parties dépassent le SLA en additionnées, la conception échoue avant de partir en production.
```text
p95 target: 6,000 ms
├─ network + auth ingress ...... 150 ms
├─ retrieval (hybrid + rerank) .. 400 ms
├─ model TTFT (Sonnet 5) ........ 600 ms
├─ model generation (1.5k tok) .. 3,200 ms
├─ tool round-trip (1 call) ..... 700 ms
├─ output validation ............ 120 ms
└─ headroom ..................... ~830 ms ✓ fits
```
| Si le budget est dépassé à cause de… | Levier |
| --- | --- |
| Temps de génération | Modèle plus petit/rapide, fast mode, sortie plus courte, streaming (améliore la latence perçue) |
| Trop d’allers-retours d’outils | Moins d’outils, paralléliser les appels indépendants, cacher les résultats d’outils |
| Récupération | k plus faible avec reranking, préchauffer l’index, cacher les embeddings |
| Mise en file du modèle sous charge | Palier supérieur, routage de débordement, Batch pour le travail non interactif |
:::tip[Signal d’examen]
« Le p95 dépasse le budget et l’essentiel est la génération » → réduire le modèle / la sortie / l’effort, ou streamer. Ajouter une couche multi-agents *augmente* la latence ; c’est la mauvaise réponse chaque fois qu’un budget de latence est la contrainte contraignante.
:::
---
## 1.13 Scénario détaillé : concevoir un assistant de triage de sinistres d’assurance
**Scénario.** Un assureur de taille moyenne veut « utiliser l’IA pour accélérer les sinistres ». La discovery fait émerger : 12 000 sinistres/jour (pic 3×), chaque sinistre a un PDF plus des métadonnées structurées ; l’assistant doit classer le type de sinistre, extraire les champs clés, signaler la fraude probable pour revue humaine, et rédiger un accusé de réception client. Réglementé (GDPR, résidents UE), déjà sur Azure, budget 40 000 $/mois, p95 sous 10 s pour le brouillon interactif, et les signalements de fraude **ne doivent pas auto-refuser** — un expert humain décide. Le taux de fraude historique est ~4 %.
**Trace de raisonnement d’expert.**
1. **Ancrer sur les contraintes.** GDPR + résidents UE + Azure existant → le placement est **Microsoft Foundry (Azure) en région UE** ; l’API directe est rejetée sur la résidence. L’auto-refus de fraude est irréversible et réglementé → un **point de contrôle humain** est obligatoire, non optionnel.
2. **Choix de patron.** Les étapes sont énumérables (classer → extraire → scorer la fraude → rédiger), donc c’est un **workflow**, pas une boucle agentique. Rejetez le multi-agent : les étapes sont séquentielles et partagent le contexte ; le fan-out n’apporte rien et ajoute coût/latence.
3. **Portefeuille de modèles.** L’extraction et la classification sont étroites, à fort volume → **Haiku 4.5**. Le raisonnement de fraude et le brouillon client sont à plus fort enjeu → **Sonnet 5**. Réservez l’escalade vers **Opus 5** aux seuls cas de fraude à faible confiance (une cascade sur un signal de *validation*, jamais sur la confiance auto-déclarée par le modèle).
4. **Capacité + coût.** 12k/jour de base, pic 3× → ~0,4 req/s en moyenne, ~1,25 req/s au pic — largement dans le palier ; pas besoin de Batch pour le chemin interactif, mais le re-scoring de masse nocturne peut utiliser Batch. Le coût est dominé par les tokens d’entrée des PDF → cachez le préfixe système/police stable ; le calcul passe sous 40 000 $.
5. **Boucle de rétroaction.** L’acceptation/l’override des experts sur les signalements de fraude est le flux d’étiquettes de référence → alimente une éval par segment (par type de sinistre) et recalibre le seuil de fraude. Sans cette boucle, la conception est incomplète.
6. **Consigner l’ADR.** Placement (Foundry UE), patron (workflow), portefeuille (cascade Haiku/Sonnet/Opus), point de contrôle humain sur la fraude, et les alternatives rejetées (API directe, multi-agent, auto-refus) avec leurs raisons.
**Pourquoi chaque alternative tentante est fausse :** l’API directe ignore la résidence UE ; le multi-agent sur-conçoit un workflow séquentiel ; l’auto-refus supprime le point de contrôle humain obligatoire sur une action irréversible et réglementée ; escalader sur la confiance auto-déclarée est l’anti-patron n° 4 ; un seul chiffre de justesse agrégé masquerait la défaillance par type de sinistre.
---
## 1.14 Common misconceptions
| Idée reçue | Réalité | Pourquoi c’est important à l’examen |
| --- | --- | --- |
| « L’agentique est plus avancé, donc c’est la meilleure conception. » | L’agentique est un outil pour un flux de contrôle *imprévisible* ; un workflow est meilleur quand les étapes sont connues. | Le distracteur de sur-ingénierie est la mauvaise réponse la plus fréquente en D1. |
| « Une plus grande fenêtre de contexte supprime le besoin de RAG. » | Une fenêtre de 1M coûte toujours par token et peut se dégrader sur le needle-in-haystack ; la récupération est moins chère et plus fraîche. | Les distracteurs proposent « bourrer le corpus dans le contexte » — rejetez-le sur le coût/la fraîcheur. |
| « Le modèle le plus capable est le choix par défaut sûr. » | Le modèle le moins cher qui franchit la barre de qualité est le bon défaut ; la capacité est routée là où elle est nécessaire. | Les réponses « Opus partout » font exploser les budgets coût/latence. |
| « Un 429 signifie que quelque chose est cassé. » | Le 429 est une contre-pression attendue ; gérez-le avec backoff + `retry-after`. | Les réponses qui traitent le 429 comme fatal ou l’avalent sont fausses. |
| « Le repli signifie juste réessayer un modèle moins cher. » | Le repli doit préserver la parité fonctionnelle (p. ex. les thinking blocks de Fable 5.1) et journaliser le mode dégradé. | Le distracteur de rétrogradation silencieuse corrompt les sessions agentiques. |
| « Le placement cloud est un choix de performance. » | C’est avant tout un choix de résidence/IAM/engagement (conformité). | Les signaux de résidence dans l’énoncé priment sur la nouveauté et le coût. |
| « Les critères de réussite sont un seul chiffre de justesse. » | Les critères doivent être par segment et liés au pilier de valeur. | Le piège de la métrique agrégée masque les défaillances par segment. |
---
## Pièges de l’examen dans ce domaine
| Piège | Pourquoi c’est faux |
| --- | --- |
| Recourir à l’orchestration multi-agents pour une tâche qu’un workflow linéaire gère | Sur-ingénierie ; coût, latence et surface de défaillance plus élevés sans bénéfice |
| Terminer une boucle d’agent en analysant le texte à la recherche de « done » | Devrait vérifier `stop_reason` ; le pattern-matching de chaîne est fragile et non sûr |
| Utiliser un plafond d’itérations comme mécanisme d’arrêt principal | Un plafond est un filet de sécurité ; le flux de contrôle doit être piloté par `stop_reason` |
| Choisir l’API directe quand l’énoncé indique une résidence UE / FedRAMP | Ignore une contrainte contraignante ; utilisez Bedrock/Vertex/Foundry |
| Concevoir sans boucle de rétroaction | Architecture incomplète ; aucun chemin des signaux de production vers l’amélioration |
| Choisir le modèle le plus puissant partout pour « être sûr » | Fait exploser les budgets coût/latence ; le routage/les cascades existent pour cela |
| Traiter un 429 comme une erreur fatale | Attendu en rafale ; réessayer avec backoff + `retry-after` |
| Repli silencieux vers un modèle plus ancien dans une session Fable 5.1 | Supprime les thinking blocks ; corrompt la boucle agentique ; masque la dégradation |
| Fixer les critères de réussite comme un seul chiffre agrégé | Masque la défaillance par segment ; les critères doivent être par segment |
| Sauter la discovery et concevoir à partir de la demande vague | Conception sans ancrage ; la contrainte contraignante n’est jamais mise au jour |
| Répondre à un énoncé de budget de latence en ajoutant une couche multi-agents | Le multi-agent augmente la latence ; faux quand le p95 est contraignant |
| « Acheter un plus gros modèle » comme correctif de coût quand le calcul favorise cache + cascade + batch | Ignore le modèle de coût ; un plus gros modèle augmente le coût unitaire |
| Choisir le placement sur la performance/nouveauté quand un signal de résidence est présent | Résidence/IAM/engagement gouvernent le placement, pas la vitesse |
| Auto-exécuter une action irréversible/réglementée sans point de contrôle humain | Supprime le point de contrôle d’approbation obligatoire ; non sûr et non conforme |
| Traiter la capacité par « le palier suffit probablement » sans calculer RPM/ITPM/OTPM | La limite contraignante est celle des trois que vous franchissez en premier |
---
## Questions d’entraînement
A. Un système multi-agents avec un coordinateur et des sous-agents spécialisés pour chaque type d’e-mail.
B. Un augmented-LLM ou un workflow simple : classer l’intention, appeler l’outil de statut de commande, renvoyer une réponse structurée — car les étapes sont connues et le budget SLA/coût favorise le patron le plus simple.
C. Une boucle agentique avec un large catalogue d’outils pour qu’elle puisse tout gérer.
D. Fine-tuner un modèle sur les e-mails historiques avant qu’aucun pipeline n’existe.
**Réponse : B.** Les étapes sont énumérables (classer → recherche → répondre), la latence et le coût sont contraignants, et le volume est modeste. Le patron le plus simple qui satisfait les critères l’emporte. Le multi-agent (A) et une large boucle agentique (C) sont sur-conçus, augmentant coût, latence et surface de défaillance. Le fine-tuning (D) est prématuré sans pipeline ni référentiel d’éval.
A. L’API directe Anthropic pour l’accès le plus précoce aux nouveaux modèles.
B. Google Vertex AI en région UE, en héritant de l’IAM et de la résidence GCP.
C. Amazon Bedrock, car il a le plus de certifications de conformité.
D. Le moins cher par token, quel qu’il soit.
**Réponse : B.** Deux contraintes contraignantes — la résidence UE et une empreinte GCP existante (IAM, engagement). Vertex AI en région UE satisfait les deux. L’API directe (A) risque la résidence. Bedrock (C) est conforme mais ignore l’investissement GCP et le modèle d’identité existants. Le coût (D) ne peut pas primer sur une exigence légale de résidence.
A. Piloter la terminaison à partir de `stop_reason` (`end_turn` / plus de `tool_use`).
B. Garder le plafond d’itérations, mais seulement comme filet de sécurité, pas comme contrôle principal.
C. Continuer à analyser le texte à la recherche de « complete » comme signal principal.
D. Supprimer toutes les limites et faire confiance au modèle pour s’arrêter.
E. Baisser la température pour qu’il s’arrête plus tôt.
**Réponse : A et B.** Le flux de contrôle doit reposer sur `stop_reason` ; un plafond d’itérations est un *filet de sécurité* légitime contre les boucles emballées mais pas le mécanisme principal. Analyser le langage naturel (C) est fragile et non sûr. Supprimer toutes les limites (D) risque un coût emballé. La température (E) ne gouverne pas la terminaison.
A. Commencer à construire un système agentique immédiatement.
B. Mener la discovery pour définir des critères de réussite mesurables par segment et énumérer les contraintes avant de concevoir.
C. Choisir Opus 5 car c’est le plus capable.
D. Supposer une cible de déflexion de 90 % et poursuivre.
**Réponse : B.** Sans critères de réussite ni contraintes, toute conception est sans ancrage. La discovery met au jour le pilier de valeur, les cibles numériques (par segment), le volume, la sensibilité des données et les contraintes. Construire (A), se replier sur le plus gros modèle (C) ou inventer une cible (D) sautent tous l’étape d’ancrage que l’examen récompense.
A. Déplacer les jobs tolérants à la latence vers la Message Batches API et ajouter un backoff exponentiel avec jitter respectant `retry-after`.
B. Réessayer immédiatement dans une boucle serrée jusqu’à réussir.
C. Demander un palier d’usage supérieur et/ou router le débordement vers un second modèle.
D. Avaler le 429 et renvoyer un résultat vide comme succès.
E. Basculer chaque requête sur Opus 5.
**Réponse : A et C.** Les plafonds ITPM/RPM sont dépassés au pic ; basculer le travail tolérant vers Batch (remise de 50 %, 24 h) plus le backoff, et augmenter le palier ou déborder vers un second modèle, sont les bons leviers de capacité. Le retry en boucle serrée (B) aggrave la tempête. Avaler les erreurs (D) est un anti-patron d’échec silencieux. Passer chaque requête à Opus (E) augmente le coût et ne corrige pas les rate limits.
A. Un pipeline de nettoyage de documents séquentiel en trois étapes avec contexte partagé.
B. Une tâche de recherche qui se déploie en plusieurs investigations indépendantes avec contexte isolé, puis synthétise les résultats.
C. Une seule recherche de statut de commande avec un budget de latence serré.
D. N’importe quelle tâche, pour être sûr.
**Réponse : B.** Des sous-tâches parallèles indépendantes avec isolation de contexte et synthèse par fan-in sont le signal multi-agents classique. Le travail séquentiel à contexte partagé (A) est un workflow. Une seule recherche (C) est un augmented-LLM. « N’importe quelle tâche » (D) est le piège de la sur-ingénierie.
A. Tout basculer sur Haiku 4.5 et accepter une justesse moindre.
B. Introduire une cascade : tenter d’abord Haiku 4.5 / Sonnet 5, escalader vers Opus 5 seulement quand les vérifications de confiance/validation échouent, et ajouter du prompt caching pour le préfixe stable.
C. Réduire le nombre d’utilisateurs.
D. Supprimer la suite d’évals pour économiser du calcul.
**Réponse : B.** Les cascades routent le moins cher d’abord et escaladent en cas d’échec, réduisant le coût tout en préservant la qualité sur les cas difficiles ; le caching amortit le préfixe stable. Haiku partout (A) sacrifie la justesse. Réduire les utilisateurs (C) ou les évals (D) ne traite pas l’économie unitaire de façon responsable.
A. Renvoyer une erreur à chaque utilisateur jusqu’au rétablissement.
B. Réessayer avec backoff ; si l’échec persiste, replier sur un modèle/fournisseur secondaire et journaliser la requête comme servie en mode dégradé.
C. Renvoyer silencieusement des réponses cachées mais périmées comme si elles étaient fraîches.
D. Basculer immédiatement vers un modèle bien plus ancien dans une session de thinking Fable 5.1 active.
**Réponse : B.** Le retry-puis-repli avec journalisation explicite du mode dégradé maintient le système disponible et observable. L’échec dur (A) est une mauvaise HA. Faire passer des réponses périmées pour fraîches (C) est un échec silencieux. Faire basculer une session Fable 5.1 active vers un modèle plus ancien (D) supprime les thinking blocks et corrompt la session.
A. Construire un runtime Agent SDK et un sandbox sur mesure de zéro.
B. Utiliser des managed agents (Anthropic héberge la boucle et le sandbox) pour réduire la charge d’exploitation et tenir l’échéance.
C. Reporter le projet jusqu’à l’embauche d’une équipe de plateforme ML.
D. Acheter le produit d’un concurrent sans support de Claude.
**Réponse : B.** Pas de capacité d’exploitation, échéance serrée, capacité de commodité → buy/managé. Les managed agents suppriment l’exploitation de la boucle et du sandbox. Construire (A) contredit les contraintes ; reporter (C) échoue à l’échéance ; (D) abandonne l’exigence.
A. Des exécutions d’éval offline contre un golden set à chaque release.
B. Des métriques online, des traces et de la télémétrie de coût qui informent les changements de prompt/modèle/récupération.
C. La normalisation initiale de la requête et la validation de la charge utile.
D. La définition du schéma de sortie structurée.
E. Le load balancer devant l’API.
**Réponse : A et B.** L’étape de rétroaction ferme la boucle des signaux de production vers les prompts, le routage et la récupération du système — les évals offline et la télémétrie/les traces online font exactement cela. La normalisation d’entrée (C) et la définition de schéma (D) relèvent des étapes d’entrée/sortie ; le load balancer (E) est de l’infrastructure, pas de la rétroaction.
A. Opus 5 avec effort xhigh pour une qualité maximale.
B. Haiku 4.5 (ou Sonnet 5), possiblement avec fast mode, un minimum d’allers-retours d’outils et du prompt caching — car la latence et le volume sont les piliers contraignants et la barre de justesse est modeste.
C. Un pipeline multi-agents pour la robustesse.
D. Le bourrage en long-context de toute la base de connaissances par requête.
**Réponse : B.** Le pilier contraignant est la latence à fort volume avec seulement un besoin de justesse modeste — le modèle le moins cher/le plus rapide qui franchit la barre, avec moins d’allers-retours et du caching. Opus + xhigh (A) maximise la latence et le coût face au SLA. Le multi-agent (C) ajoute de la latence. Le bourrage en long-context (D) gonfle les tokens, le coût et la latence.
A. Pour satisfaire un quota de documentation.
B. Pour capturer le contexte, les alternatives rejetées et leurs raisons, et l’arbitrage accepté, afin que la décision puisse être revue et reconsidérée à mesure que les contraintes changent.
C. Parce que les ADR remplacent les évals.
D. Parce qu’un système agentique ne peut pas être construit sans.
**Réponse : B.** Un ADR rend le raisonnement et les arbitrages explicites et revisables — exactement l’altitude que l’examen récompense. Ce n’est pas une formalité (A), ne remplace pas l’évaluation (C), et n’est pas un prérequis technique (D).
A. Environ \$0.027 ; le plus gros levier unique est le prompt caching sur le préfixe stable.
B. Environ \$0.27 ; basculer tout le monde sur Opus 5.
C. Environ \$0.003 ; ne rien faire.
D. Le coût est inconnaissable sans un test de charge.
**Réponse : A.** `6k×\$2/1e6 + 1.5k×\$10/1e6 = \$0.012 + \$0.015 = \$0.027`. Avec un préfixe stable, le prompt caching (lecture ≈ 0,1× de l’entrée) supprime l’essentiel du coût d’entrée — le plus grand levier ici. Opus (B) augmente le coût unitaire ; \$0.003 (C) est décalé d’un ordre de grandeur ; le coût est directement calculable (D).
A. Ajouter un coordinateur et trois sous-agents pour la robustesse.
B. Utiliser un modèle plus petit/rapide ou le fast mode, raccourcir/streamer la sortie, et baisser l’effort là où c’est suffisant — car la génération est le terme dominant.
C. Augmenter k dans la récupération pour améliorer la qualité.
D. Déplacer le chemin interactif vers la Batch API.
**Réponse : B.** Le budget de latence est dominé par la génération, donc réduisez le modèle/la sortie/l’effort ou streamez. Le multi-agent (A) ajoute de la latence ; un k plus grand (C) ajoute du temps de récupération ; Batch (D) a une latence pouvant aller jusqu’à 24 h et ne peut pas servir un SLA p95 interactif.
A. L’ITPM est la limite contraignante (ITPM de pic ≈ 7,2M > 4M).
B. Le RPM est la limite contraignante ; rien d’autre ne compte.
C. Basculer le trafic tolérant à la latence vers Batch et/ou demander un palier supérieur ou déborder le surplus vers un second modèle.
D. L’ignorer ; les rafales sont rares.
E. Envoyer tout vers Opus 5 pour être sûr.
**Réponse : A et C.** `peak_ITPM = 20×60×6,000 = 7.2M`, ce qui dépasse le plafond de 4M, donc l’ITPM contraint en premier. Le correctif est de réduire l’ITPM interactif via Batch, un palier supérieur ou un routage de débordement. RPM seul (B) fait mal le calcul ; ignorer les rafales (D) cause des tempêtes de 429 ; Opus pour tout (E) augmente le coût et l’ITPM.
A. Déployer sur Microsoft Foundry en région UE pour la résidence et l’IAM existant.
B. Router l’auto-refus de fraude directement vers le modèle pour gagner du temps d’expert.
C. Insérer un point de contrôle d’approbation humaine obligatoire avant tout refus (action irréversible, réglementée).
D. Utiliser l’API directe Anthropic pour le modèle le plus récent.
E. Fixer une seule cible de justesse agrégée sur tous les types de sinistres.
**Réponse : A et C.** Résidence UE + Azure existant → Foundry UE ; une action réglementée irréversible requiert un point de contrôle humain. L’auto-refus (B) supprime le point de contrôle obligatoire ; l’API directe (D) risque la résidence ; une seule cible agrégée (E) masque la défaillance par type de sinistre.
A. Augmenter le plafond d’itérations.
B. Ne replier que vers un modèle à parité fonctionnelle (support du thinking égal ou plus récent), journaliser le mode dégradé, et ne jamais rétrograder silencieusement une session de thinking.
C. Désactiver les retries pour échouer vite.
D. Analyser le texte de sortie pour détecter la corruption.
**Réponse : B.** Le repli doit préserver la parité fonctionnelle — les thinking blocks ne sont lisibles que par le modèle producteur ou plus récent — et le mode dégradé doit être journalisé, non silencieux. Les plafonds d’itérations (A) et l’analyse de texte (D) ne traitent pas la parité fonctionnelle ; désactiver les retries (C) nuit à la disponibilité.
A. Choisir le modèle le plus capable pour que la qualité ne soit jamais en question.
B. Calculer le coût par requête, puis combiner le prompt caching sur le préfixe stable, une cascade cheap-first escaladant en cas d’échec de validation, et Batch pour le trafic tolérant à la latence jusqu’à ce que le calcul passe sous le budget.
C. Deviner une conception et l’ajuster après le lancement.
D. Supprimer l’évaluation pour réduire le coût de calcul.
**Réponse : B.** La rentabilité sous un budget énoncé est un exercice de calcul : cache + cascade + batch superposés jusqu’à coût < budget, avec la qualité préservée sur les cas difficiles via la cascade. Le tout-capable (A) surdépense ; deviner (C) est sans ancrage ; supprimer les évals (D) retire la garde de qualité.
## À retenir
- Partez de la discovery pour chaque conception : le pilier de valeur, des critères de réussite mesurables **par segment**, et les contraintes contraignantes.
- Décomposez en input → processing → output → **boucle de rétroaction** ; une conception sans la boucle est incomplète.
- Choisissez le **patron le plus simple** qui satisfait les critères : augmented-LLM → workflow → agentique. La sur-ingénierie est la mauvaise réponse n° 1.
- Les boucles agentiques se terminent sur **`stop_reason`** ; les plafonds d’itérations sont des filets de sécurité, jamais le contrôle principal.
- Le multi-agent seulement quand les sous-tâches sont réellement parallèles/isolées ; affectez des modèles moins chers aux sous-agents étroits.
- Le placement cloud suit la **résidence, l’IAM et les engagements existants** — Bedrock/Vertex/Foundry pour ces contraintes, API directe sinon.
- Planifiez la capacité face aux paliers RPM/ITPM/OTPM ; utilisez la Batch API, le backoff et le routage de débordement.
- Concevez pour la défaillance avec retries et **repli de modèle/fournisseur**, en veillant à la parité fonctionnelle (thinking blocks de Fable 5.1).
- Consignez les décisions sous forme d’**ADR** qui nomment les alternatives rejetées et les arbitrages acceptés.
- **Modélisez le calcul** : coût par requête = (in_tok×in_price + out_tok×out_price)/1e6 ; superposez caching + cascade + Batch jusqu’à passer sous le budget.
- Traitez un **SLA p95 comme un budget** décomposé sur le chemin de la requête ; si la génération domine, réduisez modèle/sortie/effort ou streamez — n’ajoutez jamais de latence avec du multi-agent.
- Calculez **RPM / ITPM / OTPM** et concevez autour de celui qui contraint en premier ; « le palier suffit probablement » n’est pas de la planification de capacité.
- Placez un **point de contrôle humain** sur chaque action irréversible/réglementée, et faites en sorte que les replis préservent la **parité fonctionnelle** avec journalisation du mode dégradé.