D2 · The Responses API and Model Selection

C’est le domaine le plus lourd de l’examen blanc OAI-API aux côtés des systèmes agentiques — à peu près 11 des 60 items (18 %). Il teste si vous savez piloter la Responses API avec aisance : construire une requête, lire les items de sortie, maintenir l’état de conversation, streamer, exécuter du travail en arrière-plan, obtenir du JSON structuré, appeler des functions, régler le reasoning effort, passer des fichiers, gérer un long contexte avec la compaction, compter les tokens et choisir le modèle le moins cher qui atteint le niveau requis. La Responses API est l’interface principale pour le travail nouveau ; Chat Completions est legacy.

Ce que vous devez savoir

La Responses API prend un input (une chaîne ou une liste d’items typés) et renvoie une réponse dont l’output est une liste ordonnée d’items — messages, function_call, reasoning et résultats d’outils. L’état est soit sans état (vous renvoyez l’historique), soit conservé côté serveur (store: true plus previous_response_id). Vous choisissez un reasoning effort par requête et suivez la règle utiliser le plus faible effort qui obtient le résultat. Vous obtenez une sortie lisible par machine avec les sorties structurées (JSON Schema), étendez le modèle avec le function calling et les outils hébergés, exécutez le travail lent en background mode, et maintenez les longues conversations dans la fenêtre de contexte avec la compaction. Le choix de modèle est un choix à quatre voies — Astra, Sol, Terra, Luna — guidé par la difficulté de la tâche, le volume et le coût.

Objectifs d’apprentissage

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

1. Construire une requête Responses API et analyser la liste d’items output.
2. Gérer l’état de conversation sans état et avec previous_response_id.
3. Utiliser le streaming et le background mode de façon appropriée.
4. Produire des sorties structurées et gérer le function calling de bout en bout.
5. Régler le reasoning effort selon la règle du plus faible effort qui fonctionne.
6. Sélectionner un modèle parmi Astra / Sol / Terra / Luna en utilisant le prix, le contexte et la difficulté.

2.1 La forme des requêtes et réponses

Un appel minimal nomme un modèle et un input et lit output_text.

from openai import OpenAI
client = OpenAI()

resp = client.responses.create(
    model="gpt-5.6-terra",
    input="Summarise this ticket in one sentence: ...",
)
print(resp.output_text)  # accesseur pratique pour le texte

import OpenAI from 'openai';
const client = new OpenAI();

const resp = await client.responses.create({
  model: 'gpt-5.6-terra',
  input: 'Summarise this ticket in one sentence: ...',
});
console.log(resp.output_text);

La réponse complète porte un tableau output ordonné. Ne supposez pas que l’item zéro est votre texte — les items de reasoning, les appels d’outils et les messages peuvent s’entremêler.

resp.output = [
  { type: "reasoning", ... },            # peut apparaître pour les modèles de reasoning
  { type: "function_call", name, args }, # si le modèle a appelé un outil
  { type: "message", role: "assistant",
    content: [ { type: "output_text", text: "..." } ] }
]

2.2 L’état de conversation

Vous avez deux façons de maintenir une conversation multi-tours, et le choix a des conséquences de coût et de confidentialité.

first = client.responses.create(
    model="gpt-5.6-terra", input="My name is Sam.", store=True,
)
second = client.responses.create(
    model="gpt-5.6-terra",
    input="What did I say my name was?",
    previous_response_id=first.id,
)

2.3 Streaming et background mode

                  besoin de latence
                        │
       ┌────────────────┼─────────────────┐
       ▼                ▼                 ▼
 L'utilisateur     Tâche longue,      Fire-and-forget,
 attend les        l'utilisateur      de plusieurs
 tokens            peut patienter     heures
       │                │                 │
   stream=True     stream, ou         background=True
   (UI token-      background +        + poll ou webhook
    par-token)     webhook             à la fin

• Le streaming (stream=True) émet des server-sent events pour qu’une UI affiche les tokens à mesure qu’ils arrivent — utilisez-le dès qu’un humain attend.
• Le background mode (background=True) démarre la réponse et renvoie immédiatement ; vous interrogez l’ID de réponse ou recevez un webhook à la fin. Utilisez-le pour du reasoning long ou des exécutions agentiques qui survivent à une requête HTTP.

