C2PA, filigranes IA et détecteurs d’images : quel contrôle pour quelle question ?

Trois contrôles répondent à trois questions différentes. Les Content Credentials (C2PA) permettent de valider un historique enregistré. Un vérificateur de filigrane recherche un signal intégré précis. Un détecteur d’images recherche les caractéristiques qu’il a appris à reconnaître dans le contenu reçu. Choisissez le contrôle selon la décision à prendre, puis recoupez les résultats : l’absence de marquage ne prouve pas l’authenticité.

Une entreprise qui reçoit des images de clients, d’agences et de fournisseurs maîtrise rarement la façon dont chaque fichier a été produit. Certaines images arrivent avec un historique signé, d’autres portent un filigrane IA détectable, d’autres encore sont des captures d’écran sans l’un ni l’autre. Un processus de vérification utile doit traiter ces trois situations sans assimiler l’absence d’information à une garantie d’authenticité.

Ces méthodes peuvent coexister dans un même examen ; aucune n’établit à elle seule qu’un événement photographié s’est déroulé comme décrit. Ce guide porte sur l’assemblage des constats et le règlement des désaccords, non sur le repérage visuel des défauts typiques de l’IA. Pour l’examen initial d’un fichier, voyez Comment savoir si une image est générée par IA.

Si vous avez déjà des résultats contradictoires, commencez par la section Quand les signaux divergent. Pour choisir un outil, partez du tableau comparatif.

Partir de l’affirmation, pas de l’étiquette « authentique »

« Cette image est-elle authentique ? » est une question trop large pour un cahier des charges. Une équipe marketing peut devoir repérer des retouches génératives non déclarées. Un service qualité fournisseurs peut devoir établir qu’un lot de production précis a bien été contrôlé. Une rédaction peut devoir vérifier où et quand une image a été prise. Ce sont trois décisions différentes, même lorsque les trois équipes reçoivent le même JPEG.

Rédigez d’abord la condition d’acceptation : « Cette image doit documenter l’unité de production identifiée avant expédition. » Distinguez ensuite la question de l’historique du fichier de celle de la scène. Un usage de l’IA peut rendre la photo irrecevable pour cet usage, mais l’absence de détection d’IA n’identifie pas l’unité de production : une photo intacte d’une autre unité ne satisferait toujours pas l’exigence.

Pour les sources mixtes, tenez deux relevés en parallèle : ce que l’on sait du fichier, et ce qui justifie son usage dans le dossier. C’est leur intersection qui détermine si la pièce suffit.

Ce qu’apporte chaque contrôle

Les Content Credentials (identifiants de contenu C2PA) portent des déclarations de provenance signées selon les normes C2PA. Un vérificateur contrôle leur intégrité et leur lien avec le fichier ; l’historique peut décrire une prise de vue, une retouche ou une génération. L’adoption est facultative, les historiques peuvent être incomplets, et les Content Credentials ne portent aucun jugement sur la véracité de la scène ou de la légende. Note explicative C2PA 2.2 (Explainer)

Un filigrane IA invisible est un signal intégré au contenu par un système participant ; un vérificateur compatible le recherche. La détection apprise, elle, analyse les caractéristiques du contenu sans exiger qu’un créateur participant ait joint des données de provenance. Le NIST décrit ces approches comme complémentaires et souligne qu’aucune n’offre à elle seule une solution complète. NIST AI 100-4, sections 3.1 et 3.2

Un logo ou un badge « IA » apposé sur l’image relève d’une autre catégorie : c’est un filigrane visible, que l’analyste peut observer et qu’un recadrage suffit souvent à retirer. Consignez-le, mais ne le confondez pas avec une vérification cryptographique ou une détection de filigrane invisible, inscrit dans les pixels et destiné à subsister après certaines transformations.

Article 50 de l’AI Act : davantage de marquages, aucune preuve par l’absence

Depuis le 2 août 2026, les obligations de transparence de l’article 50 du règlement européen sur l’IA s’appliquent. Les fournisseurs de systèmes d’IA générative doivent faire en sorte que les contenus produits (images, vidéos, audio, texte) soient marqués dans un format lisible par machine et détectables comme générés ou manipulés artificiellement ; les déployeurs doivent notamment signaler les hypertrucages (deepfakes). Un code de bonnes pratiques, publié par la Commission en juin 2026 et auquel l’adhésion est volontaire, détaille les moyens d’y répondre ; les obligations elles-mêmes sont légales. Commission européenne, code de bonnes pratiques sur la transparence des contenus générés par IA

