EU AI Act et California AI Transparency Act 2026 : que doivent changer les développeurs ?

Votre produit GenAI saura-t-il prouver l’origine de ses contenus le 2 août 2026 ?

Votre équipe génère déjà des textes, des images, des voix ou des vidéos pour des clients européens et californiens. Pourtant, une question plus difficile que l’ajout d’une simple mention « contenu généré par IA » reste souvent sans réponse : que se passe-t-il lorsque le fichier est exporté, retouché, envoyé vers une autre plateforme, puis examiné par un utilisateur ou une autorité ?

Le 2 août 2026 marque une étape importante. L’article 50 du règlement européen sur l’intelligence artificielle devient applicable, tandis que le California AI Transparency Act, modifié par l’AB 853, devient opératoire en Californie à la même date. Les deux textes poursuivent un objectif commun — rendre l’origine artificielle plus compréhensible et vérifiable — mais ils ne demandent pas exactement la même chose aux fournisseurs, aux déployeurs, aux plateformes et aux fabricants.

La difficulté n’est donc pas uniquement juridique. Elle concerne l’architecture du produit, les métadonnées, les flux d’export, les contrats avec les fournisseurs de modèles et la conservation des preuves de contrôle.

Quelles règles entrent réellement en application le 2 août 2026 ?

Le calendrier doit être lu avec précision, car toutes les obligations ne commencent pas au même moment.

Dans l’Union européenne, l’article 50 du EU AI Act impose notamment aux fournisseurs de certains systèmes d’informer les personnes lorsqu’elles interagissent avec une IA et de concevoir les systèmes générant du contenu synthétique afin que leurs sorties soient marquées dans un format lisible par machine et détectables comme générées ou manipulées par IA. Les déployeurs doivent, dans certains cas, signaler visiblement les deepfakes ainsi que les textes générés ou manipulés par IA lorsqu’ils sont publiés pour informer le public sur des sujets d’intérêt général. (digital-strategy.ec.europa.eu)

La Commission européenne indique également une période transitoire ciblée jusqu’au 2 décembre 2026 pour certaines obligations de marquage et de détection concernant des systèmes génératifs déjà mis sur le marché avant le 2 août 2026. Cette tolérance ne doit pas être interprétée comme une dispense générale : les équipes doivent vérifier précisément si leur système et leur obligation entrent dans ce cas. (digital-strategy.ec.europa.eu)

En Californie, l’AB 853 rend le California AI Transparency Act opératoire le 2 août 2026. Le texte vise notamment les personnes qui créent, codent ou produisent un système GenAI accessible dans l’État et comptant plus de 1 000 000 de visiteurs ou utilisateurs mensuels. Ces fournisseurs couverts doivent proposer gratuitement un outil de détection permettant notamment d’évaluer si une image, une vidéo ou un fichier audio a été créé ou modifié par leur système et d’afficher les données de provenance détectées. (leginfo.legislature.ca.gov)

Les autres échéances sont échelonnées :

• le 1er janvier 2027, certaines obligations supplémentaires concernent les grandes plateformes en ligne et les plateformes d’hébergement de systèmes GenAI ;
• le 1er janvier 2028, les fabricants d’appareils de capture concernés devront proposer et intégrer par défaut certaines informations de divulgation latente, lorsque cela est techniquement faisable ;
• une violation peut être considérée comme distincte pour chaque jour de non-conformité, avec une pénalité civile pouvant atteindre 5 000 dollars par violation selon le texte californien. (leginfo.legislature.ca.gov)

Pour un CTO, la première décision consiste donc à séparer les obligations applicables immédiatement des fonctionnalités prévues dans les versions 2027 et 2028. Une feuille de route qui traite tout comme une seule exigence risque de mobiliser inutilement l’équipe ou, à l’inverse, de laisser un défaut critique dans le parcours de génération.

Qui est responsable : fournisseur, déployeur ou plateforme ?

Le EU AI Act et le droit californien ne placent pas la responsabilité au même endroit.

Dans le cadre européen, le fournisseur conçoit ou met à disposition le système. Il doit donc prévoir l’information dans l’interface et le marquage lisible par machine lorsque le système produit du contenu synthétique. Le déployeur, lui, utilise le système sous son autorité. Il peut être responsable de l’affichage visible d’un deepfake publié dans une campagne, un outil de création vidéo ou une plateforme éditoriale.

