D1 · Applications and Integration

C’est de loin le domaine le plus lourd de l’examen Developer – environ 18 items sur 53. Il vérifie que vous savez intégrer Claude correctement : connaître la forme exacte d’une requête et d’une réponse de la Messages API, gérer chaque stop_reason, streamer avec SSE, utiliser des entrées vision/PDF/Files, câbler le prompt caching et le traitement par batch pour le coût, traiter les erreurs et les limites de débit, et structurer une application pour que les instructions, la configuration et les secrets se trouvent au bon endroit. La plupart des items sont des scénarios en forme de code où une option est subtilement fausse sur un mécanisme de l’API.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Décrire l’anatomie d’une requête et d’une réponse de la Messages API, y compris les rôles, les blocs de contenu, system, max_tokens, temperature/top_p, stop_sequences et usage.
2. Gérer chaque valeur de stop_reason, y compris tool_use, pause_turn, refusal et max_tokens.
3. Maintenir correctement un historique multi-tours et streamer les réponses à l’aide des types d’événements SSE en Python et TypeScript.
4. Envoyer des entrées vision, PDF et Files API, et activer le thinking étendu / adaptatif.
5. Appliquer le prompt caching avec cache_control et calculer son impact sur le coût.
6. Utiliser le cycle de vie de la Message Batches API et sa remise de 50 %.
7. Gérer les codes d’erreur, mettre en œuvre un retry avec backoff + jitter, utiliser l’idempotence, et raisonner sur les limites de débit (RPM/ITPM/OTPM) et les timeouts.
8. Accéder à Claude via Bedrock, Vertex AI et Foundry, et utiliser les SDK Python et TypeScript, y compris les patterns asynchrones.
9. Appliquer les fondamentaux du génie logiciel (REST, JSON, asynchrone, gestion de versions, refactorisation) et une conception d’application et une gestion de la configuration saines.

1.1 Requirements and the application lifecycle

Avant tout code, une intégration a un cycle de vie : définir les besoins → prototyper → évaluer → durcir → déployer → superviser → itérer. L’examen attend de vous que vous sachiez où Claude s’insère et ce qui change à chaque étape.

1.2 Anatomy of a Messages API request

Une requête Messages est un corps JSON envoyé à POST /v1/messages. Les champs principaux :

{
  "model": "claude-sonnet-5",
  "max_tokens": 1024,
  "system": "You are a precise assistant. Answer only from the provided context.",
  "messages": [
    { "role": "user", "content": "Summarise the attached report in 3 bullets." }
  ],
  "temperature": 0.2,
  "stop_sequences": ["\n\nHuman:"]
}

Champs clés :

• model – un ID de modèle ; épinglez un snapshot en production (voir 1.16).
• max_tokens – le nombre maximal de tokens que Claude peut générer (et non la fenêtre de contexte). Obligatoire. Si la sortie l’atteint, stop_reason vaut max_tokens.
• system – une chaîne de premier niveau (ou un tableau de blocs) pour le rôle/les instructions. Ce n’est pas un message avec role: "system" dans le tableau messages sur les modèles actuels (Sonnet 5 n’a pas de messages système en milieu de conversation).
• messages – une liste alternant les tours user et assistant. Chacun a un role et un content.
• temperature (0–1) et top_p – contrôles d’échantillonnage. Réglez-en un, pas les deux. Une température plus basse = plus déterministe ; temperature: 0 pour une reproductibilité maximale.
• stop_sequences – des chaînes qui, si elles sont générées, arrêtent la sortie ; stop_reason devient alors stop_sequence.

Roles and content blocks

content est soit une chaîne (raccourci pour un unique bloc texte), soit un tableau de blocs de contenu. Les types de blocs incluent text, image, document, tool_use, tool_result et thinking.

{
  "role": "user",
  "content": [
    { "type": "text", "text": "What is in this image?" },
    { "type": "image", "source": { "type": "base64", "media_type": "image/png", "data": "iVBORw0KG..." } }
  ]
}

1.3 Anatomy of a Messages API response

