API Messages, Tool Use & Architecture
20% de l'examenMessages API, tool use, streaming, gestion d'erreurs et patterns de production.
La Messages API
- Conversation = liste alternée {role: user|assistant, content}. Le system prompt est un paramètre à part.
- Paramètres clés : model, max_tokens (obligatoire), temperature, stop_sequences, system, tools.
- Le streaming (SSE) renvoie token par token pour la latence perçue.
Tool use
- On déclare des outils (name, description, input_schema JSON Schema). Claude renvoie un bloc tool_use.
- Boucle : Claude → tool_use → votre code exécute → vous renvoyez tool_result → Claude continue.
- tool_choice force/laisse libre l'usage ; les outils garantissent des sorties structurées.
Robustesse
- Gérer 429 (rate limit) avec backoff exponentiel + jitter ; 529 (overloaded) avec retry.
- Timeouts, journalisation des request-id, dégradation gracieuse, idempotence et caching.
S'entraîner — 10 questions
- 1. Où se placent le rôle/les règles persistantes dans la Messages API ?
- 2. Cycle correct du tool use ?
- 3. Garantir une extraction structurée fiable ?
- 4. L'API renvoie des 429. Stratégie correcte ?
- 5. Quel paramètre est obligatoire à chaque appel ?
- 6. La sortie est coupée et stop_reason vaut « max_tokens ». Que faire ?
- 7. Qui est responsable de conserver l'historique de conversation ?
- 8. Erreur 529 (overloaded). Réaction adaptée ?
- 9. Claude peut-il demander plusieurs appels d'outils en un seul tour ?
- 10. Meilleure approche pour réduire la latence perçue d'un chat ?