Sora 2 Pro dans les benchmarks vidéo : ce qu’une préférence à l’aveugle mesure — et ce qu’elle ne dit pas

Un score vidéo ne vaut pas évaluation complète

Dire que Sora 2 Pro « donne de bons résultats » dans un benchmark peut recouvrir des constats différents. Cela peut signifier que des personnes ont préféré ses clips lors d’une comparaison par paires, qu’il a obtenu un score élevé sur une dimension mesurée automatiquement ou qu’il a mieux satisfait un ensemble de consignes. Ces conclusions ne sont pas interchangeables : chacune dépend de ce qui a été mesuré, des échantillons utilisés et des conditions de l’évaluation.

Cette distinction est importante, car un classement agrégé peut résumer une préférence générale sans nécessairement diagnostiquer la propriété de la vidéo qui l’a suscitée. Un clip peut séduire davantage lors d’un vote tout en comportant des erreurs de continuité, en omettant des éléments du prompt ou en synchronisant mal le son. Pour attribuer une qualité précise au modèle, il faut consulter la tâche et la métrique correspondantes, plutôt que de la déduire de sa place dans un classement.

Les sources disponibles permettent de décrire la méthodologie de plusieurs évaluations, certaines données publiées par une arène ainsi que les options de l’API Sora. Elles ne démontrent pas que Sora 2 Pro a été évalué dans les benchmarks VBench ou Video-Bench. Ces travaux servent ici à expliquer les dimensions qu’un benchmark peut distinguer ; ils ne doivent pas être présentés comme des résultats obtenus par le modèle.

Commencer par identifier le système évalué

La seule mention de « Sora 2 Pro » ne suffit pas à décrire une expérience. Un compte rendu utile devrait préciser la variante identifiée, le canal d’accès et la date de génération. Il devrait aussi indiquer si les échantillons ont été obtenus par l’API ou par une autre interface, quelles options étaient disponibles et si un traitement a été effectué après la génération. Sans ces informations, il est impossible d’attribuer avec assurance une différence au seul modèle.

La documentation d’OpenAI identifie sora-2-pro et décrit des paramètres tels que la taille et la durée, ainsi que la possibilité d’utiliser une image de référence. Cela permet de poser des questions concrètes à propos d’un résultat : la génération était-elle du texte vers la vidéo ou de l’image vers la vidéo ? Quelle taille a été demandée ? Quelle était la durée ? De l’audio a-t-il été généré ? Le fait qu’une option soit documentée ne prouve pas qu’elle ait été activée dans un benchmark donné : le protocole doit le préciser.

Il est également utile de consigner la date, car les systèmes, les interfaces et les conditions d’accès peuvent évoluer. L’historique des modifications d’Arena documente l’ajout de Sora 2 et de Sora 2 Pro à son classement de génération vidéo à partir de texte. Mais la date d’ajout ne décrit pas à elle seule tous les détails de génération et ne garantit pas que les résultats de différentes périodes soient directement comparables.

Ce qu’apporte une arène de préférences

Une arène fondée sur les préférences présente généralement des sorties afin qu’une personne indique celle qu’elle préfère, sans que le nom du système ne détermine délibérément sa réponse. Lors d’une comparaison à l’aveugle, le choix fournit des indications sur les préférences dans ce format : quel clip a été le plus apprécié par les personnes participantes parmi les échantillons qu’elles ont vus. C’est un signal pertinent de la perception humaine, mais son interprétation doit rester dans ces limites.

Le classement de génération vidéo à partir de texte d’Arena affiche Sora 2 Pro avec un score et un intervalle, ainsi qu’une date de référence indiquée sur la page. La manière prudente de communiquer cette donnée consiste à l’attribuer à ce classement et à cet instantané, et non à la présenter comme une mesure universelle de la qualité. Selon la méthode de la plateforme, l’intervalle exprime l’incertitude de l’estimation ; il ne faut ni l’omettre ni le transformer en garantie qu’un système sera supérieur pour tous les prompts.

