Québec, Canada

403-1381 1re Avenue

+1 581.849.27.96

bdgouthiere@gmail.com

Contenu généré par IA : ce que ton appli doit afficher depuis le 2 août 2026

Ou : Comment l’Europe a exigé que les machines se présentent avant de parler

Depuis le 2 août 2026, l’article 50 du règlement européen sur l’intelligence artificielle, l’AI Act, s’applique en entier. Il pose quatre obligations de transparence. Un assistant conversationnel doit prévenir qu’il n’est pas humain. Une image, une vidéo, un son ou un texte produits par un système génératif doivent porter une marque lisible par machine. Un hypertrucage doit être signalé comme tel, tout comme un texte généré et publié pour informer le public, sauf relecture humaine. Et une reconnaissance des émotions doit être annoncée aux personnes qu’elle observe. L’« omnibus numérique » adopté le 8 juillet 2026 n’a reporté qu’un morceau de l’ensemble : le marquage des systèmes déjà sur le marché, jusqu’au 2 décembre 20261. Le reste s’applique, avec des amendes qui peuvent atteindre 15 millions d’euros.

Ce n’est pas un avis juridique, mais la lecture d’un développeur qui a ouvert le règlement, les lignes directrices et le code de bonnes pratiques de la Commission. La réponse dépend d’abord d’un mot.

Article 50 de l’AI Act : marquage, étiquette et chatbot, qui doit faire quoi

Fournisseur ou déployeur, le mot qui décide de tout

Le règlement répartit les obligations entre deux rôles. Le fournisseur développe un système d’IA, ou le fait développer, et le met sur le marché « sous son propre nom ou sa propre marque, à titre onéreux ou gratuit ». Le déployeur l’utilise « sous sa propre autorité », sauf dans le cadre d’une activité personnelle non professionnelle. Les paragraphes 1 et 2 de l’article 50 visent le fournisseur, les paragraphes 3 et 4 le déployeur2.

Le cas qui intéresse un développeur web est celui de l’application qui appelle l’API d’un modèle tiers. Les lignes directrices publiées par la Commission le 20 juillet 2026 donnent un exemple très proche : une entreprise qui propose sous son nom une application de discussion, un générateur d’images ou un agent est un fournisseur, que le service soit gratuit ou payant, l’entreprise européenne ou non3. Le cas de la fine enveloppe autour d’une API n’est pas tranché en toutes lettres. L’exemple lui ressemble beaucoup.

DevOps Dave : On appelle juste l’API d’un modèle. La conformité, c’est le problème de son éditeur.

Security Sarah : Ton assistant porte quel nom, sur la page d’accueil ?

DevOps Dave : Le nôtre. Avec notre logo.

Security Sarah : Le règlement lit ta page d’accueil avant ton contrat d’API.

ParagrapheQuiObligationCe que ça donne dans l’appli
50(1)FournisseurInformer qu’on échange avec une IA, sauf si c’est évidentUn message visible dès la première interaction
50(2)FournisseurMarquer les sorties dans un format lisible par machineMétadonnées signées et filigrane invisible
50(3)DéployeurPrévenir les personnes exposées à une reconnaissance des émotions ou à une catégorisation biométriqueUne information au plus tard à la première exposition
50(4)DéployeurSignaler un hypertrucage, ou un texte généré publié sur une question d’intérêt publicUne étiquette perceptible sans outil

Le chatbot qui se présente avant de parler

Le paragraphe 5 fixe la forme de toutes ces informations : elles doivent être « claires et reconnaissables », données « au plus tard au moment de la première interaction ou de la première exposition », et conformes aux exigences d’accessibilité. Pour un assistant, cela ressemble à un message dans l’interface, au début de la conversation, lisible par un lecteur d’écran. On voit mal une phrase enfouie dans les conditions générales cocher ces trois cases.

L’exception se mérite : pas besoin de prévenir si la nature artificielle de l’échange est évidente pour une personne « normalement informée et raisonnablement attentive et avisée ». Les lignes directrices précisent que c’est au fournisseur d’évaluer et de démontrer cette évidence, en partant du public réellement visé3. Un robot de discussion qui se fait appeler Julien, photo souriante comprise, aura du mal à plaider l’évidence.

Le marquage : deux couches, et un pipeline pour les effacer

Le paragraphe 2 demande des solutions techniques « aussi efficaces, interopérables, solides et fiables que la technologie le permet ». Le code de bonnes pratiques publié le 10 juin 2026 traduit cette phrase en technique. Pour l’audio, l’image et la vidéo, il demande au moins deux couches : des métadonnées signées et horodatées qui déclarent l’origine artificielle, et un filigrane imperceptible incrusté dans le contenu lui-même. Le texte libre, qui ne transporte pas de métadonnées, se contente du filigrane, dont seuls les textes très courts sont dispensés ; au-delà de 200 tokens, il reste exigé même si sa fiabilité baisse. L’empreinte et la journalisation des sorties restent facultatives, et ne suffisent jamais seules4.