Pour un analyste, la conséquence pratique est double. D’une part, davantage d’images reçues porteront des marquages lisibles par machine : Content Credentials, métadonnées, filigranes invisibles. D’autre part, l’absence de marquage reste peu informative : outils situés hors de l’Union, métadonnées effacées lors d’un envoi par messagerie, captures d’écran, ou tentatives délibérées de suppression. Les nombreux outils qui proposent d’« enlever un filigrane IA » illustrent précisément pourquoi un filigrane non détecté n’établit pas une origine humaine.

Le règlement impose un marquage ; il ne désigne pas une norme technique particulière. Ne présentez donc pas le C2PA comme une obligation de l’AI Act : les obligations de l’article 50 pèsent sur les fournisseurs et les déployeurs de systèmes d’IA générative.

Vérification C2PA : distinguer présence, validité et confiance

Au 28 octobre 2026, la version 2.5 des spécifications C2PA est publiée ; l’historique des versions de la spécification technique la date d’octobre 2026. Consignez la version et les capacités effectivement mises en œuvre par chaque vérificateur : la publication d’une norme n’établit pas qu’un produit la prend en charge. Spécifications C2PA 2.5

Le modèle de confiance de la version 2.5 distingue les manifestes bien formés, valides et de confiance, et traite à part la validation du contenu couvert par les liens au fichier : un fichier n’est valide que si les parties couvertes n’ont pas été modifiées depuis la production du manifeste actif. La présence d’un manifeste n’est donc qu’un point de départ. Consignez l’état de validation renvoyé, la validation du contenu couvert et le résultat de confiance dans le signataire. Spécification technique C2PA 2.5, section 13.3

Dans un achat, demandez au fournisseur de démontrer ces distinctions sur des fichiers d’exemple autorisés. Un analyste distingue-t-il « aucun identifiant trouvé » de « identifiant présent mais non validé » ? L’outil explique-t-il un format non pris en charge ou un signataire hors de sa configuration de confiance ? Les analystes peuvent-ils consulter l’action pertinente plutôt que de se fier à une icône verte ?

Lisez l’historique au regard de votre exigence. Un enregistrement de génération peut établir clairement un recours déclaré à l’IA tout en laissant l’image parfaitement acceptable pour une publicité conceptuelle. Un historique d’appareil photo valide peut rester insuffisant pour un contrôle si la photo ne peut être rattachée à l’unité requise. Une entrée de prise de vue suivie d’une retouche se lit comme une séquence, et non à la seule lumière de sa première entrée.

L’absence est particulièrement facile à mal interpréter. Un fournisseur qui n’a jamais utilisé de chaîne de signature ne peut pas en obtenir le bénéfice a posteriori en renvoyant le même fichier. Si une prise de vue signée est nécessaire pour un processus futur, inscrivez-le dans l’exigence avant la prise de vue. Pour les archives mixtes existantes, conservez une autre voie de vérification plutôt que de rejeter tout ce qui n’a pas d’identifiants.

Filigranes : nommer précisément le vérificateur

« Compatible SynthID » ne désigne pas un périmètre de vérification unique. Au 28 octobre 2026, la présentation de Google DeepMind décrit SynthID Detector comme un outil qui vérifie si une image, une vidéo ou un fichier audio a été produit avec l’IA de Google ou de partenaires participants : un périmètre plus large que les seuls outils de Google. Google DeepMind, présentation de SynthID

Dans le même temps, l’aide des applications Gemini indique que Gemini « ne peut actuellement reconnaître que les contenus créés par les outils d’IA de Google ». Elle documente aussi un contrôle distinct des Content Credentials : versions 2.2 et ultérieures, produits figurant sur la liste des produits conformes, et pas de prise en charge des métadonnées stockées à distance. Ce sont des limites propres à un produit, non des limites générales du C2PA ni de toute vérification SynthID. Aide Gemini, vérifier les contenus générés par IA

