Ce qu’OpenAI a annoncé, et quand
Dans sa page consacrée aux dépréciations, OpenAI indique avoir prévenu les développeurs utilisant la Videos API et les modèles Sora 2 le 24 mars 2026. La date du 24 septembre correspond à leur retrait annoncé de l’API, six mois plus tard. Il serait donc inexact de présenter cette décision comme une annonce surprise faite aujourd’hui. La nouveauté pour les équipes concernées est l’arrivée de l’échéance.
Une dépréciation désigne d’abord une période durant laquelle un accès reste documenté mais doit être abandonné. Une date de retrait marque la fin prévue de cette période. La documentation d’OpenAI donne la date, sans publier dans ce tableau une heure précise ni un compte rendu de test confirmant l’état de chaque point d’accès à la minute près. Un responsable technique doit donc traiter le retrait comme effectif pour sa planification, puis vérifier les réponses réelles de son application.
La liste exacte des accès concernés
La page officielle cite six entrées : la Videos API elle-même, deux alias de modèles et trois versions datées. Les voici :
Videos API;sora-2;sora-2-pro;sora-2-2025-10-06;sora-2-2025-12-08;sora-2-pro-2025-10-06.
Un alias comme sora-2 est un nom pratique utilisé dans une requête. Une version datée désigne une variante explicitement épinglée à un instant du développement du modèle. Les deux peuvent se cacher à des endroits différents d’un projet : code source, configuration du serveur, bibliothèque interne ou paramètres saisis dans une interface d’administration. Source : tableau OpenAI.
La colonne « remplacement recommandé » contient un tiret pour chacune de ces six entrées. Cela signifie que cette page ne propose pas de substitut direct. Cela ne prouve pas qu’aucune autre technologie de génération vidéo n’existe ; cela signifie seulement qu’OpenAI n’en recommande pas une dans le calendrier de retrait consulté.
Pourquoi la Videos API compte au-delà du nom d’un modèle
Une application vidéo n’appelle pas seulement un modèle pour obtenir un fichier immédiatement. Elle peut créer une tâche de génération, attendre son traitement, consulter son statut, récupérer un fichier, l’enregistrer et prévenir un utilisateur. Le retrait de l’API touche potentiellement cette chaîne entière. La documentation de l’API vidéo affiche elle-même un avertissement sur l’arrêt prévu au 24 septembre 2026.
Prenons un exemple : un service reçoit une demande de clip depuis son site, transmet le prompt à OpenAI, puis affiche « votre vidéo sera prête dans quelques minutes ». Si l’appel de création échoue, il doit empêcher la facturation d’une génération inexistante. Si l’échec survient au moment de consulter l’état d’une tâche ancienne, il doit distinguer ce cas d’un simple retard. Si un fichier déjà produit doit encore être récupéré, il faut connaître la politique de conservation de l’application et ses propres sauvegardes.
Ces conséquences sont des scénarios d’intégration, pas une liste d’incidents observés sur les serveurs d’OpenAI le 24 septembre. Elles montrent pourquoi le bon réflexe consiste à auditer le parcours complet, au lieu de chercher uniquement le nom sora-2 dans le code.
Ce que cette annonce ne dit pas sur Sora grand public
Le calendrier vise les accès utilisés par les développeurs. Il ne constitue pas une annonce générale sur la disponibilité de Sora dans une application, dans ChatGPT ou sur un site grand public. Les modalités de chaque interface peuvent relever d’autres annonces ou conditions d’accès. Écrire « Sora est arrêté partout » irait donc au-delà de la source officielle consultée.
De même, la page de dépréciation ne précise pas de situation particulière pour la France, ni de nouveau prix pour un autre service vidéo. Le sujet de cet article est le retrait programmé de l’API et des cinq identifiants listés. Les lecteurs qui utilisent uniquement une interface grand public doivent se référer aux informations publiées pour cette interface.
Les vérifications utiles pour un produit en production
La première étape est un inventaire. Il faut repérer les six références dans le code, les variables d’environnement, les paramètres stockés en base, les automatisations et les modèles utilisés par des clients différents. Une équipe peut croire avoir migré son application principale tout en conservant un traitement vidéo ancien dans une tâche planifiée.
La deuxième étape concerne les tâches en cours. Les journaux doivent permettre de savoir quelles demandes ont été envoyées, lesquelles ont abouti, quels fichiers ont été récupérés et quels utilisateurs attendent encore un résultat. Cette visibilité sert à éviter des promesses non tenues ou des doublons de facturation.
La troisième étape est la gestion des erreurs. L’interface doit expliquer qu’une génération ne peut plus être lancée si l’accès échoue, au lieu de laisser tourner un indicateur de chargement. Les reprises automatiques doivent être bornées : réessayer indéfiniment un point d’accès retiré ne produira pas de vidéo et peut créer des traitements inutiles.
Enfin, il faut décider du plan de continuité : suspendre la fonction, conserver les vidéos déjà générées, ou préparer une autre solution après vérification de ses formats, de ses droits d’usage, de ses délais et de ses coûts. Un modèle portant un nom proche de Sora 2 n’est pas forcément compatible avec les mêmes paramètres ou le même parcours utilisateur.
Pourquoi il n’existe pas de migration « en un clic » dans ce document
Quand OpenAI retire certains modèles, sa documentation indique parfois un modèle de remplacement. Pour la Videos API et les références Sora 2, la case correspondante est vide. Une migration suppose donc un choix de produit et des tests spécifiques. Même si un fournisseur propose une autre API vidéo, il faut comparer la qualité des résultats, les formats, les durées, la modération, les délais et la disponibilité par pays avant de modifier une application destinée à des utilisateurs.
Cette situation rappelle un principe d’architecture utile : centraliser l’accès à un service extérieur. Quand la création, le suivi et le téléchargement des vidéos passent par une couche unique de l’application, il est plus simple de désactiver proprement la fonction ou de brancher une autre solution. Si les appels sont dispersés, le retrait d’une API se transforme en recherche manuelle dans tout le produit.
Comment informer les utilisateurs concernés
Pour une application destinée au public, une migration technique a aussi une dimension éditoriale. Les utilisateurs doivent savoir si de nouvelles demandes de vidéos sont encore acceptées, si leurs créations déjà produites restent disponibles dans le service et si une commande payée mais non achevée peut être remboursée ou relancée. La réponse dépend des règles du produit concerné, pas du seul calendrier d’OpenAI.
Il est préférable d’afficher un état clair au moment de la demande plutôt que d’attendre l’échec silencieux d’une tâche en arrière-plan. Une formulation précise pourrait indiquer que la génération vidéo via cette intégration est temporairement indisponible, sans suggérer que Sora aurait disparu de tous les services. Les entreprises qui ont promis une date de livraison doivent également distinguer les vidéos terminées, les tâches encore en traitement et celles qui n’ont jamais démarré.
Un autre point mérite attention : les contenus déjà générés. La page de dépréciation ne dit pas que les fichiers enregistrés par une application doivent être supprimés. Leur conservation relève du stockage choisi par l’application et de ses conditions d’utilisation. Avant de couper une intégration, il faut donc vérifier où résident les fichiers finaux et quelles métadonnées seront nécessaires pour les retrouver.
Ce qui reste à surveiller après le 24 septembre
La documentation peut évoluer. Une nouvelle solution de migration, des précisions sur la disponibilité d’un autre service ou des détails sur le comportement de l’API après la date indiquée pourraient être publiés ultérieurement. À la clôture de cet article, la page officielle consultée ne contient pas de remplacement recommandé pour les six entrées concernées.
Une vérification réelle doit se faire dans les journaux d’une application autorisée à utiliser l’API. L’absence de test en direct dans cet article interdit d’affirmer qu’une requête donnée a échoué à une heure précise. Le message utile pour les équipes reste le même : documenter la dépendance, préparer les erreurs et adapter le service dès que son état est confirmé.
Notre analyse
L’information est avant tout opérationnelle. OpenAI a fixé une date claire pour le retrait de la Videos API et des cinq références Sora 2, mais sans détailler dans le calendrier un remplacement direct ni une heure de coupure. Les équipes concernées doivent vérifier leurs dépendances et protéger leurs utilisateurs contre des tâches qui échoueraient. Pour le public général, il faut garder la formulation limitée à l’API : cette page de documentation ne suffit pas à raconter l’avenir de toutes les expériences Sora.