Détection texte IA : les meilleurs détecteurs de filigrane en 2026

En 2026, la détection texte IA par filigrane ne dispose d’aucun détecteur universel public. Pour les équipes qui maîtrisent leur propre modèle, Hugging Face SynthID Text offre la meilleure voie vers la production. Mais son protocole d’entraînement commence par 10,000 exemples : pour chaque prompt, une sortie filigranée et une sortie sans marquage, soit 20,000 générations avant même le déploiement. Quant aux textes issus de Claude ou Gemini et fournis par un tiers, le constat honnête au 16 août 2026 reste le même : non pris en charge.

Détection texte IA : l’accès à la source désigne le bon outil

Un filigrane de texte IA n’est ni une espace suspecte, ni un tiret inhabituel, ni une estimation générique selon laquelle un texte « ressemble » à de l’IA. Les systèmes sur lesquels il vaut la peine de miser introduisent un signal statistique dans les choix de mots du modèle. Pour le lire, il faut un détecteur adapté à la configuration de filigranage du générateur et, souvent, à sa clé secrète.

Cette différence change entièrement la décision d’achat. Si vous contrôlez le modèle et ses paramètres de génération, vous pouvez déployer un véritable détecteur. Si un fournisseur propose une API officielle de vérification, vous pouvez l’interroger. Dans tous les autres cas, la bonne conclusion est non pris en charge — et non « écrit par un humain » ou « sans filigrane ».

Voici le classement des logiciels capables d’être réellement utiles aujourd’hui. Les prix ont été vérifiés le 16 août 2026. Tous les quatre disposent d’une licence logicielle open source à $0, mais aucune ne supprime les coûts d’inférence, de calibration, de stockage, d’ingénierie ou de contrôle humain.

Meilleur choix global : Hugging Face SynthID Text, mais uniquement pour une organisation qui maîtrise toute la chaîne de génération. Parmi les solutions étudiées, son implémentation est la plus proche d’une infrastructure de production, et sa documentation expose avec une rare clarté la charge d’entraînement comme les modes d’échec.

Meilleur choix pour l’évaluation : MarkLLM. Une équipe de recherche ou de plateforme dispose ainsi d’un banc unique pour comparer plusieurs méthodes, sans confondre le score de confiance d’un détecteur avec une vérité universelle.

Meilleure baseline simple : lm-watermarking. Plus ancien et plus ciblé, l’outil convient précisément lorsqu’il faut reproduire la méthode KGW avec des paramètres connus, plutôt que passer en revue une vaste boîte à outils.

Meilleur complément d’inspection : watermarks-remover. Il repère très bien les artefacts présents au niveau du texte et peut appeler un détecteur configuré à l’identique. En revanche, il ne peut pas certifier l’absence d’un filigrane propriétaire.

Le détecteur Claude annoncé par Anthropic pourrait finir par devenir la bonne réponse pour les contenus issus de Claude. Il n’apparaît pas dans ce classement, car l’API, les modalités d’accès, les limites et le prix n’ont pas encore été publiés. Les interfaces publiques de Google n’acceptent pas non plus le texte collé à ce jour, tandis que le vérificateur public d’OpenAI couvre actuellement les images et l’audio, pas le texte. Une équipe achats ne devrait pas combler ces lacunes avec un scanner grand public dans le navigateur.

Comment avons-nous sélectionné ces détecteurs de filigrane IA ?

Le classement repose sur cinq critères qui correspondent à une véritable décision de déploiement.

1. Type de preuve : un détecteur de filigrane doit rechercher un signal inséré volontairement. Un classificateur qui estime simplement si un texte ressemble à une production IA appartient à une autre catégorie.
2. Correspondance avec la source : le détecteur doit préciser quelle configuration de génération, quelle clé, quel tokenizer ou quel fournisseur il est réellement capable de vérifier. Toute promesse d’identifier tous les modèles sans accès à la source doit inciter à la prudence.
3. Capacité de déploiement : une méthode crédible exige une implémentation utilisable, des entrées documentées, une procédure de détection et suffisamment de détails pour reproduire le résultat.
4. Robustesse : la documentation doit reconnaître les faiblesses liées aux extraits courts, aux textes factuels, au code, à la paraphrase, à la réécriture, à la traduction ou à toute autre transformation susceptible d’atténuer le signal.
5. Coût opérationnel : une licence open source n’est pas un budget. Les générations, l’entraînement du détecteur, les corpus d’évaluation, la calibration des seuils, la gestion des clés, la journalisation et le contrôle humain comptent tous.

