Qu'est-ce qu'OpenAI AgentKit ?

OpenAI AgentKit est un ensemble d'outils pour créer, déployer et mesurer des agents IA sur la plateforme d'OpenAI. Si vous avez déjà configuré un agent manuellement, jonglant avec le code d'orchestration, les connecteurs et les scripts d'évaluation, AgentKit était la réponse d'OpenAI à cette fragmentation. Il y a un point important à connaître en 2026 avant de vous engager, ce guide explique donc ce qu'AgentKit inclut, à qui il s'adresse, un flux de construction de haut niveau, et où les outils de test d'API comme Apidog s'intègrent lorsque votre agent commence à appeler des services externes.

Qu'est-ce qu'AgentKit

OpenAI a introduit AgentKit lors de la DevDay le 6 octobre 2025. Ce n'était pas un produit unique. C'était un ensemble de composants qui se superposent à l'API OpenAI existante et au SDK OpenAI Agents, visant à réduire l'écart entre "J'ai une idée d'agent" et "J'ai un agent en fonctionnement devant les utilisateurs."

Avant AgentKit, la construction d'un agent impliquait généralement d'assembler une logique d'orchestration sans versioning, des connecteurs personnalisés pour chaque source de données, des pipelines d'évaluation faits à la main, un réglage manuel des invites, et une bonne quantité de travail frontend avant que quoi que ce soit ne soit livré. AgentKit a regroupé des solutions à ces problèmes sous un même chapeau.

Une chose à signaler d'emblée, car elle change la façon dont vous devriez traiter cela : le 3 juin 2026, OpenAI a annoncé qu'il mettait fin à deux des composants d'AgentKit, Agent Builder et Evals. Plus de détails sur les dates ci-dessous. Le principal à retenir est que la voie durable, axée sur le code, à travers AgentKit est le SDK Agents, et c'est sur cela que vous devriez construire si vous voulez quelque chose qui dure.

Les composants d'AgentKit

AgentKit a été livré sous la forme de quatre composants principaux. Voici ce que chacun fait et où il en est maintenant.

Agent Builder

Agent Builder est un canevas visuel pour concevoir des flux de travail d'agent multi-étapes. Vous glissez-déposez des nœuds pour chaque étape, les connectez en un flux, prévisualisez les exécutions par rapport à des entrées réelles et publiez des instantanés versionnés du flux de travail. C'est le point d'entrée "pas de page blanche", avec des modèles pour commencer.

Un détail utile pour les développeurs : Agent Builder n'est pas une impasse loin du code. Il dispose d'un onglet Agents SDK qui exporte votre flux de travail en tant que code Python ou TypeScript exécutable, afin que vous puissiez prendre la conception visuelle et l'étendre dans votre propre environnement.

Le statut est important ici. OpenAI déprécie Agent Builder, avec une date de fermeture de la plateforme au 30 novembre 2026, selon sa page de dépréciations. Si vous commencez à zéro aujourd'hui, traitez le canevas visuel comme une aide au prototypage et prévoyez d'atterrir dans le code SDK.

ChatKit

ChatKit est une interface de chat intégrable pour mettre votre agent à la disposition des utilisateurs. Au lieu de construire une interface utilisateur de chat à partir de zéro, vous insérez un composant web, le dirigez vers un ID de flux de travail publié, et personnalisez le thème et le comportement. Il gère les réponses en streaming, les fils de discussion et la plomberie habituelle du chat.

ChatKit reste disponible et est la méthode recommandée pour déployer une expérience d'agent basée sur le chat. C'est le composant d'AgentKit le moins affecté par les changements de 2026.

Registre des connecteurs

Le Registre des connecteurs est un espace d'administration permettant de gérer la connexion des données et des outils entre les produits OpenAI, englobant ChatGPT et l'API. Il consolide les connecteurs pré-intégrés (pensez à Dropbox, Google Drive, SharePoint, Microsoft Teams) et les serveurs MCP tiers dans un seul panneau, afin qu'un administrateur contrôle ce qu'un agent peut atteindre.

Si vous voulez comprendre le côté MCP de cette image, notre guide sur les serveurs MCP et le SDK OpenAI Agents explique comment les agents appellent les outils via le protocole de contexte de modèle (Model Context Protocol).

Evals et optimisation

