Images générées par l’IA : ce qu’une attestation de provenance peut démontrer

Une image peut avoir été créée par un générateur, retouchée à l’aide d’outils automatisés ou modifiée de façon classique. Ces opérations ne sont pas toujours visibles pour la personne qui reçoit l’image. Les étiquettes et attestations de provenance cherchent à apporter du contexte : elles décrivent des informations sur l’origine du fichier et, lorsqu’elles sont consignées, sur les modifications intervenues au fil de son parcours. Elles ne sont pas équivalentes à un détecteur qui tente de deviner, à partir des pixels, si une image semble synthétique.

Cette distinction est importante, car une attestation répond à des questions précises : des informations de provenance sont-elles associées au fichier ? Que déclarent-elles ? Leur structure et leur lien avec le fichier sont-ils validés ? À elle seule, elle ne répond pas aux questions « Ce que montre l’image s’est-il réellement produit ? » ou « La personne qui l’a publiée est-elle légitime ? ». L’explicatif de C2PA précise expressément que la provenance ne permet pas de déterminer si un contenu représente la vérité. Une étiquette technique est un contexte vérifiable, pas une garantie d’authenticité factuelle.

Le dossier d’une image peut inclure des indications sur sa génération ou ses retouches, si un outil les consigne. Mais décrire le processus ne remplace pas l’évaluation éditoriale : une photographie authentique peut montrer une scène sortie de son contexte, et une image générée peut illustrer une idée sans prétendre documenter un événement. Une lecture responsable distingue ce que le fichier déclare de ce qui peut être confirmé au sujet de la scène.

C2PA est une spécification permettant d’associer des informations de provenance à un contenu numérique. Ses attestations, également appelées Content Credentials, peuvent réunir des déclarations sur un élément, sa provenance et les actions ou modifications consignées. La norme prévoit aussi des mécanismes pour relier les déclarations au contenu et valider l’intégrité de cette relation. En pratique, un visualiseur compatible peut présenter les informations disponibles et indiquer si l’attestation est validée ; le résultat dépend des données qui ont été intégrées et de la capacité de l’outil à les lire.

Il vaut mieux lire ces données comme une chaîne de déclarations que comme une étiquette universelle « vrai » ou « faux ». Une attestation peut apporter du contexte sur une opération déclarée, mais elle ne garantit ni que toutes les étapes antérieures ont été documentées ni que la personne qui les a consignées décrit son travail correctement. La solidité de la conclusion dépend des informations qu’elle contient, de la personne qui l’a signée et de son lien avec le fichier examiné. Valider une signature ou une association technique ne revient pas à valider l’ensemble du récit.

L’explicatif délimite également l’objectif : la provenance peut aider les consommateurs à examiner des contenus et les professionnels à clarifier des modifications, entre autres usages, mais elle n’a pas vocation à trancher la véracité. Lors de l’examen d’une attestation, recherchez donc des informations concrètes — origine déclarée, actions consignées et état de validation — et ne transformez pas une simple mention de l’IA en conclusion sur l’intention, la qualité ou la tromperie.

Une attestation valide étaye une affirmation technique limitée : les informations présentées ont passé les vérifications effectuées par le dispositif de contrôle pour ce fichier. Elle ne prouve pas que la scène s’est déroulée comme elle est racontée, que le contexte est complet ou que toutes les transformations ont été consignées. Elle ne dispense pas non plus d’identifier la source originale. Une image assortie d’une attestation valide peut encore devoir être confrontée à sa date, son lieu, son auteur et à des sources indépendantes.

Inversement, si un vérificateur ne trouve aucune attestation, cela ne prouve pas que l’image est fausse, générée par l’IA ou manipulée. Elle peut avoir été créée sans informations de provenance ; le logiciel utilisé peut ne pas en avoir ajouté ; ou une copie ultérieure peut avoir perdu les données. Tout au plus, cette absence signifie qu’aucune attestation lisible n’est disponible dans ce fichier pour ce vérificateur. Ce n’est ni une preuve de fraude ni une preuve d’authenticité.

Il est également utile de distinguer la provenance de l’analyse visuelle automatisée. Un détecteur qui attribue une probabilité de génération travaille à partir de signaux présents dans le contenu et peut se tromper ; une attestation fournit des déclarations associées au fichier. Ces méthodes répondent à des questions différentes et ont des limites différentes. Aucune, prise isolément, ne justifie une conclusion catégorique sur l’histoire complète d’une image.

Les données de provenance peuvent être intégrées au fichier ou conservées par des mécanismes associés. Certaines opérations de retouche, d’exportation ou de conversion peuvent donc modifier les informations encore disponibles. L’outil Rusadix décrit une méthode qui reconstruit une image à partir de ses pixels et ne copie pas certains blocs de métadonnées connus dans la nouvelle copie ; il précise également que cette opération ne supprime pas d’éventuels filigranes intégrés aux pixels eux-mêmes. C’est un exemple concret de la raison pour laquelle une copie sans métadonnées ne raconte pas toute l’histoire de l’original.

Cela ne permet pas de conclure que chaque exportation supprime une attestation ni que la méthode d’un outil est universelle : tout dépend du format, du flux de travail et du fichier. Si la provenance est importante pour une vérification, conservez le fichier reçu et notez sa provenance avant de l’ouvrir et de l’enregistrer à nouveau. Si possible, comparez l’original et la copie et consignez les changements de format ou de retouche.

La confidentialité mérite également attention. Les métadonnées peuvent contenir d’autres éléments que des informations sur l’IA, par exemple des données techniques ou de localisation. Leur suppression peut réduire les informations associées au fichier, mais aussi effacer un contexte utile à la vérification. Avant de le faire, déterminez si l’objectif est de protéger des données personnelles, de préserver la traçabilité, ou les deux ; lorsque cela convient, gardez une copie originale protégée.

La vérification est plus solide lorsqu’on associe l’examen technique à la vérification du contexte. Si des attestations sont présentes, vérifiez ce que déclare le dossier et si le vérificateur le présente comme valide ; ne vous contentez pas d’une icône ou d’une étiquette résumée. En leur absence, notez-le sans considérer ce fait comme une preuve concluante. Dans les deux cas, recherchez la source disponible la plus ancienne et confrontez l’image à d’autres sources.

Une démarche pratique pour les lecteurs et les créateurs :

• Conservez le fichier reçu et notez qui vous l’a fourni, quand et par quel canal.
• Consultez un vérificateur compatible avec C2PA et examinez les détails disponibles, pas seulement la présence d’une étiquette.
• Vérifiez le lieu, la date, l’auteur et le contexte à l’aide de sources indépendantes.
• Si vous retouchez ou convertissez le fichier, conservez une copie de l’original et documentez la modification.
• En l’absence d’attestation ou si elle ne peut pas être validée, signalez cette limite et n’en déduisez pas que l’image est fausse ou vraie.

La conclusion doit être proportionnée aux éléments disponibles : « le fichier inclut une attestation qui déclare ces opérations » est plus précis que « l’image est authentique ». Si les informations sont insuffisantes, la réponse utile consiste à préciser ce qui manque et quelles vérifications indépendantes ont été effectuées. La provenance aide à reconstituer le parcours ; le contexte aide à évaluer ce que ce parcours signifie.