OpenAI Agents API : ce que c'est et comment créer un agent en 2026

Ce qu'est vraiment l'« OpenAI Agents API »

Il vaut mieux démêler cela d'abord, car l'expression désigne plusieurs choses liées arrivées à des moments différents, et les noms sont franchement déroutants.

Tout a commencé en mars 2025, quand OpenAI a lancé l'API Responses et l'Agents SDK open source ensemble, avec les premiers outils intégrés. L'API Responses est la brique de base : un sur-ensemble de Chat Completions par lequel les modèles génèrent leurs réponses et la surface sur laquelle se branche chaque outil hébergé. C'est aussi le futur remplaçant de l'ancienne Assistants API. L'Agents SDK est la couche d'orchestration par-dessus, qui gère la boucle de l'agent, les transferts entre agents et les garde-fous au sein de votre propre application.

Puis, en octobre 2025, est arrivé AgentKit, un ensemble d'outils pour ceux qui ne voulaient pas écrire la boucle à la main : Agent Builder (un canevas en glisser-déposer), le Connector Registry, ChatKit (une interface de chat intégrable) et Evals étendu. Plus récemment, OpenAI a ajouté un environnement d'exécution Agents API entièrement géré qui exécute la boucle à votre place sur son propre harnais Codex, avec compactage du contexte et orchestration multi-agents intégrés.

Je développe les intégrations d'eesel, j'ai donc construit cette boucle à la main plus d'une fois, et le modèle mental qui aide le plus est le suivant : rien de tout cela n'est magique. Un agent est un modèle à qui vous avez confié un travail, un ensemble d'outils et la permission de continuer à s'appeler lui-même jusqu'à ce que le travail soit fait. Tout le reste, le SDK, l'environnement géré, le canevas visuel, est une réponse différente à une seule question : qui exécute cette boucle, et où ?

Comment la boucle de l'agent fonctionne vraiment

C'est le concept le plus important, et celui qui fait trébucher toutes les équipes débutantes. Un appel d'API ordinaire, c'est une requête et une réponse. Un agent, c'est une boucle de requêtes.

Vous donnez une tâche à l'agent. Le modèle raisonne dessus, décide qu'il a besoin d'informations et appelle un outil (une recherche web, une requête de base de données, une fonction que vous avez écrite). L'outil renvoie un résultat, ce résultat est réinjecté dans le contexte du modèle, et le modèle raisonne à nouveau avec la nouvelle information. S'il a terminé, il répond. Sinon, il appelle un autre outil. Et ainsi de suite jusqu'à ce que la tâche soit accomplie ou qu'une limite l'arrête.

Le schéma d'exécution d'OpenAI rend la version multi-agents concrète : un agent de tri appelle POST /v1/responses, passe un garde-fou, puis transfère à un agent CRM, qui rappelle le modèle et déclenche un outil. Cela fait déjà plusieurs appels de modèle pour une seule tâche.

Ce qui surprend, c'est la croissance du contexte. Chaque résultat d'outil s'empile dans le prompt de l'appel suivant : la boucle ne se contente donc pas de multiplier les appels, elle gonfle la taille de chaque appel suivant. Un développeur l'a dit plus crûment que n'importe quelle page de documentation :

"I was spending $200/day running agents with tool calls. The problem: tools return huge JSON (search results, DB queries, file listings). Each response bloats context. By turn 10, you're paying for 100k+ tokens on every LLM call."

chopratejas, Hacker News

Ce n'est pas un avertissement pour vous faire fuir, c'est ce autour de quoi il faut concevoir. La boucle est votre puissance (c'est ce qui permet à un agent d'enchaîner recherche, décisions et actions) et votre principal levier. Des boucles plus courtes, des sorties d'outils plus resserrées et des tentatives plafonnées font l'essentiel de la différence entre un agent économique et un agent coûteux. Les meilleurs agents IA sont ceux pour lesquels quelqu'un a réfléchi à fond au nombre minimal de tours dont chaque tâche a vraiment besoin.

Les quatre environnements d'exécution : choisissez où tourne la boucle

Une fois que vous acceptez qu'un agent est une boucle, la décision suivante est de savoir où elle s'exécute. OpenAI propose désormais quatre environnements d'exécution, qui diffèrent surtout par la part de la boucle que vous possédez.