Les fonctionnalités Evals ont ajouté des jeux de données, la notation des traces (évaluant chaque étape d'une exécution multi-agents), l'optimisation automatisée des invites, et la capacité d'évaluer par rapport à des modèles tiers, et pas seulement ceux d'OpenAI. L'objectif était de mesurer la qualité des agents et d'affiner les invites sans construire votre propre harnais d'évaluation.

Comme Agent Builder, Evals est en cours de suppression. Il devient en lecture seule pour les utilisateurs existants le 31 octobre 2026 et s'arrête le 30 novembre 2026.

Comment AgentKit se rapporte au SDK Agents

C'est la partie qu'il faut bien comprendre, car elle détermine ce sur quoi vous construisez.

Le SDK Agents est le framework de code. C'est là que vous définissez les agents, les outils, les transferts et les garde-fous en Python ou TypeScript. L'Agent Builder d'AgentKit se situe au-dessus en tant que couche visuelle qui génère du code SDK. ChatKit se situe à côté en tant que surface de déploiement.

Les conseils de migration d'OpenAI sont directs : pour les flux de travail qui doivent exister sous forme de code, passez au SDK Agents. Pour les cas d'utilisation en langage naturel qui n'ont pas besoin de code, utilisez les agents Workspace dans ChatGPT. Si vous lisez ceci pour décider où investir, le SDK Agents est la réponse pour les équipes d'ingénierie.

À qui s'adresse AgentKit

AgentKit ciblait quelques groupes. Les équipes produit qui voulaient lancer un agent rapidement sans écrire de code d'orchestration s'appuyaient sur Agent Builder et ChatKit. Les entreprises qui avaient besoin d'un accès gouverné aux données internes utilisaient le Registre des connecteurs. Les équipes d'ingénierie qui voulaient un contrôle total se tournaient directement vers le SDK Agents et utilisaient Evals pour mesurer la qualité.

Compte tenu des dépréciations, la lecture la plus claire pour 2026 est la suivante : si vous êtes un ingénieur et que vous construisez quelque chose à maintenir, commencez par le SDK Agents. Si vous prototypez et que vous souhaitez prendre une longueur d'avance visuellement avant la disparition du canevas, Agent Builder exporte toujours du code utilisable.

Un flux de construction de haut niveau

Que vous commenciez visuellement ou par le code, la forme de la construction d'un agent est similaire. Voici le flux que la plupart des équipes suivent.

1. Définissez la tâche de l'agent. Quel objectif poursuit-il et de quels outils a-t-il besoin ? Les outils sont généralement des appels d'API externes : un point d'accès de recherche, une consultation CRM, un microservice interne.
2. Composez le flux de travail. Dans Agent Builder, vous glissez-déposez des nœuds ; dans le SDK Agents, vous définissez les agents et attachez les outils et les transferts dans le code.
3. Ajoutez des garde-fous. OpenAI propose une couche de garde-fous open-source et modulaire qui peut masquer ou signaler les informations d'identification personnelle (PII), détecter les tentatives d'évasion et appliquer d'autres vérifications. Vous pouvez l'utiliser comme des nœuds de flux de travail ou comme une bibliothèque autonome.
4. Connectez les données et les outils. Via le Registre des connecteurs ou en enregistrant les serveurs MCP et les outils fonctionnels que l'agent peut appeler.
5. Testez et évaluez. Exécutez l'agent avec des entrées réelles, évaluez les traces et ajustez les invites.
6. Déployez. Intégrez via ChatKit avec un ID de flux de travail publié, ou exécutez votre code SDK Agents exporté dans votre propre infrastructure.

Les étapes 4 et 5 sont celles où se trouvent la plupart des difficultés réelles, et où le test d'API prend tout son sens.

Un exemple réaliste : les outils que votre agent appelle

Un agent n'est aussi bon que les outils qu'il peut appeler, et ces outils sont presque toujours des API HTTP. Lorsque vous enregistrez un outil fonctionnel avec le SDK Agents, vous le décrivez avec un schéma JSON afin que le modèle sache quand et comment l'appeler. Un outil qui récupère les commandes récentes d'un client pourrait être défini comme suit :

{
  "type": "function",
  "name": "get_recent_orders",
  "description": "Look up a customer's recent orders by customer ID.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "The customer's unique identifier"
      },
      "limit": {
        "type": "integer",
        "description": "How many orders to return",
        "default": 5
      }
    },
    "required": ["customer_id"],
    "additionalProperties": false
  }
}

Lorsque le modèle décide d'appeler `get_recent_orders`, votre code reçoit les arguments, effectue une requête réelle à votre API de commandes, et renvoie le résultat à l'agent. Cette requête pourrait ressembler à ceci :

curl https://api.your-company.com/v1/customers/cus_8842/orders?limit=5 \
  -H "Authorization: Bearer $ORDERS_API_KEY" \
  -H "Content-Type: application/json"

Voici le problème. Le comportement de l'agent dépend entièrement de ce que cette API renvoie. Si l'API des commandes est lente, hors service ou renvoie une forme inattendue par le modèle, le raisonnement de l'agent déraille. Et pendant le développement, l'API des commandes pourrait ne pas encore exister, ou vous pourriez ne pas vouloir surcharger la production avec des exécutions de test. C'est là que Apidog intervient.

Où s'intègrent les tests et le maquettage d'API