Les quatre premiers outils ont été retenus parce que leur périmètre est explicite et leurs limites peuvent être examinées. Les scanners Unicode grand public sont présentés plus loin : ils répondent à un besoin d’assainissement beaucoup plus étroit. Les classificateurs classiques de textes IA ont été écartés, car ils infèrent un style au lieu de lire une clé intégrée. Si c’est ce type de produit qu’il vous faut, notre guide distinct des meilleurs détecteurs d’IA en 2026 compare cette catégorie sans la faire passer pour de la vérification de filigrane.

Toutes les affirmations concernant les produits, licences, dépôts, versions et disponibilités ont été vérifiées sur des pages officielles le 16 août 2026. Aucun des programmes partenaires actifs ou à forte valeur disponibles pour ce comparatif ne propose de vérification des filigranes de texte ; aucun partenaire n’a donc été ajouté au classement. Une sélection dictée par la facilité commerciale rendrait le comparatif moins fiable.

1. Hugging Face SynthID Text : le meilleur choix pour produire quand on contrôle la génération

Hugging Face SynthID Text est aujourd’hui l’option la plus solide lorsqu’une organisation maîtrise le service du modèle et peut filigraner le texte dès sa génération. Google DeepMind et Hugging Face ont ajouté l’implémentation à Transformers v4.46.0 : la génération filigranée y est associée à un détecteur entraînable, et non à un verdict magique obtenu en collant un texte. Le guide d’implémentation de Hugging Face documente les deux volets du système. Le cas d’usage concret est celui d’une plateforme de modèles d’entreprise qui doit distinguer, dans ses applications internes, les sorties de ses propres modèles pris en charge. Sa limite est tout aussi concrète : sans la configuration et les données d’entraînement correspondantes, elle ne peut pas identifier n’importe quel texte de Claude, Gemini ou ChatGPT.

Lors de la génération, le système modifie les probabilités des tokens à l’aide d’une configuration de filigranage protégée par une clé. Hugging Face recommande 20 à 30 entiers aléatoires uniques pour cette clé et présente une longueur de n-gram de 5 comme un bon réglage par défaut, 2 constituant le minimum. Il ne s’agit pas de paramètres universels que l’on pourrait recopier après coup dans un détecteur. Ils appartiennent à une configuration qui doit rester cohérente depuis la génération jusqu’à l’entraînement du détecteur.

C’est du côté du détecteur que cet outil apparemment gratuit devient un véritable projet. Hugging Face recommande au moins 10,000 exemples, répartis entre sorties filigranées et non filigranées, puis divisés en jeux d’entraînement et de test. Si l’organisation produit une réponse marquée et une réponse sans marquage pour chaque prompt, cela représente 20,000 générations avant même d’entraîner le détecteur. La licence du dépôt reste à $0 ; la puissance de calcul et le temps de travail, eux, ne le sont pas.

Une piste de mutualisation existe. Des modèles partageant le même tokenizer peuvent employer une même configuration de filigrane et un même détecteur, à condition que les données d’entraînement de ce dernier contiennent des exemples de chacun des modèles concernés. Une plateforme interne peut ainsi réduire le nombre de services de détection à maintenir. Cela implique aussi qu’une mise à niveau du modèle n’est pas une simple formalité : il faut ajouter de nouveaux échantillons et valider de nouveau le détecteur.