2.4 Sorties structurées

Quand un autre système consomme la sortie, imposez un schéma plutôt que d’analyser de la prose.

schema = {
    "type": "object",
    "properties": {
        "queue": {"type": "string", "enum": ["billing", "tech", "sales"]},
        "priority": {"type": "integer", "minimum": 1, "maximum": 4},
    },
    "required": ["queue", "priority"],
    "additionalProperties": False,
}

resp = client.responses.create(
    model="gpt-5.6-luna",
    input="Route this ticket: 'I was charged twice this month.'",
    text={"format": {"type": "json_schema", "name": "routing",
                     "schema": schema, "strict": True}},
)

strict: True garantit que la sortie valide au regard du schéma — vous n’analysez plus de façon défensive. C’est le bon pattern pour la classification, l’extraction et tout résultat consommé par une machine.

2.5 Function calling

Le function calling permet au modèle de demander que votre code s’exécute, puis de continuer avec le résultat. La boucle est : le modèle émet un function_call → vous l’exécutez → vous renvoyez un function_call_output référençant le call_id.

tools = [{
    "type": "function",
    "name": "get_weather",
    "description": "Get current weather for a city.",
    "parameters": {
        "type": "object",
        "properties": {"city": {"type": "string"}},
        "required": ["city"], "additionalProperties": False,
    },
}]

resp = client.responses.create(
    model="gpt-5.6-terra", input="What's the weather in Oslo?", tools=tools,
)

call = next(o for o in resp.output if o.type == "function_call")
result = get_weather(**json.loads(call.arguments))  # votre code s'exécute

final = client.responses.create(
    model="gpt-5.6-terra",
    previous_response_id=resp.id,
    input=[{"type": "function_call_output",
            "call_id": call.call_id, "output": json.dumps(result)}],
)

2.6 Le reasoning effort et la règle du plus faible effort

La famille GPT-5.6 expose des reasoning efforts de none à max ; Astra ajoute xhigh. Un effort plus élevé signifie plus de tokens de reasoning internes — meilleur sur les problèmes difficiles, mais plus lent et plus cher (vous payez les tokens de reasoning comme de la sortie).

La règle issue de la documentation : utilisez le plus faible reasoning effort qui obtient le résultat. Il n’existe pas de correspondance exacte des efforts de l’ancien GPT-5.5 vers GPT-5.6 — réajustez par tâche avec votre évaluation, ne supposez pas.

2.7 Entrées de fichiers, compaction et comptage de tokens

• Entrées de fichiers : passez les PDF et les images en items d’input (téléversements de fichiers ou base64/URL pour les images) pour que le modèle les lise directement ; vous ne collez pas du texte brut que vous avez déjà sous forme de fichier.
• Compaction : les longues conversations finissent par approcher la fenêtre de 1,05 M de tokens. La compaction résume les tours antérieurs pour que le fil continue sans perdre le fil de l’histoire ; l’Agents API le fait automatiquement, et vous pouvez le faire vous-même dans une boucle Responses en remplaçant les vieux tours par un résumé.
• Comptage de tokens : chaque réponse rapporte usage (input_tokens, output_tokens, total_tokens). Utilisez-le pour suivre le coût et savoir à quel point vous êtes proche de la limite de contexte.

Budget de contexte (fenêtre de 1,05 M)
┌───────────────────────────────────────────────────────────┐
│ system + tools │ contexte récupéré │ historique │ marge      │
└───────────────────────────────────────────────────────────┘
   à mesure que l'historique grandit → compacter les vieux tours → garder de la marge pour la sortie

2.8 La gamme de modèles (septembre 2026)

Les quatre modèles les plus récents : entrée texte + image, sortie texte, multilingue, vision, contexte de 1,05 M, sortie max de 128K, servis via la Responses API.

Génération précédente toujours disponible : gpt-5.5 ($5 / $30) et gpt-5.5-pro ($30 / $180).

