Une application prépare un commentaire de ventes avec Claude, dessine un graphique et rassemble le tout dans un PDF. Une question revient au moment de diffuser le rapport : peut-on vérifier ce que Claude a produit ou retouché ? Le watermark textuel, les métadonnées d’un fichier et le journal de l’application apportent des réponses différentes.
Les notes Claude du 3 novembre 2026 documentent l’extension du watermark textuel à Mythos 5, Opus 4.7 et Sonnet 4.6, sur les plateformes indiquées par Anthropic. Ce n’est pas la naissance du marquage Claude : son mécanisme a été présenté le 14 août. Le changement utile à vérifier aujourd’hui porte sur la couverture de modèles plus anciens et leurs conditions d’utilisation.
Cette analyse documentaire suit un rapport fictif pour décider quels contrôles conserver dans une chaîne de production. Aucun texte n’a été soumis au détecteur privé, aucun fichier Claude n’a été généré ou vérifié pour cet article.
Le watermark est un motif dans les choix de génération
Le mot peut faire penser à une marque visible sur une image ou à des caractères cachés dans un document. Le mécanisme textuel décrit par Anthropic utilise une autre voie : la source de l’aléa qui départage les mots possibles pendant la génération.
Quand plusieurs suites conviennent au contexte, le modèle doit choisir. Une clé et le texte précédent interviennent dans cette décision aléatoire. Sur un passage suffisamment riche, un détecteur qui dispose de la clé peut chercher la compatibilité entre la séquence obtenue et ce mécanisme. Un lecteur ne voit pas de tampon ou de code supplémentaire dans la phrase.
Anthropic décrit une variante de SynthID-Text. Le fournisseur indique que ce procédé n’ajoute ni token ni caractère caché, et n’encode pas l’identité de la personne, de l’entreprise ou de la conversation. Ses affirmations sur l’absence d’effet pratique sur la qualité et le coût restent des affirmations du fournisseur, pas un résultat mesuré ici. Explication technique d’Anthropic, publiée le 14 août.
Cette mécanique explique une limite importante pour les équipes data. Une valeur exacte, un identifiant ou une syntaxe de code offrent peu de choix interchangeables. Un commentaire rédigé peut porter davantage de signal qu’un extrait très court ou un bloc fortement contraint. Le marquage ne contrôle ni le calcul d’un indicateur ni la fidélité d’une conclusion à sa source.
Ce qui change pour les modèles utilisés en entreprise
La couverture se vérifie par modèle et plateforme, à la date de génération. Le tableau d’Anthropic distingue les sorties directes, les partenaires cloud et les fichiers avec Content Credentials. Ne remplacez pas cette matrice par une règle « toute sortie Claude est détectable ».
Au 4 novembre, deux points demandent une attention particulière :
- Amazon Bedrock : pour Mythos 5, Opus 4.7 et Sonnet 4.6, la table annonce une fin de déploiement du marquage textuel d’ici le 10 novembre. Une échéance annoncée ne prouve pas la disponibilité sur chaque requête pendant la transition.
- Sonnet 4.6 : des valeurs non standard de
temperature, top_p ou top_k peuvent rendre le marquage textuel non fiable. La documentation API conseille d’omettre ces paramètres lorsqu’on dépend du watermark, y compris ceux injectés par un framework.
La matrice actuelle des modèles et la note technique sur les paramètres sont les références à joindre au dossier d’intégration. Une case favorable dans cette matrice décrit le support du mécanisme ; elle n’est pas le résultat d’une détection sur votre document.
Si vous utilisez un réglage de génération pour une raison métier, son retrait demande aussi de requalifier la qualité des réponses. Le gain recherché dans la traçabilité ne dispense pas de vérifier que l’application réalise toujours la même tâche.
Suivre le même rapport sous trois formes
Prenons une équipe qui automatise un commentaire de ventes hebdomadaire. Dans ce scénario fictif, les chiffres viennent d’une requête contrôlée. Claude rédige une explication à partir de ces résultats. L’application récupère aussi un graphique PNG produit dans le bac à sable de code de Claude, puis assemble un PDF de diffusion.
Le raisonnement doit suivre les objets réellement échangés :
| Sortie du scénario |
Contrôle pertinent |
Ce qu’il ne faut pas conclure |
| Commentaire textuel renvoyé par un modèle couvert |
Vérification du modèle, des paramètres et, si l’accès est accordé, du watermark textuel |
Le texte est exact ou entièrement écrit par Claude |
| Graphique PNG produit dans le bac à sable et téléchargé par la Files API |
Vérification d’un Content Credential Claude dans le fichier reçu |
Les chiffres du graphique sont validés par la signature |
| PDF assemblé par l’application |
Journal des étapes et lien vers les versions sources |
Le PDF reçoit automatiquement une signature Claude parce qu’il contient du texte ou une image issus de Claude |
Sur l’API, les Content Credentials concernent les fichiers image, vidéo et audio pris en charge, produits dans le bac à sable et téléchargés via la Files API. Les fichiers texte, PDF et documents bureautiques ne sont pas signés par ce mécanisme. Un PDF fabriqué par votre application ne devient donc pas une preuve de provenance Claude par simple assemblage. Documentation des fichiers générés et de leur signature.
Il faut aussi garder séparés le texte envoyé par l’API et son export en fichier. Mettre ce texte dans un .txt ou dans un PDF ne constitue pas un test du watermark textuel. Le motif éventuel se situe dans la séquence de texte ; le contrôle C2PA examine une autre couche.
Lire une signature de fichier sans lui faire dire davantage
Un Content Credential est un manifeste signé dans les métadonnées du fichier. Pour les fichiers API concernés, la documentation décrit un émetteur Anthropic, un horodatage et une action indiquant que Claude a fourni le fichier et peut en avoir créé ou modifié le contenu.
Dans notre cas, cela peut documenter une étape de traitement du PNG. Cela ne prouve pas que Claude est l’auteur des données de ventes, ni que le graphique utilise la bonne période ou la bonne agrégation. Ces contrôles restent rattachés à la requête, aux données et à la validation du rapport.
La signature intervient au téléchargement par la Files API. La documentation précise que l’ajout du manifeste change la taille et l’empreinte du fichier par rapport à celui présent dans le conteneur. Calculez donc l’empreinte de la version effectivement reçue et diffusée. Si votre application transforme ensuite l’image, conservez le lien entre les deux versions plutôt que d’attendre une empreinte identique.
Le Claude Content Checker permet de chercher un Content Credential Claude sur les formats de fichiers qu’il accepte. Sa page précise qu’il fonctionne dans le navigateur et qu’il ne vérifie pas le texte. Le détecteur de watermark textuel est une API distincte, actuellement en preview privée pour les organisations éligibles. Ne construisez pas votre recette sur l’hypothèse d’un accès public à ce détecteur.
Un signal positif et un signal absent ne répondent pas à tout
Un résultat de détection doit rester attaché à son objet et à son outil. Un signal Claude détecté peut indiquer une génération ou une transformation : traduction, révision ou adaptation d’un contenu d’origine humaine. Il ne permet pas d’attribuer toutes les idées au modèle ou de retrouver un utilisateur.
L’absence de signal demande également une lecture limitée. Un passage trop court, un modèle ou une surface non couverts, une réécriture importante ou la suppression des métadonnées d’une image peuvent expliquer l’absence d’un marquage détectable. Un outil qui ne trouve pas de credential dans le PDF final n’établit pas que le texte source a été écrit sans IA.
La bonne sortie d’un contrôle peut donc être « aucune détection effectuée » ou « aucun credential Claude trouvé dans ce fichier ». Les remplacer par « contenu humain » ferait perdre l’information sur ce qui a réellement été examiné. Portée et limites de la détection selon Anthropic.
Première mise en pratique : préparer une trace vérifiable
La fiche de provenance du rapport organise le contrôle sur les trois sorties du scénario. C’est une proposition de recette, sans résultats de détecteur préremplis.
Commencez par un exemple non sensible déjà autorisé dans votre environnement :
- Relevez la génération effective. Modèle réellement appelé, point d’accès, date, référence de réponse et paramètres envoyés, y compris ceux ajoutés par les bibliothèques. Séparez l’intention configurée du résultat observé.
- Conservez les versions. Texte reçu, PNG téléchargé, puis PDF assemblé. Pour les fichiers, notez l’empreinte après réception et chaque transformation qui crée une nouvelle version.
- Choisissez le contrôle adapté. Modèle et plateforme d’abord ; watermark textuel seulement avec accès au détecteur ; credential pour le fichier pris en charge. Enregistrez « non effectué » lorsque le contrôle n’a pas eu lieu.
- Reliez les preuves au rapport diffusé. La trace de génération, un éventuel résultat de détection, les transformations et la validation des chiffres restent des pièces distinctes.
Le premier critère de réussite est simple : une personne qui reprend le dossier doit savoir quel objet a été vérifié, par quel moyen, et ce qui reste inconnu. On peut préparer cette traçabilité sans modifier les appels API pour le seul marquage ni attendre un accès au détecteur privé.
L’extension du 3 novembre mérite ainsi une vérification de vos modèles et de vos paramètres. Elle enrichit les signaux de provenance disponibles. La décision d’accepter et de diffuser un rapport continue de s’appuyer sur ses sources, ses transformations et sa validation métier.
