Antoine Laurent

Posted on Jun 25 • Originally published at apidog.com

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 OpenAI. Si vous construisez un agent en 2026, le point clé est le suivant : Agent Builder et Evals sont dépréciés, donc la voie durable est le SDK Agents. Ce guide explique quoi utiliser, quoi éviter, comment structurer un agent, et où des outils de test d’API comme Apidog s’intègrent quand votre agent appelle des services externes.

Essayez Apidog aujourd’hui

Qu’est-ce qu’AgentKit

OpenAI a introduit AgentKit lors de la DevDay le 6 octobre 2025. AgentKit n’est pas un produit unique : c’est un ensemble de composants autour de l’API OpenAI et du SDK OpenAI Agents, conçu pour passer plus vite de l’idée d’agent à un agent utilisable.

Avant AgentKit, créer un agent impliquait souvent de maintenir soi-même :

une logique d’orchestration ;
des connecteurs vers chaque source de données ;
des scripts d’évaluation ;
des prompts versionnés manuellement ;
une interface utilisateur de chat ;
des tests sur les API appelées par l’agent.

AgentKit a regroupé plusieurs réponses à ces problèmes : Agent Builder, ChatKit, le Registre des connecteurs et Evals.

Mais il y a un changement important : le 3 juin 2026, OpenAI a annoncé la fin d’Agent Builder et d’Evals. Si vous démarrez un nouveau projet, utilisez Agent Builder uniquement comme outil de prototypage, puis migrez vers le SDK Agents.

Les composants d’AgentKit

AgentKit comprend quatre composants principaux. Voici comment les utiliser et leur statut en 2026.

Agent Builder

Agent Builder est un canevas visuel pour concevoir des workflows d’agents multi-étapes.

Vous pouvez y :

ajouter des nœuds pour chaque étape ;
connecter les étapes dans un flux ;
prévisualiser les exécutions ;
publier des instantanés versionnés ;
exporter le workflow en Python ou TypeScript via l’onglet Agents SDK.

Pour un développeur, l’usage recommandé est simple :

prototypez rapidement le flux dans Agent Builder ;
exportez le code SDK ;
continuez le développement dans votre dépôt applicatif ;
versionnez, testez et déployez comme du code classique.

Attention : OpenAI déprécie Agent Builder. D’après la page de dépréciations, l’arrêt est prévu le 30 novembre 2026.

ChatKit

ChatKit est une interface de chat intégrable pour exposer un agent à vos utilisateurs sans construire toute l’UI vous-même.

Il sert à :

intégrer un composant de chat dans une application ;
connecter l’interface à un workflow publié ;
gérer les conversations ;
afficher les réponses en streaming ;
personnaliser le thème et le comportement.

ChatKit reste disponible. Si votre agent doit être utilisé via une interface conversationnelle, c’est le composant AgentKit le plus stable à utiliser côté produit.

Registre des connecteurs

Le Registre des connecteurs est un panneau d’administration pour gérer l’accès aux données et aux outils utilisés par les agents.

Il permet de centraliser :

des connecteurs pré-intégrés comme Dropbox, Google Drive, SharePoint ou Microsoft Teams ;
des serveurs MCP tiers ;
les autorisations disponibles pour les agents ;
la gouvernance des sources de données.

Si votre agent doit appeler des outils via le Model Context Protocol, consultez aussi ce guide sur les serveurs MCP et le SDK OpenAI Agents.

Evals et optimisation

Evals servait à mesurer la qualité des agents avec :

des jeux de données d’évaluation ;
la notation des traces ;
l’analyse des étapes d’exécution multi-agents ;
l’optimisation automatisée des prompts ;
l’évaluation avec des modèles tiers.

Mais Evals est aussi déprécié. Il devient en lecture seule pour les utilisateurs existants le 31 octobre 2026, puis s’arrête le 30 novembre 2026.

