Pourquoi votre plateforme détruit la provenance de vos images
Une identité de provenance C2PA vit dans quelques octets précis d'un fichier. N'importe quelle opération qui ré-encode l'image (un import de CMS, un CDN, une capture d'écran) efface ces octets. Voici où ils se trouvent, pourquoi ils disparaissent, et comment vérifier ce qui reste réellement en ligne.
Page informative, ce n'est pas un conseil juridique. Vérifiez votre situation avec un professionnel du droit qualifié pour toute question de conformité.
Un Content Credential C2PA (la norme derrière les « Content Credentials ») est un petit conteneur de métadonnées signées (un manifeste JUMBF) inséré dans le fichier image lui-même : dans un PNG, il vit dans un bloc caBX, avec les métadonnées XMP compagnes dans un bloc iTXt. Ce manifeste est lié cryptographiquement aux octets exacts du fichier au moment de sa création. Or presque toute manipulation ultérieure de l'image (import dans un CMS, passage par un CDN qui redimensionne pour chaque taille d'écran, conversion PNG vers WebP, capture d'écran, réexport depuis un éditeur) modifie ces octets ou supprime purement le bloc de métadonnées, ce qui invalide ou efface le manifeste. Le paradoxe documenté est que les plateformes les plus engagées publiquement dans la coalition C2PA font tourner, pour des raisons de performance légitimes, les mêmes pipelines de recompression qui détruisent ce qu'elles promeuvent. C'est pour cela que le filigrane invisible au niveau des pixels (type SynthID) existe en complément : il est conçu pour survivre au recadrage et à la compression, précisément là où le C2PA ne le peut pas. Sous l'article 50(2) de l'AI Act, l'obligation de marquage lisible par machine pèse sur le fournisseur du système d'IA au moment de la génération. Elle ne garantit rien sur ce que devient l'image ensuite, ce qui laisse le marchand sans preuve de provenance technique dès que son propre pipeline a recompressé le fichier. La dernière section explique comment vérifier, concrètement, ce qu'affichent vos propres images produit en ligne aujourd'hui.
Ce qu'est un Content Credential C2PA, et où il vit dans le fichier
C2PA (Coalition for Content Provenance and Authenticity) est la norme technique derrière ce que les outils affichent sous le nom « Content Credentials » : un manifeste indiquant qui a créé ou modifié l'image, avec quel outil, à quelle date, et avec quelles assertions sur la nature du contenu (généré par IA, retouché, capturé), signé cryptographiquement et horodaté. Ce manifeste n'est pas un fichier séparé ni une entrée de base de données externe : il est encodé au format JUMBF (JPEG Universal Metadata Box Format, malgré le nom utilisable au-delà du JPEG) et inséré directement dans le fichier image.
Concrètement, dans un fichier PNG (le format que produit MannequinIA), le manifeste C2PA occupe un bloc ancillaire caBX, et les métadonnées XMP compagnes, dont la propriété IPTC DigitalSourceType qui déclare un contenu généré par IA, vivent dans un bloc iTXt. Dans un JPEG, le conteneur diffère (un segment APP11 portant la boîte JUMBF), mais le principe est identique : la preuve de provenance est un morceau de données binaires cousu dans le fichier, pas un attribut qui voyage à côté de lui.
Pourquoi un simple ré-encodage suffit à tout effacer
Le manifeste C2PA contient une liaison cryptographique (un hash) calculée sur les octets exacts du fichier au moment de sa signature. Redimensionner l'image, la recompresser à un taux de qualité différent, ou changer son format modifie ces octets : le hash ne correspond plus, et le manifeste devient invalide même s'il est techniquement encore présent dans le fichier.
Dans la pratique, le cas le plus fréquent est plus radical encore : la plupart des bibliothèques de traitement d'image ré-encodent un fichier en ne conservant que les blocs qu'elles reconnaissent explicitement, et suppriment silencieusement les blocs ancillaires qu'elles ne traitent pas, ce qui inclut, par défaut, un bloc caBX ou un segment JUMBF que l'outil ne sait pas interpréter. Le manifeste ne devient pas seulement invalide : il disparaît purement et simplement du fichier de sortie. Un import dans un CMS, un CDN qui génère plusieurs tailles pour le responsive, une conversion vers WebP ou AVIF pour la performance, une capture d'écran, un réenregistrement depuis un éditeur d'image : chacune de ces opérations, parfaitement anodine et sans intention de dissimuler quoi que ce soit, produit le même résultat.
Le paradoxe des plateformes qui promeuvent le C2PA
Le constat documenté est presque contre-intuitif : certaines des plateformes les plus visibles dans la promotion publique du C2PA (réseaux sociaux, places de marché, outils créatifs) exploitent, pour des raisons de performance parfaitement légitimes, des pipelines de traitement d'image qui recompressent et redimensionnent systématiquement chaque fichier importé pour le servir à la bonne taille sur chaque écran. Ce sont exactement les opérations qui détruisent le bloc de métadonnées C2PA décrit plus haut. Il n'y a pas de mauvaise foi dans ce constat : servir des images rapidement à l'échelle d'une plateforme et préserver un conteneur de métadonnées binaires jusqu'ici non standardisé dans les pipelines existants sont deux contraintes qui, à ce stade de maturité de l'écosystème, ne sont pas encore réconciliées par défaut. Le résultat pratique est le même quelle que soit l'intention : une image peut quitter son générateur marquée, et arriver sur l'écran d'un acheteur totalement dépouillée de cette preuve.
Pourquoi le filigrane invisible est le complément, pas un doublon
C'est précisément parce que le C2PA est fragile face au ré-encodage qu'un filigrane invisible au niveau des pixels (du type SynthID) existe comme couche complémentaire, et non redondante. Un tel filigrane est conçu pour survivre au recadrage, à la recompression et au changement de format (les opérations mêmes qui détruisent le C2PA), parce qu'il est encodé dans les valeurs de pixels de l'image plutôt que dans un conteneur de métadonnées séparé. Aucune des deux couches n'est suffisante seule : le C2PA porte des informations riches (qui, quand, avec quel outil) mais casse facilement ; le filigrane pixel résiste mieux mais ne porte, en général, qu'un signal binaire (généré par IA ou non), sans le détail du manifeste. Un marchand ne devrait donc s'appuyer sur aucune des deux couches isolément, quel que soit l'outil utilisé pour générer ses visuels.
Pourquoi cela compte au titre de l'article 50(2) de l'AI Act
L'article 50(2) du règlement européen sur l'intelligence artificielle impose au fournisseur du système d'IA, l'éditeur du modèle de génération, de marquer ses images produites dans un format lisible par machine et détectable comme artificiel. Cette obligation porte sur le moment de la génération : c'est au fournisseur du modèle qu'il revient de marquer sa sortie, pas au marchand qui la publie ensuite. Mais c'est exactement ce qui rend le mécanisme décrit dans cet article pertinent pour un e-commerçant : une image sortie conforme du générateur peut arriver, une fois passée par le pipeline du marchand, sans aucune trace technique vérifiable de son origine, ce qui ne remet pas en cause la conformité du fournisseur, mais prive le marchand de la preuve de provenance sur laquelle il pourrait vouloir s'appuyer pour sa propre transparence, y compris pour la question distincte de la divulgation au titre de l'article 50(4).
L'articulation complète entre les deux obligations de l'article 50 est détaillée dans notre article dédié. Article 50 de l'AI Act →
Ce que fait MannequinIA et ce qui lui arrive ensuite
Chaque image générée par MannequinIA porte, à la sortie du studio, un Content Credential C2PA signé et horodaté cryptographiquement, délivré par le fournisseur du modèle de génération (Google Media Processing Services, rattaché à la Google C2PA Root CA G3), ainsi que la propriété XMP IPTC DigitalSourceType avec la valeur trainedAlgorithmicMedia. Ce marquage a été vérifié le 28 juillet 2026 par inspection binaire directe d'un fichier PNG 4K produit en environnement de production : les blocs caBX et iTXt décrits plus haut y étaient bien présents.
Les modèles de génération que nous utilisons intègrent par ailleurs, selon la documentation publique de leur fournisseur, un filigrane invisible de type SynthID au niveau des pixels : une propriété documentée du modèle en amont, que nous ne vérifions pas nous-mêmes par inspection de fichier, puisqu'elle n'est pas conçue pour être détectable de cette façon.
Vos visuels partent donc du studio avec leur provenance attachée, vérifiable par n'importe qui, sans que vous ayez la moindre manipulation à faire. Ce qui se passe ensuite ne dépend plus d'aucun générateur : la limite décrite dans cet article est celle du format lui-même, et elle vaut pour tout fichier marqué, quel que soit l'outil qui l'a produit. C'est exactement pour cette raison que nous consacrons une section entière à la façon de contrôler vos propres visuels en ligne, et que le filigrane au niveau des pixels existe en complément du C2PA plutôt qu'en doublon. Un dernier point à garder en tête : ce marquage ne se substitue pas à votre obligation de déployeur au titre de l'article 50(4) de l'AI Act. C'est à vous qu'il revient de décider si, et comment, divulguer le caractère IA d'un visuel publié.
Le détail complet de notre marquage est expliqué sur notre page de transparence IA. Transparence IA →
Questions fréquentes
01Qu'est-ce qu'un Content Credential C2PA, concrètement ?
C'est un manifeste de métadonnées signé cryptographiquement, encodé au format JUMBF et inséré directement dans le fichier image, pas un fichier séparé ni une entrée externe. Il déclare qui a créé ou modifié l'image, avec quel outil, à quelle date, et avec quelles assertions sur sa nature (générée par IA, retouchée, capturée).
02Pourquoi un simple redimensionnement suffit-il à l'effacer ?
Le manifeste est lié cryptographiquement aux octets exacts du fichier au moment de sa signature ; changer ces octets invalide cette liaison. Dans la pratique, c'est souvent pire : la plupart des outils de traitement d'image suppriment purement les blocs de métadonnées qu'ils ne reconnaissent pas lors d'un ré-encodage, donc le manifeste ne devient pas seulement invalide, il disparaît du fichier.
03Les plateformes qui promeuvent le C2PA le préservent-elles réellement ?
Pas systématiquement, et c'est documenté : certaines des plateformes les plus engagées publiquement dans la coalition C2PA exploitent, pour des raisons de performance légitimes, des pipelines qui recompressent chaque image importée, ce qui détruit le même manifeste qu'elles promeuvent. Ce n'est pas de la mauvaise foi, c'est que les deux contraintes ne sont pas encore réconciliées par défaut dans l'écosystème actuel.
04Un filigrane invisible (type SynthID) remplace-t-il le C2PA ?
Non, il le complète. Le filigrane pixel est conçu pour survivre au recadrage et à la compression là où le C2PA ne le peut pas, mais il porte en général un signal plus pauvre (généré par IA ou non) que le manifeste C2PA complet. Les deux couches sont complémentaires, aucune n'est suffisante seule.
05Comment vérifier si mes images produit affichent encore leurs identifiants C2PA ?
Téléchargez le fichier réellement servi sur votre fiche produit en ligne, pas votre fichier d'origine, et passez-le dans le vérificateur ouvert de la coalition C2PA (contentcredentials.org/verify). Répétez le test sur chaque variante affichée par votre site (miniature, fiche, zoom, image de partage social), car chacune peut avoir subi un traitement différent.
06Le C2PA effacé signifie-t-il que je suis en infraction avec l'AI Act ?
Pas automatiquement : l'obligation de marquage machine-readable de l'article 50(2) pèse sur le fournisseur du système d'IA au moment de la génération, pas sur le marchand qui publie ensuite. Un C2PA absent vous prive surtout d'une preuve technique de provenance, ce qui reste distinct de votre propre obligation de déployeur au titre de l'article 50(4).
07Mes images MannequinIA restent-elles marquées une fois publiées ?
Elles sortent du studio avec un Content Credential signé et horodaté, et le conservent tant que le fichier n'est pas ré-encodé. Au-delà, la question ne se joue plus au niveau du générateur mais à celui de votre chaîne de publication : aucune métadonnée ne survit à un redimensionnement, quel que soit l'outil qui l'a produite. La section précédente explique comment contrôler ce que votre plateforme conserve réellement, et le filigrane au niveau des pixels est justement la couche conçue pour résister là où le C2PA ne le peut pas.
Comment vérifier vos propres images produit en ligne
Trois vérifications concrètes, indépendantes de l'outil utilisé pour générer l'image d'origine :
Pour une inspection plus technique
Un fichier PNG est une simple suite de blocs ; un outil qui liste ces blocs (par exemple pngcheck -v en ligne de commande, ou n'importe quel éditeur hexadécimal) permet de vérifier directement la présence d'un bloc caBX sans dépendre d'un service tiers. L'absence de ce bloc, sur le fichier réellement téléchargé depuis votre site, est la preuve la plus directe que la provenance a été perdue en cours de route.
Cela ne signifie pas automatiquement que vous êtes en infraction : l'obligation de marquage de l'article 50(2) pèse sur le fournisseur du système de génération, pas sur vous. Cela signifie que vous avez perdu la trace technique de provenance sur laquelle vous pourriez vouloir vous appuyer : pour votre propre transparence, pour répondre à une question d'un client, ou en cas de litige sur l'origine d'un visuel.