Conseils de sélection, issus de la documentation : Astra pour le travail de bout en bout le plus difficile (reasoning soutenu, jugement, multi-outils) ; Sol pour le travail complexe, ouvert et à forte valeur ; Terra le pragmatique polyvalent et le remplaçant naturel des charges GPT-5.5 ; Luna pour les tâches claires, répétables et à fort volume (extraction, classification, transformation, résumés structurés).

Cadre de décision

Utilisez la LADDER (échelle) pour le choix de modèle et d’effort : commencez bas, ne montez que lorsqu’une évaluation prouve qu’il le faut.

L’habitude que le cours valorise : changer une chose, puis remesurer. Sauter directement à Astra en max est l’anti-pattern que ce cadre existe pour prévenir.

Erreurs fréquentes

Défi de mise en situation

Mise en situation. Votre équipe livre un assistant de support client. Il doit (a) répondre instantanément aux FAQ dans un widget de chat, (b) consulter le plan actuel du client depuis un service de facturation interne, (c) traiter occasionnellement un litige de facturation multi-comptes épineux qui nécessite un reasoning soigné, et (d) renvoyer un objet structuré {intent, plan, next_action} à l’application environnante. Un ingénieur junior propose : « Utiliser gpt-6-astra en max pour tout, renvoyer toute la transcription à chaque tour, et analyser le JSON dans le texte de la réponse. »

Trace de raisonnement d’expert.

1. Répartir la charge par difficulté. La plupart des tours sont des FAQ et des consultations — un travail bien défini, à fort volume, que gpt-5.6-luna ou gpt-5.6-terra gère en effort low/medium. Seul le rare litige multi-comptes nécessite une escalade. Un modèle unique en max brûle environ 50× le prix d’entrée pour le chemin courant.
2. Les données de plan en direct sont un function call, pas la connaissance du modèle. La consultation de facturation doit être un function_call vers le service interne ; la rappeler ou la fine-tuner serait périmé et invérifiable.
3. Sortie structurée, pas analyse de prose. L’application consomme {intent, plan, next_action}, donc utilisez text.format avec un JSON Schema et strict: true. Analyser de la prose est fragile et le plan du junior casserait la première fois que le modèle ajoute une phrase aimable.
4. État : ne pas tout renvoyer. Pour un widget de chat, store: true + previous_response_id maintient les tokens d’entrée bas ; pour les longs fils, compacter les tours plus anciens.
5. Latence : streamer les réponses de FAQ pour que le widget paraisse instantané ; n’utiliser l’effort high que sur le chemin du litige, idéalement en background mode si l’utilisateur peut attendre.
6. L’escalade est pilotée par l’évaluation. Router le chemin du litige vers Sol (ou Astra en high) seulement après qu’une évaluation ait montré que Terra échoue — LADDER, pas défaut.

Décision conforme à l’examen : router les tours courants vers Luna/Terra à faible effort avec streaming, utiliser le function calling pour la consultation de facturation, imposer une sortie structurée avec un schéma, garder l’état côté serveur, et escalader le rare cas difficile en montant la LADDER sur preuve d’évaluation. Pas Astra-en-max-pour-tout, pas l’analyse de JSON en prose, pas les renvois de transcription complète.

Pièges d’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler.

Points clés à retenir

• La Responses API est l’interface principale pour le travail nouveau ; parcourez la liste d’items output plutôt que de supposer l’index zéro.
• Maintenez l’état sans état (renvoi) ou côté serveur (store + previous_response_id) ; compactez les longs fils.
• Streamez pour les utilisateurs en attente ; utilisez le background mode pour le travail qui survit à une requête.
• Imposez les résultats consommés par machine avec les sorties structurées et strict: true.
• Accédez aux données en direct et privées avec le function calling, pas le fine-tuning ni les déversements collés.
• Utilisez le plus faible reasoning effort qui fonctionne ; il n’y a pas de correspondance exacte GPT-5.5 → GPT-5.6.
• Montez la LADDER pour le choix de modèle — Luna → Terra → régler l’effort → Sol → Astra — en remesurant avec une évaluation après chaque changement.