Pour un nouveau projet, évitez donc de dépendre d’Evals comme composant critique.

AgentKit vs SDK Agents

Le SDK Agents est la base à privilégier.

AgentKit fournit des composants autour de l’expérience agent, mais le SDK Agents est le framework de code où vous définissez réellement :

les agents ;
les outils ;
les transferts entre agents ;
les garde-fous ;
la logique d’exécution.

Couche	Rôle	Statut en 2026
SDK Agents	Framework de code pour définir les agents, outils et garde-fous	Actif, recommandé à long terme
Agent Builder	Canevas visuel qui exporte du code SDK Agents	Déprécié, arrêt le 30 novembre 2026
ChatKit	Interface de chat intégrable	Disponible
Registre des connecteurs	Administration des connecteurs et serveurs MCP	Disponible
Evals	Évaluation des traces et optimisation des prompts	Lecture seule le 31 octobre 2026, arrêt le 30 novembre 2026

La règle pratique :

si votre workflow doit vivre dans du code, utilisez le SDK Agents ;
si vous voulez prototyper vite, utilisez Agent Builder puis exportez ;
si vous voulez une interface utilisateur de chat, utilisez ChatKit ;
si votre agent accède à des sources internes ou à des outils MCP, utilisez le Registre des connecteurs.

À qui s’adresse AgentKit

AgentKit s’adresse principalement à trois profils.

Équipes produit

Elles peuvent utiliser ChatKit pour exposer rapidement une expérience agent aux utilisateurs.

Agent Builder peut encore servir au prototypage, mais il ne faut pas en faire une dépendance long terme.

Équipes plateforme ou entreprise

Elles utiliseront surtout le Registre des connecteurs pour contrôler l’accès aux outils et aux données internes.

C’est utile si vous devez gérer :

des sources de données multiples ;
des autorisations ;
des intégrations MCP ;
des contraintes de gouvernance.

Équipes engineering

Elles devraient commencer directement avec le SDK Agents.

C’est l’option la plus maintenable pour :

versionner le code ;
écrire des tests ;
déployer sur votre infrastructure ;
intégrer CI/CD ;
auditer les appels d’outils ;
gérer les secrets proprement.

Flux de construction recommandé

Voici un flux de travail concret pour construire un agent maintenable.

1. Définir la tâche de l’agent

Commencez par écrire clairement ce que l’agent doit faire.

Exemple :

L’agent aide le support client à retrouver les commandes récentes d’un utilisateur et à résumer leur état.

Listez ensuite les outils nécessaires :

recherche client ;
récupération des commandes ;
consultation du statut de livraison ;
création éventuelle d’un ticket support.

Chaque outil correspond souvent à une API HTTP.

2. Définir les outils

Un outil doit avoir un contrat clair : nom, description, paramètres et réponse attendue.

Exemple de définition JSON d’un outil :

{
  "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
  }
}

L’objectif est que le modèle sache :

quand appeler l’outil ;
quels arguments fournir ;
quelles contraintes respecter ;
quelles données attendre en retour.

3. Connecter l’outil à une vraie API

Quand le modèle appelle get_recent_orders, votre code reçoit les arguments, appelle votre API, puis retourne le résultat à l’agent.

Exemple d’appel HTTP :

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

Le point critique : l’agent dépend directement de la qualité de cette API.

Si l’API :

répond lentement ;
retourne un schéma inattendu ;
renvoie un 200 avec des champs incorrects ;
échoue de manière intermittente ;

alors l’agent peut produire une réponse incorrecte.

4. Ajouter des garde-fous

Ajoutez des garde-fous dès le début, pas après le premier incident.

Selon le cas, vous pouvez vérifier :

la présence de données personnelles ;
les tentatives d’évasion ;
les entrées malformées ;
les sorties non conformes ;
les appels d’outils non autorisés.

OpenAI propose une couche de garde-fous open-source et modulaire utilisable comme nœuds de workflow ou comme bibliothèque autonome.