• Agents API exécute la boucle à votre place sur un harnais Codex géré, avec compactage automatique du contexte, orchestration multi-agents et un bac à sable hébergé en option. L'option la plus autonome, et le compactage aide vraiment à garder la boucle légère.
• Agents SDK exécute la boucle au sein de votre propre application. Vous gérez le déploiement, le stockage et les validations ; le runner gère la boucle et les transferts. C'est là qu'atterrissent la plupart des équipes qui veulent un vrai contrôle.
• API Responses consiste à construire à partir de la brique de base : vous appelez le modèle directement et vous câblez votre propre orchestration et historique. Contrôle maximal, responsabilité maximale.
• ChatKit est l'interface de chat intégrée que vous déposez dans votre produit, posée sur celui des précédents qui fait le vrai travail.

Aucun ne change ce que font le modèle ou les outils. Ils changent qui est responsable du déclenchement de la boucle, ce qui est la décision qui façonne toute votre architecture. Si vous voulez que l'agent soit votre produit, le SDK ou l'API Responses vous donnent le contrôle. Si vous voulez un agent dans une application existante sans héberger de runner, l'Agents API géré est le raccourci.

Les outils hébergés qu'un agent peut utiliser

Un agent n'est utile que dans la mesure des outils qu'il peut appeler. En plus de vos propres fonctions, OpenAI fournit un ensemble d'outils intégrés qui se branchent directement sur l'API Responses :

• Web search permet à l'agent d'obtenir des informations en direct sur Internet, avec un réglage return_token_budget qui plafonne le nombre de tokens de résultats renvoyés au modèle. Pratique, car les résultats de recherche sont exactement le genre de sortie volumineuse qui gonfle une boucle.
• File search fait de la recherche sur vos propres documents dans un magasin de vecteurs, construit sur des embeddings. C'est ainsi que vous donnez à un agent votre base de connaissances, et vous pouvez plafonner le nombre de résultats récupérés pour garder le contexte serré.
• Code Interpreter exécute du Python dans un conteneur isolé, pour l'analyse de données, la manipulation de fichiers et les calculs que le modèle ne devrait pas faire de tête.
• Computer use permet à l'agent de piloter un navigateur ou un bureau. Pour les modèles les plus récents, la voie recommandée par OpenAI est une boucle d'exécution de code où le modèle écrit un script que votre propre bac à sable exécute, plutôt qu'une action hébergée dédiée.

Les outils sont ce qui transforme un chatbot en agent, et bien les choisir représente la moitié du travail de conception. Un agent de support capable de chercher dans votre centre d'aide et de lire l'historique des commandes fait ce qu'un simple bot de FAQ ne pourrait jamais faire. Chaque appel d'outil est aussi un tour de la boucle : la règle pratique est donc de donner à l'agent exactement les outils dont le travail a besoin, et pas plus.

AgentKit, et ce qui est arrêté

Si écrire la boucle à la main vous semble beaucoup, AgentKit était la réponse d'OpenAI : une couche visuelle pour assembler des agents sans code. Agent Builder en est le canevas en glisser-déposer, et il mérite un coup d'œil car il rend visible la forme multi-agents.

