AEGIS : ce que mesure ce benchmark d’images académiques manipulées, et pourquoi détection, explication et localisation ne sont pas le même résultat

AEGIS n’équivaut pas à une preuve d’authenticité scientifique

AEGIS est un benchmark destiné à évaluer l’analyse forensique d’images académiques générées ou manipulées par l’IA. Son intérêt ne consiste pas uniquement à demander si un modèle reconnaît un contenu synthétique : il cherche à distinguer une décision de classification, une explication des indices et la localisation spatiale de l’altération possible. Cette séparation compte, car ces trois sorties répondent à des questions différentes et peuvent échouer indépendamment les unes des autres.

Dans une lecture orientée intégrité scientifique, le résultat d’AEGIS doit être compris comme une mesure obtenue sous un protocole défini, et non comme une certification qu’une figure est authentique ou frauduleuse. Un score élevé peut indiquer qu’un système a bien fonctionné sur les exemples, formats, annotations et règles d’évaluation du jeu de données. Il ne démontre pas, à lui seul, que le système conservera ce comportement face à une image inédite, à une figure compressée différemment, à une retouche légitime mais mal documentée ou à un possible cas réel de faute professionnelle.

Cela en délimite aussi la portée par rapport aux benchmarks génériques de détection de contenu synthétique. Une image académique obéit souvent à des conventions visuelles et sémantiques particulières : panneaux composites, échelles, annotations, microscopie, graphiques ou autres sous-types documentés par le jeu. Ce contexte peut fournir des signaux utiles, mais aussi créer des raccourcis. Un modèle pourrait apprendre des corrélations avec des styles de génération ou de retouche présents dans les tests sans avoir acquis une capacité forensique générale.

La comparaison utile n’est donc pas, dans l’absolu, « quel système a le chiffre le plus élevé ». Elle consiste à demander : « quelle tâche a-t-il résolue, avec quelle entrée, sur quelle partition, selon quel critère de réussite et avec quelles limites déclarées ? » Les rubriques d’Inferama consacrées aux benchmarks, à la sécurité et au glossaire peuvent aider à situer cette distinction entre une évaluation contrôlée et une décision appliquée.

Trois tâches, trois types d’affirmation

La détection binaire pose une question circonscrite : selon la définition opérationnelle du benchmark, une image doit-elle être classée comme réelle ou comme générée ou manipulée ? Sa sortie est une étiquette, qui peut être accompagnée d’un score ou d’une probabilité. Elle est utile pour hiérarchiser les cas nécessitant un examen, mais elle n’identifie pas nécessairement le mécanisme de retouche et ne montre pas la preuve visuelle qui a motivé la décision.

Le raisonnement sur les indices demande au système d’exprimer pourquoi il soupçonne une altération. Selon le format de référence et l’évaluateur prévus par AEGIS, la réponse doit être reliée à des indices observables ou à la stratégie de falsification représentée. Cette tâche n’est pas validée du seul fait que l’étiquette binaire est correcte. Un système peut trouver la bonne classe grâce à une corrélation fortuite tout en donnant une explication vague, incompatible avec l’image ou formulée après la décision.

La localisation impose d’indiquer où se trouve l’altération, généralement à l’aide d’une région, d’un masque ou d’une autre représentation spatiale comparable à une annotation de référence. C’est une exigence différente de la description d’une anomalie en langage naturel. Une explication peut mentionner un panneau ou un élément visuel sans le délimiter assez précisément ; inversement, une région plausible ne prouve pas que le modèle a correctement expliqué la nature de la manipulation.

Ces différences ont une conséquence pratique : il n’est pas valide de remplacer les performances d’une tâche par celles d’une autre. L’exactitude de détection n’est pas l’exactitude d’explication ; une correspondance textuelle n’est pas un masque correct ; et un bon recouvrement spatial ne détermine pas, à lui seul, la fiabilité de la classification finale. Toute table de résultats devrait conserver les colonnes de tâche, de métrique et de protocole plutôt que de les réduire à un classement unique des modèles.

Lire les métriques sans les rendre équivalentes

Les métriques de classification, telles que l’exactitude, résument le nombre de décisions qui correspondent aux étiquettes du jeu. Toutefois, l’exactitude agrégée peut masquer des différences entre les classes. Lorsque le protocole publie des métriques par classe, elles permettent de vérifier si les performances se concentrent sur une classe majoritaire ou si le système traite inégalement les images réelles et altérées. Pour interpréter un pourcentage, il faut également connaître la taille de la partition, la distribution des classes et les règles appliquées aux réponses invalides ou ambiguës.

La métrique spatiale habituelle pour les tâches de segmentation ou de localisation est l’intersection sur union, ou IoU. Elle compare le chevauchement entre la région prédite et la région annotée. Une IoU faible peut révéler une zone trop large, un emplacement décalé ou une prédiction qui ne recouvre qu’une fraction de la zone annotée. Son interprétation dépend toutefois du type d’annotation, du fait que l’évaluation porte sur des boîtes ou des masques, des seuils, et de la manière dont sont traitées les régions multiples ou les images sans altération.

