Construire des Agents avec État avec l'API Responses d'OpenAI : Un Guide Pratique

Points clés

• L'API Responses est la primitive d'API recommandée par OpenAI pour tous les nouveaux projets, et l'API Assistants a été retirée le 26 août 2026 — la fenêtre de migration est fermée ; Chat Completions reste supporté, mais ce n'est pas là que les nouvelles capacités agentiques atterrissent en premier.
• Les évaluations internes d'OpenAI montrent une amélioration de 3% sur SWE-bench et une meilleure utilisation du cache de 40–80% par rapport à Chat Completions lors de l'utilisation de modèles de raisonnement comme GPT-6 Astra via l'API Responses — la boucle agentique n'est pas qu'une commodité, elle améliore mesurablement la qualité de sortie.
• Les serveurs MCP distants sont un type d'outil de première classe dans l'API Responses — vous connectez n'importe quel serveur MCP avec un server_url et un server_label, et le modèle découvre et appelle ses outils dans la même requête, sans orchestration personnalisée requise.
• Le moniteur de désalignement de GPT-6 Astra arrête les tâches API directement lorsqu'il détecte un comportement non autorisé — il n'y a pas de chemin de reprise ; le flux de travail doit être récupérable depuis un état durable, ce qui est la contrainte architecturale la plus importante pour l'adoption en production.
• Le mode avec état est environ 2x plus lent que Chat Completions sans état selon plusieurs rapports de développeurs — la commodité de previous_response_id s'accompagne d'un coût de latence qui compte pour les flux orientés utilisateur sensibles à la latence.

L'API Responses d'OpenAI est la primitive d'API recommandée par l'entreprise pour tout nouveau développement, et l'API Assistants a été officiellement retirée le 26 août 2026. Chat Completions reste supporté, mais l'API Responses est là où les nouvelles capacités agentiques — outils intégrés, conversations avec état, MCP distant, mode arrière-plan, pilotage mi-tour — atterrissent en premier. Pour une équipe construisant des agents en production sur GPT-6 Astra, la question n'est plus de savoir s'il faut migrer mais comment architecturer autour du modèle d'état de l'API, de ses caractéristiques de latence et des contraintes de gouvernance que le moniteur d'exécution d'Astra impose. Ce guide cartographie les cinq capacités qui comptent, les trois décisions qui déterminent l'adoption, et le patron architectural qui garde votre agent portable entre fournisseurs.

Ce que l'API Responses change

L'API Chat Completions est sans état : vous envoyez tout l'historique de conversation avec chaque requête, et l'API retourne un seul message. L'API Responses introduit trois changements structurels qui affectent la façon dont vous construisez des agents.

Des Items au lieu de messages. Chat Completions retourne un tableau de choices, chacune contenant un message. L'API Responses retourne un tableau d'Items output, où chaque Item est une union typée — un message, un function_call, un function_call_output, un résumé de raisonnement, ou un appel d'outil. Ce n'est pas cosmétique : cela signifie que les appels d'outils, le raisonnement et le texte sont des objets de première classe dans la réponse, pas des champs collés sur un message. Quand vous chaînez des réponses avec previous_response_id, l'API préserve tous les types d'Item — y compris le raisonnement chiffré — entre les tours, ce qui fait fonctionner les flux agentiques multi-tours sans rejeu manuel du contexte.

Une boucle agentique en une requête. L'API Responses est conçue comme une boucle agentique : le modèle peut appeler plusieurs outils — web_search, file_search, computer_use, code_interpreter, image_generation, serveurs MCP distants et fonctions personnalisées — au sein d'un seul appel API, itérant jusqu'à atteindre une condition d'arrêt. Avec Chat Completions, vous implémentez cette boucle vous-même : appelez le modèle, analysez l'appel d'outil, exécutez-le, ajoutez le résultat, appelez à nouveau. L'API Responses exécute la boucle côté serveur. Les évaluations internes d'OpenAI montrent une amélioration de 3% sur SWE-bench avec le même prompt et la même configuration lors de l'utilisation de modèles de raisonnement via l'API Responses, plus 40–80% de meilleure utilisation du cache — la boucle côté serveur bénéficie de réussites de cache qu'une boucle manuelle ne peut pas répliquer.

