Version : 1.1 · Date : 2026-10-22 · Domaine 4 : Eval, Testing, and Debugging (2,6 %), puis préparation à l'examen

En une phrase : face à une panne, on identifie d'abord la couche (une erreur HTTP de l'intégration, ou un HTTP 200 dont le contenu ne va pas), puis la classe (déterministe ou transitoire, ou le stop_reason), et seulement ensuite la reprise ; et on protège chaque correction par un jeu d'évaluation qui empêche la régression.

Ce chapitre a deux parties :

• Partie A (sections 1 à 6) : le domaine 4, le plus petit de l'examen (2,6 %, une ou deux questions), mais celui qui sert tous les jours en production.
• Partie B (sections 7 à 11) : la préparation à l'examen, avec la méthode, les 3 questions d'exemple officielles commentées, 36 questions d'entraînement réparties comme l'examen et une fiche de révision finale.

Ce que l'examen demande#

Le guide officiel (Exam Guide v1.0, juillet 2026) découpe ce skill en quatre gestes : identifier le type d'erreur (section 2), choisir la stratégie de reprise (section 3), analyser une trace pour trouver le mode de défaillance (section 4), isoler l'origine entre la couche d'intégration et la sortie du modèle (section 5). La section 6 ajoute les évaluations, citées dans le profil du guide (« designing and running evals ») comme compétence attendue d'un développeur.

Partie A · Eval, Testing, and Debugging

1. Les bases : deux couches, deux signaux#

Deux champs à ne pas confondre :

• error.type n'existe que dans une réponse en échec. C'est une chaîne stable (rate_limit_error, invalid_request_error…) sur laquelle on branche le code, plutôt que sur le message.
• stop_reason n'existe que dans une réponse réussie. Il dit pourquoi la génération s'est arrêtée.

Piège classique : « HTTP 200 » ne veut pas dire « réponse correcte ». Une réponse tronquée (max_tokens), un refus de sécurité (refusal) ou une réponse vide arrivent avec un 200.

2. Identifier le type d'erreur#

2.1 La forme d'une erreur#

L'API renvoie toujours ses erreurs en JSON, avec un objet error qui porte un type et un message, plus un request_id :

