AgentKit : que migrer avant l’arrêt des services OpenAI ?

OpenAI AgentKit réunissait les outils d’OpenAI pour créer, déployer et évaluer des agents. Son service Agent Builder doit fermer le 30 novembre 2026. L’Agents SDK et ChatKit restent disponibles, mais une application ChatKit qui s’appuie sur Agent Builder devra disposer de son propre backend de remplacement. Les évaluations existantes passeront en lecture seule le 31 octobre, avant l’arrêt prévu, le 30 novembre, du tableau de bord et de l’API Evals, ainsi que de l’API v1/prompts et de ses objets prompt réutilisables.

Informations vérifiées dans la documentation en ligne d’OpenAI le 14 octobre 2026. L’enjeu concret : préserver le workflow, ses prompts et les tests qui permettent de vérifier qu’il fonctionne toujours. Traitez ces éléments comme des chantiers de migration distincts, chacun avec son responsable. Le calendrier de retrait d’OpenAI fixe les dates ; la checklist ci-dessous les transforme en jalons de livraison.

AgentKit : ce qui s’arrête et ce qui reste disponible

L’outil de création hébergé ferme, mais les outils d’OpenAI pour développer des agents restent disponibles. AgentKit regroupait des outils de création, de déploiement et d’évaluation d’agents. OpenAI Agent Builder fournissait l’éditeur visuel de workflows, ChatKit l’interface de chat intégrée, et Evals l’environnement de test. La migration doit traiter chaque composant séparément.

Imaginez un espace de travail équipé : les locaux fournissent l’environnement dans lequel on conçoit et exécute le travail, tandis que le workflow décrit les tâches à accomplir. Si les locaux ferment, il faut trouver où poursuivre l’activité. Cela n’oblige ni à jeter tous les outils ni à changer de fournisseur de modèles.

Les dates de retrait proviennent de la page des dépréciations d’OpenAI. Les options d’exécution qui restent disponibles figurent dans sa présentation des agents. Ces retraits ont été annoncés le 3 juin 2026. Le passage en lecture seule en octobre et l’arrêt en novembre sont deux événements distincts.

Cette annonce ne déprécie pas Responses API. Une application qui utilise Responses peut toutefois être concernée si ses requêtes font référence à des objets prompt réutilisables. Le point de terminaison appelé et les ressources enregistrées dont il dépend sont deux choses différentes.

Qui doit agir dès maintenant ?

Il faut agir si un workflow en service dépend d’Agent Builder, du service managé Evals ou d’objets prompt enregistrés. La bonne destination dépend de l’environnement dans lequel le workflow doit fonctionner, pas du nom de produit qui ressemble le plus à l’ancien.

Équipes qui développent une application destinée aux clients : exportez le workflow et désignez un responsable de son exécution. Un chatbot d’assistance intégré à votre produit aura besoin d’un service applicatif opérationnel après la fermeture du workflow hébergé. Déplacer uniquement l’interface visuelle ne résout pas cette dépendance essentielle.

Équipes qui gèrent des processus internes : envisagez ChatGPT Workspace Agents si le travail peut être réalisé dans l’espace ChatGPT de l’entreprise. Une synthèse récurrente sur un compte client ou un assistant de recherche interne s’y prête mieux qu’une intégration sur un site public. Confiez l’évaluation du résultat au responsable du processus et la vérification des accès à l’administrateur de l’espace de travail.

Entreprises sur le point de lancer un projet : choisissez dès maintenant une solution qui restera disponible. Si une proposition commerciale repose sur Agent Builder, exigez de connaître l’environnement d’exécution après l’arrêt, le livrable de migration et les critères d’acceptation avant de valider la réalisation. Une démo fonctionnelle pendant la période de transition ne répond pas à ces questions.

Utilisateurs actuels du SDK ou de Responses en direct : vous n’avez peut-être aucune migration Builder à effectuer. Vérifiez votre chaîne d’évaluation et les références aux prompts enregistrés avant de conclure que l’application n’est pas concernée. En l’absence de ces dépendances également, cette annonce ne justifie pas à elle seule de réécrire l’application.