{
  "id": "msg_01ABC...",
  "type": "message",
  "role": "assistant",
  "model": "claude-sonnet-5",
  "content": [
    { "type": "text", "text": "Here are three bullets: ..." }
  ],
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 2145,
    "output_tokens": 87,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

• id – journalisez-le (ainsi que l’en-tête de réponse request-id) pour le support et le débogage.
• content – tableau de blocs de sortie ; itérez plutôt que de supposer un unique bloc texte (une réponse peut contenir ensemble des blocs thinking, text et tool_use).
• stop_reason – la raison de l’arrêt de la génération (voir 1.4).
• usage – comptabilité des tokens, y compris les champs de cache. Facturez et budgétez à partir de là.

1.4 stop_reason – the control signal

stop_reason est le champ le plus important pour le flux de contrôle. Ne déduisez jamais la fin à partir du texte.

resp = client.messages.create(model="claude-sonnet-5", max_tokens=1024, messages=msgs)

if resp.stop_reason == "tool_use":
    handle_tools(resp)          # exécuter, ajouter tool_result, boucler
elif resp.stop_reason == "pause_turn":
    msgs.append({"role": "assistant", "content": resp.content})
    resp = client.messages.create(model="claude-sonnet-5", max_tokens=1024, messages=msgs)
elif resp.stop_reason == "max_tokens":
    handle_truncation(resp)     # la sortie est incomplète
elif resp.stop_reason == "refusal":
    handle_refusal(resp)        # chemin de politique, pas une boucle de retry

1.5 Multi-turn conversations

L’état est côté client : vous renvoyez tout l’historique à chaque tour. Ajoutez la réponse de l’assistant telle quelle, puis le tour suivant de l’utilisateur.

messages = [{"role": "user", "content": "My name is Dana."}]
r1 = client.messages.create(model="claude-sonnet-5", max_tokens=256, messages=messages)
messages.append({"role": "assistant", "content": r1.content})   # ajouter les blocs complets
messages.append({"role": "user", "content": "What is my name?"})
r2 = client.messages.create(model="claude-sonnet-5", max_tokens=256, messages=messages)

Comme l’historique grandit à chaque tour, le coût d’entrée et la latence augmentent aussi. C’est pourquoi le prompt caching (1.9), l’édition de contexte et la compaction comptent pour les conversations longues.

1.6 Streaming with SSE

Le streaming renvoie des Server-Sent Events pour que vous puissiez afficher les tokens à mesure qu’ils arrivent. La séquence d’événements :

message_start
  content_block_start        (index 0)
  content_block_delta ...    (text_delta / input_json_delta / thinking_delta)
  content_block_stop
  [more content blocks ...]
message_delta                (carries stop_reason and final usage)
message_stop

from anthropic import Anthropic

client = Anthropic()

with client.messages.stream(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Write a haiku about tokens."}],
) as stream:
    for text in stream.text_stream:      # pratique : deltas de texte uniquement
        print(text, end="", flush=True)
    final = stream.get_final_message()   # Message complet avec stop_reason + usage
print("\n", final.stop_reason, final.usage.output_tokens)

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

const stream = client.messages.stream({
  model: 'claude-sonnet-5',
  max_tokens: 1024,
  messages: [{ role: 'user', content: 'Write a haiku about tokens.' }],
});

stream.on('text', (delta) => process.stdout.write(delta));
const final = await stream.finalMessage();
console.log('\n', final.stop_reason, final.usage.output_tokens);

with client.messages.stream(model="claude-sonnet-5", max_tokens=512,
                            messages=[{"role": "user", "content": "hi"}]) as stream:
    for event in stream:
        if event.type == "content_block_delta":
            if event.delta.type == "text_delta":
                print(event.delta.text, end="")
            elif event.delta.type == "input_json_delta":
                print(event.delta.partial_json, end="")  # les args d'outil arrivent en JSON
        elif event.type == "message_delta":
            print("\nstop:", event.delta.stop_reason)

1.7 Vision, PDF and the Files API

Les entrées multimodales sont des blocs de contenu dans un message user.

{
  "role": "user",
  "content": [
    { "type": "text", "text": "Extract the invoice total." },
    { "type": "image", "source": { "type": "url", "url": "https://example.com/invoice.png" } },
    { "type": "document", "source": { "type": "base64", "media_type": "application/pdf", "data": "JVBERi0..." } }
  ]
}

• Images : source.type peut être base64 ou url. Les types pris en charge incluent PNG, JPEG, GIF, WebP.
• PDF : type: "document" avec application/pdf ; Claude lit le texte et les images des pages.
• Files API : téléversez une fois les fichiers volumineux ou réutilisés, puis référencez-les par file_id au lieu de renvoyer les octets à chaque tour – économise la bande passante de téléversement et permet la réutilisation.

uploaded = client.files.upload(file=("report.pdf", open("report.pdf", "rb"), "application/pdf"))
resp = client.messages.create(
    model="claude-sonnet-5", max_tokens=1024,
    messages=[{"role": "user", "content": [
        {"type": "text", "text": "Summarise."},
        {"type": "document", "source": {"type": "file", "file_id": uploaded.id}},
    ]}],
)

Les citations peuvent être activées sur les documents pour que Claude renvoie des références ancrées vers des passages de la source.

1.8 Extended and adaptive thinking

Le thinking permet à Claude de raisonner avant de répondre ; le raisonnement apparaît sous forme de blocs de contenu thinking.

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "thinking": { "type": "adaptive" },
  "messages": [{ "role": "user", "content": "Prove sqrt(2) is irrational." }]
}