Les modes d’échec doivent guider la politique interne. Une réécriture approfondie ou une traduction peut fortement réduire la confiance, tandis que les réponses factuelles se prêtent moins bien au marquage puisque le modèle a moins de latitude dans le choix des mots plausibles. Le résultat du détecteur doit donc compléter les métadonnées de source, jamais les remplacer. Il sert à consolider une piste d’audit, pas à accuser un salarié, un étudiant, un prestataire ou un éditeur sur la foi d’un seul score.

Idéal pour : les équipes produit et plateforme qui contrôlent la génération de texte et peuvent conserver la configuration du filigrane.
Atout distinctif : une implémentation Transformers pensée pour la production, accompagnée d’un protocole explicite d’entraînement du détecteur.
Tarif : licence logicielle Apache-2.0 à $0, vérifiée le 16 août 2026 ; l’inférence, l’entraînement, le stockage et l’ingénierie sont en supplément.
Essai gratuit : sans objet ; l’implémentation est open source.

Un pilote SynthID Text concret

1. 1

   Choisir une seule chaîne de génération maîtrisée

   Commencez avec un modèle, un tokenizer et un type de sortie bien délimité, par exemple des brouillons pour le support client. Ne mélangez ni modèles ni cas d’usage avant d’avoir compris la baseline.

2. 2

   Figer la configuration du filigrane

   Créez et protégez la clé, consignez le réglage du n-gram et versionnez l’intégralité de la configuration de génération. Les résultats du détecteur n’ont de sens que tant que cette configuration source reste connue.

3. 3

   Constituer des exemples appariés

   Utilisez au moins 10,000 prompts représentatifs. Produisez pour chacun une sortie marquée et une sortie sans marquage, puis répartissez les 20,000 générations obtenues entre données d’entraînement et jeu de test isolé.

4. 4

   Entraîner et calibrer le détecteur

   Entraînez-le sur les classes connues, puis définissez un seuil opérationnel à partir du corpus isolé. Mesurez les faux positifs sur les sorties non marquées et les détections manquées sur les sorties marquées avant d’associer la moindre conséquence prévue par votre politique au résultat.

5. 5

   Mettre le résultat à l’épreuve

   Ajoutez au jeu d’évaluation des réponses courtes, des passages factuels, du texte proche du code, des paraphrases et des traductions. Consignez séparément les cas non pris en charge au lieu de les forcer dans un verdict binaire.

6. 6

   Versionner toute la chaîne

   Conservez ensemble l’application source, le modèle, le tokenizer, la version de configuration, la version du détecteur et son résultat. Recalibrez après toute modification du modèle ou du filigrane.

Verdict : choisissez Hugging Face SynthID Text lorsque la provenance fait partie d’un système de génération que vous maîtrisez. Écartez-le si vous ne disposez que d’un texte collé provenant d’un fournisseur inconnu.

2. MarkLLM : le meilleur banc d’essai avant de choisir un filigrane

MarkLLM est le meilleur environnement d’évaluation pour une équipe de recherche qui veut déterminer quelle méthode de filigranage résistera à ses vrais contenus et à ses tests de robustesse. Le projet open source prend en charge la génération et la détection pour plusieurs approches, dont KGW et SynthID-Text, avec des pipelines distincts pour les contenus filigranés et non filigranés. Son cas d’usage concret : permettre à une équipe plateforme de comparer les méthodes sur des prompts propres à son produit avant de retenir un mécanisme de génération. Sa limite reste fondamentale : couvrir de nombreuses méthodes publiées ne lui donne pas accès à la configuration secrète du modèle privé d’un fournisseur.

MarkLLM recense 12 outils d’évaluation couvrant la détectabilité, la robustesse et la qualité du texte. C’est essentiel : un détecteur peut briller sur de longs échantillons intacts, puis échouer après les transformations courantes d’un workflow. Un produit de rédaction juridique, un assistant de support et un assistant de programmation ne génèrent pas la même distribution de textes. Avec le bon banc d’essai, ces différences permettent de choisir la méthode au lieu de se fier à un unique score mis en avant.