Exporter les workflows OpenAI Agent Builder vers l’Agents SDK

OpenAI Agent Builder exporte le code des workflows : un point de départ pour une application dont vous assurez l’exploitation. Son guide de migration actuel propose des exports Python et TypeScript. Conservez l’export complet avant toute modification pour pouvoir comparer les changements ultérieurs à l’original. Instructions de migration.

1. 1

   Copier l’export du workflow

   Ouvrez le workflow, sélectionnez Code dans la navigation supérieure, choisissez Agents SDK, puis Python ou TypeScript. Copiez l’export complet dans votre dépôt. Indiquez quel workflow déployé il remplace.

2. 2

   Rendre l’application exécutable

   Installez et configurez le SDK correspondant en suivant son guide de démarrage actuel. Raccordez les outils et les identifiants d’accès attendus par le workflow. Attribuez les responsabilités du déploiement, du stockage et de l’exécution avant de considérer l’export comme un service de remplacement.

3. 3

   Valider le comportement métier

   Rejouez des entrées représentatives sur la nouvelle implémentation. Vérifiez la branche choisie, les arguments transmis aux outils, la gestion des approbations et le résultat final. Ne déployez qu’une fois les critères d’acceptation du workflow satisfaits.

L’OpenAI Agents SDK exécute la boucle de l’agent tout en laissant à votre application le contrôle du déploiement, du stockage, des outils et des approbations. La présentation du SDK reste la référence pour l’implémentation.

La contrainte du SDK, c’est que l’exploitation vous revient. Copier un fichier ne met en place ni le déploiement en production, ni la gestion des redémarrages, ni la persistance de l’état. Pour un workflow d’assistance, définissez ce qui se passe lorsqu’une recherche de commande dépasse le délai imparti, lorsqu’une approbation est refusée ou lorsque la même requête arrive de nouveau. Ce sont des cas d’acceptation à implémenter et à vérifier, pas des garanties fournies par le bouton d’export.

Consultez le comparatif OpenAI Agents API et Agents SDK si vous réexaminez aussi la répartition des responsabilités d’exploitation. Le guide de migration actuel de Builder cite le SDK et Workspace Agents ; ne considérez pas l’Agents API managée, qui est un produit distinct, comme une destination d’import automatique.

Transférer les workflows no-code vers ChatGPT Workspace Agents

ChatGPT Workspace Agents est la voie documentée pour les workflows en langage naturel partagés au sein d’une équipe. Le guide de migration d’OpenAI exige un espace Business, Enterprise ou Edu avec accès aux agents et autorisation d’en créer. Exportez le workflow Builder, collez ce code dans l’outil de création d’agents de l’espace de travail et demandez-lui de recréer le workflow. Conditions requises pour migrer vers l’espace de travail.

Le guide pratique des agents d’espace de travail d’OpenAI illustre ce fonctionnement : applications connectées, instructions réutilisables, tâches planifiées et partage au sein d’un espace de travail. Ce modèle convient à un workflow interne de préparation de synthèses sur des comptes clients, dont le responsable peut examiner le résultat final.

La limite majeure est la fidélité du comportement. OpenAI avertit que les workflows exigeant un comportement fortement déterministe, où les mêmes conditions doivent toujours conduire au même parcours prescrit, risquent de ne pas être reproduits fidèlement. Vérifiez les connexions et les autorisations, utilisez Preview avec des entrées représentatives, puis sélectionnez Create après validation. Il s’agit de recréer le workflow, sans garantie de conversion de chacun de ses nœuds et de chacune de ses liaisons.

Un assistant de recherche interne peut, par exemple, suivre des pistes différentes tant que la synthèse finale répond aux exigences. En revanche, si un workflow doit systématiquement obtenir une approbation avant de modifier une fiche client, il faut vérifier explicitement le respect de cette règle. Si votre activité dépend d’un enchaînement exact des branches, je recommande de conserver cette logique dans le code applicatif et de valider d’abord la voie du SDK.

Conserver ChatKit et remplacer le backend hébergé

