# D2 · The Responses API and Model Selection

La forme des requêtes et réponses de la Responses API, l’état de conversation, le streaming, le background mode, les sorties structurées, le function calling, le reasoning effort, les entrées de fichiers, la compaction, le comptage de tokens et le choix du bon modèle.

import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components';

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`.

<Tabs>
<TabItem label="Python">

```python
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
```

</TabItem>
<TabItem label="TypeScript">

```typescript
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);
```

</TabItem>
</Tabs>

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.

```text
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: "..." } ] }
]
```

:::tip[Signal d’évaluation]
Les énoncés mentionnant `output_text`, les items `output`, « l’interface principale » ou « quelle API pour du développement nouveau » pointent ici. La Responses API est correcte pour le travail nouveau ; Chat Completions est le distracteur legacy.
:::

## 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é.

| Approche | Comment | Compromis |
| --- | --- | --- |
| **Sans état** | Renvoyer tout l’historique dans `input` à chaque tour | Contrôle total, aucune rétention serveur ; vous payez les tokens d’entrée de tout l’historique à chaque tour |
| **Conservé côté serveur** | `store: true`, puis `previous_response_id` à l’appel suivant | Moins de données renvoyées, plus simple ; la réponse est conservée côté serveur |

```python
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

```text
                  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.

```python
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`.

```python
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)}],
)
```

:::tip[Signal d’évaluation]
« Le modèle a besoin de données en direct/privées », « appeler un système interne » ou « prendre une action » pointent vers le **function calling**. Les options qui disent « fine-tuner les données » ou « coller les données à chaque requête » sont les distracteurs.
:::

## 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).

| Effort | Utiliser pour | Coût/latence |
| --- | --- | --- |
| `none` / `low` | Extraction, classification, formatage, Q&R simple | Le moins cher, le plus rapide |
| `medium` | Reasoning général, la plupart des étapes agentiques | Équilibré |
| `high` / `xhigh` / `max` | Reasoning multi-étapes difficile, planification, code délicat | Le plus lent, le plus cher |

**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.

```text
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.

| Modèle | ID | Reasoning efforts | Entrée $/MTok | Sortie $/MTok | Contexte | Cutoff |
| --- | --- | --- | --- | --- | --- | --- |
| **GPT-6 Astra** | `gpt-6-astra` | low…max, plus `xhigh` | $10 | $50 | 1.05M | 30 avr. 2026 |
| **GPT-5.6 Sol** | `gpt-5.6-sol` (alias `gpt-5.6`) | none…max | $4 | $20 | 1.05M | 16 févr. 2026 |
| **GPT-5.6 Terra** | `gpt-5.6-terra` | none…max | $2 | $12 | 1.05M | 16 févr. 2026 |
| **GPT-5.6 Luna** | `gpt-5.6-luna` | none…max | $0.20 | $1.20 | 1.05M | 16 févr. 2026 |

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.

| Barreau | Choix | Monter quand |
| --- | --- | --- |
| **L**una, effort low | Tâches à fort volume, bien définies | L’évaluation montre une qualité sous la cible |
| **A** step to Terra | Travail général, remplacements de GPT-5.5 | Terra échoue sur du reasoning réellement complexe |
| **D**ial effort up | Même modèle, `medium` puis `high` | Les échecs sont une profondeur de reasoning, pas une classe de modèle |
| **D**eploy Sol | Complexe, ouvert, à forte valeur | Sol échoue encore sur les tâches de bout en bout les plus difficiles |
| **E**scalate to Astra | Reasoning soutenu le plus difficile + multi-outils | — |
| **R**e-measure | Après chaque changement, relancer l’évaluation | Ne jamais supposer ; il n’y a pas de correspondance d’effort fixe |

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