• Tous les modèles actuels acceptent thinking: {"type": "adaptive"}.
• budget_tokens n’est valide que sur Haiku 4.5 ; il renvoie 400 sur Fable 5.x / Opus 5 / Sonnet 5.
• Les niveaux d’effort low | medium | high (default) | xhigh ajustent la profondeur de raisonnement (xhigh pour les travaux de code/agentiques les plus ardus sur Opus 5 / Fable 5.1). Haiku 4.5 n’a pas de paramètre effort.
• Fable 5.1 a toujours le thinking activé ; ses blocs de thinking ne sont lisibles que par le modèle producteur ou plus récent (un repli silencieux vers un modèle plus ancien les supprime).

# Haiku 4.5 – le seul modèle actuel utilisant budget_tokens
client.messages.create(
    model="claude-haiku-4-5", max_tokens=2048,
    thinking={"type": "enabled", "budget_tokens": 1024},
    messages=[{"role": "user", "content": "Plan the refactor."}],
)

1.9 Prompt caching mechanics and cost math

Le prompt caching stocke un préfixe de la requête pour que les appels répétés évitent de le retraiter. Marquez la fin du préfixe stable avec cache_control.

{
  "model": "claude-sonnet-5",
  "max_tokens": 512,
  "system": [
    { "type": "text", "text": "You are a support agent. Policies:\n<policies>...large...</policies>",
      "cache_control": { "type": "ephemeral" } }
  ],
  "messages": [{ "role": "user", "content": "How do I return an item?" }]
}

Règles :

• Placez le contenu stable en premier (prompt système, définitions d’outils, longs documents), puis le contenu variable.
• Le préfixe minimal pouvant être mis en cache est d’environ 1024 tokens (2048 sur Haiku).
• Une écriture de cache coûte ≈ 1,25× l’entrée de base (TTL de 5 minutes) ou 2× (TTL d’1 heure).
• Une lecture de cache coûte ≈ 0,1× l’entrée de base (10 % du prix).
• Rapporté dans usage sous cache_creation_input_tokens et cache_read_input_tokens.

Worked cost example

Un bot de support envoie un préfixe de politique mis en cache de 10 000 tokens sur Sonnet 5 (entrée $2/MTok) plus 200 tokens variables, à 100 appels/heure.

Sur 100 appels : sans cache ≈ $2.00 sur le préfixe ; avec cache ≈ $0.025 + 99 × $0.002 ≈ $0.223 – soit une réduction d’environ 9× sur la portion mise en cache.

1.10 Message Batches API

Pour un travail à fort volume tolérant à la latence, la Batches API traite de nombreuses requêtes de manière asynchrone avec une remise de 50 % sur les tokens d’entrée et de sortie, avec des résultats généralement bien en deçà de 24 heures.