Cette distinction devient particulièrement importante pour les logiciels B2B. Une entreprise peut fournir une API de génération d’images, tandis que son client crée les supports publicitaires, les publications sociales ou les vidéos de formation. Le contrat doit alors préciser qui ajoute le libellé visible, qui conserve les données de provenance et qui vérifie le résultat après export.

En Californie, le seuil de 1 000 000 de visiteurs ou utilisateurs mensuels vise spécifiquement la définition du « covered provider ». Le texte définit également le système GenAI comme un système capable de générer du contenu synthétique, notamment du texte, des images, de la vidéo ou de l’audio. Les plateformes de téléchargement de code source ou de poids de modèles, les grandes plateformes en ligne et les fabricants d’appareils de capture entrent dans des catégories distinctes, avec des dates d’application différentes. (leginfo.legislature.ca.gov)

Une équipe située hors de l’Union européenne ou de la Californie ne devrait donc pas conclure trop vite qu’elle est hors périmètre. La mise à disposition d’un service dans ces territoires, l’accès par des utilisateurs locaux ou l’intégration du produit dans une offre distribuée sur place peuvent créer un point de rattachement à analyser avec le conseil juridique.

EU AI Act et California AI Transparency Act : quelle différence opérationnelle ?

Les deux régimes se recoupent sur la provenance et la transparence, mais leurs priorités divergent.

Ce tableau est une analyse pratique de mise en œuvre, et non une interprétation juridique personnalisée. Il montre cependant un point essentiel : un filigrane visuel unique ne suffira probablement pas à couvrir les deux régimes.

Que signifie concrètement le marquage lisible par machine ?

Un marquage lisible par machine est une information intégrée au fichier ou à ses métadonnées afin qu’un logiciel puisse détecter et interpréter l’origine, le système utilisé ou l’historique de modification sans dépendre uniquement de ce que l’utilisateur voit à l’écran.

Cela peut inclure :

• l’identification du système ayant généré le contenu ;
• le type de contenu produit, comme une image, une vidéo ou une piste audio ;
• la date de création ou de modification ;
• l’existence d’une signature numérique ;
• l’historique des transformations ;
• l’indication qu’un contenu a été généré ou substantiellement modifié.

Cette couche est différente d’un filigrane visible. Une mention dans un coin d’image peut aider l’utilisateur à comprendre l’origine du visuel, mais elle peut être recadrée, masquée ou supprimée lors d’une retouche. À l’inverse, un marquage intégré peut être invisible tout en restant exploitable par un outil de vérification.

Pour le texte, l’approche est plus délicate. Le texte peut être copié-collé dans un autre éditeur, traduit, résumé ou fusionné avec une rédaction humaine. Le produit doit donc documenter ce qu’il marque réellement, à quel moment le marquage est appliqué et dans quelles opérations il peut disparaître.

Pour l’audio et la vidéo, les risques sont encore plus concrets : changement de conteneur, recompression, montage, extraction d’une piste audio ou publication sur un réseau qui supprime les métadonnées. Le flux de conformité doit tester ces transformations, pas uniquement la génération du fichier original.

Et la divulgation latente, est-ce simplement un filigrane invisible ?

Non. La divulgation latente désigne une information présente mais non manifeste pour une personne. Dans le texte californien, les données de provenance servent à vérifier l’authenticité, l’origine ou l’historique des modifications. Les données de provenance du système peuvent notamment indiquer le type de dispositif, de système ou de service utilisé pour créer le contenu, ainsi que des informations liées à son authenticité. (leginfo.legislature.ca.gov)

La bonne architecture sépare trois niveaux :

1. Le signal utilisateur : une indication claire dans l’interface ou sur le contenu.
2. La donnée technique : un marquage intégré, une signature ou une métadonnée vérifiable.
3. La preuve interne : journaux, versions du modèle, identifiant de génération et résultat du contrôle.

Cette séparation protège aussi la vie privée. Il ne faut pas injecter automatiquement des informations personnelles ou un identifiant d’utilisateur dans chaque fichier. L’équipe doit décider quelles données sont nécessaires à la provenance et lesquelles doivent rester dans un journal interne protégé.