ChatKit reste utilisable comme interface de chat ; votre application doit fournir le serveur de remplacement qui l’alimente. OpenAI oriente les nouveaux projets et les applications déjà adossées à Builder vers une intégration avec un serveur personnalisé. Les workflows hébergés existants ne sont pris en charge que pendant la période de transition. Consignes de transition pour ChatKit.

C’est donc le fonctionnement derrière la fenêtre de chat qui change. Dans l’architecture qui reste disponible, le navigateur envoie ses requêtes à votre serveur ChatKit, celui-ci exécute votre implémentation de l’agent et ses outils, puis les résultats reviennent dans l’interface. Conserver la même expérience visuelle ne maintient pas l’ancien circuit d’exécution hébergé.

Le guide d’intégration avancée détaille les éléments à implémenter : un ChatKitServer, un point de terminaison HTTP, un stockage persistant pour les fils de conversation et les messages en production, un stockage de fichiers si vous autorisez les téléversements, ainsi qu’un contexte serveur pour l’identité et les autorisations. Il fournit également le raccordement à l’Agents SDK.

Pour une application d’assistance client, la recette doit aller au-delà de la simple réception d’une réponse. Vérifiez que le client connecté ne voit que la conversation prévue, que les pièces jointes restent utilisables là où c’est nécessaire, que les outils autorisés s’exécutent et que le transfert vers un autre niveau d’assistance arrive toujours au bon destinataire. Prévoyez le traitement de l’historique des conversations ; ne supposez pas qu’il accompagne l’export du workflow.

Le guide de création d’un chatbot avec ChatKit couvre plus largement les responsabilités liées au produit. Pour cette migration, la question décisive est de savoir si une véritable conversation aboutit via le backend de remplacement, dans le respect des règles d’accès et d’action attendues.

La checklist de migration, échéance par échéance

Sauvegardez d’abord le référentiel d’évaluation, puis migrez l’exécution et les prompts avant l’arrêt. Ce référentiel réunit les exemples et les résultats acceptables qui permettent de juger si le remplacement fonctionne. Sans lui, vous pouvez déplacer le code tout en perdant le comportement sur lequel vos utilisateurs comptent.

Avant le 31 octobre 2026 : exporter et sauvegarder les évaluations

Désignez dès maintenant un responsable des évaluations. Conservez les entrées de test, les résultats attendus, les définitions des évaluateurs, les versions des prompts, les paramètres des modèles et les résultats existants importants pour comprendre le comportement actuel. Exportez ce que votre workflow permet d’extraire ; lorsqu’aucun export n’est disponible, copiez la configuration et recréez-la hors de la plateforme.

Le 31 octobre marque le passage en lecture seule, pas une date limite d’export indiquée par la documentation. Terminer la sauvegarde avant cette date est ici une échéance de projet recommandée, afin de disposer d’un référentiel exploitable pendant la migration.

Le guide de migration d’Evals d’OpenAI recommande Promptfoo et décrit la recréation manuelle des prompts, des fournisseurs, des cas de test et des assertions. Cette démarche ne nécessite pas de fonction d’export d’OpenAI Evals. Exécutez de nouveau les évaluateurs recréés et validez-les avant de vous fier à leurs scores : OpenAI avertit que la notation peut varier d’un système à l’autre.

Un livrable utile associe une suite d’évaluation exécutable à une explication de ce qui constitue un échec. Une capture d’écran d’un ancien score apporte un élément d’historique, mais ne remplace pas cette suite.

Avant le 30 novembre 2026 : migrer les workflows et les objets prompt

Terminez les tâches suivantes avant l’arrêt prévu :

• Déployer le workflow exporté vers le SDK ou valider et créer son remplaçant sous forme de Workspace Agent.
• Basculer chaque application ChatKit adossée à Agent Builder sur le serveur de remplacement.
• Sortir le contenu des prompts réutilisables des objets prompt managés.
• Exécuter le nouveau processus d’évaluation et examiner les changements de comportement.
• Supprimer les dépendances de production aux services retirés et désigner un responsable du nouveau fonctionnement.