1. Créez un batch avec une liste de requêtes, chacune ayant un custom_id.

   batch = client.messages.batches.create(requests=[
       {"custom_id": "row-1", "params": {"model": "claude-haiku-4-5", "max_tokens": 256,
        "messages": [{"role": "user", "content": "Classify: great product"}]}},
       {"custom_id": "row-2", "params": {"model": "claude-haiku-4-5", "max_tokens": 256,
        "messages": [{"role": "user", "content": "Classify: terrible support"}]}},
   ])

2. Interrogez processing_status jusqu’à ce qu’il soit ended.

   import time
   while client.messages.batches.retrieve(batch.id).processing_status != "ended":
       time.sleep(30)

3. Streamez les résultats et faites la correspondance par custom_id.

   for result in client.messages.batches.results(batch.id):
       print(result.custom_id, result.result.type)  # "succeeded" | "errored" | "expired"

1.11 Error codes, retries and idempotency

Réessayez 429, 500 et 529 avec un backoff exponentiel + jitter ; ne réessayez pas les 4xx autres que 429.

import time, random
from anthropic import Anthropic, APIStatusError, RateLimitError

client = Anthropic(max_retries=0)   # désactiver le retry auto du SDK pour montrer le pattern

def call_with_backoff(**kwargs):
    for attempt in range(6):
        try:
            return client.messages.create(**kwargs)
        except (RateLimitError, APIStatusError) as e:
            status = getattr(e, "status_code", None)
            if status not in (429, 500, 529):
                raise
            retry_after = float(getattr(e, "response", None).headers.get("retry-after", 0)) if getattr(e, "response", None) else 0
            sleep = max(retry_after, min(60, (2 ** attempt))) + random.uniform(0, 1)  # jitter
            time.sleep(sleep)
    raise RuntimeError("exhausted retries")

Les SDK réessaient sans danger par défaut (max_retries=2). Pour l’idempotence sur les écritures (p. ex. la création de batch), passez une clé d’idempotence afin qu’une requête réessayée ne soit pas traitée deux fois.

1.12 Rate limits and timeouts

Les limites de débit sont appliquées par modèle et par palier selon trois axes :

Vous pouvez atteindre l’une avant les autres. Les réponses 429 portent retry-after et des en-têtes de limite de débit. Stratégies : limitation/mise en file d’attente côté client, étalement de la charge, batching, demande d’un palier supérieur, et réduction des tokens (sortie plus courte, caching). Utilisez client.models.list() / .retrieve(id) pour les limites en direct.

Réglez les timeouts délibérément – un thinking long ou de grandes sorties nécessitent des timeouts généreux ; les appels interactifs courts doivent échouer vite. Les SDK exposent une option timeout.

const client = new Anthropic({ timeout: 60_000, maxRetries: 3 });

1.13 Third-party access: Bedrock, Vertex, Foundry

Claude est disponible via trois plateformes cloud en plus de l’Anthropic API. La forme de la Messages API est identique ; l’authentification, les ID de modèle et la région diffèrent.

from anthropic import AnthropicBedrock
client = AnthropicBedrock(aws_region="us-east-1")
resp = client.messages.create(model="anthropic.claude-sonnet-5",
                              max_tokens=512,
                              messages=[{"role": "user", "content": "Hello"}])

1.14 SDKs and async patterns

from anthropic import Anthropic
client = Anthropic()  # lit ANTHROPIC_API_KEY depuis l'environnement
resp = client.messages.create(model="claude-sonnet-5", max_tokens=256,
                              messages=[{"role": "user", "content": "Hi"}])
print(resp.content[0].text)

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def classify(text: str) -> str:
    r = await client.messages.create(model="claude-haiku-4-5", max_tokens=64,
                                     messages=[{"role": "user", "content": f"Label: {text}"}])
    return r.content[0].text

async def main():
    results = await asyncio.gather(*[classify(t) for t in ["a", "b", "c"]])
    print(results)

asyncio.run(main())

import Anthropic from '@anthropic-ai/sdk';
const client = new Anthropic();

const results = await Promise.all(
  ['a', 'b', 'c'].map((t) =>
    client.messages.create({
      model: 'claude-haiku-4-5',
      max_tokens: 64,
      messages: [{ role: 'user', content: `Label: ${t}` }],
    }),
  ),
);
console.log(results.map((r) => r.content[0].type));