Tout ne se marque pas. Les lignes directrices excluent les sorties très courtes, comme un mot isolé, une légende ou un texte alternatif, les échanges de machine à machine, et le code source, commentaires compris. Ton assistant de programmation n’a pas à tatouer ses fonctions.

Le code ne nomme aucune technologie, mais des métadonnées signées qui déclarent l’origine d’un fichier, c’est exactement ce que fait C2PA, le standard ouvert derrière les « Content Credentials ». Sa propre spécification prévoit le cas où ces métadonnées ont été supprimées, et s’en remet alors à un filigrane ou à une empreinte5. Le code demande aussi aux fournisseurs signataires d’interdire, dans leurs conditions d’utilisation, la suppression volontaire de ces marquages. Ton pipeline d’images, lui, n’a jamais lu de conditions d’utilisation.

J’ai fait l’essai avec cwebp, l’outil de conversion WebP de Google, sur une image portant la métadonnée IPTC qui déclare un contenu créé par un modèle d’IA entraîné :

1
2
3
4
5
6
7
# Marquer l'image comme générée par IA (vocabulaire IPTC « Digital Source Type »)
exiftool -overwrite_original -XMP-iptcExt:DigitalSourceType=http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia illustration.jpg

cwebp -q 85 illustration.jpg -o defaut.webp                 # réglage par défaut
cwebp -q 85 -metadata all illustration.jpg -o complet.webp  # tout ce que cwebp sait recopier

exiftool -s -XMP-iptcExt:DigitalSourceType illustration.jpg defaut.webp complet.webp
1
2
3
4
5
6
======== illustration.jpg
DigitalSourceType               : http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia
======== defaut.webp
======== complet.webp
DigitalSourceType               : http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia
    3 image files read

Par défaut, cwebp ne recopie aucune métadonnée. Avec -metadata all, il garde l’EXIF, le profil ICC et le XMP, et rien d’autre : un segment APP11 de test, l’endroit où un JPEG range son manifeste C2PA, n’a survécu à aucune des deux conversions. La chaîne d’illustrations de ce blog va plus loin, sans la moindre malice : l’image générée arrive en JPEG, elle est décodée puis réenregistrée en PNG, ce qui ne garde que les pixels, avant de passer par cwebp. Seul un filigrane incrusté dans les pixels a une chance de traverser ce traitement. C’est précisément pour ça que le code exige deux couches.

L’étiquette, c’est l’affaire du déployeur

Le paragraphe 4 change de destinataire : celui qui publie un hypertrucage doit l’indiquer. Le règlement le définit comme une image, un son ou une vidéo « présentant une ressemblance avec des personnes, des objets, des lieux, des entités ou événements existants », et pouvant passer à tort pour authentique. Une œuvre manifestement artistique, satirique ou fictive s’en tire avec une mention qui n’entrave pas sa jouissance. La foire aux questions de la Commission ferme en revanche une porte que beaucoup espéraient ouverte : le déployeur ne peut pas se reposer sur le marquage invisible posé par le fournisseur6. L’étiquette doit se voir sans outil, et l’Union propose pour cela trois icônes facultatives, construites autour du sigle « AI ».

Pour le texte, l’obligation ne vise que celui qui est publié pour informer le public sur une question d’intérêt public. Elle tombe s’il a fait l’objet d’un examen humain ou d’un contrôle éditorial, et si une personne assume la responsabilité éditoriale de la publication. Les lignes directrices durcissent la nuance : une vérification superficielle, limitée à la grammaire, ne compte pas. Leur contre-exemple décrit des articles générés, relus par une autre IA, puis survolés par un humain. Le paragraphe 3, enfin, vise les déployeurs de reconnaissance des émotions ou de catégorisation biométrique, quand l’article 5 n’interdit pas carrément l’usage, comme sur le lieu de travail ou à l’école.

Le calendrier, après l’omnibus

Les gros titres de l’omnibus numérique ont porté sur les systèmes à haut risque, repoussés à décembre 2027 et août 2028. Pour l’article 50, le règlement (UE) 2026/1744 n’a ajouté qu’un sursis : les fournisseurs de systèmes génératifs mis sur le marché avant le 2 août 2026 ont jusqu’au 2 décembre 2026 pour se conformer au marquage1. Les paragraphes 1, 3 et 4 n’ont pas bougé.