5. Tester les APIs appelées par l’agent

C’est souvent l’étape la plus sous-estimée.

Un agent ne “répare” pas une mauvaise API. Il raisonne à partir de ce qu’elle renvoie.

Vous devez donc tester chaque endpoint utilisé comme outil :

statut HTTP attendu ;
schéma JSON ;
champs obligatoires ;
valeurs limites ;
erreurs prévues ;
latence ;
réponses vides ;
cas non autorisés.

6. Déployer

Deux options principales :

déployer l’interface conversationnelle avec ChatKit ;
exécuter le code SDK Agents dans votre propre infrastructure.

Dans les deux cas, gardez les appels d’outils observables et testables.

Exemple réaliste : un outil de récupération de commandes

Imaginons un agent support qui doit répondre à cette question :

“Peux-tu me dire où en est ma dernière commande ?”

Le flux minimal ressemble à ceci :

l’utilisateur pose une question ;
l’agent identifie le client ;
l’agent appelle get_recent_orders ;
l’agent lit la réponse ;
l’agent résume l’état de la commande.

Une réponse API attendue pourrait ressembler à ceci :

{
  "customer_id": "cus_8842",
  "orders": [
    {
      "order_id": "ord_10091",
      "status": "shipped",
      "carrier": "DHL",
      "tracking_number": "DHL123456789",
      "created_at": "2026-06-10T14:22:00Z"
    }
  ]
}

Votre agent peut alors générer une réponse utile :

Votre dernière commande a été expédiée avec DHL. Le numéro de suivi est DHL123456789.

Mais si l’API renvoie ceci :

{
  "id": "cus_8842",
  "items": [
    {
      "id": "ord_10091",
      "state": "sent"
    }
  ]
}

le contrat n’est plus le même. Le modèle peut mal interpréter state, ignorer le transporteur ou inventer une information absente.

C’est précisément ce type de dérive qu’il faut détecter avant la production.

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

Apidog n’est pas un framework d’agent. Il ne remplace pas AgentKit ni le SDK Agents.

Son rôle est de fiabiliser la couche API que votre agent utilise.

1. Maquetter les APIs avant qu’elles existent

Si l’équipe backend n’a pas encore livré l’API de commandes, vous pouvez mettre en place une API de maquette.

Cela permet de développer l’agent contre un contrat stable.

Vous pouvez simuler :

une commande trouvée ;
aucune commande ;
une erreur 404 ;
une erreur 500 ;
une réponse lente ;
un champ manquant ;
une pagination.

Votre agent peut donc être développé et testé sans attendre la disponibilité complète du backend.

2. Vérifier les contrats d’API

Un outil d’agent doit retourner exactement ce que l’agent attend.

Écrivez des cas de test d’API pour valider :

le code de statut ;
le type de contenu ;
les champs requis ;
les types de données ;
les valeurs critiques ;
les erreurs attendues.

Exemple de vérifications à automatiser :

GET /v1/customers/{customer_id}/orders

Attendu :
- status = 200
- response.orders est un tableau
- response.orders[0].order_id existe
- response.orders[0].status est une chaîne
- response.orders[0].created_at est une date ISO

L’intérêt est simple : si le contrat change, vous le voyez avant que l’agent ne raisonne sur des données incorrectes.

3. Gérer les environnements et les secrets

Les outils d’agent utilisent souvent des secrets :

ORDERS_API_KEY=...
CRM_API_KEY=...
SUPPORT_API_KEY=...

Évitez de les coller dans le code ou dans les prompts.

Gérez plutôt :

une URL de base par environnement ;
des clés par environnement ;
des variables séparées pour développement, staging et production ;
des collections d’endpoints testables isolément.

Vous pouvez télécharger Apidog et importer vos endpoints d’outils dans un projet pour les tester en dehors de l’exécution de l’agent.

4. Traiter chaque outil comme une API testable

La règle à appliquer :

Chaque outil appelé par un agent est une API. Chaque API doit avoir un contrat, des mocks et des tests.

Pour un guide plus détaillé, consultez comment tester les appels d’outils d’un agent IA.

Checklist d’implémentation

Avant de mettre un agent AgentKit ou SDK Agents en production, vérifiez les points suivants.

Architecture

[ ] Le workflow critique est dans le SDK Agents, pas uniquement dans Agent Builder.
[ ] Les outils sont définis avec des schémas explicites.
[ ] Les transferts entre agents sont documentés.
[ ] Les garde-fous sont activés pour les cas sensibles.
[ ] Les secrets ne sont pas codés en dur.

APIs d’outils

[ ] Chaque API appelée par l’agent a un contrat clair.
[ ] Les endpoints critiques ont des tests.
[ ] Les réponses vides sont testées.
[ ] Les erreurs 4xx et 5xx sont testées.
[ ] Les temps de réponse sont surveillés.
[ ] Les mocks existent pour les services non disponibles.

Déploiement

[ ] Les environnements dev, staging et production sont séparés.
[ ] Les clés API sont gérées par environnement.
[ ] Les appels d’outils sont journalisés.
[ ] Les erreurs d’outils sont remontées clairement.
[ ] L’interface utilisateur utilise ChatKit si une UI de chat est nécessaire.

Foire aux questions

OpenAI AgentKit est-il gratuit ?

AgentKit s’appuie sur votre utilisation de l’API OpenAI. Vous payez donc les jetons de modèle sous-jacents et les appels d’outils générés par votre agent.

Il n’y a pas de ligne d’abonnement AgentKit distincte mentionnée ici. Le coût principal dépend de l’usage du modèle et des APIs appelées. Vérifiez toujours les prix actuels sur la plateforme OpenAI.

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

Le SDK Agents est le framework de code pour définir les agents, outils, transferts et garde-fous.

AgentKit est l’ensemble plus large qui incluait Agent Builder, ChatKit, le Registre des connecteurs et Evals.

Avec la suppression progressive d’Agent Builder et d’Evals fin 2026, le SDK Agents est la voie durable pour les équipes engineering. Le guide du SDK Agents couvre cette approche de bout en bout.

Agent Builder va-t-il disparaître ?

Oui. OpenAI a annoncé le 3 juin 2026 la dépréciation d’Agent Builder et de la plateforme Evals.

Les deux seront arrêtés le 30 novembre 2026. Evals deviendra en lecture seule le 31 octobre 2026.

ChatKit reste disponible. Pour les workflows maintenables par des développeurs, OpenAI recommande de passer au SDK Agents.

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

Oui, et vous devriez le faire systématiquement.

Chaque outil appelé par un agent correspond à une requête et une réponse API. Vous pouvez :

maquetter les APIs pendant leur développement ;
vérifier que les réponses respectent le schéma attendu ;
tester les erreurs ;
gérer les clés par environnement ;
éviter que des changements backend cassent le comportement de l’agent.

Une plateforme comme Apidog permet de tester et maquetter ces APIs avant qu’elles n’impactent de vrais utilisateurs.

Conclusion

AgentKit a simplifié la création d’agents OpenAI avec Agent Builder, ChatKit, le Registre des connecteurs et Evals. Mais en 2026, Agent Builder et Evals sont en fin de vie. Pour un projet maintenable, construisez sur le SDK Agents, utilisez ChatKit si vous avez besoin d’une interface de chat, et gérez les connecteurs avec le Registre des connecteurs.

La fiabilité de votre agent dépend ensuite des APIs qu’il appelle. Maquettez-les tôt, testez leurs contrats, gérez les secrets proprement et surveillez les dérives. Apidog vous donne un espace unique pour tester, documenter et maquetter les endpoints dont votre agent dépend.

DEV Community