Le raisonnement exige encore davantage de prudence. L’évaluation peut dépendre de réponses de référence, de critères de correspondance sémantique ou d’une procédure automatique. Le résultat renseigne sur la conformité à cette procédure ; il n’établit pas, à lui seul, que l’explication reconstitue causalement le processus de retouche. Avant de comparer des résultats, il convient de vérifier si les systèmes ont reçu la même image, les mêmes instructions, les mêmes possibilités de récupération externe et le même format de sortie.

Une métrique ne devient pas moins utile parce qu’elle est limitée. Le problème est de lui attribuer une signification que le protocole ne mesure pas. Le jeu distribué par le projet comporte des champs relatifs à la tâche, à la réponse de référence, à la catégorie, au sous-type, à la stratégie de falsification et au modèle génératif. Ces champs permettent de désagréger certains résultats, mais un chiffre global demeure un résumé, et non un diagnostic complet.

Composition du jeu et importance de cette composition

La fiche du jeu publiée par BUPT Reasoning Lab déclare 20 571 lignes et une licence CC BY 4.0. La structure décrite inclut des informations de tâche, des réponses de référence, une catégorie, un sous-type, une stratégie de falsification et un modèle génératif. Le dépôt de données permet d’inspecter des exemples et des ressources associées, tandis qu’un instantané identifié du dépôt répertorie des répertoires d’images et des fichiers JSON pour des images réelles et quatre stratégies de falsification.

Cette traçabilité est utile, mais elle ne remplace pas l’audit de la partition exacte utilisée pour un résultat. Le nombre de lignes ne doit pas être interprété automatiquement comme le nombre d’images visuellement indépendantes : une même image, ou une image associée, peut intervenir dans plusieurs tâches ou posséder des métadonnées connexes. L’unité d’analyse pertinente est celle que fixe le protocole d’évaluation et ses séparations entre entraînement, développement et test.

Les catégories et sous-types académiques sont essentiels à la difficulté du test. Un système peut fonctionner de manière inégale selon les conventions visuelles, le niveau de détail ou le type de signal disponible dans chaque sous-type. De même, diverses stratégies de falsification peuvent laisser des artefacts différents. Si les résultats sont agrégés sans ventilation, ils ne permettent pas de savoir si la performance provient d’une capacité largement répartie ou de cas particulièrement faciles à distinguer.

La présence de modèles génératifs dans les métadonnées permet d’étudier la généralisation entre familles de générateurs, à condition que le protocole sépare explicitement les conditions d’entraînement et de test. Cette séparation ne doit pas être supposée sans documentation. Un résultat est plus informatif s’il précise s’il évalue des images produites par des générateurs vus ou inédits, s’il maintient une stratégie de retouche hors de la phase d’ajustement et s’il évite les doublons, variantes proches ou métadonnées reliant les exemples entre partitions.

Ce qui est réellement comparé entre les modèles

AEGIS peut réunir des systèmes aux capacités différentes : modèles multimodaux à usage général, détecteurs forensiques spécialisés et approches unifiées qui produisent plusieurs sorties. Leur présence dans une même table ne signifie pas que leurs conditions sont identiques. Un détecteur spécialisé peut recevoir une image et produire un score ; un modèle multimodal peut nécessiter des instructions, générer du texte libre et dépendre de la façon dont ce texte est transformé en étiquette ou en région évaluable.

La comparabilité exige de déclarer la version exacte du modèle, la configuration d’inférence, les prompts, le nombre de tentatives, le traitement des images de grande taille, les transformations préalables, les seuils de décision et le budget de ressources. Toute récupération ou information supplémentaire doit également être signalée. Une modification qui paraît mineure — par exemple une règle différente pour interpréter une réponse textuelle — peut modifier une métrique sans que la capacité visuelle sous-jacente ait changé.

Les résultats d’un modèle tel qu’Amazon Nova 2 Lite ne sont interprétables face à AEGIS que s’il existe une configuration documentée pour cette évaluation. Son appartenance à une famille de modèles multimodaux ne permet pas d’en déduire un score, une capacité de localisation ou une adéquation à l’intégrité scientifique. Il en va de même pour tout produit ou détecteur spécialisé : une affirmation de performance exige le protocole qui l’a produite.

Le dépôt officiel d’AEGIS documente l’exécution du benchmark et relie des données JSON, des réponses de référence, des images, des masques et des ressources de récupération facultatives. Cette architecture permet de distinguer ce que l’évaluateur calcule de ce qu’un système peut utiliser. Cependant, toute personne reproduisant un résultat doit consigner quelles ressources étaient activées et quels matériels sont restés inaccessibles au modèle évalué.

Ce que les résultats publiés permettent, et ne permettent pas, de conclure

