OpenAI a officiellement fixé la date d’arrêt de son Assistants API au 26 août 2026. Si votre logiciel utilise cette API, vous devrez migrer votre code avant cette date limite pour éviter toute interruption de fonctionnalités. L’annonce est apparue pour la première fois dans la liste des dépréciations de l’OpenAI API le 20 août 2025, bien qu’OpenAI n’ait pas précisé l’heure exacte de l’interruption définitive.
Comment fonctionne la nouvelle structure
Pour remplacer l’ancien système, OpenAI oriente les développeurs vers la Responses API et la Conversations API. Le guide officiel de migration d’Assistants détaille la façon dont les anciens éléments se traduisent :
- Les Assistants deviennent des prompts.
- Les Threads se transforment en
Conversations. - Les Runs deviennent des
Responses. - Les Run steps se transforment en éléments généraux.
Une réponse peut utiliser des éléments d’entrée directs ou un objet conversation. Ce changement ajoute du travail à votre backend. Le code de votre propre application doit désormais gérer l’orchestration, y compris le nettoyage de l’historique, les nouvelles tentatives de requêtes et les boucles d’appels d’outils.
Deux pièges à surveiller
Tout d’abord, OpenAI ne fournit aucun outil automatisé pour convertir les anciens Threads en nouvelles Conversations. Vous devez le faire vous-même. Le guide suggère d’acheminer d’abord les nouveaux échanges via la nouvelle API, puis de copier l’historique des anciennes conversations uniquement en cas de besoin.
Ensuite, la migration des prompts a sa propre date limite. Le guide mentionne des objets prompts, mais OpenAI prévient que les objets prompts réutilisables sont également en cours de dépréciation. Vous devriez vérifier ce calendrier avant de finaliser votre architecture.
Ce que la documentation ne prouve pas
Les documents d’OpenAI confirment la date d’arrêt et la nouvelle structure, mais ils ne garantissent pas une vitesse ou une tarification équivalentes. Personne en dehors de l’entreprise n’a vérifié la latence, le coût en tokens ou la qualité des résultats entre les deux systèmes. La documentation n’établit pas non plus de panne générale en direct sur l’ensemble des comptes ou des régions.
Comment tester votre migration
Commencez votre migration tôt. N’attendez pas la précipitation de dernière minute.
Commencez par répertorier chaque assistant, thread, run, outil personnalisé et chemin de fichier dans votre codebase. Ensuite, créez un flux de test à l’aide de la Responses API et de la Conversations API. Rejouez les conversations enregistrées et les appels d’outils en plusieurs étapes sur les deux systèmes. Comparez côte à côte la qualité des résultats, l’utilisation des tokens, la latence et la récupération d’erreurs. Gardez les deux voies observables jusqu’à ce que vous soyez certain que votre nouvelle application fonctionne de manière fiable.