Contexte avec état via previous_response_id. Au lieu d'envoyer tout l'historique avec chaque requête, vous passez l'ID de la réponse précédente et la nouvelle entrée utilisateur. L'API reconstruit le contexte côté serveur, y compris les Items de raisonnement. Les réponses sont stockées par défaut pendant 30 jours ; toute réponse attachée à une conversation persiste ses items sans TTL. Vous pouvez désactiver le stockage avec store: false pour les flux de travail à zéro rétention de données, mais vous devez alors rejouer manuellement tout l'historique d'Items — y compris les items de raisonnement chiffré — pour préserver le contexte de raisonnement entre les tours.

Les cinq capacités qui comptent

Les capacités de l'API Responses se mappent à cinq décisions architecturales, chacune avec un compromis concret :

1. previous_response_id : chaînage avec état

Le patron avec état le plus simple chaîne les réponses par ID :

from openai import OpenAI
client = OpenAI()

first = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    store=True,
)

second = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=first.id,
    input="And its population?",
    store=True,
)

Le deuxième appel ne renvoie pas la première question ni la réponse. L'API reconstruit le contexte complet depuis la réponse stockée, y compris tout raisonnement que le modèle a effectué. C'est le patron pour les agents conversationnels, les assistants de recherche et tout flux où le suivi de l'utilisateur dépend des tours précédents.

Le compromis est la latence. Plusieurs rapports de développeurs sur le forum communautaire OpenAI et Microsoft Q&A indiquent que le chemin avec état est environ 2x plus lent que Chat Completions sans état — 1 seconde contre 0,5 seconde dans les cas typiques, et jusqu'à 9x plus lent (2,9 secondes contre 0,3 secondes) sous charge. Pour un agent de recherche en arrière-plan qui tourne pendant des minutes, c'est sans importance. Pour un chat orienté utilisateur qui doit répondre en moins de 500 ms, le coût de latence peut justifier de rester sur Chat Completions avec gestion manuelle du contexte.

2. Serveurs MCP distants comme outil intégré

L'API Responses supporte les serveurs MCP distants comme type d'outil de première classe. Vous enregistrez un serveur par URL, et le modèle découvre ses outils et les appelle dans la boucle agentique :

response = client.responses.create(
    model="gpt-6-astra",
    tools=[{
        "type": "mcp",
        "server_label": "inventory",
        "server_description": "NetSuite inventory and pricing lookups",
        "server_url": "https://your-mcp-server.example.com/mcp",
        "require_approval": "never",
    }],
    input="Check stock levels for SKU A100-23 and suggest a reorder quantity.",
)

Le champ require_approval contrôle si le modèle a besoin d'une approbation humaine avant d'appeler les outils du serveur. Pour les déploiements en production, les options de filtrage des outils MCP — allowed_tools pour whitelister des noms d'outils spécifiques, et des politiques d'approbation personnalisées par outil — sont la couche de gouvernance qui empêche le modèle d'appeler des opérations destructrices sans autorisation explicite.

C'est la capacité la plus pertinente pour le patron d'intégration d'IdeaBosque. Un module MCP personnalisé qui enveloppe les APIs NetSuite, HubSpot ou BigCommerce peut être enregistré comme serveur MCP distant dans un appel d'API Responses, et le modèle l'utilise de la même façon qu'il utilise web_search ou code_interpreter. La couche sémantique — schémas typés, journaux d'audit, gestion des limites de débit — vit dans le module MCP, pas dans le prompt. L'API Responses ne résout pas le problème de la couche sémantique ; elle fait du module MCP le point d'intégration naturel. Pour un traitement plus approfondi de ce patron, voir MCP Module Code Standard.

3. Mode arrière-plan pour les tâches longues

Le mode arrière-plan découple l'appel au modèle de la connexion client. L'API accepte la requête, retourne un ID de réponse immédiatement, et exécute le travail du modèle de façon asynchrone. Vous sondez le statut ou recevez les résultats en streaming au fur et à mesure :

resp = client.responses.create(
    model="gpt-6-astra",
    input="Analyze all 200 RFQs from last week and categorize by supplier risk tier.",
    background=True,
)

while resp.status in {"queued", "in_progress"}:
    sleep(2)
    resp = client.responses.retrieve(resp.id)

print(resp.output_text)

Pour les agents à long horizon — synthèse de recherche, analyse de documents par lots, flux d'approvisionnement multi-étapes — le mode arrière-plan est le patron qui survit aux coupures réseau et aux délais d'attente client. Une réponse en arrière-plan qui prend six minutes ne dépend pas d'une connexion HTTP active ; si le client se déconnecte, le travail continue, et vous vous reconnectez avec une reprise en streaming utilisant le dernier numéro de séquence.

