OpenAI prévoit de retirer l’API Sora le 24 septembre 2026 : les vérifications à effectuer par les équipes

La date annoncée et les composants concernés

La documentation d’OpenAI sur les dépréciations fixe au 24 septembre 2026 la date de retrait de Videos API, ainsi que des modèles sora-2 et sora-2-pro et des snapshots répertoriés sur cette page. La colonne consacrée aux remplacements ne mentionne aucune solution de remplacement. Au vu des informations officielles disponibles, les équipes ne devraient donc pas planifier leurs opérations en partant du principe qu’une migration automatique, une prolongation du délai ou un modèle de remplacement compatible sera proposé.

La date indiquée correspond à un calendrier publié. Elle ne confirme ni que le service est déjà désactivé ni le comportement exact qu’il adoptera à cette échéance. Le guide de génération vidéo décrit actuellement un processus dans lequel les tâches sont créées de façon asynchrone, leur état est consulté, puis le fichier obtenu est téléchargé. La référence de consultation décrit également les métadonnées d’une tâche, dont le champ expires_at pour les ressources téléchargeables. Aucune de ces descriptions ne précise ce qu’il adviendra des nouvelles requêtes, des tâches en cours ou des métadonnées une fois la date de retrait atteinte.

En pratique, il faut distinguer deux objectifs : préparer la continuité du produit et préserver les ressources internes déjà disponibles. Enregistrer une vidéo téléchargée peut conserver ce fichier, mais ne permet pas, à lui seul, de continuer à en générer d’autres par l’intermédiaire de l’intégration. À l’inverse, le fait qu’une application conserve une référence ou un identifiant de tâche ne prouve pas que la ressource restera récupérable.

Ne pas confondre l’API avec l’application ou le site web

Videos API est une interface qui permet aux applications et aux processus de production d’effectuer, par programmation, des opérations de génération et de récupération de vidéos. Le guide technique décrit la création d’une tâche, la consultation de son état et le téléchargement de son contenu. Cela permet d’identifier des dépendances logicielles précises : appels à l’API, traitement des réponses et composants qui s’attendent à recevoir une vidéo ou à consulter ses métadonnées.

Le retrait d’une API ne doit pas être présenté automatiquement comme la fermeture d’une application ou d’un site web destiné aux utilisateurs. Il s’agit de canaux différents, susceptibles d’avoir des calendriers, des conditions et des outils d’exportation distincts. Toutefois, les sources vérifiées pour cet article documentent l’API et ne précisent pas quand l’application et le site web Sora ont fermé, ni même s’ils ont fermé. Elles ne fournissent pas non plus d’instructions d’exportation ou de suppression pour ces produits. Il n’est donc pas possible d’utiliser ici des informations d’exportation relatives à l’application pour conclure ce qu’il adviendra des données ou des ressources créées par l’intermédiaire de l’API.

Cette distinction est importante pour les équipes qui utilisent plusieurs canaux. Une bibliothèque de vidéos téléchargées depuis l’API, un compte utilisateur dans une application et un système de production connecté par API peuvent impliquer des ressources et des dépendances différentes. Il faut vérifier les instructions officielles propres à chaque canal ; les sources disponibles ne permettent pas de regrouper ces situations dans une politique unique de conservation.

Vérifications à effectuer sur une intégration avant l’échéance

La première étape consiste à repérer toutes les dépendances, et pas seulement le point où une génération est demandée. Dans le guide technique, la création utilise POST /videos, la consultation de l’état utilise GET /videos/{video_id} et la récupération du fichier s’effectue avec GET /videos/{video_id}/content. Ces noms peuvent servir de termes de recherche dans le code, la configuration, les journaux, les tâches planifiées et les services tiers susceptibles de masquer l’appel direct.