L’environnement repose sur Python 3.10 et PyTorch. Au 16 août 2026, le dépôt affichait 1.0k étoiles GitHub, 176 commits et un dernier commit daté du 10 juillet 2026. Ces indicateurs ne prouvent pas la fiabilité en production. Ils témoignent néanmoins d’un périmètre de recherche plus large et d’une maintenance plus récente que plusieurs implémentations plus étroites.

La meilleure raison d’adopter MarkLLM n’est pas la longueur de la liste des méthodes compatibles. Son intérêt est de réunir génération, attaque, détection et évaluation de la qualité dans une même expérience reproductible. Il devient alors plus simple de répondre à la vraie question métier : quel signal reste exploitable après les modifications autorisées par notre workflow, à un taux de faux positifs compatible avec notre politique ?

MarkLLM ne doit pas servir de guichet d’entrée pour des documents soumis sans contexte. Il doit rester au sein d’une expérimentation contrôlée ou d’un système de génération maîtrisé, où la méthode et les réglages du filigrane sont connus. Sans cette correspondance avec la source, son résultat ne peut pas devenir un verdict de provenance pour Claude, Gemini ou ChatGPT.

Idéal pour : les équipes de recherche et de plateforme qui comparent des méthodes de filigranage avant de passer en production.
Atout distinctif : douze outils d’évaluation, complétés par des pipelines de génération et de détection pour plusieurs méthodes.
Tarif : licence logicielle Apache-2.0 à $0, vérifiée le 16 août 2026 ; la puissance de calcul et l’intégration sont en supplément.
Essai gratuit : sans objet ; la boîte à outils est open source.

Verdict : utilisez MarkLLM avant de choisir un filigrane, pas comme détecteur universel une fois le texte arrivé.

3. lm-watermarking : la meilleure baseline KGW explicable

lm-watermarking est le choix le plus limpide pour une petite équipe de recherche qui recherche l’implémentation officielle de KGW et une baseline ciblée, facile à expliquer. Le dépôt officiel s’intègre à la génération de Hugging Face Transformers et rend visible la relation entre les paramètres de génération et ceux de la détection. Le cas d’usage concret consiste à reproduire une expérience de filigranage publiée avant de la comparer à des méthodes plus récentes. Le point de blocage tient à la sensibilité de la configuration : gamma, méthode d’initialisation, tokenizer, device et autres entrées du détecteur doivent correspondre à la génération. Un texte de fournisseur inconnu reste donc hors périmètre.

Le point de départ documenté dans le dépôt utilise un gamma de 0.25, un delta de 2.0, une largeur de contexte h=4 et selfhash. Cette recommandation est présentée comme l’état des connaissances des mainteneurs en août 2023 : il faut donc y voir une baseline reproductible, pas un optimum universel actuel. Son ancienneté n’est pas forcément un défaut. Lorsqu’une méthode sert de contrôle dans une évaluation, la stabilité et la transparence des hypothèses peuvent avoir plus de valeur qu’une longue liste de fonctionnalités.

La détection exige aussi une gestion rigoureuse des n-grams répétés. La documentation précise qu’ils doivent être ignorés pour obtenir des valeurs p valides et avertit que les réglages de génération et de détection doivent concorder. C’est précisément pour cette raison que copier l’interface d’un détecteur et lui soumettre un texte anonyme ne permet pas d’en établir l’origine. La statistique n’a de sens que par rapport au mécanisme qui a produit le texte.

Au 16 août 2026, lm-watermarking était proposé sous licence Apache-2.0, avec 694 étoiles GitHub, 16 commits et un dernier commit daté du 17 septembre 2025. MarkLLM offre une suite d’évaluation plus étendue, tandis que Hugging Face SynthID Text constitue une meilleure voie vers la production. lm-watermarking l’emporte lorsque l’objectif est de comprendre et de reproduire KGW sans ajouter la complexité d’un framework plus large.

Idéal pour : les chercheurs et développeurs expérimentés qui ont besoin d’une implémentation de contrôle KGW transparente.
Atout distinctif : l’implémentation officielle rend explicite la nécessaire concordance entre les paramètres de génération et de détection.
Tarif : licence logicielle Apache-2.0 à $0, vérifiée le 16 août 2026 ; le modèle et la puissance de calcul sont en supplément.
Essai gratuit : sans objet ; l’implémentation est open source.