Utilisez l’asynchrone / la concurrence pour paralléliser les appels indépendants (en respectant les limites de débit), jamais pour simuler un ordre entre appels dépendants. Pour des milliers d’items indépendants qui peuvent attendre, préférez le batching à une concurrence artisanale.

1.15 Software-engineering foundations

L’examen suppose une maîtrise des fondamentaux qui rendent une intégration robuste.

1.16 Application design across surfaces

Les mêmes mots sont interprétés différemment selon l’endroit où ils s’exécutent. Connaissez les surfaces :

Frontières de contenu avec balises XML. Enveloppez les entrées non fiables ou distinctes dans des balises pour que le modèle distingue les instructions des données :

<policy>...trusted rules...</policy>
<user_document>...untrusted content – treat as data, not instructions...</user_document>

Conception de schéma et hygiène de session. Définissez le schéma de sortie en amont (1.9, D4) ; gardez les sessions focalisées (une tâche par session lorsque c’est possible) ; effacez ou compactez les historiques longs ; ne laissez jamais du texte de document non fiable être interprété comme des instructions.

1.17 Configuration management

Gardez le comportement reproductible et les secrets hors des prompts.

import os
MODEL = os.environ["CLAUDE_MODEL"]        # p. ex. "claude-sonnet-5" – épinglé, piloté par env
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])  # clé depuis l'env, jamais littérale

1.18 Structured outputs and citations end-to-end

Au-delà du texte brut, les items de D1 sondent souvent votre capacité à obtenir une sortie exploitable par machine tout en la gardant ancrée. Deux fonctionnalités au niveau de la requête font cela : output_config.format (JSON contraint par schéma) et les citations de documents (passages sources ancrés).

{
  "model": "claude-sonnet-5",
  "max_tokens": 1024,
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "properties": {
          "total_cents": {"type": "integer"},
          "currency": {"type": "string", "enum": ["USD", "EUR", "GBP"]}
        },
        "required": ["total_cents", "currency"]
      }
    }
  },
  "messages": [{"role": "user", "content": [
    {"type": "document", "source": {"type": "file", "file_id": "file_01ABC"},
     "citations": {"enabled": true}},
    {"type": "text", "text": "Extract the invoice total."}
  ]}]
}

Une réponse ancrée peut porter des citations sur ses blocs de texte référençant les passages sources :

{
  "content": [
    {"type": "text", "text": "The total is $482.10.",
     "citations": [{"type": "page_location", "cited_text": "Total due: $482.10",
                    "document_index": 0, "start_page_number": 3, "end_page_number": 3}]}
  ],
  "stop_reason": "end_turn"
}

1.19 Idempotency, timeouts and the SDK retry contract

Les écritures et les appels longs nécessitent des contrôles de fiabilité explicites. Les SDK réessaient les erreurs transitoires par défaut, mais l’idempotence et les budgets de timeout vous appartiennent.

from anthropic import Anthropic

client = Anthropic(max_retries=3, timeout=120)  # retries bornés ; timeout généreux pour le batch

batch = client.messages.batches.create(
    requests=[...],
    extra_headers={"Idempotency-Key": "nightly-2026-09-15"},  # sûr à réessayer, s'exécute une fois
)

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({ maxRetries: 3 });

const resp = await client.messages.create(
  { model: 'claude-sonnet-5', max_tokens: 8000, messages },
  { timeout: 120_000 },   // sortie longue → timeout plus long ; les appels courts restent rapides
);

1.20 Common misconceptions

1.21 Scenario walkthrough: a resilient extraction service

Scénario. Vous détenez un service qui extrait des champs structurés de jusqu’à 100 000 PDF téléversés par nuit. Chaque requête envoie un préfixe instruction+schéma de 6 000 tokens (identique à chaque appel) plus un document ; les résultats sont attendus pour 08

Trace de raisonnement d’expert.