Apidog n'est pas un framework d'agent, et il ne construit pas d'agents. AgentKit et le SDK Agents s'en occupent. Ce que fait Apidog, c'est la couche sous-jacente : il teste, maquette et documente les API et les outils que votre agent appelle. Trois tâches concrètes se présentent constamment.

Premièrement, maquettez les API externes avant qu'elles ne soient prêtes. Si votre agent doit appeler un service de commandes que l'équipe backend n'a pas terminé, vous pouvez mettre en place une API de maquette qui renvoie des réponses réalistes correspondant au schéma convenu. Votre agent se développe par rapport à un contrat stable au lieu d'attendre le backend, et vous contrôlez les cas limites, les résultats vides, les erreurs, les réponses lentes, à la demande.

Deuxièmement, assurez-vous que chaque outil renvoie ce que l'agent attend. Un appel d'outil qui renvoie un 200 avec des noms de champs incorrects est pire qu'un échec pur et simple, car le modèle essaiera de raisonner sur des données aberrantes. En écrivant des cas de test d'API qui valident les codes de statut, la forme de la réponse et les valeurs de champs spécifiques, vous détectez les dérives de contrat sur chaque endpoint que votre agent touche avant qu'elles n'atteignent le modèle.

Troisièmement, gérez les clés d'environnement et les URL de base entre les environnements de développement, de staging et de production. Les outils d'agent contiennent des secrets comme `$ORDERS_API_KEY`. Conserver ceux-ci dans des variables d'environnement et les échanger par environnement, sans coller les clés dans le code, est exactement le genre de chose qu'une plateforme d'API gère proprement. Vous pouvez télécharger Apidog et importer vos points d'extrémité d'outils dans un projet pour les tester de manière isolée, loin de l'environnement d'exécution de l'agent.

Si vous souhaitez un guide détaillé sur la façon de traiter les appels d'outils d'un agent comme des API testables, nous en avons écrit un dans comment tester les appels d'outils d'un agent IA. En bref : chaque outil que votre agent appelle est une API, et les API méritent d'être testées.

Foire aux questions

OpenAI AgentKit est-il gratuit ?

Les outils d'AgentKit se superposent à votre utilisation de l'API OpenAI, vous payez donc pour les jetons de modèle sous-jacents et tous les appels d'outils effectués par l'agent. Il n'y a pas de ligne distincte d'abonnement à AgentKit ; le coût est celui de l'utilisation du modèle et de l'API que votre agent génère. Vérifiez toujours les prix actuels sur la plateforme d'OpenAI, car les tarifs des modèles peuvent changer.

Quelle est la différence entre AgentKit et le SDK Agents ?

Le SDK Agents est le framework de code pour définir les agents, les outils et les garde-fous. AgentKit est un ensemble plus large qui incluait l'Agent Builder visuel, ChatKit, le Registre des connecteurs et Evals en plus de ce SDK. Avec la suppression progressive d'Agent Builder et d'Evals fin 2026, le SDK Agents est la voie durable et axée sur le code. Notre guide du SDK Agents le couvre de bout en bout.

Agent Builder va-t-il disparaître ?

Oui. OpenAI a annoncé le 3 juin 2026 qu'il déprécie Agent Builder et la plateforme Evals. Les deux seront arrêtés le 30 novembre 2026, et Evals deviendra en lecture seule le 31 octobre 2026. ChatKit reste disponible, et OpenAI recommande de déplacer les flux de travail axés sur le code vers le SDK Agents et ceux en langage naturel vers les Workspace Agents dans ChatGPT.

Puis-je tester les API que mon agent AgentKit appelle ?

Oui, et vous devriez le faire. Chaque outil qu'un agent appelle est une API HTTP avec une requête et une réponse. Vous pouvez maquettez ces API pendant qu'elles sont encore en construction, vérifier que leurs réponses correspondent au schéma attendu par votre agent, et gérer les clés dont chacune a besoin. Une plateforme comme Apidog gère les trois pour que les outils de votre agent se comportent de manière prévisible avant d'atteindre un utilisateur réel.

Conclusion

AgentKit a offert aux développeurs OpenAI un accès plus rapide à la création d'agents : un canevas visuel dans Agent Builder, une interface utilisateur intégrable dans ChatKit, des connecteurs gouvernés dans le Registre des connecteurs et des mesures via Evals. À l'approche de fin 2026, Agent Builder et Evals sont retirés, de sorte que le pari durable pour les équipes d'ingénierie est le SDK Agents, accompagné de ChatKit et du Registre des connecteurs.

Quelle que soit la voie que vous empruntez, la fiabilité de votre agent dépend des API qu'il appelle. Maquettez-les tôt, assurez-vous de la conformité de leurs réponses et organisez vos clés. Apidog vous offre un seul endroit pour tester et maquettez chaque point d'extrémité d'outil dont votre agent dépend, afin que les intégrations tiennent bon lorsque l'agent les sollicite.