Verdict : utilisez lm-watermarking lorsque la reproductibilité est l’objectif. Écartez-le pour une évaluation multiméthode, une gouvernance prête à l’emploi ou la vérification d’un fournisseur tiers.

4. watermarks-remover : le meilleur complément d’inspection, pas une preuve côté fournisseur

watermarks-remover est le meilleur complément pour examiner les différents artefacts que l’on regroupe trop facilement sous l’appellation « filigranes IA ». Le projet open source peut analyser et nettoyer l’Unicode invisible, les métadonnées et les structures liées à C2PA, puis employer une couche de réécriture distincte pour les motifs statistiques. Son intégration facultative à MarkLLM permet de détecter les marques KGW et SynthID lorsque la même configuration est disponible. Le projet précise bien que cette intégration n’a rien d’un oracle capable de lire le filigrane propriétaire d’un fournisseur : c’est justement pourquoi il occupe la quatrième place et non la première.

Le cas d’usage concret est un workflow éditorial, de conformité ou de sécurité qui doit inventorier les artefacts avant de transférer le texte entre plusieurs systèmes. L’Unicode invisible peut perturber la recherche, l’analyse, la comparaison ou la mise en forme sans pour autant constituer une marque de provenance IA. Les métadonnées et les structures C2PA représentent encore d’autres couches de preuve. Un outil capable de rendre ces niveaux visibles améliore l’hygiène du texte sans prétendre savoir ce qu’il ignore.

Le risque se trouve dans l’interprétation. Supprimer un caractère de largeur nulle ne retire pas le motif statistique fondé sur le choix des mots d’Anthropic, puisque l’entreprise affirme que sa méthode n’ajoute aucun caractère caché. Une réécriture peut affaiblir un signal statistique, mais sans le détecteur du fournisseur, impossible de certifier sa disparition. « Le fichier semble propre » et « le détecteur du fournisseur renverra un résultat négatif » sont deux affirmations différentes.

Lors de la vérification du 16 août, le dépôt comptait 11.1k étoiles GitHub, 1.2k forks, 87 commits et un dernier commit daté du 15 août 2026. Cette adoption en fait un élément important de la réflexion des acheteurs, d’autant que l’intérêt pour la suppression peut devancer les infrastructures de détection. Sa popularité n’élargit toutefois pas la nature des preuves qu’il sait lire.

Idéal pour : les auditeurs et les équipes chargées des contenus qui doivent distinguer l’Unicode, les métadonnées, C2PA et les contrôles statistiques effectués à configuration identique.
Atout distinctif : un workflow d’inspection unique pour plusieurs types d’artefacts, avec une intégration facultative au détecteur MarkLLM.
Tarif : licence logicielle MIT à $0, vérifiée le 16 août 2026 ; les modèles et infrastructures facultatifs sont en supplément.
Essai gratuit : sans objet ; le projet est open source.

Verdict : utilisez watermarks-remover pour inspecter et assainir des catégories d’artefacts connues. Ne vous en servez pas pour certifier qu’un texte tiers inconnu n’a jamais été filigrané.

Le détecteur Claude d’Anthropic domine la liste de veille, mais ce n’est pas encore un produit

L’API Claude Watermark Detection d’Anthropic est le vérificateur fournisseur le plus important à surveiller, car elle est liée à la clé employée par le nouveau système de marquage de texte de Claude. Anthropic a annoncé cette fonction le 14 août 2026 et indique que l’API de détection est à venir. L’entreprise n’a encore publié ni détails d’implémentation, ni conditions d’accès, ni limites, ni tarifs. La piste est crédible, mais aucun acheteur ne peut encore la déployer.