{
  "type": "error",
  "error": {
    "type": "not_found_error",
    "message": "The requested resource could not be found."
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

La documentation prévient que les valeurs de type peuvent s'enrichir avec le temps : prévoir une branche par défaut.

2.2 Les codes à connaître#

2.3 Le cas piège du 429#

Le même rate_limit_error recouvre deux situations qui se traitent à l'opposé :

À l'inverse, une spend limit que vous avez fixée vous-même sous le plafond du tier renvoie un 400 invalid_request_error (message « You have reached your specified API usage limits »).

2.4 Le request ID, et les erreurs en plein streaming#

• Chaque réponse porte un en-tête request-id (par exemple req_018EeW…), recopié dans request_id du corps d'erreur. C'est l'identifiant à donner au support. Les SDK Python et TypeScript l'exposent dans _request_id de l'objet réponse ; la CLI ant l'affiche avec --debug.
• En streaming, une erreur peut survenir après le 200 : elle arrive sous forme d'événement error dans le flux, pas comme une exception à l'appel. Un try/except autour de la seule création du flux ne suffit pas.
• Toujours en streaming, stop_reason vaut null dans message_start et n'arrive que dans l'événement message_delta.

2.5 Les exceptions typées des SDK#

Les SDK officiels lèvent des exceptions typées (anthropic.NotFoundError, anthropic.RateLimitError…). La documentation recommande de capturer les classes typées plutôt que de comparer des messages, en traitant les plus spécifiques d'abord :

import logging
import anthropic

log = logging.getLogger("claude")
client = anthropic.Anthropic()  # clé lue dans ANTHROPIC_API_KEY ; 2 retries automatiques par défaut

def appeler(messages, **params):
    try:
        msg = client.messages.create(model="claude-sonnet-5-5", max_tokens=2048, messages=messages, **params)
    except anthropic.RateLimitError as e:            # 429 : rate limit ou spend cap
        log.warning("429 request-id=%s retry-after=%s", e.response.headers.get("request-id"),
                    e.response.headers.get("retry-after"))
        raise
    except anthropic.APIStatusError as e:            # tous les autres 4xx / 5xx
        log.error("HTTP %s request-id=%s %s", e.status_code, e.response.headers.get("request-id"), e.message)
        raise
    except anthropic.APIConnectionError:             # réseau : aucune réponse HTTP reçue
        log.error("connexion impossible")
        raise
    # Un 200 n'est pas un succès tant que stop_reason n'est pas vérifié (section 3.2)
    log.info("request-id=%s stop_reason=%s usage=%s", msg._request_id, msg.stop_reason, msg.usage)
    return msg

3. Choisir la stratégie de reprise#

3.1 Selon la classe d'erreur#

Les SDK officiels réessaient automatiquement les erreurs transitoires (connexion, rate limits, 5xx) avec un backoff exponentiel, 2 fois par défaut, en respectant retry-after. On règle ce comportement avec max_retries (maxRetries en TypeScript), y compris à 0 pour le désactiver et gérer soi-même la reprise.

Pour les requêtes longues, la documentation recommande le streaming ou Message Batches, surtout au-delà de 10 minutes : les SDK refusent un appel non streamé susceptible de dépasser 10 minutes, et certains réseaux coupent les connexions inactives. Si l'on n'a pas besoin des événements, le SDK peut consommer le flux et rendre le Message complet (get_final_message() en Python, finalMessage() en TypeScript).

Deux garanties à vérifier pour toute reprise automatique :

• Idempotence : ne pas réexécuter un outil à effet de bord (envoyer un e-mail, débiter un compte) parce que l'appel suivant a échoué.
• Épuisement : après le dernier essai, échouer clairement ou dégrader explicitement ; ne jamais servir une ancienne réponse comme si elle était fraîche.

3.2 Selon le stop_reason d'un HTTP 200#

Le refus en détail. Sur Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5 et Haiku 5.5, un refus arrive comme une réponse normale avec stop_reason: "refusal" ; stop_details.category nomme le domaine (cyber, bio, frontier_llm, general_harms…). Un refus peut arriver avant toute sortie ou en plein flux : toute sortie partielle est à jeter. Trois façons de réessayer sur un autre modèle :

Claude Haiku 5.5 n'a ni server-side fallback ni fallback credit : passer par le middleware ou un essai manuel.

La réponse vide après un outil. Claude peut renvoyer une réponse quasi vide avec end_turn juste après des résultats d'outils. Cause fréquente : du texte ajouté juste après un bloc tool_result, ou la réponse terminée renvoyée telle quelle. Ne pas réessayer la réponse vide à l'identique ; en dernier recours, ajouter « Please continue » dans un nouveau message utilisateur.

3.3 Selon l'erreur d'un outil#

Quand l'exécution d'un outil échoue, on renvoie un tool_result avec is_error: true et un message exploitable (ce qui a échoué, ce que Claude peut essayer à la place). Un message générique comme « failed » pousse le modèle à deviner. Le détail de la conception des erreurs d'outil est au chapitre 07.

4. Analyser une trace#

4.1 Ce qu'il faut journaliser à chaque appel#

Attention au champ input_tokens : il ne compte que les tokens après le dernier cache breakpoint. Le total d'entrée vaut cache_read_input_tokens + cache_creation_input_tokens + input_tokens.

4.2 La règle de la première divergence#

Dans une exécution en plusieurs étapes (classification, recherche, appel d'outil, réponse), une erreur au début se propage : l'étape finale fausse n'est souvent qu'une conséquence. On compare chaque étape à l'attendu, dans l'ordre, et on s'arrête à la première qui diverge. Corriger le prompt de la réponse finale quand c'est la recherche qui a ramené le mauvais document ne résout rien.

flowchart TD
    A["Symptôme constaté"] --> B{"Statut HTTP ?"}
    B -- "4xx / 5xx" --> C["Couche d'intégration : lire error.type"]
    C --> C1{"Même échec à chaque essai ?"}
    C1 -- "Oui" --> C2["Déterministe : corriger la requête"]
    C1 -- "Non" --> C3["Transitoire : backoff, retry-after"]
    B -- "200" --> D{"stop_reason ?"}
    D -- "max_tokens, model_context_window_exceeded" --> D1["Budget ou contexte"]
    D -- "refusal" --> D2["Modèle de repli, jeter la sortie partielle"]
    D -- "end_turn" --> E{"Le contexte envoyé était-il correct ?"}
    E -- "Non" --> E1["Corriger l'étape qui a construit le contexte"]
    E -- "Oui" --> E2["Prompt ou modèle : itérer avec un jeu d'évaluation"]

5. Isoler l'origine : intégration ou modèle#

Les changements cassants qui se déguisent en bug. Plusieurs paramètres valides sur d'anciens modèles renvoient un 400 invalid_request_error sur les nouveaux (documentation Errors, section Common validation errors) :

Réflexe d'examen : un 400 qui apparaît juste après un changement de modèle est un problème d'intégration (paramètre retiré), pas un problème de prompt. Le détail des changements entre modèles est au chapitre 04.

6. Évaluer pour ne pas régresser#

Un correctif de prompt qui règle un cas peut en casser trois autres. La documentation Anthropic (Define success criteria and build evaluations) propose une démarche en trois temps.

1. Des critères de succès specific, measurable, achievable, relevant : « F1 d'au moins 0,85 sur 10 000 tweets », pas « bonne classification ». Critères courants : task fidelity, consistency, relevance and coherence, tone and style, privacy preservation, context utilization, latency, price. La plupart des cas demandent plusieurs critères à la fois.

2. Un jeu de test fidèle à la distribution réelle, avec les cas limites (entrée vide ou hors sujet, très longue, ambiguë, malveillante). Chaque bug trouvé en production devient un cas de régression.

3. Une notation automatisée, en privilégiant le volume : beaucoup de cas notés automatiquement valent mieux que peu de cas notés à la main.

Conseils documentés pour un grader LLM : utiliser un autre modèle que celui qui a produit la sortie, délimiter la sortie évaluée par des balises (<response>…</response>), définir les bornes de l'échelle, contraindre la réponse du grader (« Output only the number »).

Lancer une évaluation à grande échelle : Message Batches est fait pour cela (50 % moins cher, la plupart des lots finissent en moins d'une heure, expiration à 24 h, résultats disponibles 29 jours). Chaque résultat a un type : succeeded, errored (requête invalide ou erreur serveur, non facturée), canceled, expired (non facturée). L'ordre des résultats n'est pas garanti : on les rapproche par custom_id.

# Rejouer un jeu de test et noter par exact match ; un changement à la fois, même jeu à chaque essai
cas = [{"entree": "Livraison en retard, très déçu.", "attendu": "negatif"},
       {"entree": "Parfait, merci !", "attendu": "positif"}]

def noter(sortie: str, attendu: str) -> bool:
    return sortie.strip().lower() == attendu

score = sum(noter(classer(c["entree"]), c["attendu"]) for c in cas) / len(cas)   # classer() appelle Claude

6.1 Labs conseillés (domaine 4)#

Clé d'API d'un workspace de test, avec une spend limit basse fixée dans la Console (Billing > Spend limits).

Nettoyage : révoquer la clé de test, remettre la spend limit voulue.

6.2 Pièges d'examen (domaine 4)#

Partie B · Préparer l'examen

7. L'examen en bref#

Les questions sont des cas pratiques : 120 minutes pour 53 questions laissent environ 2 minutes par question.

8. Méthode : lire une question, écarter les distracteurs#

1. Lire la dernière phrase d'abord : que demande-t-on (la meilleure approche, la cause, la première action) ?
2. Souligner la contrainte décisive : coût, latence, sécurité, réutilisation, volume, délai.
3. Classer le problème : intégration ou modèle, déterministe ou transitoire, temps réel ou différé.
4. Éliminer les réponses qui ne traitent pas la contrainte, puis choisir la plus simple qui la traite.

9. Les questions d'exemple officielles, commentées#

Le guide (§ 8) propose 3 questions illustratives, hors banque d'examen. Elles sont résumées ici (le guide est en lecture libre ; le contenu de l'examen réel, lui, est confidentiel).

10. 36 questions d'entraînement#

Réparties comme l'examen : D1 5, D2 12, D3 1, D4 1, D5 6, D6 4, D7 3, D8 4. Une seule réponse sauf mention contraire. Corrigé en fin de section.

Domaine 1 · Agents and Workflows#

Q1. Une tâche suit toujours les mêmes étapes : extraire les champs d'une facture, les valider, les enregistrer. Quelle architecture ? A. Un agent autonome qui décide de l'ordre des étapes · B. Un workflow à étapes codées · C. Un coordinator avec trois subagents · D. Un agent par champ

Q2. Un agent de recherche accumule des dizaines de pages intermédiaires et sa fenêtre de contexte sature. Quelle évolution aide le plus ? A. Augmenter max_tokens · B. Confier les recherches à des subagents qui renvoient un résultat condensé · C. Passer à un modèle plus gros · D. Désactiver les outils

Q3. Règle impérative : l'agent ne doit jamais supprimer de fichier hors du dépôt. Quel mécanisme ? A. Une phrase en majuscules dans le system prompt · B. Un hook PreToolUse qui bloque l'appel · C. Un exemple few-shot · D. Un modèle plus récent

Q4. Un coordinator délègue une analyse à un subagent, qui répond « je n'ai pas le document ». Cause la plus probable ? A. Le subagent n'hérite pas automatiquement du contexte du coordinator : il faut lui passer explicitement ce dont il a besoin · B. Rate limit · C. Le modèle est trop petit · D. Le document est trop long

Q5. Quel est le principal inconvénient cité par Anthropic à propos des frameworks d'agents (LangGraph, Strands, PydanticAI…) ? A. Ils sont incompatibles avec Claude · B. Ils ajoutent des couches d'abstraction qui masquent les prompts et les réponses sous-jacents et compliquent le débogage · C. Ils interdisent les outils · D. Ils coûtent plus cher en tokens par nature

Domaine 2 · Applications and Integration#

Q6. Une équipe veut rejouer chaque nuit 5 000 cas d'évaluation au moindre coût. Quelle API ? A. Messages en parallèle · B. Message Batches · C. Streaming · D. Token Counting

Q7. Les résultats d'un lot reviennent dans un autre ordre que les requêtes. Comment les rapprocher ? A. Par position · B. Par custom_id · C. Par horodatage · D. Impossible

Q8. Dans un lot terminé, 40 requêtes ont le type expired. Que faut-il en conclure ? (2 réponses) A. Elles n'ont pas été facturées · B. Elles ont été facturées au tarif batch · C. Le lot a atteint son expiration de 24 h avant de les traiter : les resoumettre · D. Elles contenaient une erreur de validation

Q9. Une génération très longue, non streamée, échoue côté SDK avant même l'envoi. Explication ? A. Bug du SDK · B. Le SDK refuse un appel non streamé susceptible de dépasser 10 minutes : passer au streaming · C. La clé est invalide · D. max_tokens est trop bas

Q10. En streaming, où lit-on stop_reason ? A. Dans message_start · B. Dans message_delta · C. Dans chaque content_block_delta · D. Dans l'en-tête HTTP

Q11. Une application tourne sur Amazon Bedrock et veut un repli automatique après un refus. Quelle approche ? A. Le paramètre fallbacks: "default" · B. Le middleware du SDK (ou un essai manuel) · C. Augmenter la temperature · D. Message Batches

Q12. Un document de 200 000 tokens est réutilisé à chaque requête. Quel effet a le prompt caching sur les rate limits ? A. Aucun · B. Pour la plupart des modèles, les tokens lus dans le cache ne comptent pas dans l'ITPM : le débit utile monte · C. Le cache double l'ITPM consommée · D. Le cache supprime l'OTPM

Q13. Un utilisateur envoie un PDF de 80 MB. La requête Messages échoue en 413. Que faire ? A. Réessayer · B. Passer par la Files API, dont la limite est bien plus haute (500 MB) · C. Augmenter max_tokens · D. Changer de modèle

Q14. Un service envoie des centaines de requêtes simultanées et reçoit des 429 par vagues. Quelle combinaison ? (2 réponses) A. Client asynchrone avec une concurrence plafonnée · B. Retry immédiat sans délai · C. Backoff avec jitter respectant retry-after · D. Désactiver les retries du SDK

Q15. L'application parse le JSON produit par Claude et plante une fois sur cinquante. Quelle solution est la plus robuste ? A. « Réponds uniquement en JSON » en majuscules · B. Une sortie contrainte par schéma (structured outputs) et une validation côté code · C. Un modèle plus gros · D. Une temperature à 0

Q16. Une équipe met ses règles de rédaction dans CLAUDE.md et s'étonne que son application, qui appelle la Messages API, ne les applique pas. Pourquoi ? A. CLAUDE.md est lu par Claude Code, pas par la Messages API : il faut mettre ces règles dans le system prompt de l'application · B. Le fichier est trop long · C. Il faut un en-tête bêta · D. Le modèle ignore le français

Q17. En production, pourquoi épingler une version de modèle précise plutôt que suivre automatiquement la dernière ? A. C'est moins cher · B. Pour qu'un changement de modèle (et ses éventuels changements cassants) passe d'abord par les tests et l'évaluation · C. C'est obligatoire · D. Pour éviter les rate limits

Domaine 3 · Claude Code#

Q18. Dans un pipeline de CI, on veut lancer Claude Code sans interface et exploiter sa sortie. Quel mode ? A. Le mode interactif · B. Le mode headless (claude -p) avec une sortie JSON (--output-format json) · C. Plan mode · D. Une session reprise

Domaine 4 · Eval, Testing, and Debugging#

Q19. Une réponse de résumé s'arrête au milieu d'une phrase, toujours à peu près à la même longueur, avec un HTTP 200. Que faire ? A. Changer de modèle · B. Réécrire le prompt · C. Lire stop_reason : c'est max_tokens, augmenter le budget ou poursuivre la réponse · D. Réessayer

Domaine 5 · Model Selection and Optimization#

Q20. Après passage à un modèle récent, l'appel renvoie « "thinking.type.enabled" is not supported for this model ». Que faire ? A. Réessayer · B. Passer à thinking: {"type": "adaptive"} et régler output_config.effort · C. Retirer les outils · D. Augmenter budget_tokens

Q21. Une application préremplit le début de la réponse assistant pour forcer un format. Sur un modèle Claude 4.6 ou plus récent, la requête échoue en 400. Correction documentée ? A. Préremplir plus court · B. Structured outputs (output_config.format) ou consignes dans le system prompt · C. Un autre SDK · D. Une temperature plus basse

Q22. Sur Claude Opus 5.5, tool_choice: {"type": "tool", "name": "extraire"} renvoie un 400. Que faire ? A. Passer à tool_choice: auto avec strict tool use, ou utiliser structured outputs · B. Retirer name · C. Réessayer · D. Ajouter un en-tête bêta

Q23. Une tâche de classification simple et très volumineuse doit coûter le moins possible. Démarche ? A. Prendre Opus par défaut · B. Essayer le plus petit modèle qui atteint le seuil de qualité (par exemple Haiku), validé par un jeu d'évaluation · C. Toujours le plus récent · D. Le choix n'a pas d'effet sur le coût

Q24. usage affiche input_tokens: 50 alors que la requête contient un document de 200 000 tokens en cache. Est-ce une erreur ? A. Oui · B. Non : input_tokens ne compte que les tokens après le dernier cache breakpoint ; le total = cache_read_input_tokens + cache_creation_input_tokens + input_tokens · C. Le cache a échoué · D. Le document a été ignoré

Q25. Une application interactive sur Opus doit répondre plus vite, et le budget le permet. Quelle option l'API propose-t-elle ? A. Baisser la temperature · B. Le fast mode (speed: "fast"), avec ses propres rate limits · C. Message Batches · D. Le prefill

Domaine 6 · Prompt and Context Engineering#

Q26. Un agent qui tourne longtemps ralentit et se trompe sur des faits du début de la session. Quelles mesures ? (2 réponses) A. Élaguer les sorties d'outils verbeuses et compacter l'historique · B. Augmenter la temperature · C. Isoler les sous-tâches dans des subagents · D. Répéter tout l'historique à chaque tour

Q27. Le format de sortie varie d'une réponse à l'autre malgré une consigne claire. Quel levier en premier ? A. Un modèle plus gros · B. Des exemples few-shot du format attendu et une contrainte de sortie explicite · C. Plus de contexte · D. Un retry

Q28. L'application insère des documents fournis par les utilisateurs dans le prompt. Bonne pratique ? A. Les mélanger aux instructions · B. Les délimiter clairement (balises) et les traiter comme des données, jamais comme des instructions · C. Les traduire · D. Les mettre dans le system prompt

Q29. Claude affirme avec assurance un résultat chiffré qui alimente une décision. Attitude attendue ? A. Lui faire confiance s'il est affirmatif · B. Valider la sortie (schéma, contrôles métier, sources) avant de l'utiliser · C. Demander « es-tu sûr ? » · D. Doubler max_tokens

Domaine 7 · Security and Safety#

Q30. Où ranger la clé d'API d'une application web qui appelle Claude ? A. Dans le code JavaScript du navigateur · B. Côté serveur, dans un gestionnaire de secrets ou une variable d'environnement, une clé par environnement, avec rotation · C. Dans le dépôt Git privé · D. Dans le system prompt

Q31. Un agent dispose d'un outil de suppression en base. Comment éviter une suppression destructive déclenchée par un contenu malveillant ? (2 réponses) A. Moindre privilège : retirer l'outil quand il n'est pas nécessaire, ou le restreindre · B. Une consigne polie · C. Un hook ou une approbation humaine avant toute action destructive · D. Un modèle plus gros

Q32. Des données personnelles transitent par l'application. Bonne pratique ? A. Tout journaliser en clair pour le débogage · B. Minimiser les PII envoyées, les masquer dans les journaux et limiter qui peut lire les traces · C. Ne jamais journaliser du tout · D. Chiffrer seulement le prompt

Domaine 8 · Tools and MCPs#

Q33. L'API métier appelée par un outil renvoie une erreur. Que renvoyer à Claude ? A. Rien · B. Un tool_result avec is_error: true et un message qui dit ce qui a échoué et quoi essayer · C. « failed » · D. Une exception au niveau HTTP

Q34. Une équipe veut donner à Claude Code une procédure réutilisable (instructions et scripts de revue de code), chargée à la demande. Quel mécanisme ? A. Un serveur MCP · B. Une Skill · C. Un custom tool dans chaque requête · D. Un CLAUDE.md de 3 000 lignes

Q35. Un serveur MCP est lancé en local comme sous-processus de l'application. Quel transport ? A. stdio · B. SSE · C. Un fichier partagé · D. Une file de messages

Q36. Claude appelle souvent le mauvais de deux outils aux noms proches. Premier correctif ? A. Un modèle plus gros · B. Réécrire les descriptions (quand l'utiliser, entrées, sorties, différence avec l'autre outil), voire fusionner les outils · C. Retirer un outil au hasard · D. Forcer l'outil par tool_choice

Corrigé#

11. Fiche de révision finale#

Domaine 1 · Agents and Workflows (14,7 %) · chapitre 01

• Workflow (étapes codées) ou agent (étapes décidées par le modèle) ; le plus simple qui suffit.
• Coordinator et subagents : contexte isolé, passé explicitement, résultat condensé.
• Hooks pour les actions qui doivent être déterministes ; agents managés ou auto-hébergés.

Domaine 2 · Applications and Integration (33,1 %) · chapitres 02 et 03

• Messages API, streaming (message_delta, événement error), vision, thinking, caching, Message Batches (−50 %, 24 h, 29 jours, custom_id).
• Temps réel ou différé selon la latence exigée ; requêtes de plus de 10 minutes : streaming ou batch.
• CLAUDE.md et settings.json pour Claude Code, system prompt pour l'API ; épingler les versions de modèle et de prompt.

Domaine 3 · Claude Code (3,1 %) · chapitre 03

• Hiérarchie CLAUDE.md, Rules, Skills, Commands, Agents ; mode headless -p pour la CI.

Domaine 4 · Eval, Testing, and Debugging (2,6 %) · ce chapitre

• Couche (HTTP 4xx/5xx ou 200), classe (déterministe, transitoire, stop_reason), reprise.
• 429 avec ou sans retry-after ; spend limit fixée par vous = 400.
• Journaliser request-id, statut, error.type, stop_reason, usage, contexte réel ; chercher la première divergence.
• Jeu de régression, notation automatisée, grader LLM distinct du modèle évalué.

Domaine 5 · Model Selection and Optimization (16,8 %) · chapitre 04

• Tokens, fenêtre de contexte, non-déterminisme ; zero-, single-, multi-shot.
• Adaptive thinking et effort ; fast mode ; changements cassants (prefill, extended thinking, outil forcé).
• Opus, Sonnet ou Haiku selon qualité, latence, coût ; suivi de usage et prompt caching.

Domaine 6 · Prompt and Context Engineering (11,0 %) · chapitre 05

• Instructions claires, few-shot, placement system / user, contraintes de sortie, entrées délimitées.
• Élagage, compaction, isolation par subagents ; sortie structurée, validation, parsing défensif.

Domaine 7 · Security and Safety (8,1 %) · chapitre 06

• Prompt injection : contenu externe = données ; jailbreak, PII, fuite de données.
• Guardrails en couches, moindre privilège, hooks contre les actions destructives ; clés en coffre, par environnement.

Domaine 8 · Tools and MCPs (10,6 %) · chapitre 07

• Descriptions d'outils précises, is_error: true, client tools et server tools, approbation.
• Serveur MCP (tools, resources, prompts ; stdio en local) ; built-in tool, custom tool, Skill ou MCP selon le besoin.

Références#

Lues le 22/10/2026 :

• Claude Certified Developer – Foundations, Exam Guide v1.0 (PDF officiel), lié depuis Partner certifications
• Claude API errors
• Handling stop reasons
• Refusals and fallback
• Rate limits
• Streaming messages
• Batch processing
• Define success criteria and build evaluations
• Python SDK · TypeScript SDK
• Cursus tiers : claudecertificationguide.com, leçon 4.1 Debugging and Error Handling