Assistants API : où aller, sans note

L'Assistants API n'a plus d'alternative à choisir dans un catalogue : OpenAI l'a arrêtée le 26 août 2026. La documentation demande d'utiliser Responses pour les nouvelles intégrations. Cette page est donc un guide de migration, puis un choix d'architecture entre les surfaces OpenAI actuelles. Aucun appel API ni export n'a été exécuté. Prix : non relevés.

Ce qui a disparu

Le guide officiel remplace les objets de l'ancienne API ainsi :

Avant	Maintenant	Point à porter
Assistants	Prompts	Modèle, instructions et outils
Threads	Conversations	Messages, appels d'outils et sorties deviennent des items
Runs	Responses	La boucle d'outils est gérée explicitement
Run steps	Items	Messages et événements partagent un format plus général

Cette correspondance aide à lire l'ancien code. Elle ne garantit pas une migration automatique.

Le point de départ imposé : Responses API

Pour une nouvelle intégration, le guide Assistants renvoie vers Responses. L'application envoie des items et reçoit des items. Elle peut gérer l'historique elle-même, chaîner des réponses ou utiliser Conversations.

Un ancien appel qui listait les messages d'un thread ne fonctionne plus. Après l'arrêt, la migration repart donc des messages déjà conservés par l'application. Si cet historique n'existe pas dans votre stockage, la documentation ne donne pas de moyen de le récupérer par l'ancien endpoint.

Les choix d'architecture autour de Responses

Responses API directe

Ce chemin convient si l'application possède la boucle, l'exécution des outils et l'état. Il demande le plus de code d'intégration parmi les options comparées par OpenAI. Les outils hébergés et les fonctions de l'application peuvent être combinés, mais leurs permissions restent à concevoir.

Agents SDK

L'Agents SDK tourne dans l'application et fournit agents, outils, handoffs, garde-fous, sessions et boucle d'exécution. Il convient si l'équipe veut garder déploiement, stockage et approbations dans son runtime sans tout écrire autour de Responses.

Agents API

L'Agents API exécute un harness Codex géré par OpenAI et conserve sessions, tours et items. C'est un autre contrat d'exploitation : OpenAI gère davantage l'infrastructure et l'état de progression. Ce choix ne remplace pas Responses par un simple renommage.

ChatKit

ChatKit est le point de départ documenté pour intégrer un chat. Il traite l'interface embarquée, pas la migration des anciens threads à lui seul.

Prompts : une étape transitoire à vérifier

Le guide Assistants associe les anciens Assistants à des Prompts créés dans le dashboard. La page de dépréciations annonce toutefois l'arrêt de l'API v1/prompts et des objets de prompt réutilisables au 30 novembre 2026. Pour une intégration destinée à durer au-delà de cette date, recopier toute la configuration dans un nouvel objet bientôt arrêté crée une seconde migration.

La documentation demande de déplacer le contenu des prompts réutilisables dans le code. Il faut donc distinguer le geste de reprise décrit par le guide Assistants et l'architecture cible après le 30 novembre 2026.

Agent Builder et Workspace Agents

Le guide de migration Agent Builder propose deux chemins : exporter vers l'Agents SDK, ou recréer le workflow comme Workspace Agent dans ChatGPT. Il précise que l'export ne convertit pas le graphe et ne garantit pas le transfert de chaque comportement.

Les Workspace Agents exigent un espace ChatGPT Business, Enterprise ou Edu avec les droits nécessaires. Ils conviennent au partage dans un espace ChatGPT. L'Agents SDK convient au code d'une application déployée par l'équipe. Ce sont deux destinations différentes.

Migration par étapes

Repérez tous les appels à assistants, threads, messages, runs et run steps.
Inventoriez les instructions, outils, fichiers, métadonnées et états que l'application stocke déjà.
Choisissez où la boucle doit vivre : code avec Responses, runtime Agents SDK, ou harness géré via Agents API.
Transformez les nouveaux échanges en items et définissez le stockage des Conversations.
Portez les appels d'outils avec validation des arguments, délais, erreurs et idempotence.
Testez un échantillon représentatif contre les résultats attendus de l'ancienne intégration.
Retirez les objets Prompts réutilisables avant leur date d'arrêt si votre migration les a utilisés comme pont.
Supprimez le code mort seulement après vérification des nouveaux parcours.

Ces étapes n'ont pas été exécutées sur un projet. Elles traduisent les dépendances citées dans les guides officiels.

Cas qui demandent une décision distincte

Un chat SaaS doit décider qui garde l'historique et comment un utilisateur retrouve sa conversation.
Une équipe doit choisir entre un agent partagé dans ChatGPT et un runtime livré dans son application.
Un workflow déterministe peut mal migrer vers un Workspace Agent ; OpenAI demande de revoir contrôle, déclencheurs, outils et permissions.
Un framework externe comme LangGraph ou CrewAI reste un choix d'architecture hors du chemin de migration OpenAI. Voir LangGraph, CrewAI et Agents SDK.

Aucun ordre de performance n'est proposé. La bonne destination dépend de l'endroit où doivent vivre l'état, les outils et l'exécution.

Sources

Sources officielles consultées le 2026-10-18 et revérifiées le 2026-10-19 :