La méthode de Claude est une version de SynthID-Text. Elle inscrit dans les choix de mots un motif statistique protégé par une clé, sans caractères cachés, tokens supplémentaires ou identité d’utilisateur ou d’organisation intégrée. Anthropic affirme que ce marquage n’a qu’un effet négligeable sur la vitesse et n’ajoute aucun coût de service ou d’utilisation. Ces conditions économiques sont encourageantes pour la génération, mais elles ne constituent pas les modalités commerciales de l’API de détection.

La couverture est elle aussi bien délimitée. Les informations d’assistance d’Anthropic indiquent que les modèles Claude lancés dans l’UE à compter du 2 août 2026 prennent en charge le marquage dès leur lancement, tandis que l’ajout des modèles plus anciens est en cours. Là où il est disponible, le marquage peut s’appliquer dans le monde entier à Claude Platform and API, Claude, Claude Code, Claude Cowork, Claude Tag et aux partenaires cloud cités. Cette couverture n’est utile que si le vérificateur en aval peut accéder au service de détection correspondant.

Les limites doivent figurer dans chaque note d’achat. Les échantillons courts sont peu probants, les passages factuels et le code portent moins de signal, et une modification poussée, une paraphrase, une traduction ou une réécriture complète peut supprimer tout motif détectable. Même un résultat positif signifie que Claude a peut-être traité le texte. Il ne prouve pas que Claude est à l’origine des idées ou de la première version.

La conséquence métier est simple : conservez dès maintenant le fournisseur, le modèle, la version, l’horodatage et l’application source. Placez la vérification du filigrane derrière un adaptateur qui pourra recevoir plus tard la réponse du fournisseur. N’achetez pas un scanner Unicode générique comme détecteur Claude provisoire : il lit une autre catégorie de preuve.

Idéal pour : la future vérification des sorties Claude compatibles à l’aide de la clé et du service d’Anthropic.
Atout distinctif : un détecteur contrôlé par le fournisseur et associé au filigrane statistique protégé par clé de Claude.
Tarif : non publié pour la future API de détection au 16 août 2026.
Essai gratuit : non annoncé.

Verdict : préparez votre architecture pour l’API d’Anthropic, mais ne l’inscrivez pas au budget comme un contrôle disponible tant que l’accès et les tarifs ne sont pas publics.

Quel détecteur de texte IA choisir selon votre situation ?

Un fondateur ayant levé des fonds et qui exploite son propre endpoint de modèle devrait commencer avec Hugging Face SynthID Text. Le filigrane peut être installé là où le texte est généré, puis le détecteur entraîné sur la véritable distribution de sorties de l’entreprise. Budgétez les 20,000 générations appariées et un pilote bien délimité avant de promettre une traçabilité à l’échelle de tout le produit.

Un CTO d’une entreprise de taille intermédiaire qui compare plusieurs méthodes devrait d’abord employer MarkLLM. Sélectionnez des prompts représentatifs du support, des ventes, des politiques internes et du code, puis évaluez ensemble la détectabilité, la robustesse et la qualité du texte. Il ne s’agit pas de désigner un vainqueur universel, mais de trouver la méthode dont le mode d’échec correspond au niveau de risque accepté par l’entreprise.

Une petite équipe de recherche qui reproduit KGW devrait retenir lm-watermarking. Son périmètre plus étroit rend les hypothèses visibles et l’expérience explicable. Passez à MarkLLM lorsque la question de recherche vise une comparaison plutôt qu’une reproduction.

Un responsable de l’audit ou des opérations de contenu qui examine des artefacts variés devrait employer watermarks-remover comme outil complémentaire. Conservez l’original, inspectez l’Unicode et les métadonnées, et n’exécutez un détecteur statistique que si la configuration correspondante est connue. Présentez séparément chaque couche de preuve.

Un acheteur qui contrôle des textes tiers de Claude, Gemini ou ChatGPT ne devrait choisir aucun des quatre comme scanner universel. Attendez le vérificateur du fournisseur concerné, demandez les enregistrements de source ou classez le cas comme non pris en charge. L’API d’Anthropic est annoncée, la vérification publique de texte de Google ne figure pas parmi ses interfaces actuelles de vérification des médias, et le vérificateur public d’OpenAI couvre pour l’instant les formats image et audio.