Les objets prompt méritent une recherche dédiée dans l’application. Un workflow peut s’exécuter correctement alors qu’une autre fonctionnalité dépend encore de l’identifiant d’un prompt enregistré. Le guide de migration des prompts d’OpenAI place le texte des prompts dans le code source, remplace les variables par des arguments de fonction et transmet les messages générés via le champ input de Responses API, à la place de l’objet prompt managé. Versionnez le prompt avec l’application et conservez, lorsque c’est possible, un préfixe commun stable avant les valeurs dynamiques.

Pour un assistant de facturation, le livrable comprend l’ensemble des instructions, les substitutions de variables et les réponses attendues dans des cas représentatifs. Copier uniquement le paragraphe visible en perdant une variable ou en choisissant la mauvaise version enregistrée ne constitue pas une migration complète.

Fixez votre propre date de bascule avant l’échéance du fournisseur, avec une marge pour analyser un test en échec. Conservez une solution de repli documentée pendant le reste de la transition ; une solution qui dépend toujours d’un service retiré ne vous protégera plus après sa fermeture.

Les raccourcis et les confusions à éviter

« AgentKit ferme » est une formule trop générale pour guider une décision technique. Les annonces visent des produits et des ressources enregistrées précis. Le SDK, ChatKit, Responses API et l’Agents API distincte conservent une documentation active ; les services hébergés concernés doivent faire l’objet d’une migration.

Un export ne prouve pas l’équivalence du comportement. Une implémentation de remplacement générée peut fournir une réponse convaincante tout en sautant la branche qui imposait une approbation. Comparez le comportement observable aux exigences d’origine, sans vous fier à la ressemblance du nouveau schéma ou du code.

Le maintien de ChatKit ne prolonge pas l’hébergement par Builder. L’interface peut rester en place alors que le service qui effectue le travail change. Prévoyez les moyens techniques nécessaires pour en assumer la responsabilité, sans présumer qu’il faut un nouveau frontend.

L’arrêt d’Evals ne supprime pas le besoin d’évaluer. Il déplace la responsabilité de la maintenance de vos tests. De même, intégrer un prompt au code ne retire pas Responses API : cela change la façon dont l’application lui fournit ses instructions.

Utiliser AgentKit aujourd’hui : les questions fréquentes

Le kit d’agents d’OpenAI est-il gratuit ?

Ne fondez pas une migration sur l’idée qu’AgentKit serait un produit unique et gratuit. Choisissez d’abord un environnement d’exécution qui reste disponible, puis vérifiez ses coûts actuels de modèles, d’outils et d’infrastructure. Les annonces d’arrêt ne fixent aucun tarif universel de migration.

Comment utiliser un agent OpenAI ?

Pour un workflow Agent Builder existant, exportez-le vers l’Agents SDK ou recréez-le sous forme de Workspace Agent. Pour une nouvelle application, choisissez un environnement d’exécution actuel et testez les outils et les autorisations nécessaires à votre tâche. Une interface ChatKit exige une implémentation côté serveur.

Que peut-on faire avec les agents OpenAI ?

Les agents peuvent utiliser des outils et accomplir des tâches en plusieurs étapes. Une migration utile part du travail précis dont vous dépendez déjà, comme préparer une synthèse interne ou répondre à une demande d’assistance authentifiée, puis préserve le comportement requis dans le nouvel environnement d’exécution.

Dès lundi, commencer par un workflow réel

Désignez un responsable de la migration et choisissez un workflow représentatif en service. Sauvegardez son export, le contenu de ses prompts et son référentiel d’évaluation, puis faites fonctionner une solution de remplacement de bout en bout. Utilisez le résultat pour estimer le travail restant sur les autres workflows. Le premier livrable doit prouver qu’une tâche nécessaire s’accomplit avec les bonnes autorisations et les résultats attendus, puis être suivi d’un calendrier de migration pour le reste.

Pour recevoir des conseils pratiques sur la création et l’exploitation de workflows d’IA, abonnez-vous à la newsletter.