Consignez dans la fiche d’analyse le nom du vérificateur et le point d’accès utilisé. Un résultat négatif de Gemini ne doit pas être étendu en « tous les partenaires participants ont été contrôlés ». À l’inverse, la présence d’un partenaire dans une annonce d’écosystème n’établit pas que chaque produit, chaque export ancien ou chaque mode d’édition de ce partenaire est couvert.

La même aide précise qu’un filigrane peut ne pas être détecté après de nombreuses modifications, qu’une modification trop légère ou un contenu trop pauvre en détails peuvent empêcher de conclure, et qu’il n’est parfois pas possible de déterminer si l’image a été créée ou modifiée par l’IA de Google. Conservez « incertain » comme une issue à part entière. Aide Gemini, limites de la vérification

En exploitation, exigez que les analystes conservent le résultat effectif de la vérification. L’avis visuel d’un assistant conversationnel selon lequel une image « semble générée par IA » ne doit pas être enregistré comme une détection de filigrane réussie : la fiche doit identifier le mécanisme qui a fourni l’élément.

Côté Fileverity, une analyse détecte des filigranes invisibles connus et signale le cas où les Content Credentials ont été supprimés alors que l’image porte encore leur filigrane invisible. Ce constat montre que le fichier a été modifié après l’ajout de ses Content Credentials ; il ne prouve pas à lui seul que l’image a été retouchée. La liste à jour des filigranes pris en charge est communiquée sur demande avant toute évaluation ; pour un vérificateur propriétaire non listé, confirmez sa prise en charge et son accès auprès de son éditeur.

Détection apprise : couvrir les sources inconnues

Un service d’analyse d’images généraliste est utile lorsque les fournisseurs ne participent à aucun écosystème de provenance, ou lorsqu’une copie reçue a perdu son historique. Sa valeur dépend de la tâche : génération de l’image entière, retouche locale et attribution à un système d’IA sont trois exigences différentes.

Précisez celle qui compte dans l’évaluation. Un outil qui classe les images entièrement générées n’établit pas forcément qu’une petite étiquette d’inspection a été remplacée. Un signal de retouche peut justifier un examen sans désigner l’IA générative comme cause. Pour cette distinction, voyez Photo modifiée par IA : comment repérer une retouche locale.

Demandez une évaluation sur votre composition réelle de sources : envois directs depuis l’appareil, exports d’agence, photos retouchées, images reçues par messagerie ou par capture d’écran. Le NIST insiste sur les faux positifs et sur les performances à des seuils définis : un score a besoin d’une définition et d’une validation pertinente avant d’orienter une décision. NIST AI 100-4, section 4.2.2 Les fichiers recompressés réduisent ce qu’une analyse peut établir ; le guide Captures d’écran et images compressées explique quel fichier redemander.

Supposons qu’un contrôle local pris en charge soulève un doute sur un détail de produit dans un export d’agence sans historique exploitable. Ce constat permet de cibler la demande sur le fichier source avant retouche et sur le traitement de ce détail, au lieu d’exiger de façon générale la preuve que le fichier entier est « réel ». Si le fichier est inadapté ou le résultat non concluant, la demande de source reste ouverte.

Conservez le résultat dans les termes du fournisseur. Ne le convertissez pas en probabilité que l’expéditeur ait menti, et n’en faites pas la moyenne avec un statut de filigrane : ces opérations effacent les différences entre ce que chaque contrôle mesure.

Comment une déclaration signée est liée à l’image qu’elle décrit

L’analyse d’images de Fileverity lit et valide les Content Credentials C2PA disponibles, puis confronte ces déclarations à l’image elle-même sans les confondre avec les constats tirés des pixels. Un principe sous-tend cet examen : le lien cryptographique au contenu. Un identifiant copié à côté d’une image sans rapport ne suffit pas ; la déclaration enregistrée doit être rattachée au contenu examiné.

Deux liens sont à comprendre. Un lien par empreinte rattache les données couvertes du fichier à une empreinte enregistrée dans une assertion. La déclaration signée référence les assertions par leurs empreintes, ce qui rattache cet enregistrement à une clé de signature. La vérification de la signature seule ne permet pas d’établir que l’image actuelle correspond au contenu couvert ; c’est la validation du lien au contenu qui traite ce second maillon. La confiance dans le signataire est encore une autre question. Spécification C2PA 2.5, liens au contenu, section 12.2

