OpenAI cède sa spécification Open Responses à la fondation Agentic AI pour standardiser les API de modèles
Le 22 octobre 2026, OpenAI transfère Open Responses, sa spécification d’API commune pour les modèles de langage, à l’Agentic AI Foundation, hébergée par la Linux Foundation, aux côtés d’OpenSandbox et d’OpenEv. Pour les équipes qui jonglent entre plusieurs fournisseurs de modèles, c’est un levier concret pour réduire la surface d’intégration propre à chaque vendeur.
22 octobre 2026. OpenAI annonce le transfert d’Open Responses, sa spécification d’API commune pour les modèles de langage, vers l’Agentic AI Foundation (AAIF), une fondation hébergée par la Linux Foundation. 22 octobre 2026. Deux autres projets la rejoignent au passage : OpenSandbox et le framework d’environnements d’agents OpenEv de Hugging Face, ainsi que les Agent Skills d’Anthropic. 22 octobre 2026. AWS, Databricks, Nvidia, Red Hat, Vercel et vLLM figurent déjà parmi les soutiens déclarés. Pourquoi c’est important : la fragmentation des API de modèles est en train de se résorber par le bas, et c’est la couche d’intégration de vos applications qui va en profiter.
Un problème que tout intégrateur de modèles connaît
Le constat de départ est simple. Tous les fournisseurs de LLM proposent désormais les mêmes briques — messages, appels d’outils, function calling — mais chacun les représente différemment dans son API. Une équipe qui bascule d’un modèle à l’autre doit traduire ses appels entre des idiomes incompatibles, et maintenir autant de couches d’intégration que de vendeurs. Open Responses vise exactement ce point : une spécification qui standardise ces primitives pour que les développeurs n’aient plus à réécrire la plomberie à chaque changement de modèle.
La généalogie de la spécification est transparente. Le guide des contributeurs reconnaît que ses schémas de base sont copiés de l’API d’OpenAI. C’est cohérent avec l’histoire du marché : l’ancienne API Chat Completions d’OpenAI a servi de standard de fait que d’autres ont imité, avant que l’API Messages d’Anthropic — portée par le succès de Claude Code — ne s’impose à son tour comme référence, reprise par DeepSeek, Moonshot, Z.ai ou MiniMax. Le marché s’est donc scindé en deux dialectes dominants. C’est précisément la fragmentation qu’une spécification neutre est censée réparer.
Ce que la spécification normalise, et ce qu’elle laisse de côté
Open Responses ne prétend pas uniformiser les modèles eux-mêmes, seulement la couche d’appel. Les primitives visées — messages, appels d’outils, function calling, formats de réponse — sont celles que chaque fournisseur réinvente à sa manière. La spécification décrit une API unique pour les exprimer, ce qui permet à un gateway ou à une plateforme d’exposer plusieurs modèles derrière un même contrat. C’est exactement ce que font déjà Vercel AI Gateway et Databricks Model Serving, les deux implémentations productives du jour.
Ce qu’elle laisse de côté est tout aussi important. La spécification ne couvre pas les capacités spécifiques d’un modèle — certains modes de function calling, les formats d’images, les variantes de streaming — ni les garanties de qualité d’une implémentation. Un fournisseur peut annoncer le support d’Open Responses tout en dégradant subtilement les primitives qu’il expose. La standardisation réduit la plomberie, elle ne supprime pas le besoin de tests d’intégration par fournisseur.
Il faut aussi comprendre le geste politique. En cédant la spécification, OpenAI abandonne le contrôle exclusif d’un standard qui porte son ADN — les schémas de base sont copiés de son API. C’est un pari : mieux vaut une spécification neutre largement adoptée qu’un standard propriétaire que Anthropic et Google ignoreront. La fondation, de son côté, gagne un projet de plus dans un portefeuille — MCP, A2A, AGENTS.md — qui couvre déjà l’essentiel de la pile d’agents. Le signal est clair : l’interopérabilité des agents se construit désormais à la Linux Foundation, pas dans les labs des vendeurs.
Pour un décideur technique, le choix se pose en termes simples. Adopter Open Responses revient à parier que la spécification deviendra le dénominateur commun du marché — un pari raisonnable au vu des soutiens (AWS, Nvidia, Red Hat) et des deux implémentations déjà productives. Ne pas l’adopter, c’est conserver la liberté de s’optimiser pour un fournisseur précis, au prix d’une dépendance qu’il faudra assumer à la prochaine bascule. Entre les deux, la voie médiane — un gateway qui parle Open Responses en façade et garde des adaptateurs maison en interne — est celle que choisissent déjà les équipes les plus avancées.
Une fondation neutre, des soutiens déjà larges
Le choix de l’AAIF n’est pas anodin. La fondation, lancée en décembre 2025 au sein de la Linux Foundation, héberge déjà MCP, A2A, AGENTS.md (également issu d’OpenAI), l’agent open source goose, agentgateway et Agent Router. Un comité technique composé initialement des mainteneurs des projets pilotera les discussions. C’est ce « foyer neutre » qui motive en général le don d’un projet à une fondation : il transforme un standard de fait contrôlé par un vendeur en bien commun gouverné collectivement.
La liste des soutiens est déjà large : AWS (dans Bedrock), Databricks, LM Studio, Ollama, Hugging Face, Nvidia, OpenRouter, Red Hat, Vercel, ainsi que les projets open source vLLM et OGC (ex-Llama Stack). Deux implémentations sont déjà en production — Vercel AI Gateway et Databricks Model Serving — ce qui donne à la spécification une réalité au-delà du papier.
Les absents sont tout aussi instructifs. Anthropic n’adopte pas la spécification et conserve son API Messages ; membre de l’AAIF, l’entreprise pourrait évoluer, mais rien ne l’y oblige. Google, de son côté, défend son API Interactions. La bataille de standardisation n’est donc pas gagnée : elle oppose trois dialectes — celui d’OpenAI, celui d’Anthropic et celui de Google — et le don d’Open Responses retire à OpenAI le contrôle exclusif de sa propre spécification sans garantir l’adoption des deux autres.
Ce que cela change pour une équipe qui construit des agents
Pour l’ingénieur qui assemble des applications multi-modèles, la promesse est concrète. Une spécification commune signifie moins d’intégrations spécifiques à entretenir et une bascule plus fluide entre fournisseurs, à condition que les vendeurs implémentent fidèlement la spécification. La déclaration d’OpenAI est directe sur ce point : « Open Responses donne aux développeurs un format partagé pour travailler avec les modèles sur les endpoints qui le supportent, afin qu’ils aient moins d’intégrations spécifiques à maintenir. »
La prudence reste de mise. Une spécification neutre n’élimine pas les particularités de chaque modèle — capacités de tool calling, formats d’images, streaming — et les implémentations peuvent diverger. L’adoption réelle, mesurée par le nombre de gateways et de plateformes qui l’exposent, sera le vrai test. Pour l’instant, les deux implémentations productives (Vercel, Databricks) sont un signal encourageant, mais le chemin vers un standard effectif passe par l’adoption des grands fournisseurs absents.
Verdict
Si vous construisez des applications qui appellent plusieurs modèles, adoptez Open Responses là où il est supporté — via un gateway comme Vercel AI Gateway ou une plateforme comme Databricks Model Serving — pour réduire la surface d’intégration propre à chaque vendeur, tout en gardant une couche d’abstraction maison pour les cas limites que la spécification ne couvre pas. Si vous êtes contraint à un seul fournisseur, le bénéfice est plus faible : suivez l’évolution de la spécification, mais ne migrez pas pour la seule beauté du standard. Si vous choisissez une pile d’agents aujourd’hui, privilégiez les composants qui s’appuient sur des standards gouvernés par l’AAIF — MCP, A2A, désormais Open Responses — car c’est là que la portabilité se construit. La bataille entre les dialectes d’OpenAI, d’Anthropic et de Google n’est pas finie, mais pour la première fois, le coût de la fragmentation retombe sur quelqu’un d’autre que vous.