Le choix bascule autour d’une seule question : contrôlez-vous le générateur ou disposez-vous du canal de vérification du fournisseur ? Toutes les comparaisons de fonctionnalités s’inscrivent à l’intérieur de cette frontière.

Le vrai poste budgétaire est la calibration, pas la licence

La licence logicielle de chaque outil classé commence à $0. C’est le chiffre le moins utile pour prendre une décision.

Les recommandations minimales de Hugging Face pour l’entraînement créent le premier véritable poste de dépense. Commencez par 10,000 prompts représentatifs. Produisez pour chacun une sortie marquée et une sortie sans marquage. Vous obtenez 20,000 générations, avant l’entraînement du détecteur, l’évaluation sur un jeu isolé, le choix du seuil et les nouveaux tests à chaque changement de modèle ou de configuration.

Le coût d’inférence n’est qu’une partie de ce budget. Il faut définir des prompts représentatifs, versionner les clés et les configurations, stocker les sorties, étiqueter les deux classes, analyser les échecs et décider des conséquences autorisées pour un résultat de détection. Si un score positif bloque automatiquement une publication, un paiement, une admission ou un emploi, la conception du seuil et de la procédure de recours devient plus importante que la popularité du dépôt.

Trois états doivent être conservés :

• Détecté : le détecteur correspondant a trouvé un signal au seuil opérationnel choisi par l’organisation.
• Non détecté : le détecteur correspondant n’a pas trouvé de signal dans un échantillon pris en charge. Le résultat peut néanmoins s’expliquer par la modification, la longueur, le type de contenu ou une incompatibilité de modèle.
• Non pris en charge : aucun détecteur adapté à la source n’existe pour le générateur annoncé, ou l’échantillon ne remplit pas les conditions d’utilisation du détecteur.

Fusionner les deux derniers états est l’erreur qui coûte cher. « Non détecté » est déjà bien plus précis que « écrit par un humain ». « Non pris en charge » signifie que le système ne disposait d’aucun instrument valable pour répondre à la question.

La gouvernance globale doit être définie en parallèle de votre politique de filigranage des contenus générés par l’IA. Marques intégrées, mentions de transparence, journaux de source et certificats de contenu répondent à des facettes différentes du problème de provenance. Un workflow robuste les combine, au lieu de demander à un unique score de détection de trancher tout le dossier.

Les outils à ne pas utiliser comme preuve de provenance

GetGPT Text Watermark Scanner est un vérificateur Unicode gratuit et utile, mais pas un détecteur de la marque statistique protégée par clé d’Anthropic. Cet outil dans le navigateur recherche plus de 34 caractères Unicode cachés ou ambigus, dont U+200B, U+202F, U+2014 et U+2003, sans exiger d’inscription. Il peut ainsi repérer des artefacts de mise en forme qu’il vaut la peine de nettoyer. Il ne sait pas lire un signal dont Anthropic affirme qu’il ne contient aucun caractère caché.

Utilisez GetGPT lorsqu’un texte copié se comporte étrangement dans un CMS, un diff, un index de recherche ou un parseur en aval. Ne déduisez pas d’un résultat propre que Claude, Gemini, ChatGPT ou un humain en est l’auteur. Les catégories de preuve ne correspondent pas.

WatermarkDetector.com est un autre scanner Unicode gratuit qui fonctionne localement dans le navigateur. Il couvre 26 catégories de caractères, annonce un usage illimité et ne propose pas d’API publique. Il convient bien aux contrôles rapides de mise en forme lorsque des textes sensibles doivent rester dans le navigateur. Il lui manque toujours la clé du fournisseur ou la configuration de génération nécessaire à la vérification d’un filigrane statistique de modèle.

Gardez WatermarkDetector.com dans la boîte à outils d’hygiène éditoriale, pas au tribunal de la paternité. Son périmètre produit est plus étroit que la question posée ; le présenter honnêtement évite de détourner un outil utile de sa fonction.