Ce flux (début, un garde-fou anti-jailbreak, un agent de classification, un if/else qui aiguille vers un agent de retour, de rétention ou d'information, puis un garde-fou anti-hallucination avant la réponse) donne une bonne image de ce dont un vrai workflow de support a besoin. Chaque nœud qui dit « agent » est au moins un POST /v1/responses de plus.

Voici le hic, et il compte si vous choisissez une surface aujourd'hui. OpenAI met fin à Agent Builder et à Evals, et à partir du 30 novembre 2026 ils ne seront plus disponibles. Dans la documentation, ils figurent déjà sous la rubrique « Legacy APIs », et OpenAI vous oriente désormais vers l'Agents SDK centré sur le code ou vers les Workspace Agents dans ChatGPT.

Construisez donc sur les surfaces durables : l'API Responses, l'Agents SDK, l'environnement Agents API géré, ChatKit et le Connector Registry. Considérez le canevas visuel comme une bonne façon de prototyper et de comprendre la forme, pas comme ce sur quoi engager la production. La bonne nouvelle, c'est que les couches elles-mêmes n'entraînent pas de frais séparés ; OpenAI est explicite : les outils AgentKit sont "included with standard API model pricing", le choix porte donc sur la durabilité, pas sur le coût.

Comment en construire un concrètement

Assez de concepts. Voici la séquence que je suivrais pour faire tourner un premier agent, quel que soit l'environnement choisi.

1. Choisissez un modèle. Adaptez-le au travail, pas à la brochure. Un routeur ou classificateur simple se contente d'un modèle moins cher comme gpt-5.6-luna ; un agent de recherche ou de raisonnement en plusieurs étapes en demande un plus fort. Vous pouvez même mélanger les modèles dans un flux multi-agents : un petit pour le tri, un plus gros pour l'étape difficile.
2. Choisissez un environnement d'exécution. L'Agents API géré si vous voulez qu'OpenAI exécute la boucle, l'Agents SDK si vous voulez l'exécuter dans votre propre application avec un contrôle total.
3. Rédigez les instructions et choisissez les outils. Le prompt système est la fiche de poste de l'agent. Donnez-lui ensuite exactement les outils dont il a besoin : des intégrés comme web search et file search, plus vos propres appels de fonctions pour tout ce qui est propre à votre produit.
4. Ajoutez des garde-fous. Des garde-fous en entrée (contrôles de jailbreak et de sujet) et en sortie (un contrôle d'hallucination ou de sécurité avant que la réponse n'atteigne un utilisateur). C'est la partie que les équipes sautent et regrettent.
5. Testez avant la mise en ligne. Faites tourner l'agent sur des entrées réalistes et observez toute la boucle, pas seulement la réponse finale. Voir qu'un agent a bouclé quatre fois parce que les trois premières sorties ont échoué à la validation, c'est exactement ce que vous voulez repérer avant un client.
6. Livrez, puis surveillez le coût d'exécution. L'unité qui compte est l'exécution entière, tentatives et appels d'outils compris, pas le prix d'un seul token. Instrumentez pour voir la longueur de boucle par tâche dès le premier jour.

Si cette liste ressemble à un vrai projet d'ingénierie, c'est parce que c'en est un. Construire un agent sur de l'infrastructure brute est le bon choix quand l'agent est votre produit et que vous voulez du contrôle jusqu'au token. C'est le mauvais choix quand vous avez simplement besoin qu'un travail soit fait, comme un bon service client, et que vous ne voulez pas posséder pour toujours une boucle, un banc d'évaluation et une pile de supervision.

Ce que ça coûte (la version courte)

Il n'existe pas de « prix de l'Agents API ». Vous empilez des tokens de modèle à chaque tour, des frais par appel pour les outils hébergés et du temps de conteneur pour l'exécution de code, et c'est la longueur de la boucle qui fait vraiment bouger la facture. Les tarifs des modèles vont de $0.20 par 1M de tokens pour le moins cher à $10 par 1M en entrée pour le haut de gamme ; web search coûte $10 pour 1 000 appels ; file search coûte $2.50 pour 1 000 appels.

C'est le titre, mais le vrai calcul est dans la boucle, nous lui avons donc consacré son propre guide : la décomposition complète, un exemple chiffré et un estimateur de coût en direct se trouvent dans tarifs de l'OpenAI Agents API. Si vous comparez les fournisseurs, notre article OpenAI API vs Anthropic API fait les mêmes calculs pour Claude.

Essayez eesel et sautez complètement la boucle

Voici le cadrage honnête. L'OpenAI Agents API est de l'infrastructure : la matière première avec laquelle vous assemblez un agent, plus la boucle, les évaluations et la supervision que vous construisez et maintenez vous-même. C'est le bon choix quand l'agent est votre produit.

eesel est l'autre bout de ce compromis : pas de l'infrastructure, mais un coéquipier prêt à travailler. Vous embauchez le coéquipier de support IA, vous le branchez à votre helpdesk, et il arrive en connaissant déjà votre entreprise grâce à vos anciens tickets et à votre centre d'aide. Nous passons des années à mettre des agents IA sur de vraies files de support, c'est pourquoi chaque déploiement est simulé sur vos tickets historiques avant de répondre à un seul vrai client. Il n'y a pas de boucle à mesurer pour vous, car le prix est fixe : à partir de $299 par mois pour 500 crédits, où 1 crédit correspond à un ticket ou un chat, sans facturation au nombre d'appels de modèle ou de sauts d'outils nécessaires pour le résoudre. La boucle imprévisible est notre problème, pas le vôtre.

Et si c'est le contrôle programmatique qui vous a attiré vers l'Agents API, eesel le conserve. Il existe une vraie CLI publique (@eesel/cli) ainsi qu'un serveur MCP, des webhooks et un accès réseau, pour que vous puissiez connecter une intégration, modifier les instructions permanentes de l'agent, lister et valider les actions avec humain dans la boucle, et lire le journal d'activité exécution par exécution depuis un terminal ou un script. La documentation le dit simplement, "everything on this site can be done from the terminal", et des agents de code comme Claude Code et Cursor peuvent le piloter directement. Vous obtenez la surface adaptée aux agents sans construire ni surveiller l'agent lui-même.

Si vous construisez un agent parce que vous voulez posséder chaque token, l'OpenAI Agents API est un très bon endroit pour le faire. Si vous en construisez un parce que vous avez besoin que le service client soit assuré, démarrez un essai gratuit et laissez le coéquipier faire le travail.