La méthode de classement d’Arena explique le calcul des scores ainsi que le traitement de l’incertitude et des rangs. Pour évaluer la solidité d’une affirmation, il faut néanmoins examiner quelles comparaisons ont été prises en compte, comment elles ont été attribuées, combien d’observations étayent le résultat et quels types de prompts ont été représentés. Si la page consultée ne donne pas tous ces détails, il ne faut pas les remplacer par des conjectures.

Une préférence exprimée à l’aveugle ne révèle pas non plus, à elle seule, la raison du choix. Les participants peuvent privilégier la composition, le style, la lisibilité du mouvement ou l’adéquation apparente au prompt, et ces facteurs peuvent se combiner. Un vote n’équivaut pas automatiquement à une grille d’évaluation du suivi des instructions, de la continuité temporelle ou de la synchronisation audiovisuelle.

Pourquoi les benchmarks doivent distinguer plusieurs dimensions

Les benchmarks conçus autour de tâches ou de dimensions explicites permettent de préciser l’aspect évalué. VBench, par exemple, répartit l’évaluation des modèles de génération vidéo entre plusieurs dimensions, notamment la cohérence, le scintillement temporel et la fluidité du mouvement. Video-Bench se présente comme un benchmark aligné sur les jugements humains. Ces dispositifs illustrent des solutions autres que la réduction de l’évaluation à une préférence globale unique, mais ils ne prouvent pas que Sora 2 Pro y ait obtenu un résultat particulier.

La séparation des dimensions présente un intérêt diagnostique. Si une évaluation met en évidence une faiblesse de cohérence temporelle, cela ne signifie pas nécessairement que la qualité visuelle globale est faible. À l’inverse, un bon résultat sur une dimension visuelle ne prouve pas que le modèle respecte tous les détails d’une consigne. Les mesures doivent être interprétées en fonction de la définition et de la procédure du benchmark ; un score automatique ne doit pas être assimilé sans précaution à une appréciation humaine.

La comparaison avec une arène peut être complémentaire. Un test de préférence résume quelle sortie est choisie selon un protocole donné, tandis qu’une batterie de tests par dimension cherche à décrire des propriétés distinctes. Aucun de ces formats ne suffit à répondre à toutes les questions : le premier ne fournit pas automatiquement un diagnostic causal et le second ne reflète pas nécessairement les clips que les personnes préfèrent dans une situation d’utilisation donnée.

Comparabilité : prompts, générations et sélection des clips

Deux résultats ne sont comparables que si l’on sait quelles conditions ils ont en commun. La modalité d’entrée constitue une première différence : générer une vidéo à partir d’un texte n’est pas exactement la même tâche qu’animer une image de référence. Il faut également tenir compte de la durée et de la taille demandées, de la présence ou de l’absence d’audio et des contraintes appliquées à chaque système. La documentation d’une interface peut confirmer les paramètres qu’elle accepte, mais pas ceux utilisés par une expérience donnée.

Le prompt fait partie du protocole ; ce n’est pas un simple détail rédactionnel. Un ensemble de consignes simples, une liste de scènes complexes et un corpus exigeant des actions dans un ordre précis peuvent produire des profils différents. Si le benchmark ne publie pas ou ne décrit pas ses entrées, il devient plus difficile de comprendre ce que couvre l’échantillon et de reproduire le test.

Le nombre de générations par prompt et la règle de sélection sont particulièrement importants. Si plusieurs sorties sont créées puis qu’une seule est publiée parmi elles, le résultat mesure aussi le processus de sélection, et pas uniquement une génération individuelle. Pour établir une comparaison équitable, il faut préciser si la première sortie a été présentée, si une sortie a été sélectionnée selon une règle établie à l’avance ou si l’échantillon a été obtenu autrement. Les sources fournies n’établissent pas de règle unique applicable à toutes les évaluations de Sora 2 Pro ; ce point doit être vérifié au cas par cas.

L’évaluation humaine peut elle aussi varier : qui vote, quelles consignes sont données et quels éléments sont visibles. Si de l’audio est inclus, il faut préciser si le vote tient compte du son ou seulement de l’image. Si des évaluateurs automatiques sont utilisés, le compte rendu devrait indiquer ce qu’ils évaluent et comment leur emploi a été validé. Sans ces informations, un chiffre peut rester informatif en tant que résultat publié, mais sa portée est plus étroite.

