Vous recevez un texte destiné à votre site. Sa fiche indique qu’un assistant a préparé une première version, puis qu’une personne l’a retravaillée. Pourrait-on retrouver cette origine en analysant seulement le texte final ? L’annonce d’OpenAI donne un nouvel outil pour explorer cette question. Elle ne dispense pas de garder l’historique de rédaction. Dans le scénario fictif de cet article, vous préparez une fiche d’aide en français et cherchez à documenter sa fabrication sans confondre indice technique, exactitude et responsabilité.
Ce qui est annoncé le 5 octobre
Le 5 octobre 2026, OpenAI ouvre un filigrane optionnel pour certains modèles de son API, désactivé par défaut. Le marquage des sorties éligibles de ChatGPT et Codex dans l’Union européenne suivra dans les prochaines semaines. L’accès initial au détecteur vise des chercheurs et organismes experts agréés. Une API permet à votre application d’appeler un service.
Cette distinction suggère trois questions différentes pour votre équipe : votre application peut-elle demander un texte marqué ? Disposez-vous d’un accès autorisé à la vérification ? Savez-vous conserver l’origine déclarée même sans détecteur ? Répondre à la première ne résout pas les deux suivantes. Au 6 octobre, mieux vaut inscrire le statut exact de chaque étape dans votre fiche de projet que présenter une fonctionnalité annoncée comme un service déjà intégré.
Le mot « provenance » désigne ici le chemin de fabrication d’un contenu. Il peut comprendre la préparation automatique, la sélection des informations et la révision humaine. Votre fiche d’aide possède déjà une provenance lorsque vous consignez ces étapes. L’intérêt d’un signal technique serait de compléter cette description ; la documentation de votre travail reste utile avant comme après son arrivée.
Comprendre ce qu’un signal peut apporter
La méthode textGrain marque statistiquement les choix de mots. Selon OpenAI, la détection reste faillible, notamment après modification ou traduction et sur les textes courts. Elle n’établit ni vérité, ni identité, ni propriété ou responsabilité. Son absence ne prouve pas une rédaction humaine.
Pour vous représenter la notion statistique, imaginez deux ensembles de textes : l’un produit avec un marquage, l’autre sans. Certaines caractéristiques pourraient être plus fréquentes dans le premier ensemble. Les ensembles peuvent pourtant se recouvrir. Cette image est une explication conceptuelle proposée par Partitech, pas une reproduction de l’algorithme. La proximité d’un texte avec un ensemble ne raconte pas tout son parcours individuel.
Dans notre fiche d’aide fictive, une personne a corrigé une étape erronée et ajouté une précision issue du produit. Le texte final peut être pertinent ou incorrect indépendamment d’une détection. Pour contrôler son contenu, vous devez vérifier les instructions dans le produit. Pour connaître son processus de validation, vous devez consulter la fiche éditoriale. Ces questions appellent des preuves différentes.
Une erreur positive consiste à relever un signal alors qu’il n’était pas présent. Une erreur négative consiste à manquer un signal présent. Le coût des deux erreurs dépend de votre usage. Une indication interne destinée à demander une relecture ne produit pas les mêmes conséquences qu’une accusation publique. Notre recommandation éditoriale est de limiter la première intégration à une aide au contrôle, avec une possibilité explicite de ne pas conclure.
Préparer une évaluation avant de chercher un verdict
Le protocole qui suit est une proposition Partitech. Il n’a pas été exécuté et ne fournit aucun résultat de performance. Son objectif serait de déterminer dans quels cas votre équipe peut interpréter un résultat, avec un corpus autorisé et une vérité de référence connue.
Commencez par des textes dont la fabrication est documentée. Prévoyez des fiches écrites par des personnes sans assistance générative, des versions issues d’une génération marquée lorsque cette option est effectivement accessible et des variantes révisées. L’origine doit être connue par le processus de création, jamais déduite du détecteur que vous évaluez. Sinon votre test tournerait en rond : l’outil servirait à fabriquer sa propre réponse attendue.
Gardez séparées les familles de textes : français et autres langues utiles, passages courts et longs, contenus libres et formulations contraintes. Une fiche de dépannage comprenant surtout des noms de boutons ressemble peu à un long article explicatif. Si vous mélangez tout, une moyenne satisfaisante peut cacher une catégorie inutilisable. Définissez également la longueur avec une unité constante ; n’assimilez pas un nombre de mots à un nombre d’unités de traitement du modèle.
Les transformations servent ici à reproduire le cycle éditorial : correction d’une phrase, raccourcissement pour une interface ou traduction autorisée. Consignez leur objectif et leur auteur. Cette approche évalue vos documents usuels ; elle n’a pas pour objectif d’organiser la dissimulation d’une origine.
| Cas proposé | Origine connue | Transformation déclarée | Accès détecteur | Résultat et interprétation |
|---|---|---|---|---|
| Fiche française initiale | À documenter à la création | Aucune | À confirmer | À renseigner après essai |
| Fiche française révisée | Même document de départ | Relecture métier | À confirmer | À renseigner séparément |
| Résumé pour une interface | Même document de départ | Raccourcissement | À confirmer | À renseigner séparément |
| Traduction autorisée | Même document de départ | Traduction | À confirmer | À renseigner séparément |
| Témoin humain | Processus humain documenté | Relecture habituelle | À confirmer | À renseigner séparément |
N’indiquez pas « aucun filigrane » lorsque l’appel n’a pas été possible. Inscrivez « non testé » et sa raison. Une erreur réseau, une absence d’autorisation et une sortie négative sont trois observations distinctes. Conservez la sortie brute dans un espace protégé, accompagnée de la version de l’outil et de la date. La synthèse doit préciser le nombre de cas effectivement contrôlés et celui des cas exclus.
Définir la décision avant de lire les résultats
Avant l’essai, rédigez les phrases autorisées dans votre produit. Par exemple : « Un signal associé au marquage a été détecté ; l’historique éditorial reste à consulter. » Ou : « Aucun résultat interprétable n’est disponible pour ce document. » Vous évitez ainsi qu’un score soit traduit automatiquement en une conclusion plus large.
Définissez aussi les critères d’abstention. Un document sans origine de référence, une langue absente du protocole, un passage trop éloigné des cas évalués ou une version inconnue de l’outil justifient une revue. L’abstention signifie que votre système conserve une incertitude visible. Elle ne désigne pas la faute d’une personne et ne doit pas produire une sanction par défaut.
Pour la fiche d’aide, la décision de publication peut rester simple : une personne vérifie chaque étape, confirme la source du contenu et valide la version finale. Le contrôle de provenance possède son propre statut. Un incident sur cet outil n’a pas à faire disparaître la preuve d’une relecture déjà menée ; une détection positive ne peut pas créer une relecture qui n’a jamais eu lieu.
Tenir un journal minimal de fabrication
Voici une organisation conceptuelle que votre équipe pourrait adapter à son outil éditorial. Chaque version du document conserve une origine déclarée, une date de création, le modèle et sa version lorsqu’ils sont connus, l’état demandé du marquage, les transformations et la personne chargée de la validation. Le contrôle éventuel possède une date, un outil, une sortie protégée et une conclusion limitée.
Reliez la validation à la version exacte du texte. Si une phrase change ensuite, il faut savoir si la relecture reste valable. Dans notre exemple, remplacer le nom d’un bouton peut nécessiter une vérification ciblée ; changer une consigne de manipulation peut imposer une nouvelle validation. Une règle claire aide davantage qu’un tampon « contrôlé » attaché au document pour toujours.
Ce journal n’exige pas de conserver toute conversation avec un assistant. Notre proposition consiste à garder uniquement les éléments nécessaires au suivi éditorial, avec des droits d’accès et une durée définis. Les textes sensibles et les résultats détaillés peuvent rester dans un espace réservé ; la page publique peut recevoir une information courte et compréhensible sur sa préparation. Faites décider cette information par les responsables du contenu, selon son usage.
Relier la technique aux obligations de transparence
La Commission européenne distingue le marquage et la détection côté fournisseurs de la divulgation côté déployeurs selon les usages. Elle indique que le code de bonnes pratiques est volontaire, tandis que les obligations de transparence concernées s’appliquent depuis le 2 août 2026. L’annonce d’octobre ne constitue donc pas une nouvelle date d’entrée en vigueur.
Pour votre projet, cartographiez l’usage, le public, la responsabilité éditoriale et les preuves conservées avant de choisir un outil. C’est une méthode de préparation, pas un avis juridique personnalisé. Un bouton activé fournit une information technique ; il ne remplit pas à lui seul votre dossier de conformité.
La décision raisonnable aujourd’hui est de documenter votre cycle de rédaction et de préparer un test borné si vous obtenez un accès autorisé. Commencez par une famille de fiches, formulez les conclusions permises et vérifiez la séparation entre provenance et qualité. Tant que les performances françaises dans votre contexte ne sont pas établies, gardez le détecteur comme un indice à examiner.
Sources et date de vérification
Sources primaires rouvertes et lues le 6 octobre 2026 : OpenAI, annonce du 5 octobre sur la provenance textuelle ; Commission européenne, code de transparence, page mise à jour le 31 juillet. Les exemples, le journal et le protocole sont des propositions Partitech, sans essai du détecteur ni taux de précision revendiqué.