# Quiz — Niveau Avancé, Session 1 # « Claude API : plongée en profondeur » **Programme :** Applied AI — Yann Isola **Format :** 10 QCM (QCM = Questionnaire à Choix Multiples), niveau certification *Claude Certified Architect* **Durée :** 20 minutes — une seule réponse correcte par question sauf mention contraire **Seuil :** 7/10 > ⚠ Les valeurs chiffrées (tarifs, limites, TTL) reflètent la documentation au moment de la rédaction et sont volatiles. --- ### Q1 — Champs obligatoires Quels champs sont **strictement obligatoires** dans une requête `POST /v1/messages` ? - A. `model`, `messages`, `system` - B. `model`, `max_tokens`, `messages` - C. `model`, `max_tokens`, `messages`, `temperature` - D. `model`, `messages` — `max_tokens` a une valeur par défaut **Réponse : B.** `system`, `temperature` et les autres paramètres d'échantillonnage sont optionnels. `max_tokens` n'a **pas** de valeur par défaut : son omission provoque une erreur 400. Piège en D : contrairement à d'autres API du marché, il est obligatoire chez Anthropic. --- ### Q2 — stop_reason et code HTTP Une extraction JSON retourne un document tronqué à mi-chemin. Le code HTTP était 200. Quelle est l'explication la plus probable et où fallait-il la détecter ? - A. Erreur 500 masquée par le SDK ; détecter via les logs du SDK - B. `stop_reason: "max_tokens"` ; détecter en inspectant le champ `stop_reason` de la réponse - C. `stop_reason: "stop_sequence"` ; détecter via l'en-tête `anthropic-stop` - D. Le modèle a jugé la tâche terminée (`end_turn`) ; c'est un problème de prompt **Réponse : B.** Atteindre le plafond `max_tokens` n'est pas une erreur HTTP : la requête réussit (200) mais la génération est coupée. La seule détection fiable est applicative : tester `stop_reason == "max_tokens"` sur chaque réponse. L'en-tête de C n'existe pas. --- ### Q3 — Prefilling Vous terminez le tableau `messages` par `{"role": "assistant", "content": "{"}`. Quelles affirmations sont exactes ? **(deux réponses)** - A. Le modèle continuera sa génération à partir de `{`, favorisant une sortie JSON directe - B. Le caractère `{` sera inclus au début du texte retourné par l'API - C. Le caractère `{` ne sera PAS inclus dans la réponse ; le client doit le re-préfixer - D. Cette requête est invalide : `messages` doit se terminer par un rôle `user` **Réponses : A et C.** Le prefilling est une technique officielle : le dernier message peut être un tour `assistant` partiel que le modèle prolonge. Le texte préfixé appartient à l'entrée, pas à la sortie — l'oublier produit des JSON invalides (sans accolade ouvrante). D est faux : seul le **premier** message doit être `user`. --- ### Q4 — System prompt Pourquoi qualifie-t-on le system prompt de « canal privilégié » plutôt que de « premier message » ? - A. Il est gratuit : les tokens du system prompt ne sont pas facturés - B. Il est transmis hors du tableau `messages` et traité par le modèle avec une priorité particulière pour les personas, règles et politiques de sortie - C. Il est chiffré de bout en bout, contrairement aux messages - D. Il persiste automatiquement entre les requêtes sans être renvoyé **Réponse : B.** Le paramètre `system` est structurellement séparé de `messages` et le modèle est entraîné à lui accorder un poids particulier (instructions durables, résistance accrue aux tentatives de contournement dans les tours `user`). A est faux (facturé comme tout token d'entrée), C est fantaisiste, D est faux — l'API est **sans état** : tout doit être renvoyé à chaque appel. --- ### Q5 — Fenêtre de contexte et coûts Une conversation assistant accumule en moyenne 40 000 tokens d'historique renvoyés à chaque tour, sur 25 tours. Quelle affirmation d'architecte est correcte ? - A. Seuls les nouveaux tokens de chaque tour sont facturés ; le coût total est marginal - B. Chaque tour refacture l'intégralité de l'entrée : le coût cumulé de la conversation croît approximativement de façon quadratique avec sa longueur, d'où l'intérêt du résumé, de la troncature ou du caching - C. La fenêtre de contexte se vide automatiquement des tokens du milieu (« lost in the middle ») - D. Le coût est constant par tour car l'API compresse l'historique **Réponse : B.** L'API étant sans état, l'historique complet est renvoyé — et facturé — à chaque tour. La somme des préfixes croît quadratiquement. « Lost in the middle » (C) est un effet de **rappel dégradé** de l'information au milieu du contexte, pas une suppression de tokens. --- ### Q6 — Prompt caching : économie Avec le prompt caching : quelle paire (coût d'écriture, coût de lecture) est correcte, en pourcentage du tarif d'entrée normal ? ⚠ - A. Écriture 100 %, lecture 50 % - B. Écriture 125 %, lecture 10 % - C. Écriture 90 %, lecture 25 % - D. Écriture 110 %, lecture 0 % (lecture gratuite) **Réponse : B.** ⚠ L'écriture au cache coûte un surcoût de ~25 % (donc 125 % du tarif) ; la lecture d'un hit coûte ~10 % du tarif (soit ~90 % d'économie). Conséquence : le cache est rentable dès la **deuxième** requête dans la fenêtre TTL (1,25 + 0,10 < 2,00) — et un cache jamais relu (préfixe instable) coûte *plus cher* que pas de cache du tout. --- ### Q7 — Prompt caching : invalidation Quel changement N'invalide PAS le cache d'un préfixe posé sur le system prompt via `cache_control` ? - A. Modifier un caractère du system prompt en amont du breakpoint - B. Modifier la définition d'un outil (`tools`) - C. Modifier le contenu du dernier message `user` (après le breakpoint) - D. Changer de modèle entre deux appels **Réponse : C.** Le cache porte sur le **préfixe exact** jusqu'au breakpoint, dans l'ordre `tools → system → messages`. Tout ce qui se situe **après** le breakpoint peut varier librement — c'est précisément le design cible : contenu stable en tête, question variable en queue. A et B modifient le préfixe ; D : le cache est propre à chaque modèle. --- ### Q8 — Comptage de tokens Quelle affirmation sur le comptage de tokens est correcte ? - A. Le nombre de tokens d'un texte est identique pour tous les modèles Claude et GPT (GPT = Generative Pre-trained Transformer), le tokenizer étant standardisé - B. L'endpoint `count_tokens` génère une réponse d'un token pour estimer le total - C. Chaque famille de modèles possède son propre tokenizer ; l'endpoint dédié `count_tokens` permet de compter une requête complète (system + messages + tools) sans lancer de génération - D. On ne peut compter les tokens qu'après l'appel, via le champ `usage` **Réponse : C.** Les tokenizers diffèrent entre familles et éditeurs — réutiliser un comptage tiktoken (OpenAI) pour Claude est une erreur classique. L'endpoint de comptage est distinct de la génération et permet de valider la fenêtre de contexte et d'estimer le coût **avant** de payer un appel. D décrit le comptage *a posteriori*, qui existe mais n'est pas le seul. --- ### Q9 — Streaming SSE Dans un flux SSE (SSE = Server-Sent Events), dans quel événement le client trouve-t-il le `stop_reason` final et le décompte définitif des tokens de sortie ? - A. `message_start` - B. `content_block_stop` - C. `message_delta` - D. `message_stop` **Réponse : C.** La séquence canonique est `message_start → content_block_start → content_block_delta* → content_block_stop → message_delta → message_stop`. Les métadonnées finales (`stop_reason`, `usage.output_tokens`) arrivent dans **`message_delta`**. `message_stop` (D) est le piège classique : il clôt le flux mais ne porte pas ces champs ; un client qui ne parse pas `message_delta` ne détectera jamais une troncature en streaming. --- ### Q10 — Batches API Pour la classification non urgente de 80 000 documents, quelle combinaison (remise, SLA, limite, corrélation) décrit correctement la Batches API ? ⚠ - A. −25 % ; résultats en 1 h garantis ; 10 000 requêtes max ; résultats retournés dans l'ordre de soumission - B. −50 % ; SLA de 24 h (souvent bien plus rapide en pratique) ; jusqu'à 100 000 requêtes par batch ; corrélation obligatoire par `custom_id` car l'ordre n'est pas garanti - C. −50 % ; temps réel ; 100 000 requêtes ; corrélation par index de tableau - D. −90 % ; SLA de 24 h ; requêtes illimitées ; le batch partage la mémoire conversationnelle entre requêtes **Réponse : B.** ⚠ Remise de 50 % sur entrée et sortie, engagement de traitement sous 24 h (la majorité des batches terminent en moins d'une heure), plafond de 100 000 requêtes (~256 Mo). Les requêtes sont indépendantes (pas d'état partagé — D faux) et les résultats arrivent dans un ordre quelconque : le `custom_id` est la seule clé de corrélation fiable. Bonus certification : batch et prompt caching se cumulent (hits non garantis). --- ## Grille de correction | Q | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |---|---|---|---|---|---|---|---|---|---|----| | R | B | B | A+C | B | B | B | C | C | C | B | **Analyse des erreurs fréquentes (pour le formateur) :** - Q2/Q9 confondues → revoir la distinction *erreur HTTP* vs *état métier* et la séquence SSE. - Q6 ratée → refaire le calcul de rentabilité du bloc 5 du guide. - Q10 ratée sur l'ordre des résultats → insister : tout pipeline batch sans `custom_id` est un défaut de conception éliminatoire en certification.