Le malentendu de départ
Quand un fournisseur de modèle annonce qu'il marquera ce que son modèle écrit, beaucoup d'équipes en concluent que la question est réglée pour elles. Elle ne l'est pas : l'obligation de transparence vis-à-vis de l'utilisateur final pèse sur celui qui met le système en service.
La distinction est la même que celle qui structure tout le règlement : le fournisseur du modèle a ses obligations, l'intégrateur a les siennes, et les secondes ne se délèguent pas aux premières.
Un engagement de fournisseur est une pièce utile à verser au dossier. Ce n'est pas une réponse à la question « est-ce que mes utilisateurs savent qu'ils lisent un texte produit par une machine ».
Les trois situations à distinguer
Un contenu vu par un utilisateur final, un contenu retravaillé par un humain avant diffusion, et un contenu interne qui ne sort pas n'appellent pas le même traitement. Les mélanger produit soit de la sur-conformité, soit un manquement.
Le premier cas est le plus clair : un texte produit par le système et présenté tel quel à une personne extérieure doit être identifiable comme tel.
Le deuxième est celui que les équipes traitent mal. Un brouillon généré puis repris, corrigé et validé par une personne qui en répond n'est plus un contenu généré au sens du texte : c'est un document de l'organisation. Le point de bascule est la validation humaine effective, pas le fait qu'un modèle soit intervenu.
Le troisième cas, un contenu strictement interne, relève de la politique de l'organisation plutôt que de l'obligation. Ce qui ne veut pas dire qu'il ne faut rien faire, comme le montre écrire la fiche d'un système d'IA.
Ce qu'il faut décider au moment de la conception
- Où le marquage apparaît : dans l'interface, dans le document produit, dans les métadonnées, ou dans les trois.
- Ce qui se passe quand un humain valide : le marquage tombe-t-il, et qui en décide ?
- Comment on le prouve : la journalisation doit conserver la trace de ce qui a été généré et de la validation. Voir l'observabilité des systèmes IA.
- Qui répond du dispositif, nommément. Sans cette réponse, il n'y a pas de dispositif.
Pourquoi le marquage se conçoit et ne s'ajoute pas
Un marquage plaqué à la fin est retiré par le premier utilisateur qui copie le texte ailleurs, et il ne prouve rien. Il doit être décidé avec l'interface, pas après.
Le cas concret revient constamment : un assistant produit une réponse, l'utilisateur la copie dans un courriel, et la mention disparaît. Le système a rempli son obligation d'affichage, la chaîne réelle ne l'a pas.
Les réponses possibles sont limitées et il faut choisir. Marquer dans le contenu lui-même, ce qui survit à la copie mais alourdit le texte. Marquer dans l'interface, ce qui est propre et ne survit pas. Ou concevoir le flux pour que la sortie passe toujours par une validation humaine, ce qui déplace la question.
Cette troisième voie est souvent la meilleure, et elle rejoint le cadre posé dans supervision humaine : la concevoir, pas la promettre.
Ce que l'engagement du fournisseur apporte réellement
Il apporte une pièce datée pour votre dossier, et un signal sur la stabilité de votre chaîne. Ce n'est pas rien, et ce n'est pas ce qu'on en attend.
La pièce datée est utile : elle documente que le modèle utilisé relève d'un fournisseur engagé dans une démarche de transparence, à telle date. Elle s'archive avec la documentation technique.
Le signal sur la stabilité est plus intéressant en pratique. Un fournisseur qui s'engage sur le marquage introduira des mécanismes techniques dans ses réponses, et ces mécanismes peuvent changer le format de sortie. Une équipe qui a un jeu de tests le verra ; une équipe qui n'en a pas découvrira une régression sans cause apparente.
C'est un cas de plus où le jeu de tests protège d'un changement subi, comme dans le jour où le modèle a changé sans prévenir.
La question à poser au cadrage
« Un lecteur extérieur peut-il croire que ce texte a été écrit par une personne ? » Si la réponse est oui, le marquage se conçoit maintenant. Si elle est non, il faut écrire pourquoi, et cette phrase suffit au dossier.
Ce que ça change pour les usages de rédaction
Les systèmes qui produisent du texte destiné à sortir de l'organisation sont ceux qui doivent être repris en premier. Ils sont aussi les plus répandus et les moins documentés.
Le schéma type : une équipe marketing ou support utilise un assistant pour préparer des réponses, et ces réponses partent parfois telles quelles. Personne n'a décidé que c'était le cas, et personne ne sait dans quelle proportion.
Le premier geste n'est donc pas de marquer, c'est de mesurer : sur cent réponses préparées, combien sont envoyées sans modification. Ce chiffre décide de la suite.
S'il est élevé, le flux relève de la génération diffusée et doit être traité comme tel. S'il est bas, la validation humaine est réelle et le dispositif est déjà en place, il suffit de le documenter. C'est le même raisonnement de mesure préalable que dans mesurer l'adoption, pas la satisfaction.
Questions fréquentes
Qui doit marquer un contenu généré ?
Celui qui met le système en service vis-à-vis de son utilisateur final, pas le fournisseur du modèle. L'engagement du fournisseur est une pièce pour le dossier, pas une réponse à l'obligation.
Un texte relu et validé par un humain doit-il être marqué ?
Le point de bascule est la validation humaine effective. Un brouillon repris, corrigé et validé par une personne qui en répond devient un document de l'organisation.
Où placer le marquage ?
Dans l'interface, dans le contenu, ou dans les métadonnées, selon ce qui doit survivre à une copie. Un marquage plaqué à la fin disparaît dès que l'utilisateur transfère le texte ailleurs.
Par quoi commencer ?
Par mesurer, sur cent réponses préparées, combien partent sans modification. Ce chiffre dit si le flux relève de la génération diffusée ou d'une validation humaine réelle.