La provenance répond à une question circonscrite
Un fichier visuel peut circuler avec de nombreux signaux : une étiquette de plateforme, des données EXIF, un filigrane visible, une déclaration de l’auteur ou une crédential de provenance. Ils n’ont pas tous la même signification, ni la même résistance aux modifications ultérieures. Pour une rédaction, une équipe de marque, un service d’archives ou un produit intégrant des outils génératifs, la première étape consiste à poser la bonne question : quels éléments existent au sujet de l’historique déclaré de ce fichier précis ?
C2PA est une spécification technique permettant d’exprimer et de vérifier des informations sur la provenance d’un contenu. En pratique, une crédential peut relier des déclarations concernant la création, la modification ou la combinaison d’actifs à un fichier, et protéger ces déclarations à l’aide de mécanismes cryptographiques. Le résultat peut aider à déterminer si les éléments présentés sont intacts et qui les a signés, à condition que le validateur puisse les vérifier et que la confiance accordée au signataire soit justifiée.
Cette portée est importante, mais limitée. Une crédential valide ne transforme pas automatiquement une scène en fait établi. Elle ne prouve pas non plus que la personne désignée comme auteur détient tous les droits nécessaires, que les personnes identifiables ont consenti à l’usage, qu’une identité déclarée est correcte, ni qu’aucune manipulation n’a eu lieu hors de la chaîne enregistrée. Ces questions nécessitent des sources et des contrôles distincts.
L’absence de crédential ne permet pas davantage de conclure que le fichier est faux, manipulé ou généré par IA. Elle peut être absente parce que l’outil ne l’émet pas, parce qu’elle a été supprimée lors d’une exportation, parce qu’une plateforme l’a séparée du fichier ou parce qu’un autre format de provenance a été employé. La décision éditoriale doit refléter à la fois ce que les éléments permettent d’affirmer et ce qu’ils laissent indéterminé.
Quatre types d’éléments à ne pas confondre
Les crédentials signées sont le type d’élément qui se rapproche le plus d’une chaîne vérifiable de déclarations. Elles peuvent comporter un émetteur, des affirmations sur les actions réalisées, des références à des ingrédients — des actifs utilisés pour produire un autre actif — et une signature. Leur utilité dépend de la disponibilité du fichier ou de son manifeste associé, du caractère satisfaisant de la validation et de la capacité du destinataire à évaluer le signataire.
Les métadonnées ordinaires, telles que les champs de date, de logiciel ou d’appareil photo, sont utiles pour le catalogage et pour orienter un examen. Toutefois, elles n’offrent pas à elles seules le même modèle d’intégrité cryptographique et peuvent être perdues ou modifiées lors d’une copie, d’une conversion ou d’une publication. Elles doivent être traitées comme des indices documentaires, et non comme une preuve concluante de l’origine.
Les filigranes, visibles ou détectables par logiciel, remplissent une fonction différente. Ils peuvent informer ou aider à identifier un contenu, mais ne démontrent pas nécessairement l’intégralité de la séquence de modification et ne remplacent pas une vérification des manifestes. Un filigrane visible peut être rogné ; un signal imperceptible peut ne pas survivre à certaines transformations. Son comportement réel doit être testé dans le flux retenu.
Enfin, une déclaration de l’éditeur peut être nécessaire pour expliquer au public comment un contenu a été produit ou modifié. Il s’agit d’une communication attribuable au responsable de la publication, non d’une preuve technique indépendante. Elle peut être étayée par des registres et des crédentials, mais doit être formulée à proportion des éléments disponibles.
Ce que chaque signal peut étayer
| Signal | Peut étayer | Ne démontre pas à lui seul |
|---|---|---|
| Crédential C2PA validée | Intégrité des déclarations de provenance et des actions enregistrées ; identité déclarée du signataire | Véracité factuelle, licence, consentement, identité réelle d’une personne ou absence complète de modifications externes |
| Métadonnées ordinaires | Catalogage et contexte technique déclaré | Intégrité cryptographique ou historique complet |
| Filigrane | Avertissement ou identification selon sa conception et sa conservation | Chaîne de transformations, droits ou exactitude du contenu |
| Déclaration publique | Information attribuable à l’éditeur | Vérification technique indépendante |
Lire une crédential sans en faire un sceau d’authenticité
L’audit doit commencer par l’actif reçu, et non par une capture d’écran d’une interface. Conservez une copie non modifiée et calculez ou enregistrez un identifiant interne du fichier avant de l’ouvrir dans des outils susceptibles de l’enregistrer à nouveau. Exécutez ensuite un validateur C2PA à jour et conservez le résultat avec la date, la version du validateur et tous les avertissements.
Examinez qui a émis ou signé le manifeste et quel niveau de confiance l’organisation peut lui accorder. La vérification cryptographique et la confiance organisationnelle sont deux couches distinctes : un manifeste peut être bien formé et disposer d’une signature vérifiable, mais l’équipe doit tout de même décider si elle connaît et accepte l’émetteur pour l’usage prévu. Si l’identité de l’émetteur est affichée au moyen d’un certificat ou d’un autre identifiant, ne la transformez pas automatiquement en déclaration de propriété intellectuelle ou d’identité civile.
Examinez les actions déclarées. Une action peut indiquer une création, une modification, une exportation ou une autre opération du flux, mais elle décrit ce que le manifeste affirme avoir eu lieu. Examinez également les ingrédients et leur relation avec l’actif final. La présence d’un outil dans la chaîne ne prouve pas nécessairement que tout le contenu visuel provient de cet outil : il peut avoir été combiné à des photographies, graphiques, séquences vidéo, éléments audio ou autres matériaux.
Le rapport doit distinguer l’état technique de la décision d’utilisation. Enregistrez, par exemple, si le manifeste a pu être localisé, si le contenu était correctement relié, si la signature a pu être validée, quelles affirmations étaient présentes et quelles limites subsistaient. Évitez de réduire ce résultat à une étiquette binaire telle que « authentique » ou « non authentique ».
Audit reproductible d’un fichier reçu
- 01Isolez le fichier reçu et conservez une copie en lecture seule avec un identifiant interne.
- 02Exécutez un validateur C2PA et conservez le rapport complet, la date et la version de l’outil employé.
- 03Vérifiez l’émetteur déclaré, la validité de la signature, les actions, les ingrédients et les avertissements du rapport.
- 04Confrontez les déclarations techniques à la documentation disponible concernant la commande, la licence, le consentement et le contexte éditorial.
- 05Classez le cas comme éléments suffisants, incomplets, absents ou contradictoires ; documentez la personne qui a pris la décision.
- 06Répétez la vérification sur le fichier téléchargé depuis chaque destination de publication lorsque la portabilité est pertinente.
Chaîne de conservation : préserver davantage que le fichier final
La provenance perd de son utilité lorsqu’on tente de la reconstituer au terme de la chaîne. Le moment le plus solide pour documenter un actif est sa création ou sa réception. Dans un flux de génération ou de modification, il est souhaitable de préserver l’original fourni par l’outil, sa version exportée, les crédentials qu’il contient et la documentation opérationnelle reliant le fichier à une commande ou à une autorisation.
Pour chaque transformation importante, créez une nouvelle version identifiable plutôt que de remplacer silencieusement l’original. Notez l’outil et sa version, l’opérateur, la date, l’objectif de la modification et le fichier d’entrée. Si un outil compatible met à jour la provenance lors d’une modification, validez de nouveau le résultat. Si un outil ne la préserve pas, le registre interne devient un élément contextuel particulièrement important, même s’il ne remplace pas la signature de l’original.
Ne confondez pas stockage et publication. Le master d’archive peut conserver une crédential intégrée, alors qu’un réseau social, un système de gestion de contenu ou un fournisseur de vidéo peut distribuer une copie réencodée qui en est dépourvue. La politique doit donc définir quelle copie constitue l’objet archivé, quelle copie sera vue par le public et quels éléments restent disponibles pour répondre aux demandes ultérieures.
La spécification prévoit des modes de transport des manifestes qui ne se limitent pas nécessairement à un seul bloc de métadonnées intégré. L’organisation doit néanmoins tester sa propre combinaison de formats, d’outils et de destinations. Il ne suffit pas de supposer qu’une crédential survivra parce qu’elle était visible dans l’application d’origine.
Là où les éléments peuvent être rompus, dégradés ou séparés
Une capture d’écran crée habituellement un nouveau fichier et laisse généralement de côté la crédential de l’actif initial. Elle peut servir à illustrer ce qui a été affiché dans une interface, mais ne doit pas être présentée comme une preuve de la provenance du fichier capturé. Lorsque cela est possible, demandez l’original ou un lien interne vers l’objet conservé, sans dépendre de l’image d’écran.
Le réencodage vidéo, les conversions de format, l’optimisation d’images, le recadrage, la suppression de métadonnées et certaines modifications peuvent altérer ou supprimer les informations nécessaires à la validation de la provenance. Certains outils peuvent émettre une nouvelle crédential reflétant la transformation ; d’autres non. L’effet dépend de l’implémentation, des formats d’entrée et de sortie et des options activées. Les affirmations de compatibilité doivent donc reposer sur des essais documentés du flux précis.
Il faut aussi distinguer une crédential supprimée d’une crédential qui existe encore mais est dissociée de l’objet téléchargé par le public. Les manifestes peuvent être intégrés, externes ou distribués par d’autres mécanismes. Si une interface affiche un indicateur de provenance, vérifiez ce qui se produit lors du téléchargement, du partage ou de l’ouverture du fichier dans un autre validateur. Une interface ne remplace pas l’audit de l’objet effectivement distribué.
Lorsque des incohérences sont constatées — par exemple, lorsqu’une déclaration publique attribue une image à un outil mais que le fichier disponible ne comporte pas les éléments annoncés —, il ne convient pas d’en déduire automatiquement une mauvaise foi. Il convient de suspendre les conclusions fortes, de préserver les copies examinées et de demander l’original, le rapport de validation et une explication du flux.
Points de défaillance et réponse opérationnelle
| Situation | Risque pour la provenance | Réponse recommandée |
|---|---|---|
| Capture d’écran | Le nouveau fichier peut ne pas inclure les éléments de l’original | Demander et archiver le fichier source ; traiter la capture comme un simple contexte |
| Exportation ou conversion | La crédential peut être supprimée, devenir invalide ou être mise à jour | Valider avant et après l’exportation ; conserver les deux résultats |
| Publication sur une plateforme | La copie publique peut être réencodée ou dissociée du manifeste | Télécharger et valider la copie effectivement distribuée |
| Modification hors d’un flux compatible | La transformation peut ne pas être déclarée | Enregistrer la modification en interne et ne pas affirmer l’existence d’une chaîne complète |
| Manifeste ou déclaration contradictoires | Aucune conclusion simple ne peut être soutenue | Transmettre pour examen humain et demander les matériaux primaires |
Protocole de décision avant publication ou réutilisation
Classez les éléments dans quatre états opérationnels. « Suffisants » ne signifie pas certitude totale : cela signifie que, pour une décision précise et documentée, un original est disponible, que le résultat de validation est satisfaisant, que l’émetteur a été évalué et que des registres complémentaires sur les droits, le consentement et le contexte existent lorsque nécessaire. Même dans cet état, la publication d’une affirmation factuelle requiert une vérification éditoriale indépendante.
« Incomplets » signifie qu’il existe un signal utile — par exemple, une crédential valide sur un original mais non sur la copie de publication, ou des registres de production sans manifeste vérifiable —, alors que des éléments manquent pour formuler une attribution large. Le contenu peut être publiable si le risque éditorial est faible et si la communication se limite à ce qui est confirmé, mais une note interne doit consigner les lacunes.
« Absents » signifie qu’aucune crédential ni aucun registre vérifiable de provenance n’est disponible. Cela ne revient ni à qualifier le contenu de trompeur, ni à le qualifier de généré. Dans cet état, la décision dépendra du contexte, de la confiance envers le fournisseur, des politiques d’acquisition et d’autres vérifications. « Contradictoires » signifie que des éléments ne concordent pas ou qu’une discontinuité importante ne peut être expliquée. Cet état exige une revue humaine avant toute diffusion d’une attribution sur l’origine ou l’IA.
La classification doit s’appliquer à chaque version. Une validation satisfaisante d’un master ne se transfère pas automatiquement à une image compressée pour le web, à un extrait vidéo, à une traduction audiovisuelle ou à une composition ultérieure. Reliez chaque décision à un identifiant de fichier, et non uniquement au nom commercial du projet.
Décision de publication en six questions
- 01Le fichier exact qu’il est prévu de publier ou de réutiliser est-il conservé ?
- 02La validation de provenance a-t-elle été réalisée sur cette version et a-t-elle produit un résultat documenté ?
- 03Quelles actions, quels ingrédients et quel émetteur la crédential déclare-t-elle exactement ?
- 04Quelles questions restent sans réponse : véracité, licence, consentement, identité ou contexte ?
- 05L’étiquette publique proposée correspond-elle aux éléments disponibles et évite-t-elle des inférences supplémentaires ?
- 06Une règle, un contrat ou une politique interne impose-t-il une divulgation additionnelle pour ce public et cette juridiction ?
Étiquettes publiques : décrire les éléments, ne pas promettre davantage
L’étiquette la plus sûre décrit le processus connu ou les limites des éléments. S’il existe une crédential validée pour la version distribuée et que ses déclarations sont pertinentes, une formulation possible est : « Ce fichier contient des informations de provenance vérifiables concernant les actions déclarées lors de sa création et de sa modification. » Si l’organisation souhaite mentionner l’IA, elle ne doit le faire que lorsque les éléments techniques et les registres de production identifient suffisamment cet usage.
Lorsque la crédential est présente dans l’original, mais que sa conservation dans la copie publique n’a pas été confirmée, il est préférable d’indiquer : « Le fichier master conservé par l’organisation contient des informations de provenance vérifiables ; la disponibilité de ces informations peut varier selon les plateformes. » Cette formulation informe sans affirmer que le public peut contrôler les mêmes éléments sur toutes les destinations.
Évitez des formules telles que « image authentique », « contenu réel », « sans manipulation », « utilisation de l’IA certifiée », « droits garantis » ou « sans deepfake » lorsqu’elles reposent uniquement sur une crédential. Évitez aussi de dire « non généré par IA » au seul motif qu’aucune crédential n’apparaît. Ces formulations confondent les éléments de provenance avec la vérification des faits, l’analyse forensique, les droits ou l’absence d’une technique.
Dans l’Union européenne, les obligations de transparence applicables à certains contenus générés ou manipulés par IA nécessitent une analyse distincte de la crédential technique. Les orientations de la Commission européenne indiquent qu’un marquage lisible par machine ne suffit pas, à lui seul, lorsqu’il convient d’informer les personnes. L’applicabilité concrète dépend du cas, du rôle de l’organisation, des exceptions et du calendrier réglementaire ; elle doit être examinée avec un conseil juridique pour chaque publication.
Registre interne minimal et évaluation des fournisseurs
Un registre interne cohérent permet d’expliquer les décisions plusieurs mois plus tard, lorsqu’une plateforme a déjà remplacé la copie publiée ou qu’un fournisseur a modifié son produit. Incluez un identifiant du fichier et de chaque version, l’emplacement de l’original non altéré, l’origine de la réception ou de la production, l’outil et la version déclarés, l’opérateur ou responsable, les dates pertinentes et l’objectif de l’usage. Ajoutez le résultat complet de validation, le validateur utilisé et les avertissements détectés.
Conservez séparément les éléments de licence, de cession, d’autorisation contractuelle, de consentement des personnes représentées, de restrictions territoriales et de toute vérification d’exactitude factuelle. Si un document n’existe pas ou si l’organisation n’a pas vérifié un point, le registre doit l’indiquer expressément. Réunir ces catégories sous un unique statut « approuvé » empêche de savoir ce qui a réellement été vérifié.
Avant de souscrire à un outil visuel ou de l’intégrer, demandez des démonstrations reproductibles à l’aide de fichiers de test. Demandez quels formats prennent en charge les crédentials, comment elles sont conservées lors de la génération, de la modification, du téléchargement et de la remise en ligne, quelles déclarations sont émises et comment les actifs se comportent après leur passage par les véritables destinations de publication. Testez à la fois des cas positifs et des fichiers sans crédential, avec des crédentials endommagées ou avec des transformations ultérieures.
Cette diligence est particulièrement nécessaire lorsque des capacités sont attribuées à des noms de modèles ou de produits tels que GPT‑Image‑2.5 Sunburst, Sora 2 Pro, Nano Banana 2 ou Veo 3.1. Il ne faut pas affirmer que l’un d’eux génère, préserve, met à jour ou supprime des crédentials C2PA sans documentation technique vérifiable et sans tests sur la version précise. Les noms commerciaux ne remplacent pas une vérification du produit, de la configuration et de la date.
Champs minimaux du dossier interne
| Champ | Finalité |
|---|---|
| Identifiant et version du fichier | Relier les éléments et la décision à un objet précis |
| Original et lieu de conservation | Permettre une validation ultérieure |
| Origine, outil, version et opérateur | Documenter le flux déclaré |
| Rapport de validation et outil utilisé | Rendre l’audit reproductible |
| Licence, consentement et restrictions | Distinguer les conditions juridiques de la provenance technique |
| Décision, responsable et étiquette publiée | Expliquer ce qui a été autorisé et pourquoi |
Liste de contrôle finale
Avant de publier, d’archiver, d’acquérir ou de réutiliser un actif, vérifiez que la version exacte a été identifiée ; que l’original disponible est conservé ; que la validation a été effectuée avec un outil et une version enregistrés ; que les actions, les ingrédients et l’émetteur ont été lus ; et que les avertissements ont été consignés. Si une plateforme intervient dans le flux, examinez également la copie qu’elle remet à l’utilisateur final.
Examinez ensuite, en dehors de C2PA, ce que la crédential ne résout pas : licence et portée d’utilisation, consentement, protection des données, identité des personnes, exactitude factuelle, contexte potentiellement trompeur et exigences de divulgation applicables. Une politique utile attribue ces contrôles à des responsables distincts, tout en coordonnant leurs résultats dans le même dossier.
Enfin, ne communiquez que ce qui peut être étayé. La provenance fonctionne mieux comme une couche d’éléments traçables que comme une étiquette définitive. L’adoption de cette discipline permet de tirer parti de crédentials vérifiables sans transformer leur présence en promesse d’authenticité totale, ni leur absence en accusation infondée.
Questions ouvertes
- Le comportement des crédentials dans un outil, un format, une version logicielle ou une plateforme précise doit être vérifié par des essais reproductibles ; il ne peut être déduit d’une seule affirmation commerciale.
- La confiance qu’une organisation accorde à un émetteur ou à un certificat dépend de ses politiques et du contexte d’utilisation.
- L’application des obligations légales de transparence dépend de la juridiction, de la date, du type de contenu, du rôle de l’organisation et d’éventuelles exceptions.
- Aucune documentation technique vérifiée n’a été fournie permettant d’attribuer des capacités précises de provenance à GPT‑Image‑2.5 Sunburst, Sora 2 Pro, Nano Banana 2 ou Veo 3.1.
Poursuivre l’exploration
Sources consultées
Corrections et transparence
Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.
Proposer une correction