| Erreur | Pourquoi elle survient | Que faire à la place |
| --- | --- | --- |
| Prendre Astra en `max` par défaut | « Meilleur modèle, aucun risque » | Commencer au barreau le plus bas de la LADDER et monter avec des preuves d’évaluation |
| Utiliser Chat Completions pour du travail nouveau | Familiarité, vieux tutoriels | Utiliser la Responses API ; Chat Completions est legacy |
| Supposer que `output[0]` est le texte | C’est souvent le cas dans les démos | Parcourir `output` ; les items de reasoning et d’appel d’outil s’entremêlent |
| Renvoyer tout l’historique à chaque tour sur d’énormes fils | Le plus simple à coder | Utiliser `store` + `previous_response_id`, ou compacter les vieux tours |
| Analyser du JSON dans de la prose | Habitude des anciens modèles | Utiliser les sorties structurées avec `strict: true` |
| Fine-tuner pour injecter des données en direct | Confondre connaissance et accès aux données | Utiliser function calling / récupération pour les données en direct et privées |
| Copier les niveaux d’effort GPT-5.5 vers GPT-5.6 | Suppose qu’une correspondance existe | Réajuster l’effort par tâche ; il n’y a pas de correspondance exacte |
| Bloquer une UI sur une réponse longue | Ignorer l’existence du streaming/background | Streamer pour les utilisateurs en attente ; background mode pour les jobs longs |

## 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

| Piège | Pourquoi il est tentant | Le discriminant |
| --- | --- | --- |
| « Utiliser `gpt-6-astra` en `max` pour être tranquille » | Le meilleur modèle semble le moins risqué | Le plus faible effort qui fonctionne ; monter la LADDER avec preuve d’évaluation |
| « Chat Completions convient pour le nouveau service » | Ça marche encore | La Responses API est l’interface principale pour le développement nouveau |
| « Fine-tuner pour qu’il connaisse le plan du client » | Ça ressemble à enseigner au modèle | Les données en direct/privées sont un function call, pas de l’entraînement |
| « Analyser le JSON dans le texte de la réponse » | Ça marche souvent en test | Les sorties structurées avec `strict: true` garantissent la forme |
| « Mapper le `high` de GPT-5.5 sur le `high` de GPT-5.6 » | La symétrie semble sûre | Pas de correspondance exacte ; réajuster avec votre évaluation |
| « Renvoyer toute la transcription à chaque tour » | Simple et explicite | `previous_response_id` et compaction contrôlent le coût sur les longs fils |
| « Lire `output[0]` pour la réponse » | Marche dans le cas idéal | Les items de reasoning et d’appel d’outil s’entremêlent ; parcourir `output` |

## Questions d’entraînement

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

