Le 2 août, la question n'est pas « suis-je concerné » mais « dans quel rôle »

Le 2 août 2026, l'article 50 du règlement européen sur l'intelligence artificielle devient applicable. Il porte sur la transparence : ce qu'un système doit dire de lui-même, et ce qu'une organisation doit dire des contenus qu'elle publie.

Deux affirmations opposées circulent à son sujet, et l'une comme l'autre conduisent à mal se préparer. La première : « tout est repoussé, on verra plus tard. » La seconde : « il faut désormais étiqueter tout ce qui est produit avec une IA. »

Le paquet européen de simplification est devenu le règlement (UE) 2026/1744, publié au Journal officiel le 24 juillet 2026 et entré en vigueur le 27. Il reporte bien des obligations — celles des systèmes à haut risque, en 2027 et 2028. Il ne touche pas à l'article 50.

Quant à l'étiquetage généralisé, il n'est écrit nulle part. Et c'est ici que se joue tout ce qui suit, parce que l'article 50 ne distribue pas ses obligations selon la taille de l'entreprise, ni selon le secteur, ni selon le volume publié. Il les distribue selon un rôle. Tant que ce rôle n'est pas identifié, aucune des questions que vous vous posez n'a de réponse.

Deux rôles, et la ligne qui les sépare

Le règlement distingue le fournisseur — celui qui développe un système d'IA et le met sur le marché sous son nom — et le déployeur — celui qui utilise un tel système sous sa propre autorité.

Cette distinction paraît abstraite. Elle décide pourtant de presque tout :

Le marquage technique dont tout le monde parle — celui qui suppose des filigranes, des métadonnées, une détectabilité automatique — relève des paragraphes 1 et 2. Nous avons regardé de près ce qu'un filigrane mesure réellement, qui n'est pas ce qu'on croit y lire. Il pèse sur celui qui fabrique le système, pas sur celui qui s'en sert.

Si vous rédigez vos publications avec un assistant conversationnel du commerce, vous n'êtes pas le fournisseur de cet assistant. Son éditeur l'est.

Cinq situations, et la question qu'il faut se poser dans chacune

Le règlement est écrit pour des organisations qui disposent d'un service juridique. Notre travail consiste à le ramener à des situations que rencontre une structure de trois personnes. Voici cinq cas fréquents. Nous n'y donnons pas de verdict — nous indiquons quelle question déclenche la réponse.

Vous publiez des articles rédigés avec un assistant IA, sur votre activité, vos produits, votre métier. La question : ces textes sont-ils « publiés dans le but d'informer le public sur des questions d'intérêt public » ? Un contenu commercial, une note de service, une page produit, un retour d'expérience professionnel n'entrent pas spontanément dans cette catégorie. Un texte d'analyse sur un sujet de société, oui, possiblement.

Vous avez intégré un agent conversationnel sur votre site. Ici, deux rôles se superposent. Vous êtes déployeur de la brique que vous avez achetée — mais si l'agent est mis à disposition sous votre nom, la question de savoir si vous en devenez fournisseur au sens du règlement mérite d'être posée sérieusement. C'est la situation la plus fréquemment sous-estimée, et celle où l'écart entre les deux réponses est le plus coûteux.

C'est aussi la nôtre, et nous l'avons tranchée dans le sens qui nous coûte. Les deux assistants que nous exposons sur nos propres pages sont mis à disposition sous notre nom : nous nous en sommes déclarés fournisseurs, et nous avons donc mis en œuvre le marquage lisible par machine du paragraphe 2 — métadonnées portées à trois niveaux, en-têtes de réponse, corps des messages, page rendue. Nous l'écrivons ici pour une raison précise : dans le paragraphe précédent, la répartition par rôle est une lecture du texte ; dans celui-ci, c'est une décision qui nous engage. Vous pouvez ouvrir les outils de développement de votre navigateur et vérifier vous-même que le marquage est là.

Deux limites, du même mouvement. Ce marquage repose sur des métadonnées : il ne survit pas à un copier-coller, et ce n'est pas un filigrane cryptographique. Le texte n'exige d'ailleurs qu'une solution efficace « dans la mesure de ce qui est techniquement possible » — le dire fait partie du travail. Et la règle que nous nous sommes donnée n'est pas « il y a un marquage » mais « le marquage dit la vérité » : lorsqu'une réponse ne vient pas du modèle — un refus, une erreur, un message local — elle est marquée comme non générée par IA. Un marquage faux vaudrait moins que pas de marquage du tout.

Vous publiez des visuels générés représentant des personnes. Le paragraphe 4 vise explicitement les deepfakes. Et une seconde obligation, franco-française celle-là, s'ajoute indépendamment du règlement européen : la mention « Images virtuelles » s'impose dès qu'un visuel de communication montre un visage retouché ou fabriqué, même inventé.