Votre outil de détection doit-il identifier tous les contenus générés par IA ?
Pas nécessairement. Un outil sérieux doit décrire son périmètre : formats supportés, fournisseurs de modèles reconnus, données de provenance présentes, fichiers modifiés et cas indéterminés. Une réponse « probablement humain » ne doit pas être présentée comme une preuve absolue si le système n’a détecté aucune donnée technique.

Comment adapter le produit en au moins cinq étapes ?

1. Cartographiez les contenus et les territoires

Listez les sorties produites par votre service : texte, image, audio, vidéo ou combinaison de plusieurs formats. Pour chaque fonctionnalité, indiquez si elle est destinée à des utilisateurs de l’Union européenne, de la Californie ou d’autres marchés.

Ajoutez les cas créatifs souvent oubliés : voix de synthèse, doublage multilingue, avatar vidéo, retouche d’une photographie, génération d’une maquette publicitaire et composition musicale.

2. Séparez les responsabilités produit

Attribuez une responsabilité à chaque étape : génération, modification, export, publication et vérification. Le fournisseur de l’API ne doit pas supposer que le client final affichera correctement le label visible. Le client ne doit pas supposer que le fournisseur garantit la conservation de la provenance après une conversion de format.

3. Écrivez le marquage dès la sortie du modèle

Le marquage ne doit pas être ajouté uniquement lors de la publication finale. Il doit accompagner la sortie dès sa création, puis être contrôlé après chaque opération susceptible de modifier le fichier.

Pour une vidéo, testez au minimum la génération, le montage, la compression et l’export. Pour un audio, ajoutez les conversions de fréquence, le mixage et la normalisation du volume. Pour une image, vérifiez la retouche, le redimensionnement et la conversion de format.

4. Construisez un vérificateur indépendant

Le vérificateur doit pouvoir recevoir un fichier, examiner les données disponibles, produire une réponse compréhensible et conserver un identifiant de contrôle. En Californie, l’outil destiné à l’utilisateur doit être accessible gratuitement pour les fournisseurs couverts. (leginfo.legislature.ca.gov)

Prévoyez au moins quatre réponses : provenance confirmée, provenance absente, provenance invalide ou fichier non pris en charge. Évitez le résultat binaire qui donnerait une illusion de certitude.

5. Testez les pertes de métadonnées

Envoyez les fichiers dans les principaux parcours de votre produit : téléchargement, stockage, partage, conversion et diffusion par API. Mesurez à quel endroit les informations disparaissent.

Cette étape doit inclure les dépendances tierces. Si votre service appelle plusieurs modèles, demandez à chaque fournisseur quels signaux de provenance sont produits, conservés ou supprimés. L’absence d’engagement contractuel crée un angle mort difficile à défendre.

6. Conservez les preuves de décision

Enregistrez la version du système, le type de contenu, l’identifiant de génération, les paramètres utiles, le résultat de la vérification et les éventuelles interventions humaines. La conservation doit respecter votre politique de confidentialité et limiter les données personnelles.

Les équipes qui travaillent déjà sur des environnements de test peuvent structurer cette validation avec une infrastructure Mac dédiée aux essais et aux prototypes, notamment pour les flux créatifs audio et vidéo.

7. Préparez les interfaces et les contrats

Ajoutez les mentions visibles dans l’interface, la documentation API et les exports. Dans les contrats B2B, précisez qui est fournisseur, qui est déployeur, qui contrôle la publication et qui répond aux demandes de vérification.

« Nous ajoutons déjà un filigrane : sommes-nous prêts ? »

C’est l’un des pièges les plus fréquents. Un filigrane visible peut être utile, mais il ne prouve pas à lui seul que le fichier conserve une provenance vérifiable. Il peut également être absent des textes, inaudible dans une piste audio ou supprimé par une chaîne de montage.

Autres erreurs courantes :