L’article AEGIS présente le benchmark, ses tâches, la construction du jeu, les métriques et les évaluations de référence. C’est la source appropriée pour attribuer des résultats aux baselines étudiées par les auteurs. Néanmoins, une lecture critique doit conserver la granularité de l’article : une moyenne agrégée décrit un comportement sous un mélange particulier d’exemples, et non une garantie uniforme pour chaque catégorie, sous-type ou stratégie de falsification.

Les résultats diagnostiques sont ceux qui montrent où les performances changent : différences entre tâches, catégories, sous-types, stratégies ou familles de génération, lorsque l’étude les rapporte. Ces ventilations peuvent révéler que la détection paraît plus robuste que la localisation, ou que certains cas dominent une moyenne. La conclusion prudente est conditionnelle : dans la configuration évaluée, le système a obtenu des performances différentes dans ces groupes. Elle n’autorise pas à extrapoler ce schéma à des jeux externes sans nouvelle évaluation.

Il n’est pas non plus correct de traduire un faible score de localisation par une incapacité absolue à détecter une manipulation, ni un score de classification élevé par une preuve d’explicabilité. Chaque résultat identifie un type d’erreur potentiel. Pour une organisation qui examine des figures, cette information peut aider à concevoir un flux de priorisation et de contrôle humain, mais non à automatiser une sanction.

AEGIS ne fournit pas, à lui seul, une estimation de la prévalence de la fraude dans la littérature, un taux de faux positifs dans l’environnement opérationnel d’une revue, ni une validation juridique ou institutionnelle d’une accusation. Ces questions requièrent des échantillons représentatifs du contexte d’usage, des critères de revue indépendants, des procédures de recours et une évaluation prospective. Elles exigent aussi de distinguer les altérations trompeuses des transformations légitimes et correctement déclarées.

Risques méthodologiques : distribution, contamination et calibration

La différence entre falsifications simulées et cas réels constitue une limite fondamentale. Les stratégies intégrées au benchmark permettent de contrôler les annotations et les tâches, mais les manipulations réelles peuvent être plus hétérogènes, dégradées par les chaînes de publication ou combiner des procédés non représentés. Dans le même temps, des images authentiques utilisées en conditions réelles peuvent contenir des recadrages, ajustements de contraste, compressions ou compositions de panneaux légitimes qui ressemblent partiellement à des signaux de retouche.

La fuite ou la contamination peut prendre plusieurs formes. Un modèle peut avoir vu des images, textes associés, gabarits ou ressources proches pendant son entraînement ; une équipe peut ajuster ses prompts à répétition sur des éléments de test ; ou des exemples liés peuvent traverser les partitions. La publication des matériels facilite la reproduction, mais rend essentielle la documentation de ce qui était public, de ce qui a été réservé et de la protection de l’évaluation contre l’ajustement itératif.

La calibration est importante lorsqu’un score se transforme en action. Un seuil choisi pour maximiser une métrique de benchmark peut être inadapté dans un environnement où les manipulations sont rares et où le coût d’un faux positif est élevé. Un outil appliqué devrait rapporter des courbes et des erreurs pertinentes pour son scénario, ainsi que des critères de transmission à une revue humaine. Sans ces informations, l’exactitude isolée renseigne peu sur l’utilité opérationnelle.

Enfin, le transfert entre domaines doit être démontré, non supposé. Un système évalué dans les catégories d’AEGIS peut se comporter autrement face à de nouvelles disciplines, de nouveaux instruments, des langues d’annotation, des formats de revue ou des générateurs différents. Une évaluation externe, clairement séparée des ressources de développement, est la preuve appropriée pour étayer une affirmation de généralisation.

Liste de contrôle avant d’utiliser un chiffre AEGIS

Avant de reproduire un chiffre, d’acheter un outil ou d’inclure un résultat dans un rapport, demandez les éléments permettant de reconstruire la comparaison. La première question concerne la version du jeu et de l’évaluateur utilisée. La deuxième porte sur les informations reçues par le modèle. La troisième concerne la décision que la sortie est censée soutenir. Ces questions relient la conception technique aux risques institutionnels.

Il est également utile de demander les résultats désagrégés pertinents pour la décision. Si l’objectif est de prioriser des images pour examen, les faux positifs, la calibration et la stabilité entre sous-types sont particulièrement importants. S’il s’agit de désigner une région, la métrique de localisation et des exemples d’erreurs doivent être examinés. Si une explication est évaluée, il faut analyser le critère qui définit une réponse acceptable, et non seulement la fluidité du texte produit.

AEGIS est le plus utile comme instrument diagnostique lorsqu’il est présenté avec ses conditions et ses limites. Il peut alors révéler quel type de preuve un système fournit et quelles vérifications supplémentaires sont nécessaires. Le traiter comme une certification d’authenticité supprimerait précisément les distinctions entre détection, raisonnement et localisation que le benchmark cherche à mesurer.

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.