Il est ensuite utile de documenter les éléments du produit qui dépendent de chaque opération. Par exemple, une requête peut lancer un processus de montage, attendre la fin d’une tâche, puis envoyer le fichier vers un système de stockage ou de validation. Si un appel devient indisponible, la défaillance peut se propager aux composants en aval, même si la documentation fournie ne précise ni le code de réponse ni le comportement du service après sa désactivation. La bonne approche consiste à tester la gestion des erreurs et à prévoir un mode de fonctionnement dégradé, plutôt qu’à affirmer d’avance comment le fournisseur répondra.

Les équipes devraient également distinguer les ressources déjà présentes dans leur propre stockage de celles qui ne peuvent être récupérées qu’au moyen de l’API. Pour chaque vidéo téléchargée, elles peuvent conserver le fichier et les métadonnées nécessaires pour en identifier l’usage, sous réserve de leurs exigences internes et des droits applicables. Pour les ressources dont la récupération dépend encore d’une opération via l’API, la documentation examinée ne garantit pas que cette opération restera disponible après la date indiquée.

Exemple d’inventaire et de réponse opérationnelle

Imaginons un service interne qui reçoit des demandes de vidéos, enregistre l’identifiant de la tâche, consulte régulièrement son état puis, une fois celle-ci terminée, télécharge le contenu pour l’envoyer à un système de validation. L’inventaire devrait consigner séparément chaque opération et chaque destination en aval. L’équipe pourra ainsi savoir si elle dépend de la création de nouvelles vidéos, de la consultation de tâches déjà lancées, du téléchargement de fichiers ou de ces trois opérations.

Si l’équipe ne conserve que l’identifiant de la tâche, elle ne possède pas nécessairement une copie locale de la vidéo. Si elle conserve le fichier téléchargé, elle peut préserver cette ressource dans son propre stockage ; cela ne signifie toutefois pas que la génération restera disponible et ne garantit pas la durée pendant laquelle les métadonnées resteront accessibles dans le service. La référence mentionne expires_at comme donnée associée aux ressources téléchargeables, mais la source n’explique pas comment ce champ s’appliquerait après le retrait.

Un test de désactivation contrôlée pourrait simuler des réponses en échec ou une indisponibilité dans un environnement de test, puis vérifier que la file d’attente ne relance pas les requêtes indéfiniment, que les utilisateurs reçoivent un état compréhensible et que les processus en aval ne marquent pas une tâche comme terminée en l’absence de fichier. Il s’agit d’une recommandation d’ingénierie, et non d’une prédiction sur la réponse précise de l’API. La documentation fournie ne précise pas cette réponse.

La migration n’est toujours pas définie

Le tableau des dépréciations n’indique aucun remplacement pour les composants concernés. Cela ne prouve pas qu’il n’existe pas d’autres outils de génération vidéo, mais signifie qu’au vu des sources examinées, rien ne permet de recommander une solution comme remplacement officiel ou compatible. Avant de choisir une autre solution, les responsables devraient vérifier les opérations qu’elle propose, la gestion des tâches, les formats produits, ses conditions, ainsi que sa conformité aux exigences de sécurité, de coût, de qualité et d’intégration.

Ces sources ne permettent pas non plus d’affirmer ce qu’il adviendra des tâches en attente le 24 septembre 2026, si les métadonnées resteront visibles et pendant combien de temps, ni si des exceptions ou des changements de calendrier seront annoncés. La référence technique indique la date prévue, mais ne détaille pas les conséquences opérationnelles de cette échéance. Si OpenAI publie des mises à jour, il faudra les consulter avant de prendre des décisions irréversibles.

Pour prendre une décision concernant le service, le plus prudent est de séparer ce que l’équipe peut contrôler de ce qui dépend du fournisseur. L’équipe peut repérer les appels, réduire les nouvelles dépendances, sauvegarder les ressources auxquelles elle a déjà accès, consigner ses propres métadonnées et tester le comportement de ses systèmes en cas d’erreur. Ces mesures ne permettent pas de déduire que le point de terminaison restera disponible, que les ressources distantes seront conservées ou qu’une prolongation sera accordée. Il est utile de désigner des responsables et des échéances internes pour chaque tâche, puis de vérifier la documentation officielle à l’approche du changement.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.