Vous utilisez un outil d'analyse d'expressions faciales ou vocales — recrutement, relation client, mesure de satisfaction. Le paragraphe 3 s'applique directement, et il ne comporte pas l'exception de relecture. C'est le cas le moins discuté et le plus net.

Vous vendez un logiciel qui embarque un modèle. Vous êtes fournisseur. Les paragraphes 1 et 2 vous concernent — et la date qui compte devient celle de votre mise sur le marché. Ici, un mot décide de six mois. Le règlement de simplification accorde un délai au 2 décembre 2026 pour le marquage lisible par machine, mais il le réserve aux systèmes « mis sur le marché » avant le 2 août. Quelques lignes plus haut, le même texte réécrit le paragraphe 2 avec la formule complète — « mis sur le marché ou mis en service ». Les deux expressions sont donc à sa disposition, et il n'en retient qu'une pour le report : l'omission est un choix, pas une négligence de rédaction. Un système que vous hébergez et exposez vous-même, sans le vendre, n'est pas « mis sur le marché » — et ne bénéficie d'aucun délai. C'est la lecture que nous avons retenue pour nos propres assistants, et c'est la plus exigeante des deux.

L'exception de relecture humaine, et ce qu'elle exige réellement

Le paragraphe 4 prévoit une exception : l'obligation de divulgation ne s'applique pas lorsque le contenu a fait l'objet d'une relecture humaine et que quelqu'un en assume la responsabilité éditoriale.

Elle est souvent invoquée. Elle est rarement citée en entier. Les lignes directrices publiées par la Commission le 24 juillet 2026 la précisent pour la première fois, et elles la resserrent nettement.

La relecture doit porter sur la substance. Le texte évoque un examen délibéré du fond par une personne physique possédant la connaissance du sujet, et pose la vérification factuelle comme exigence minimale. Il énumère ensuite ce qui ne suffit pas : un contrôle formel, une correction orthographique, la simple existence d'une politique éditoriale, une validation automatisée, ou une approbation sommaire sans engagement réel.

Quelqu'un doit être identifiable. L'identité et les coordonnées de la personne portant la responsabilité éditoriale doivent être publiquement accessibles, à un endroit facile à trouver.

Et rien ne doit intervenir après. Si un système d'IA modifie ou reformule le contenu postérieurement à la validation humaine, l'exception tombe.

Ce dernier point mérite l'attention de toute organisation qui corrige ses publications après leur mise en ligne — c'est-à-dire de presque toutes. Nous l'avons relevé chez nous avant de l'écrire ici.

Ce qu'il faut en retenir : cette exception n'est pas un statut, c'est un processus. On ne la « détient » pas ; on la tient, ou on la perd, à chaque publication.

Ce que cet article ne peut pas faire

Nous décrivons une répartition de rôles telle que le règlement l'établit et telle que les lignes directrices la commentent. Nous ne qualifions pas votre situation, et personne ne peut le faire à distance : la frontière fournisseur / déployeur dépend de la façon dont votre outil est mis à disposition, sous quel nom, avec quelles modifications. Cette qualification-là relève d'un conseil juridique, et il vaut son prix — précisément parce que la mauvaise réponse coûte davantage.

Ce que nous pouvons affirmer, en revanche, c'est ceci : les deux affirmations qui circulent le plus sont fausses toutes les deux. Le règlement n'est pas repoussé. Et il n'impose pas d'étiqueter tout contenu produit avec une IA.

Ce sont deux erreurs symétriques. La première dispense d'agir. La seconde fait agir au mauvais endroit — en produisant des mentions inutiles pendant que l'obligation réelle, celle du paragraphe 3 ou celle du fournisseur, reste ignorée.

Une dernière remarque, sur la méthode

Nous avons vérifié ces éléments en remontant aux textes : au règlement, aux lignes directrices, au communiqué du Conseil du 29 juin. Nous l'avons fait parce que notre propre documentation interne portait, jusqu'à cette semaine, une qualification périmée — elle décrivait le paquet de simplification comme un accord provisoire, ce qu'il avait cessé d'être à sa publication au Journal officiel, le 24 juillet.

Et parce que la première version de cet article-ci datait cette publication du 29 juin. Nous avions lu le communiqué du Conseil intitulé « feu vert final » et en avions tiré une publication ; il annonçait une adoption, qui la précède. L'erreur a été corrigée avant parution, non par vigilance mais par un geste de méthode : dater chaque affirmation réglementaire et la revérifier avant de la republier.

Nous corrigeons en laissant la trace de l'erreur, datée. Et nous en tirons la seule règle que nous appliquons désormais sans exception : une affirmation réglementaire vraie n'a pas vocation à le rester. Elle se revérifie, ou elle se périme sans prévenir.

Le détail de ces vérifications, et le protocole que nous utilisons pour reprendre — ou refuser de reprendre — une affirmation, sont publiés sur notre blog : ce que notre propre source nous a appris sur la valeur d'une signature.

Quelle est la dernière affirmation réglementaire que vous avez reprise sans ouvrir le texte ?