Les classificateurs génériques de textes IA doivent rester hors du classement des filigranes pour la même raison. Ils estiment si des motifs linguistiques ressemblent à une production de modèle. Un détecteur de filigrane cherche, lui, un signal volontairement introduit par un processus de génération connu. Les deux peuvent fournir un score, mais ce score ne répond pas à la même question.

Google et OpenAI exigent également une formulation rigoureuse. Google affirme que SynthID marque et identifie le texte généré dans Gemini. Pourtant, le parcours public de vérification Gemini et le portail SynthID Detector répertorient actuellement la vérification des images, des vidéos et de l’audio, sans proposer le collage de texte. De même, le vérificateur public d’OpenAI indique des formats image et audio. Aucune de ces interfaces publiques ne transforme un scanner Unicode tiers en vérificateur officiel de texte.

Ce qu’il faut faire dès lundi

Ne commencez pas lundi par l’achat d’un scanner. Commencez par un inventaire.

1. Répertoriez chaque produit et workflow qui génère, modifie ou reçoit du texte assisté par IA.
2. Consignez le fournisseur, le modèle, la version, l’application source et précisez si votre organisation contrôle la génération.
3. Affectez l’un des trois états de détection : détecteur interne disponible, vérificateur officiel du fournisseur disponible ou non pris en charge.
4. Choisissez un workflow reposant sur un modèle maîtrisé pour mener un pilote Hugging Face SynthID Text ciblé, avec des sorties appariées marquées et non marquées.
5. Conservez les originaux avant tout nettoyage Unicode, suppression de métadonnées, paraphrase ou traduction.
6. Placez la vérification des fournisseurs derrière un adaptateur interne unique, afin d’ajouter la future API d’Anthropic sans réécrire la politique.
7. Définissez ce qu’un résultat positif, négatif ou non pris en charge est réellement autorisé à déclencher.

Le résultat attendu lundi n’est pas un contrat pour un détecteur universel. C’est une cartographie de la provenance qui montre où les preuves existent, où investir dans la calibration et où l’organisation doit répondre « inconnu ».

Questions fréquentes

Comment détecter un filigrane dans un texte généré par l’IA ?

Utilisez le détecteur associé à la clé ou à la configuration de filigranage du générateur. Si vous maîtrisez la génération, entraînez et calibrez le détecteur correspondant sur des sorties marquées et non marquées. Si un fournisseur propose un vérificateur officiel, utilisez ce service. Sans l’une de ces deux voies, un scan générique ne peut pas vérifier la marque statistique du fournisseur.

L’IA laisse-t-elle un filigrane dans les textes ?

Certains systèmes compatibles le font. Google affirme que SynthID marque le texte généré dans Gemini, et les nouveaux modèles Claude compatibles utilisent une version de SynthID-Text. La couverture n’est pas universelle ; un texte court, factuel, traduit ou profondément modifié peut contenir trop peu de signal détectable.

Claude ajoute-t-il un filigrane aux textes générés ?

Les modèles Claude compatibles lancés dans l’UE à compter du 2 août 2026 marquent le texte généré dès leur lancement, tandis que la prise en charge des modèles plus anciens continue d’être déployée. La marque est un motif statistique protégé par une clé dans le choix des mots, pas une astuce fondée sur des caractères cachés. L’API de détection d’Anthropic est à venir.

Comment vérifier un filigrane ChatGPT ?

Le vérificateur public d’OpenAI prend actuellement en charge les images et l’audio, pas le texte collé. Un scanner Unicode dans le navigateur peut repérer des caractères suspects dans un texte copié, mais il ne peut pas établir que ChatGPT a généré les mots.

ChatGPT peut-il supprimer les filigranes ?

Une réécriture complète peut perturber les motifs statistiques liés au choix des mots, sans prouver pour autant une rédaction humaine ni garantir que le détecteur du fournisseur renverra un résultat négatif. Conservez l’original et indiquez précisément ce que le détecteur disponible est capable de vérifier.

Obtenez la carte des outils IA pour les dirigeants afin de distinguer les infrastructures IA réellement déployables des outils qui n’en ont que l’apparence.