Limites d’attribution : modèle, interface et configuration

Une évaluation n’observe pas un modèle abstrait : elle observe des sorties obtenues au moyen d’un système et dans des conditions concrètes. Le résultat peut dépendre de la variante, des paramètres, du mode d’accès, de la politique de génération et de toute sélection ou tout traitement ultérieurs. Lorsque des services dotés d’interfaces différentes sont comparés, une différence ne permet pas d’isoler automatiquement l’effet du modèle.

Dans la rédaction, il est donc utile de distinguer trois niveaux : le résultat observé (« ces échantillons ont reçu ces préférences »), l’interprétation compatible avec les données (« dans ce test et ces conditions, une sortie a été choisie plus souvent ») et l’affirmation générale (« le système est meilleur »). Ce troisième niveau exige davantage de preuves que les deux premiers : des tâches variées, des conditions comparables et des résultats qui étayent précisément la propriété attribuée.

Les dépôts de VBench et les travaux de Video-Bench fournissent des repères méthodologiques pour comprendre les évaluations multidimensionnelles et les éléments qui les accompagnent. Le dépôt VBench rassemble du code, des prompts, des dimensions, des consignes d’évaluation et des liens vers des vidéos et des configurations. L’existence de matériel reproductible pour ce projet ne signifie pas que les prompts, les générations ou la configuration d’une évaluation d’Arena soient disponibles. La reproductibilité doit être vérifiée séparément pour chaque résultat.

Reproductibilité après la fermeture de l’API

OpenAI indique que l’API et les modèles Sora seront arrêtés le 24 septembre 2026. La documentation d’aide distingue cet arrêt de la fin des expériences Web et de l’application. Il ne faut donc pas présenter l’annonce comme si toutes les formes d’accès cessaient nécessairement au même moment. Selon la documentation du fournisseur, la date concerne la fermeture de l’API ; toute reproduction ultérieure nécessitera de vérifier les conditions en vigueur et l’accès effectivement disponible.

La conséquence méthodologique est claire : un résultat archivé peut rester une observation utile même s’il n’est plus possible de demander une nouvelle génération avec la même configuration. Réévaluer un score à partir de clips stockés n’équivaut pas non plus à répéter l’expérience de génération. Dans le premier cas, il est possible de réévaluer le matériel existant ; dans le second, il faut avoir accès à la génération, à la configuration et aux entrées d’origine.

Un compte rendu historique devrait préciser les éléments conservés : vidéos, prompts, paramètres, date, consignes d’évaluation, résultats détaillés et procédure d’agrégation. Si seul un classement ou un score publié subsiste, on peut le citer comme trace de cette page, mais pas le reconstruire en expérience complète. Les sources disponibles ne confirment pas que tous ces éléments soient conservés pour le classement de Sora 2 Pro ; cette disponibilité doit être considérée comme une incertitude, et non comme un fait.

Liste de vérification pour lire les résultats de Sora 2 Pro

Avant de transformer un classement en conclusion éditoriale ou technique, vérifiez précisément quelle affirmation il étaye. Le nom du benchmark, le score et la position dans un tableau ne suffisent pas si la tâche, les échantillons et la méthode restent inconnus. Une fiche incomplète peut malgré tout être citée avec prudence, à condition de signaler clairement ce qui manque et de ne pas attribuer au résultat une capacité qu’il ne mesure pas.

Évitez en particulier de comparer directement un classement de préférences à une métrique de benchmark par dimensions. Ne comparez pas non plus différentes périodes d’une même arène sans vérifier l’évolution de sa méthodologie. Enfin, ne présentez pas les résultats de modèles différents comme s’ils avaient reçu des prompts, des paramètres et des possibilités de génération identiques lorsque la source ne le documente pas.

La conclusion la plus solide que permettent les sources est d’ordre méthodologique : une préférence peut indiquer quel échantillon a été davantage apprécié dans le cadre d’un protocole ; une batterie de tâches explicites peut examiner des propriétés circonscrites ; la reproductibilité dépend d’artefacts et d’un accès qu’il faut vérifier. À elle seule, aucune de ces pièces n’autorise une affirmation universelle sur la qualité de Sora 2 Pro.

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.