Le piège opérationnel est que le mode arrière-plan n'est pas une file de jobs. Comme une analyse le dit : l'API exécute l'appel au modèle, mais votre application possède toujours l'état du job — ce que l'UI affiche, comment éviter de traiter un webhook deux fois, quand annuler un travail qui n'a plus d'importance. Pour la production, vous avez besoin d'un système de jobs durable autour de la réponse en arrière-plan, pas juste de l'ID de réponse. C'est le même patron décrit dans Long-running Agent Patterns : le runtime de l'agent, non l'API du modèle, est la couche de fiabilité.

4. Raisonnement chiffré pour les flux à zéro rétention de données

Quand store: false, l'API ne persiste pas la réponse, mais elle retourne des items de raisonnement chiffré dans la sortie. Vous repassez ces items dans l'entrée de la requête suivante pour préserver le contexte de raisonnement entre les tours sans rien stocker sur les serveurs d'OpenAI. C'est le patron pour les environnements régulés où la rétention de données est interdite — systèmes à haut risque de l'EU AI Act, flux de santé sous HIPAA, flux de défense sous ITAR.

Le compromis est que vous devenez le stockage d'état. Vous devez sérialiser, stocker et rejouer le tableau complet d'Items — y compris les blobs opaques de raisonnement chiffré — à chaque tour. Si vous perdez les items de raisonnement chiffré, le modèle perd son contexte de raisonnement et la qualité de sortie se dégrade. C'est la même charge de gestion d'état que Chat Completions, mais avec un type d'item supplémentaire à gérer.

5. Le moniteur d'arrêt de tâche Astra

GPT-6 Astra est livré avec une surveillance de désalignement sur chaque requête utilisant des outils. Quand le moniteur signale un comportement potentiellement non autorisé, la réponse du modèle inclut un signal d'arrêt. Dans ChatGPT et Codex, l'utilisateur voit une tâche en pause à examiner. Dans l'API, la tâche s'arrête directement — il n'y a pas de chemin de reprise.

Pour les agents en production construits sur l'API Responses, c'est la contrainte architecturale la plus importante. Une tâche qui tourne pendant des heures à travers des chaînes de previous_response_id ou du mode arrière-plan peut être terminée en plein vol par un classifieur. Votre flux de travail doit être récupérable depuis un état durable — chaque appel d'outil, chaque résultat intermédiaire, chaque sortie partielle doit être persisté dans votre propre stockage avant le prochain appel API. Si le moniteur arrête la tâche à l'étape 47 sur 50, vous devez pouvoir reprendre depuis l'étape 47, pas redémarrer depuis zéro.

Le directeur scientifique d'OpenAI, Jakub Pachocki, a révélé dans An Alien Mind (6 septembre 2026) que la capacité de l'entreprise à s'appuyer sur la surveillance de la chaîne de pensée est "progressivement diminishante" — les modèles sont meilleurs pour raisonner sur et manipuler leur propre processus de raisonnement, et le pré-entraînement amélioré rend les modèles plus intelligents même sans raisonnement verbalisé. Le moniteur qui arrête votre tâche est la meilleure couche d'exécution d'exécution disponible, mais son fournisseur a dit que le signal dont il dépend se dégrade. Pour un traitement plus approfondi des couches d'exécution qui ne lisent pas le raisonnement du modèle, voir GPT-6 Astra Ships the Runtime Kill Switch.

Les trois décisions d'adoption

Décision 1 : Avec état ou sans état ?

Utilisez store: true avec previous_response_id quand votre flux est conversationnel, multi-tours et tolérant à la latence. Utilisez store: false avec rejeu manuel d'Items quand votre flux exige une zéro rétention de données ou quand vous avez besoin d'un contrôle total sur la gestion du contexte. La différence de latence est d'environ 2x — acceptable pour les agents en arrière-plan, potentiellement inacceptable pour le chat orienté utilisateur.

Décision 2 : Outils intégrés ou fonctions personnalisées ?

Les outils intégrés (web_search, file_search, code_interpreter, computer_use, image_generation, MCP distant) s'exécutent côté serveur et bénéficient de l'optimisation du cache de la boucle agentique. Les fonctions personnalisées requièrent que vous implémentiez vous-même la boucle d'appel d'outils. La règle pratique : utilisez les outils intégrés pour les capacités qu'OpenAI fournit mieux que vous (recherche web, exécution de code), et utilisez les serveurs MCP distants pour vos propres intégrations système (NetSuite, HubSpot, BigCommerce). Utilisez les fonctions personnalisées uniquement pour les capacités qui ne peuvent pas être exposées comme un serveur MCP.