1. Classez chaque charge de travail par tolérance à la latence. Le job nocturne est tolérant à la latence et en masse → il relève de la Message Batches API (50 % de moins, résultats en 24 h), et non d’une concurrence artisanale qui déclenche des tempêtes de 429. L’endpoint interactif est en temps réel → gardez-le synchrone.
2. Attaquez le coût avec les bons leviers, dans l’ordre. Le modèle le moins cher qui passe la barre est déjà choisi (Sonnet 5 — ne sautez pas vers Opus 5, sur-dimensionné ici). Ensuite, mettez en cache le préfixe stable de 6 000 tokens (le fait tomber à ~10 % sur les hits) et exécutez via Batches (50 % de plus). Empiler modèle + cache + batch est la réponse attendue ; n’en choisir qu’un laisse des économies sur la table.
3. Corrigez les 429 à la source, pas avec des retries plus serrés. Passer aux Batches supprime l’essentiel de la pression ; là où des appels synchrones subsistent, plafonnez la concurrence et honorez retry-after. Réessayer immédiatement (un distracteur tentant) aggrave la limite.
4. Corrigez le JSONDecodeError dans la bonne couche. C’est un problème de sortie du modèle/parsing, pas de transport. Utilisez output_config.format avec un schéma JSON plus une validation-retry qui réinjecte l’erreur — pas le backoff, qui est pour les erreurs de transport transitoires.
5. Traitez efficacement le contrat réutilisé. Téléversez-le une fois via la Files API et référencez-le par file_id ; renvoyer 180 pages de base64 à chaque appel est le piège bande passante/coût.
6. Rejetez les alternatives tentantes. « Tout basculer vers Opus 5 pour la qualité » — aveugle aux contraintes et coûteux. « Faire tourner les clés d’API pour battre le 429 » — les limites sont par compte, pas par clé. « Augmenter max_tokens pour corriger les erreurs JSON » — mauvaise couche ; cela traite la troncature, pas le JSON malformé.

Décision correcte. Batches API sur Sonnet 5 avec cache_control sur le préfixe partagé et des clés d’idempotence à la création du batch ; sortie contrainte par schéma avec validation-retry pour les erreurs JSON ; Files API pour le contrat réutilisé ; plafonds de concurrence et retry-after pour tout appel synchrone restant.

Pièges de l’examen dans ce domaine

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Essayez avant de révéler.

À retenir

• La Messages API est une API HTTP JSON sans état ; vous renvoyez l’historique à chaque tour et facturez à partir de usage.
• Pilotez le flux de contrôle à partir de stop_reason – n’analysez jamais la prose, ne comptez jamais sur des plafonds d’itérations.
• content est un tableau de blocs typés ; itérez et filtrez, ne supposez pas content[0].text.
• Streamez avec SSE ; les args d’outil arrivent en input_json_delta, le stop_reason/usage final sur message_delta.
• Le prompt caching (préfixe stable en premier, cache_control) réduit le coût d’entrée à ~10 % sur les hits ; les Batches donnent 50 % de moins pour un travail tolérant à la latence.
• Ne réessayez que 429/500/529 avec backoff exponentiel + jitter, honorez retry-after, et journalisez le request ID.
• budget_tokens est propre à Haiku 4.5 ; les modèles actuels utilisent thinking: {type: 'adaptive'} avec des niveaux d’effort.
• Accédez via Bedrock/Vertex/Foundry quand les données ou la conformité l’exigent ; la forme de la requête est inchangée.
• Gardez les ID de modèle épinglés en un seul endroit, les prompts versionnés, et les secrets en env/gestionnaire de secrets – jamais dans les prompts ou CLAUDE.md.
• La sortie contrainte par schéma (output_config.format / strict: true) garantit la forme, pas les valeurs ; validez la sémantique et activez les citations de document quand l’ancrage doit être traçable.
• La fiabilité est en couches : clés d’idempotence sur les écritures, timeouts délibérés pour les appels longs, retries bornés, et un plafond de concurrence pour éviter les 429 auto-infligés.
• Diagnostiquez par couche — un JSONDecodeError est un problème de parsing/sortie du modèle (schéma + validation-retry), un 429 est du transport (backoff + retry-after) ; appliquer le mauvais correctif est le piège classique.
• Sur Bedrock/Vertex, le corps de la requête et la sémantique de stop_reason sont portables ; seuls le client/l’authentification et le format de l’ID de modèle changent.