<Accordions>
  <AccordionItem title="Q1 · Vous démarrez une nouvelle intégration d’API. Sur quelle interface devriez-vous construire ? (Sélectionnez une réponse)">
    A. La Chat Completions API, parce qu’elle est la plus établie.
    B. La Responses API, l’interface principale pour le développement nouveau.
    C. L’Assistants API.
    D. L’endpoint Completions legacy.

    **Réponse : B.** La Responses API est l’interface principale pour le travail nouveau. Chat Completions (A) et l’ancien endpoint Completions (D) sont legacy pour le développement nouveau, et l’Assistants API (C) est désormais regroupée sous les Legacy APIs.
  </AccordionItem>

  <AccordionItem title="Q2 · Un classificateur doit renvoyer `{queue, priority}` que l’application environnante analyse de façon fiable. Quel est le MEILLEUR (BEST) moyen de garantir la forme ? (Sélectionnez une réponse)">
    A. Demander au modèle dans le prompt de « ne renvoyer que du JSON » et analyser le texte.
    B. Utiliser les sorties structurées avec un JSON Schema et `strict: true`.
    C. Post-traiter la prose avec une expression régulière.
    D. Fine-tuner le modèle pour qu’il émette du JSON.

    **Réponse : B.** Les sorties structurées avec un JSON Schema strict garantissent que la réponse valide au regard de la forme. Les instructions dans le prompt (A) et la regex (C) ne sont pas garanties, et le fine-tuning (D) est inutile et ne garantit pas la validité.
  </AccordionItem>

  <AccordionItem title="Q3 · Un assistant a besoin du plan d’abonnement actuel du client depuis un service de facturation interne pour répondre. Quel est le mécanisme correct ? (Sélectionnez une réponse)">
    A. Fine-tuner le modèle sur tous les plans clients chaque nuit.
    B. Définir un outil function que le modèle appelle, l’exécuter, et renvoyer un `function_call_output`.
    C. Coller toute la base de données clients dans chaque prompt.
    D. Se fier à la connaissance d’entraînement du modèle.

    **Réponse : B.** Les données en direct et privées sont accédées via le function calling : le modèle demande l’appel, votre code l’exécute, et vous renvoyez le résultat. Le fine-tuning nocturne (A) est périmé et coûteux, coller la base (C) est cher et non faisant autorité, et la connaissance d’entraînement (D) ne contient pas de données de compte en direct.
  </AccordionItem>

  <AccordionItem title="Q4 · Une tâche d’extraction à fort volume s’exécute 2 M de fois par jour et `gpt-5.6-luna` passe votre évaluation à 97 %. Quel modèle devriez-vous déployer ? (Sélectionnez une réponse)">
    A. `gpt-6-astra` à l’effort `max` pour une qualité maximale.
    B. `gpt-5.6-luna`, parce qu’il satisfait la métrique au coût le plus bas pour du travail répétable à fort volume.
    C. `gpt-5.6-sol` pour être tranquille.
    D. `gpt-5.5-pro` pour la fiabilité.

    **Réponse : B.** Luna est conçu pour les tâches claires, répétables et à fort volume et il passe l’évaluation, c’est donc le modèle le moins cher qui fonctionne. Astra-en-max (A), Sol (C) et 5.5-pro (D) coûtent tous bien plus par token sans gain de qualité mesuré.
  </AccordionItem>

  <AccordionItem title="Q5 · Un utilisateur attend dans une UI de chat une réponse qui prend plusieurs secondes à générer. Qu’est-ce qui améliore LE PLUS (MOST) l’expérience ? (Sélectionnez une réponse)">
    A. Activer le background mode et interroger toutes les 30 secondes.
    B. Streamer la réponse pour que les tokens apparaissent à mesure qu’ils sont générés.
    C. Passer à `gpt-6-astra` à l’effort `max`.
    D. Augmenter le max output tokens.

    **Réponse : B.** Le streaming affiche les tokens à mesure qu’ils arrivent, c’est le bon pattern quand un humain attend. Le background mode (A) convient aux longs jobs fire-and-forget, un modèle plus grand (C) est plus lent et non plus rapide, et augmenter la sortie max (D) ne change pas la latence perçue.
  </AccordionItem>

  <AccordionItem title="Q6 · Qu’est-ce qui est VRAI à propos du reasoning effort sur la famille GPT-5.6 ? (Sélectionnez une réponse)">
    A. Les niveaux d’effort de GPT-5.5 se mappent exactement sur GPT-5.6.
    B. Vous devriez utiliser le plus faible effort qui produit le résultat requis, en réajustant par tâche avec une évaluation.
    C. Un effort plus élevé est toujours meilleur et devrait être le défaut.
    D. L’effort n’a aucun effet sur le coût ni la latence.

    **Réponse : B.** La règle est le plus faible effort qui fonctionne, vérifié par tâche ; il n’y a pas de correspondance exacte depuis 5.5 (A). Un effort plus élevé coûte plus de temps et de tokens (contredisant C et D).
  </AccordionItem>

  <AccordionItem title="Q7 · Vous construisez un agent de recherche de longue durée dont l’exécution survit à une seule requête HTTP. Quelle fonctionnalité convient ? (Sélectionnez une réponse)">
    A. `stream=True` sur une requête synchrone.
    B. Le background mode : démarrer la réponse, puis interroger l’ID de réponse ou recevoir un webhook à la fin.
    C. Augmenter le timeout HTTP à une heure.
    D. Découper le travail en 60 appels synchrones séparés.

    **Réponse : B.** Le background mode est conçu pour du travail qui survit à une requête ; vous interrogez ou recevez un webhook. Le streaming (A) tient toujours une connexion, allonger les timeouts (C) est fragile, et le découpage manuel (D) perd la continuité du modèle.
  </AccordionItem>

  <AccordionItem title="Q8 · Quelles DEUX (TWO) pratiques contrôlent le coût en tokens d’entrée sur une longue conversation multi-tours ? (Sélectionnez deux réponses)">
    A. Conserver la réponse côté serveur et poursuivre avec `previous_response_id`.
    B. Compacter les tours plus anciens en un résumé à mesure que le fil grandit.
    C. Renvoyer la transcription complète mot pour mot à chaque tour.
    D. Augmenter le reasoning effort à `max`.
    E. Passer à `gpt-6-astra` à chaque tour.

    **Réponse : A et B.** L’état côté serveur plus `previous_response_id` évite le renvoi, et la compaction réduit le vieil historique — les deux baissent les tokens d’entrée. Tout renvoyer (C) augmente le coût, et augmenter l’effort (D) ou la classe de modèle (E) l’augmente davantage.
  </AccordionItem>

  <AccordionItem title="Q9 · En lisant un résultat Responses API qui a utilisé un modèle de reasoning et un outil, pourquoi `resp.output[0]` n’est-il pas fiable pour le texte de réponse ? (Sélectionnez une réponse)">
    A. Le tableau output est toujours vide.
    B. Les items de reasoning et d’appel de function peuvent apparaître dans la liste `output` avant le message de l’assistant.
    C. Le texte n’est que dans `resp.error`.
    D. Les modèles de reasoning ne renvoient jamais de texte.

    **Réponse : B.** Le tableau `output` est une liste ordonnée qui peut entremêler reasoning, appels de function et messages, vous devez donc trouver l’item message plutôt que de supposer l’index zéro. Le tableau n’est pas vide (A), le texte n’est pas dans un champ d’erreur (C), et les modèles de reasoning renvoient bien du texte (D).
  </AccordionItem>

  <AccordionItem title="Q10 · Une tâche est une analyse complexe, ouverte et à forte valeur sur laquelle Terra échoue à votre évaluation, et elle est à faible volume. Quel modèle est le MEILLEUR (BEST) choix suivant ? (Sélectionnez une réponse)">
    A. `gpt-5.6-luna` pour économiser.
    B. `gpt-5.6-sol`, positionné pour le travail complexe, ouvert et à forte valeur.
    C. `gpt-5.5` pour la stabilité.
    D. Rester sur Terra et baisser l’effort.

    **Réponse : B.** Sol est le choix documenté pour le travail complexe, ouvert et à forte valeur, et le faible volume signifie que son prix plus élevé est abordable. Luna (A) est pour les tâches simples à fort volume, 5.5 (C) est de la génération précédente, et baisser l’effort de Terra (D) empirerait la tâche en échec.
  </AccordionItem>

  <AccordionItem title="Q11 · Vous devez maintenir une conversation de deux tours sans renvoyer le texte du premier tour. Quelle structure d’appel est correcte ? (Sélectionnez une réponse)">
    A. Régler `stream=True` sur les deux appels.
    B. Régler `store=True` sur le premier appel et passer son `id` comme `previous_response_id` sur le second.
    C. Régler `background=True` sur le second appel.
    D. Fine-tuner le modèle sur le premier tour.

    **Réponse : B.** L’état côté serveur est créé avec `store=True` et poursuivi via `previous_response_id`. Le streaming (A) et le background mode (C) traitent la latence, pas l’état, et le fine-tuning (D) est sans rapport avec la continuité de conversation.
  </AccordionItem>

  <AccordionItem title="Q12 · Vous avez un PDF de 900 pages que le modèle doit lire pour répondre aux questions. Quel est le bon traitement d’entrée ? (Sélectionnez une réponse)">
    A. Copier le texte du PDF dans le prompt comme une seule chaîne géante manuellement.
    B. Fournir le PDF comme un item d’entrée de fichier pour que le modèle le lise directement.
    C. Faire une capture d’écran de chaque page et la décrire en mots.
    D. Fine-tuner sur le PDF d’abord.

    **Réponse : B.** Les entrées de fichiers laissent le modèle lire les documents directement plutôt que de coller du texte à la main. La copie manuelle (A) est source d’erreurs, les captures-en-prose (C) perdent du contenu, et le fine-tuning (D) est le mauvais outil pour une question sur un seul document.
  </AccordionItem>

  <AccordionItem title="Q13 · Votre conversation approche la fenêtre de contexte de 1,05 M de tokens. Quelle est l’action appropriée ? (Sélectionnez une réponse)">
    A. Passer à un modèle avec un contexte plus petit pour forcer la brièveté.
    B. Compacter les tours plus anciens en un résumé pour libérer de la place tout en préservant le sens du fil.
    C. Supprimer les instructions système.
    D. Tronquer les tours les plus récents.

    **Réponse : B.** La compaction résume les tours antérieurs pour que la conversation continue dans la fenêtre. Un modèle à contexte plus petit (A) empire les choses, retirer les instructions système (C) casse le comportement, et tronquer les tours les plus récents (D) jette la tâche courante.
  </AccordionItem>

  <AccordionItem title="Q14 · Quels DEUX (TWO) signaux dans un scénario de requête pointent vers le function calling plutôt que vers le rappel du modèle ? (Sélectionnez deux réponses)">
    A. La réponse dépend d’un inventaire en direct dans un système interne.
    B. Le modèle doit déclencher une action comme créer un ticket.
    C. L’utilisateur veut un poème sur l’automne.
    D. La tâche est de traduire un paragraphe fourni par l’utilisateur.
    E. L’utilisateur demande la définition d’un mot courant.

    **Réponse : A et B.** Les données privées en direct (A) et la prise d’action (B) exigent toutes deux que le modèle appelle votre code. Un poème (C), traduire un texte fourni (D) et définir un mot courant (E) sont de la pure génération que le modèle fait sans outils.
  </AccordionItem>

  <AccordionItem title="Q15 · Une équipe rapporte que GPT-5.6 Terra « semble pire que GPT-5.5 à effort high » après avoir copié leurs réglages d’effort. Quelle est l’explication la PLUS probable (MOST likely) et le correctif ? (Sélectionnez une réponse)">
    A. Terra est un moins bon modèle ; revenir en arrière définitivement.
    B. Les niveaux d’effort ne se mappent pas exactement entre générations ; réajuster l’effort de Terra face à l’évaluation plutôt que de copier l’ancien réglage.
    C. La fenêtre de contexte a rétréci ; réduire les entrées.
    D. La tarification a changé ; il n’y a rien à faire.

    **Réponse : B.** Il n’y a pas de correspondance d’effort exacte entre GPT-5.5 et GPT-5.6, donc les réglages copiés induisent en erreur ; réajuster avec l’évaluation. Terra n’est pas intrinsèquement pire (A), la fenêtre est inchangée à 1,05 M (C), et la tarification (D) n’explique pas la qualité.
  </AccordionItem>

  <AccordionItem title="Q16 · Une application analyse `output_text` et plante occasionnellement quand le modèle appelle un outil en milieu de réponse. Quel est le correctif RACINE (ROOT) ? (Sélectionnez une réponse)">
    A. Envelopper l’analyse dans un try/except et ignorer les échecs.
    B. Gérer la liste d’items `output` complète : détecter et exécuter les items `function_call`, renvoyer `function_call_output`, puis lire le message final.
    C. Désactiver tous les outils pour que seul du texte soit renvoyé.
    D. Réessayer la requête jusqu’à ce qu’elle ne renvoie que du texte.

    **Réponse : B.** Le crash vient de l’ignorance des items d’appel d’outil dans `output` ; la conception correcte les exécute et renvoie leurs résultats avant de lire le message final. Avaler les erreurs (A) masque le bug, désactiver les outils (C) retire une capacité nécessaire, et réessayer (D) est non déterministe et gaspilleur.
  </AccordionItem>
</Accordions>

## 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.