Andy Garcia · dev freelance
FRENES
Retour au blog
Réglementation IA

OpenAI va filigraner le texte de ChatGPT et Codex, mais seulement dans l'UE. Son API est livrée avec l'interrupteur éteint, Claude avec l'interrupteur allumé

7 octobre 2026 6 min de lecture

Le lundi 5 octobre, OpenAI a publié « Our approach to EU text provenance rules ». Le texte dit trois choses.

Dès ce jour, les clients de l'API, où qu'ils soient, peuvent activer le filigrane de texte pour certains modèles ; par défaut, il reste désactivé. Dans les semaines qui viennent, la sortie texte éligible de ChatGPT et de Codex recevra un filigrane invisible, sur tous les forfaits, dans l'Union européenne seulement : « We are not making text watermarking a global default at launch. » Et le détecteur n'est pas public. Les chercheurs agréés et les organisations expertes peuvent demander un accès.

La méthode s'appelle textGrain. Elle infléchit les choix de mots du modèle à l'aide d'une clé secrète, et un détecteur qui détient la même clé vérifie si un passage suit ce motif plus souvent que le hasard ne le permettrait.

La raison, c'est l'AI Act européen. L'article 50(2) s'applique depuis le 2 août 2026 : les fournisseurs de systèmes d'IA qui génèrent du texte doivent veiller à ce que les sorties soient « marquées dans un format lisible par machine et détectables comme générées ou manipulées artificiellement ». Les lignes directrices de la Commission décrivent une règle de maintien des droits acquis issue de l'AI Omnibus récemment adopté : les systèmes génératifs déjà sur le marché avant le 2 août ont jusqu'au 2 décembre 2026 pour respecter l'obligation de marquage. ChatGPT et Codex étaient sur le marché bien avant août, ce qui colle avec « dans les semaines qui viennent ».

En septembre, j'ai écrit pourquoi la « provenance » range trois affirmations différentes dans un seul mot. Cet article-ci est plus étroit : le code, la robustesse d'après les propres chiffres d'OpenAI, et ce que le défaut réservé à l'UE signifie si tu livres du texte d'IA à des utilisateurs européens.

Ton dépôt est en grande partie hors champ

Ma première question, en tant que quelqu'un qui laisse des agents écrire du code tous les jours : est-ce que Codex laisse désormais un filigrane dans mon dépôt ?

La loi dit non. Les lignes directrices de la Commission sur l'article 50, dont elle a approuvé le contenu le 20 juillet, listent ce qui sort de l'obligation de marquage, et le code source figure sur la liste : tout ce qui est écrit dans un langage de programmation, de script, de balisage, de requête ou de configuration destiné à être interprété, compilé ou exécuté par un ordinateur, y compris éventuellement les commentaires qui en font partie intégrante. SQL, infrastructure as code, configuration YAML et JSON sont nommés. Tout comme les sorties courtes, comme un mot isolé ou un libellé d'interface, et le trafic d'agent à agent que personne ne voit.

Le centre d'aide d'OpenAI est d'accord sur le plan technique : « Le code est aussi plus difficile à filigraner parce qu'il y a moins de choix plausibles pour la suite que dans la prose ordinaire. » Le Code of Practice ajoute un plancher pour tout texte : aucun filigrane n'est exigé en dessous de 200 tokens, ce qu'OpenAI situe à environ 150 mots d'anglais.

OpenAI ne dit pas que Codex saute le code. Elle dit sortie « éligible ». Ce que je considérerais comme éligible dans une session Codex, c'est la prose autour du code : une longue explication dans le chat, une description de pull request, une note de conception. C'est du texte écrit pour des humains, pas des instructions pour un compilateur. C'est ma lecture, pas une décision officielle.

Deux conséquences pratiques. D'abord, il n'y a rien à voir. OpenAI dit que le filigrane n'ajoute ni caractères cachés, ni espaces invisibles, ni ponctuation inhabituelle. Les diffs, les linters et les formateurs ne verront rien, et il n'y a rien à chercher avec grep ni à retirer. Ensuite, à moins que ton équipe soit une organisation de recherche ou experte agréée, personne n'y peut vérifier dans un sens ou dans l'autre.

Sa robustesse, d'après OpenAI

OpenAI est franche sur les limites. Tous ses chiffres ci-dessous sont à un taux de faux positifs cible de 1 %.

Sur des réponses de psychologie, le détecteur a trouvé le filigrane dans environ 80 % des passages de 200 tokens et environ 95 % des passages de 400 tokens. En mathématiques, où le choix des mots est moins souple, la détection était « nettement plus faible ». Sur des passages de 400 tokens, remplacer 10 % des mots par des synonymes a fait passer la détection d'environ 92 % à 66 %. En remplacer 25 % l'a fait tomber à 17 %. Dans un test séparé sur les 24 langues officielles de l'UE, la détection allait de 69,0 % en espagnol à 42,2 % en roumain, avant qu'OpenAI augmente la force du filigrane pour les langues sous 60 %.