Ce lien ne signifie pas toujours « empreinte de chaque octet du fichier final ». Pour une assertion d’empreinte de données, des plages d’octets précises sont exclues, dont celle qui contient le magasin de manifestes intégré. Sans cela, placer dans les données hachées un manifeste qui contient leur propre empreinte créerait une dépendance circulaire. La norme encadre et vérifie ces exclusions : un validateur doit s’assurer que la plage exclue ne contient que le magasin de manifestes et un remplissage autorisé. Elles ne permettent pas de laisser sans protection un contenu significatif. D’autres formats utilisent d’autres structures de lien. Spécification C2PA 2.5, assertion d’empreinte de données

Prenons un exemple simplifié de décompte d’octets. Un fichier de 1 000 octets comporte une plage de manifeste autorisée de 200 octets commençant au décalage 300. Avec des plages numérotées à partir de zéro et à borne finale exclue :

octets couverts = fichier[0:300] || fichier[500:1000]

L’entrée de l’empreinte compte 300 + 500 = 800 octets ; le symbole || désigne la concaténation. Retrouver le même texte d’identifiant dans deux fichiers ne dit rien de la validité de ces 800 octets couverts. Le vérificateur doit aussi contrôler que les exclusions respectent le format du fichier.

Dans un achat, transformez ce mécanisme en démonstration : conservez l’échantillon d’origine porteur d’identifiants, une copie dont les données d’image couvertes ont été modifiées, et les diagnostics du vérificateur pour chacun. Demandez ce qui a été contrôlé du lien au fichier, de la signature et de la confiance dans le signataire. Ne déduisez pas une conformité complète à la norme de la seule capacité d’un produit à afficher un manifeste.

Fileverity lit et valide les Content Credentials C2PA disponibles ; la liste à jour des formats et des capacités de validation est communiquée sur demande avant toute évaluation. La page Fonctionnement décrit l’articulation entre provenance et analyse des pixels. Un enregistrement correctement lié et émis par un signataire de confiance ne peut toujours pas établir que l’article photographié appartient à l’expédition.

Quand les signaux divergent

Vérifiez d’abord qu’il existe une contradiction réelle. « Aucun filigrane pris en charge détecté » et « signalement par l’analyse d’image » peuvent être exacts tous les deux : ils répondent à des questions différentes. Deux résultats portant sur des copies différentes ne sont pas des analyses concurrentes d’un même élément.

Suivez cette séquence chaque fois que les constats semblent incohérents :

1. Rapprocher les fichiers. Comparez les identifiants de fichier, les dimensions et les versions reçues. Conservez la source et étiquetez tout recadrage, conversion ou capture d’écran utilisé pour l’analyse.
2. Traduire les résultats. Rédigez une phrase par contrôle indiquant son mécanisme, son périmètre et son résultat effectif. Gardez visibles les états non pris en charge et non concluants.
3. Situer le désaccord. Porte-t-il sur un signataire, une action enregistrée, une zone précise ou l’affirmation sur le monde réel ? Rattachez l’écart à cette question.
4. Demander l’élément qui tranche. Choisissez ce qui pourrait changer la décision : un diagnostic du validateur, un export antérieur, une explication documentée de la retouche ou une inspection obtenue séparément.
5. Clore la décision au niveau étayé. Consignez ce qui est résolu, l’incertitude restante, l’analyste et le motif de la décision.

La matrice ci-dessous évite que des contrôles répétés deviennent une recherche sans fin de la réponse souhaitée.

Cas pratique : la photo de contrôle avant expédition d’un sous-traitant industriel

Dans ce cas fictif, un industriel exige de son sous-traitant, avant chaque expédition, une photo montrant un ensemble de vanne précis et sa plaque signalétique portant le numéro de série. Le sous-traitant envoie un JPEG en guise de justificatif. L’assistance de l’IA est admise pour les supports marketing, mais une photo de contrôle doit montrer l’état réel, sans remplacement génératif.

L’analyste consigne trois constats fictifs. Un validateur C2PA indique une provenance de confiance comportant un ingrédient issu d’un appareil photo, puis une action de retouche générative, sans détail suffisant pour la localiser. Un vérificateur de filigrane pris en charge n’en détecte aucun. Un classifieur portant sur l’image entière ne déclenche pas son signalement.

Qualifier le fichier de «  vérifié authentique » écarterait le constat le plus pertinent : l’absence de filigrane et le classifieur non déclenché ne disent rien de ce que la retouche enregistrée a modifié. Qualifier l’expédition de frauduleuse dépasserait tout autant les éléments : l’action peut concerner un arrière-plan sans importance, et rien n’établit encore une tromperie ou un ensemble défectueux.

Dans ce dossier, le rapport de l’analyse de Fileverity réunit pour le même fichier la lecture des Content Credentials, la recherche de filigranes invisibles connus et la localisation des zones retouchées ou régénérées ; il indique si la zone concernée par l’action générative enregistrée se situe sur la vanne ou à l’arrière-plan, et consigne l’empreinte SHA-256 du fichier et le statut de l’horodatage du rapport.

L’analyste suspend l’acceptation de cette photo et demande au sous-traitant le fichier avant retouche ainsi qu’une explication de la zone modifiée. Le sous-traitant fournit une image antérieure et indique avoir effacé une palette à l’arrière-plan. Les fichiers paraissent cohérents avec cette explication, mais la plaque signalétique reste illisible dans les deux. La question de provenance est mieux comprise ; le lien requis avec l’unité manque toujours.

L’analyste demande un nouveau contrôle par la procédure établie avec le sous-traitant : des vues reliées entre elles montrant l’ensemble et une plaque lisible, avec une fiche de contrôle identifiant l’unité de production. Un contrôleur qualifié confirme l’unité et son état. L’industriel accepte ce contrôle et consigne que la première photo ne satisfaisait pas l’exigence initiale.

La mention finale se lit ainsi : « L’image soumise comporte une action générative enregistrée, de portée d’abord non établie. La comparaison ultérieure avec la source appuie l’explication du sous-traitant (arrière-plan retouché). Les vues d’origine n’établissent pas l’identifiant de l’unité. L’acceptation repose sur le contrôle de remplacement et la fiche d’unité associée. »

Cette issue préserve la différence entre expliquer l’historique d’une image et établir l’état d’une expédition. Elle évite aussi de demander à un second détecteur de trancher un fait qu’un contrôle physique établit directement.

Traduire cette architecture en exigence d’achat

Demandez aux fournisseurs pressentis de remplir une fiche de capacités comportant ces rubriques : mécanisme de vérification, fichiers pris en charge, écosystèmes ou versions de norme pris en charge, issues négatives et non prises en charge, diagnostics conservés, et action d’analyste que chaque constat permet. Désignez un responsable de la mise à jour de ces informations de compatibilité, qui évoluent.

Organisez un petit exercice autorisé comprenant au moins un fichier sans historique, un fichier signé, un fichier dont l’assistance par IA est connue et une copie transformée. L’objectif initial est de vérifier que les analystes gardent les mécanismes séparés et aboutissent à des suites utiles ; ce n’est pas un banc d’essai de performance. Une évaluation de performance exige un échantillon défini et des étiquettes de référence : le guide Choisir un logiciel de détection d’images IA en décrit les étapes.

Pour un flux de sources mixtes, évaluez la vérification d’images Fileverity au regard des questions de génération, de retouche et de provenance que vos analystes doivent trancher. Une analyse rassemble ces trois voies dans un même rapport vérifiable, avec l’empreinte SHA-256 du fichier examiné. Inscrivez séparément dans la fiche de capacités tout vérificateur de filigrane propriétaire dont vous avez besoin, et confirmez sa prise en charge et son accès auprès de l’éditeur concerné.

Pour un fichier isolé, demandez une analyse : elle lit et valide les Content Credentials, recherche les filigranes invisibles connus et confronte ces déclarations aux pixels. Pour une évaluation par une équipe, parcourez des cas réels de votre flux avec notre équipe, en partant d’une décision récurrente pour laquelle ni historique signé ni filigrane pris en charge ne sont disponibles. Les fichiers sont supprimés après l’analyse et ne servent jamais à entraîner les modèles (Sécurité).

Par Yang Zheng · Relu par Bill Liu