Décision 3 : OpenAI uniquement ou flexible en modèles ?

L'API Responses est une primitive d'OpenAI. Si vous construisez votre agent entièrement sur previous_response_id et les outils intégrés, vous êtes verrouillé au stockage d'état et à l'écosystème d'outils d'OpenAI. Si votre exigence de production inclut la flexibilité de modèles — routage vers des modèles open-weight comme Qwen3.8-27B pour les tâches sensibles aux coûts, ou vers Claude pour des capacités spécifiques — vous avez besoin d'une couche d'abstraction qui traduit entre le modèle d'Items de l'API Responses et le format de messages de Chat Completions que les autres fournisseurs utilisent.

C'est la décision architecturale qui détermine si l'API Responses est tout votre runtime d'agent ou un backend parmi plusieurs. Une construction flexible en modèles garde la boucle d'agent dans votre propre runtime, utilise l'API Responses quand ses capacités justifient la latence et le verrouillage, et revient à Chat Completions ou à l'inférence open-weight quand elles ne le justifient pas. L'économie d'inférence est claire : 29% du volume de tokens en production tourne déjà sur des modèles open-weight avec moins de 4% des dépenses. La discipline de routage est une réalité de production, pas un plan futur.

Checklist de migration

Le guide de migration d'OpenAI fournit la checklist complète. Les décisions qui affectent l'architecture, pas seulement le code :

• Déterminez votre modèle d'état. previous_response_id, rejeu manuel d'Items, ou l'API Conversations. Cela détermine votre profil de latence et votre posture de rétention de données.
• Auditez vos définitions de fonctions. Les fonctions personnalisées migrent telles quelles, mais les sorties d'appels de fonctions doivent inclure le bon call_id. Omettre des Items de raisonnement ou d'appel de fonction lors du transport manuel du contexte est l'erreur de migration la plus courante.
• Déplacez les schémas Structured Outputs de response_format vers text.format — le nom du champ a changé.
• Ajoutez la persistance d'état durable pour tout flux qui tourne plus de quelques secondes. Le moniteur d'arrêt de tâche Astra peut terminer une tâche longue sans chemin de reprise ; votre stockage d'état est le mécanisme de récupération.
• Comparez latence, utilisation de tokens et taux d'erreur avant de router le trafic de production. L'amélioration de 3% sur SWE-bench et l'amélioration de cache de 40–80% sont des moyennes ; votre charge de travail peut différer.
• Gardez un fallback Chat Completions si la flexibilité de modèles compte. L'API Responses est réservée à OpenAI ; les autres fournisseurs parlent Chat Completions.

Lecture connexe

• GPT-6 Astra Ships the Runtime Kill Switch — le paquet d'exécution et la divulgation de surveillabilité qui déterminent comment architecturer autour de la contrainte d'arrêt de tâche
• Inference Economics: Why Always-On Production Agents Are Now Affordable — les données de coût derrière la décision de routage flexible en modèles, y compris le ratio 29% open-weight / 4% dépense
• Long-running Agent Patterns: Keeping Agents Alive Across Hours and Days — les patrons d'état durable et de récupération que le moniteur d'arrêt Astra rend obligatoires

---

Un distributeur mid-market utilisant NetSuite et BigCommerce veut ajouter un agent qui surveille les RFQ entrants, vérifie les stocks et les prix par palier, et rédige des réponses de devis. L'API Responses avec un serveur MCP distant enveloppant le module connecteur NetSuite est le chemin le plus rapide vers un prototype fonctionnel — un appel API, boucle d'outils intégrée, sans orchestration personnalisée. Mais l'architecture de production nécessite la couche de routage flexible en modèles (modèles open-weight pour 60% du volume d'inférence à 4% du coût), le stockage d'état durable (le moniteur Astra peut arrêter une longue tâche d'analyse RFQ en plein vol), et la couche sémantique dans le module MCP (schémas typés, journaux d'audit, gestion des limites de débit que l'API Responses ne fournit pas). C'est la construction que nous délimitons : l'API Responses comme backend d'exécution, les modules MCP comme couche d'intégration, votre runtime comme couche de fiabilité et de routage.

Demandez une construction délimitée. Discovery d'une semaine. Vous obtenez un inventaire système, une carte des flux et un périmètre fixe — que vous construisiez avec nous ou non.