DateCe qui s’applique
2 août 2026Tout l’article 50, marquage compris pour les systèmes mis sur le marché depuis cette date
2 décembre 2026Fin du sursis de marquage pour les systèmes déjà sur le marché avant le 2 août
2 février 2027Détection interopérable, pour les signataires du code

Le code de bonnes pratiques reste volontaire. La Commission et le Comité IA l’ont jugé adéquat dans un avis publié le 9 juillet 2026, et environ 190 organisations l’avaient signé à la fin du mois, dont Anthropic, Google, Meta, Microsoft, Mistral et OpenAI4. Le signer n’achète pas la tranquillité : le même avis précise que l’adhésion ne prouve pas à elle seule la conformité. Un manquement à l’article 50 peut coûter jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu ; pour une PME, c’est le plus faible des deux7.

L’article 50 ne demande pas à l’IA de dire vrai. Il lui demande de se présenter : au début de la conversation, dans les métadonnées du fichier, dans les pixels, et sur l’étiquette quand le contenu sort dans le monde. Pour un développeur, le plus difficile n’est pas le message d’accueil du chatbot. C’est de ne pas effacer, trois étapes plus loin, ce que le fournisseur a pris soin d’écrire. Comme le Cyber Resilience Act et son signalement en 24 heures, le texte part d’une obligation simple à énoncer. Elle se complique le jour où elle croise une commande de conversion d’images écrite il y a trois ans.



  1. Le règlement (UE) 2026/1744, signé le 8 juillet 2026 et publié au Journal officiel le 24 juillet, ajoute un paragraphe 4 à l’article 111 de l’AI Act : les fournisseurs de systèmes qui génèrent des contenus de synthèse « qui ont été mis sur le marché avant le 2 août 2026 prennent les mesures nécessaires pour se conformer à l’article 50, paragraphe 2, d’ici au 2 décembre 2026 ». Le considérant 38 parle d’une « période transitoire de quatre mois ». Le même texte reporte au 2 décembre 2027 et au 2 août 2028 les règles sur les systèmes à haut risque, et réécrit le paragraphe 7 de l’article 50, consacré aux codes de bonne pratique. ↩︎ ↩︎

  2. Règlement (UE) 2024/1689, article 3, points 3 et 4, pour les définitions du fournisseur et du déployeur. L’article 113 fixe l’application générale du règlement au 2 août 2026. ↩︎

  3. Les lignes directrices sur les obligations de transparence, publiées le 20 juillet 2026 et non contraignantes, donnent l’exemple du fournisseur au point 11 : une entreprise qui met sur le marché « a chatbot, image generator, AI agent » sous « its own name or trademark ». L’exception d’évidence est traitée aux points 42 et suivants, où le fournisseur doit « assess and demonstrate » le caractère évident de l’interaction. Les sorties exclues du marquage, dont le code source, sont listées au point 68. ↩︎ ↩︎

  4. La Commission a publié le code de bonnes pratiques le 10 juin 2026. Sa mesure 1.1 demande « at least two layers of machine-readable marking » (sous-mesures 1.1.1 pour les métadonnées signées, 1.1.2 pour le filigrane), la sous-mesure 1.1.3 rend facultatives l’empreinte et la journalisation, la mesure 1.2 prévoit l’interdiction contractuelle de retirer les marquages, et la mesure 3.4 fixe au 2 février 2027 l’interopérabilité des outils de détection. L’avis d’adéquation précise : « Adherence to the code does not constitute conclusive evidence of compliance ». La Commission a fait état d’environ 190 signataires le 31 juillet 2026. ↩︎ ↩︎

  5. La spécification de la « soft binding API » de C2PA vise le cas où « the metadata containing the C2PA Manifest has been stripped », et recourt alors à « an invisible watermark or content fingerprint ». La valeur IPTC utilisée dans l’essai, trainedAlgorithmicMedia, désigne un média « created algorithmically using an Artificial Intelligence model trained on captured content ». Essai réalisé avec cwebp 1.3.2. ↩︎

  6. La foire aux questions de la Commission sur l’article 50 : les déployeurs « cannot simply rely on the machine-readable marking embedded in the content by the provider ». L’hypertrucage est défini à l’article 3, point 60, du règlement. Les icônes européennes d’étiquetage font partie de la section 2 du code, et la fiche de synthèse de la Commission précise qu’aucun étiquetage rétroactif n’est obligatoire pour les hypertrucages créés avant le 2 août 2026. ↩︎

  7. Règlement (UE) 2024/1689, article 99, paragraphe 4, point g), pour le plafond applicable aux obligations de l’article 50, et paragraphe 6 pour les PME. ↩︎