• marquer uniquement les contenus générés par le modèle principal, mais pas ceux produits par une fonction de retouche ;
• oublier les sorties générées par un fournisseur externe intégré par API ;
• vérifier le fichier original, mais jamais le fichier téléchargé par le client ;
• traiter l’absence de métadonnées comme une preuve que le contenu est humain ;
• ne pas distinguer une intervention humaine éditoriale d’une simple correction automatique ;
• conserver des journaux impossibles à relier à la version exacte du modèle ;
• confondre l’outil de détection avec un détecteur statistique de style rédactionnel.

La Commission européenne précise que le code de bonnes pratiques constitue un outil volontaire pouvant aider les fournisseurs et déployeurs à démontrer leur conformité, mais qu’un acteur qui ne le signe pas reste responsable de démontrer ses propres mesures par d’autres moyens appropriés. (digital-strategy.ec.europa.eu)

Cas concret : une plateforme de création vidéo opérant en Europe et en Californie

Prenons une plateforme B2B qui permet de transformer un script en vidéo avec narration synthétique, images générées et sous-titres automatiques.

Pour l’Union européenne, l’équipe doit examiner le marquage machine des sorties et la divulgation visible lorsque la vidéo constitue un deepfake. Si la vidéo est publiée pour informer le public sur un sujet d’intérêt général, le texte accompagnant la publication peut également nécessiter une divulgation, sous réserve des exceptions applicables.

Pour la Californie, la première question est le seuil d’utilisateurs ou de visiteurs mensuels. Si la plateforme est un fournisseur couvert, elle doit proposer un outil gratuit permettant d’examiner les images, vidéos et fichiers audio associés à son système et de restituer les données de provenance détectées. La plateforme doit aussi prévoir les évolutions concernant les grandes plateformes en ligne à partir du 1er janvier 2027. (leginfo.legislature.ca.gov)

La même fonction « exporter une vidéo » nécessite donc :

• une donnée technique intégrée au fichier ;
• un libellé visible adapté au contexte ;
• une page ou une API de vérification ;
• un journal interne reliant le fichier à la génération ;
• une procédure de dégradation lorsque les métadonnées sont perdues.

Quelle priorité donner avant la mise en production ?

Commencez par les contenus les plus exposés : vidéos réalistes de personnes, voix imitant un intervenant, images publicitaires et textes publiés comme information. Ces formats présentent davantage de risques de confusion et demandent des tests de chaîne complète.

Ensuite, traitez les dépendances externes. Un produit dont le modèle est fourni par un tiers doit obtenir des garanties sur le marquage, la documentation des sorties et la stabilité des interfaces. Si le fournisseur change le format de métadonnées sans préavis, votre conformité peut se dégrader sans modification apparente de votre code.

Enfin, mettez en place une revue conjointe produit, ingénierie et conformité. La conformité ne peut pas être déléguée entièrement à un module technique : il faut décider quand une divulgation est visible, comment présenter un résultat indéterminé et quelles preuves sont conservées.

Votre configuration actuelle est-elle adaptée à ces tests ?

Pour les équipes qui doivent comparer plusieurs configurations sans immobiliser un budget matériel pendant des mois, les formules de location Mac de SpinMac peuvent servir à isoler un environnement de validation. La location ne remplace ni l’analyse juridique ni la conception du marquage, mais elle peut réduire les délais liés à l’achat, au déploiement et au renouvellement d’un parc de test.

Un poste Windows ou Linux existant peut convenir pour une première preuve de concept. En revanche, il devient moins confortable lorsque l’équipe doit reproduire plusieurs scénarios audio et vidéo, maintenir une configuration identique pour plusieurs développeurs et conserver un environnement stable pendant une campagne de tests. Le cloud ajoute souvent de la latence, des coûts variables et une dépendance au réseau pour les fichiers volumineux. À l’inverse, louer un Mac auprès de SpinMac permet de disposer d’un environnement de test séparé sans transformer immédiatement un prototype de conformité en projet d’achat matériel.

Avant le 2 août 2026, enregistrez la matrice des contenus, testez le marquage machine après export, vérifiez l’outil de détection et faites relire les rôles fournisseur-déployeur par vos équipes compétentes. Cette préparation donnera à votre organisation une base vérifiable pour les marchés européen et californien, sans confondre une mesure technique avec un avis juridique. Cet article fournit une analyse opérationnelle et ne constitue pas un conseil juridique.