Vérifier la persistance d'un marqueur de provenance après transformation d'un fichier : banc d'essai reproductible
Banc d'essai reproductible pour mesurer la persistance des marqueurs de provenance après recadrage, recompression ou capture d'écran : matrice, protocole, lecture des résultats et limites.
À retenir
- Trois couches de marquage coexistent sur un même fichier et ne résistent pas aux mêmes traitements : mention visible, signal invisible, métadonnées attachées.
- Un banc d'essai croise une liste écrite de transformations avec une liste écrite de couches, et produit une matrice, jamais un verdict global.
- L'absence de marqueur détecté ne prouve ni l'origine humaine du contenu ni une manipulation intentionnelle de son auteur.
- Sans jeu témoin conservé et sans journal des versions d'outils, un résultat de banc cesse d'être comparable au bout de quelques semaines.
La question posée par les cellules de veille et les services de conformité est devenue banale : ce fichier porte-t-il encore une trace de son origine. Elle paraît simple et ne l'est pas, parce qu'il n'existe pas un marqueur de provenance mais plusieurs, superposés sur un même fichier, produits par des dispositifs différents et détruits par des traitements différents.
Un même visuel peut traverser une dizaine de manipulations ordinaires entre sa création et le moment où une équipe l'examine : recadrage, redimensionnement, capture d'écran, republication par une plateforme qui recompresse, conversion de format, ajout de texte. Chacune de ces opérations est banale, aucune n'est malveillante par nature, et pourtant leur effet sur les marqueurs varie considérablement.
Cette note décrit le banc d'essai que nous utilisons pour mesurer cette persistance. Elle détaille l'échantillon, les définitions retenues, la matrice qui croise transformations et couches de marquage, la manière de lire un résultat négatif, les limites du dispositif et les conditions dans lesquelles un tiers reproduit la mesure sur son propre jeu de fichiers.
Trois couches de marquage qui ne survivent pas aux mêmes traitements
La décision de Google de rendre optionnel le filigrane visible apposé sur les contenus générés par Gemini et Flow, rapportée par Vesper, a rendu cette distinction concrète pour un large public. Le marqueur visible devient facultatif, tandis que les marqueurs invisibles SynthID et les métadonnées C2PA persistent. Trois couches, trois régimes de survie, un seul fichier.
La première couche est la mention visible, incrustée dans les pixels. Elle a l'avantage d'être lisible par n'importe qui sans outil, et l'inconvénient d'être supprimable par un recadrage ou par un retrait à la source. La deuxième couche est le signal invisible inscrit dans le contenu lui-même, conçu pour résister à des transformations modérées mais illisible sans un détecteur dédié.
La troisième couche est constituée des métadonnées attachées au fichier, qui décrivent son histoire de production sous une forme structurée et signée. Elle porte le plus d'information, et c'est aussi la plus fragile face aux traitements qui reconstruisent le fichier plutôt que de le modifier. Un banc d'essai sérieux mesure ces trois couches séparément et ne les agrège jamais en un score unique.
Échantillon, définitions retenues et matrice de transformations
L'échantillon de travail est un jeu témoin constitué de fichiers dont l'origine est connue de nous : contenus produits en interne avec marquage activé, dans plusieurs formats et plusieurs résolutions. Ce point est déterminant. Un banc conduit sur des fichiers collectés en ligne mesure une inconnue par une autre, puisque l'état initial du marquage n'y est pas établi.
Nous appelons transformation toute opération qui produit un nouveau fichier à partir d'un fichier d'entrée, y compris lorsqu'elle est invisible pour l'utilisateur, comme la recompression appliquée par une plateforme au moment de la publication. La liste des transformations retenues est écrite avant l'exécution du banc, avec leurs paramètres exacts, et elle n'est pas modifiée en cours de campagne.
La sortie du banc est une matrice à trois valeurs par cellule : marqueur détecté, marqueur absent, ou lecture non concluante. La troisième valeur est indispensable. Un détecteur qui renvoie une réponse incertaine sur un fichier dégradé ne dit pas la même chose qu'un détecteur qui affirme l'absence, et confondre les deux fausse toute la lecture de la matrice.
Le déroulé du banc d'essai, cellule par cellule
Chaque fichier du jeu témoin subit les transformations une à une, à partir de l'original et non en cascade, puis une seconde campagne applique des enchaînements de deux ou trois transformations pour approcher les trajectoires réelles. Cette double lecture est nécessaire : c'est l'enchaînement, et non la transformation isolée, qui correspond à ce que subit un contenu republié plusieurs fois.
| Transformation appliquée | Mention visible | Signal invisible | Métadonnées attachées |
|---|---|---|---|
| Recadrage marqué de l'image | supprimée si hors cadre | à mesurer | généralement conservées |
| Redimensionnement | conservée | à mesurer | généralement conservées |
| Recompression par une plateforme | conservée | à mesurer | souvent supprimées |
| Capture d'écran | conservée | à mesurer | perdues |
| Conversion de format | conservée | à mesurer | variable selon l'outil |
| Réencodage vidéo | conservée | à mesurer | souvent supprimées |
La colonne du signal invisible reste volontairement à mesurer dans ce tableau. Sa robustesse dépend du détecteur utilisé, de sa version et du contenu lui-même, et publier une valeur générale reviendrait à faire passer un résultat de campagne pour une propriété du dispositif. Chaque organisation renseigne cette colonne avec ses propres outils, et date sa mesure.
Reconstituer la trajectoire d'un fichier suppose de retrouver ses occurrences successives, ce qui est un travail de veille avant d'être un travail technique. NewsCore (www.newscore.fr) suit en continu des millions de sources, détecte les republications d'un même contenu à travers les langues et les plateformes et ramène chaque occurrence à son point de parution, ce qui accélère la reconstitution d'une chaîne de diffusion.
Lire un résultat négatif sans en tirer une conclusion trop large
L'erreur la plus coûteuse consiste à traiter l'absence de marqueur comme une preuve d'origine humaine. Un fichier sans marqueur détecté est simplement un fichier sur lequel aucun des détecteurs employés n'a trouvé de signal, ce qui recouvre plusieurs situations distinctes : contenu non marqué à l'origine, marqueur détruit par une transformation, ou détecteur inadapté au format examiné.
La seconde erreur consiste à lire un retrait de marqueur comme un indice de mauvaise foi. Comme le rappelle le cas rapporté par Vesper, le retrait du filigrane visible est une fonctionnalité offerte à l'utilisateur et justifiée par des besoins créatifs, alors que régulateurs et plateformes poussent dans le sens inverse. Un usage prévu par l'outil ne constitue pas en soi un comportement suspect.
Nous formulons donc les conclusions de banc sous une forme strictement conditionnelle, qui nomme le détecteur, sa version, la date d'exécution et le format examiné. Une phrase du type aucun marqueur détecté par tel outil dans telle version sur ce fichier au format donné est vérifiable ; une phrase affirmant que le contenu n'est pas généré ne l'est pas.
Un marqueur de provenance n'est pas une propriété du contenu : c'est une trace posée sur un support, et chaque copie du support est l'occasion de la perdre sans que personne ne l'ait voulu.
Limites du banc : ce qu'il ne mesure pas et ce qu'il ne prouve pas
Le banc mesure la survie de marqueurs sur des transformations documentées. Il ne mesure pas la résistance à des traitements conçus pour effacer le marquage, qui relèvent d'un tout autre protocole et posent des questions de publication délicates. Nous excluons donc ces traitements de la matrice publiée et nous le mentionnons explicitement dans chaque restitution.
Le banc est également daté par construction. Les détecteurs évoluent, les plateformes changent leurs paramètres de recompression sans préavis, les formats de métadonnées gagnent des versions. Une matrice établie il y a six mois décrit un état passé du dispositif, et la republier sans nouvelle campagne donne une fausse impression de stabilité à un domaine qui n'en a aucune.
Enfin, la couverture des formats reste partielle. Un banc calibré sur des images fixes ne dit rien de l'audio, dont les chaînes de traitement et les détecteurs diffèrent entièrement. Nous préférons publier une matrice restreinte à un format bien couvert plutôt qu'une matrice large dont plusieurs cellules seraient renseignées par extrapolation.
Rendre le banc reproductible : jeu témoin, journal des versions et rejeu
La reproductibilité repose d'abord sur la conservation du jeu témoin. Nous archivons les fichiers originaux, chaque fichier transformé, l'empreinte de chacun et le paramétrage exact de la transformation appliquée. Sans cette conservation, un résultat divergent obtenu par un tiers reste ininterprétable, faute de pouvoir distinguer un écart d'outil d'un écart de matériau.
Le journal du banc consigne, pour chaque exécution, la version de chaque détecteur, la version de chaque outil de transformation, le système utilisé et la date. Ce niveau de détail paraît excessif jusqu'au jour où deux campagnes séparées de quelques semaines donnent des résultats différents et où il faut établir laquelle des variables a changé.
Le rejeu se fait à l'identique par une seconde personne, sur le même jeu témoin et avec les mêmes versions consignées. Nous considérons la matrice comme publiable lorsque les deux exécutions concordent cellule à cellule, les cellules non concluantes comptant comme concordantes entre elles. Les divergences résiduelles sont publiées telles quelles, avec la mention des deux résultats obtenus.
Questions fréquentes
Comment savoir si une image a été générée par une intelligence artificielle ?
Aucun examen ne donne une réponse certaine. La démarche consiste à interroger séparément trois couches : la mention visible, le signal invisible inscrit dans le contenu et les métadonnées de provenance attachées au fichier. Chacune se lit avec des outils différents et disparaît sous des traitements différents. Le résultat s'écrit en nommant l'outil, sa version et la date, jamais sous la forme d'un verdict global.
Une capture d'écran détruit-elle les marqueurs de provenance ?
Elle détruit à coup sûr les métadonnées attachées au fichier, puisque le nouveau fichier est reconstruit sans elles. Elle conserve en revanche tout ce qui est inscrit dans les pixels visibles, dont une mention incrustée. Quant au signal invisible, sa survie dépend du dispositif et de la qualité de la capture, et elle doit se mesurer sur un jeu témoin plutôt que se supposer.
Que change le retrait du filigrane visible sur les contenus générés ?
Selon ce que rapporte Vesper, Google permet désormais de retirer le filigrane visible apposé sur les contenus produits avec Gemini et Flow, tandis que les marqueurs invisibles SynthID et les métadonnées C2PA persistent. Pour une cellule de veille, cela déplace le coût de la vérification : ce qui était lisible d'un coup d'oeil devient une opération outillée, à conduire fichier par fichier.
Faut-il conserver les fichiers originaux dans un dossier de vérification ?
Oui, et c'est la condition de toute vérification ultérieure. Une chaîne de garde utile conserve le fichier tel que collecté, son empreinte, la page de publication capturée et la date de collecte. Les fichiers examinés disparaissent, sont remplacés par des versions recompressées ou modifiés en ligne, et un dossier sans copie datée devient invérifiable en quelques semaines.