Le code, c'est le cas des mathématiques : précis, contraint, souvent court. Le centre d'aide ajoute qu'une paraphrase ou une traduction substantielle peut rendre la marque indétectable. Et une cible de 1 % de faux positifs signifie que, par construction, environ un passage sur cent sans aucun filigrane peut ressortir positif.

Le coût en qualité paraît faible. Sur le tableau de benchmarks d'OpenAI pour Astra, qu'elle présente comme son dernier modèle de pointe, les scores avec filigrane bougent dans les deux sens : DeepSWE v1.1 passe de 72,80 % à 71,68 %, Terminal-Bench 4.0 de 53,90 % à 56,06 %.

La marque est donc un signal pour un expert qui détient la clé, sur de la longue prose que personne n'a retouchée. OpenAI le dit elle-même : « L'absence de filigrane détecté ne prouve pas une rédaction humaine. »

Le défaut UE est un réglage de ChatGPT, pas ta conformité

Le défaut UE couvre ChatGPT et Codex. Il ne couvre pas ton produit qui appelle l'API, même si tous tes utilisateurs vivent à Lyon ou à Munich. Dans l'API, le filigrane reste désactivé tant que quelqu'un n'active pas « Allow text watermarking » dans les paramètres de l'organisation, Data controls, Text provenance, ou dans les paramètres d'un projet, et ne sélectionne les modèles.

Selon l'article 50(2), l'obligation de marquage pèse sur le fournisseur du système d'IA générative. Si tu mets sur le marché, sous ton propre nom, un produit qui écrit du texte, c'est très probablement toi : les lignes directrices parlent de « downstream AI system providers » bâtis sur le modèle de quelqu'un d'autre. Elles te permettent de t'appuyer sur le marquage d'un fournisseur de modèle en amont, mais « sans préjudice de la responsabilité du fournisseur du système d'IA de démontrer la conformité ». Un interrupteur que personne n'a actionné n'est pas une solution de marquage.

Mettons maintenant l'autre grand fournisseur à côté. Anthropic marque au niveau du modèle, dans le monde entier, sur chaque surface qu'elle liste : l'API, les apps Claude, Claude Code. Sa page d'aide montre des filigranes de texte pour Claude Opus 5.5 et Sonnet 5.5, sur sa propre plateforme et via les partenaires cloud. Elle montre aussi qu'il n'y a pas encore de filigrane de texte pour les modèles plus anciens comme Opus 4.6 ou Sonnet 4.6.

Je construis sur Claude, et ce tableau a été la surprise utile. La même fonctionnalité, avec le même prompt, produit du texte marqué sur un modèle Claude récent, du texte non marqué sur un modèle plus ancien, et du texte non marqué sur l'API d'OpenAI par défaut. Si tu gardes un second fournisseur en repli, et je pense que quiconque construit sur un seul fournisseur devrait le faire, ton marquage change à chaque bascule du routeur.

Les lignes directrices traitent aussi les résumés générés par IA comme du contenu à marquer, alors que la traduction et les corrections de grammaire comptent comme de l'édition standard et sont exemptées. Et OpenAI dit clairement que les filigranes « ne remplacent pas les étiquettes visibles ».

Ce que je ferais lundi

Liste chaque endroit où ton produit renvoie du texte généré à un utilisateur dans l'UE. Pour chacun, note le fournisseur, le modèle, la longueur typique et le type de sortie : résumé, brouillon, traduction, code, libellé court. La prose longue et librement générée est ce que la règle vise. Le code, les libellés courts et les traductions, en majorité, non.

Si l'un de ces chemins appelle l'API d'OpenAI, prends une décision explicite sur l'interrupteur Text provenance, projet par projet, et écris-la avec la date. Désactivé par défaut n'est pas une décision.

Si tu fais du routage entre fournisseurs ou entre modèles, traite le marquage comme une propriété de la route, et journalise quel modèle a produit chaque sortie. Le Code of Practice cite la journalisation comme un complément facultatif pour le texte, jamais comme un substitut à la marque, mais c'est la seule trace que tu peux réellement interroger.

Et ne construis rien qui dépende de la détection, ni un contrôle anti-plagiat, ni un filtre « est-ce écrit par une IA ». Tu ne peux pas obtenir le détecteur, et un résultat négatif ne prouve rien.

Le défaut réservé à l'UE montre comment OpenAI voit cette marque aujourd'hui : quelque chose qu'elle livre là où la loi le demande, pendant qu'elle apprend. C'est de bonne guerre. Pour ton produit, la décision reste la tienne.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons