Comme promis dans mon précédent post sur le fichier robots.txt, voici un petit topo sur le protocole TDMRep. Il permet de parler aux robots nourrissant les intelligences artificielles (IA) pour leur interdire de s’entraîner sur vos contenus ou pour leur indiquer la manière d’obtenir une licence. Une nouvelle façon de monétiser vos pages ? Trop tôt pour le dire. Ce protocole commence à peine à être utilisé, mais sa validation par le W3C devrait lui assurer une large adoption.

Dès à présent, Alyze se dote d’une fonctionnalité pour tester si ce protocole est bien en place sur votre site. Cette nouvelle fonctionnalité sur Alyze gagne à être présentée après un petit exposé du contexte, du protocole TDMRep, de son utilité et de ses risques éventuels.

Un peu de contexte

Tout part d’une question : les IA génératives et autres techniques de data mining ont-elles le droit d’utiliser les contenus librement accessibles sur le web pour entraîner leurs modèles ? Pour répondre à cette question, il faut interroger le droit d’auteur (ou le copyright anglo-saxon). Le droit d’auteur interdit par principe de reproduire tout ou partie d’une œuvre, mais il prévoit aussi des exceptions notables : courte citation, exception pédagogique, fair use aux États-Unis, etc. En l’état de la jurisprudence, il est très difficile de savoir si ces exceptions sont aptes à autoriser les technologies de text and data mining (abrégé TDM) utilisées par les IA. 

Il est également possible que l’adage « les idées sont de libre parcours » s’applique à ces techniques. Après tout, ces modèles apprennent des contenus qu’ils consultent sans les reproduire au sens propre. Ça sera en tout cas l’objet d’une bataille juridique qui s’annonce épique aux États-Unis.

Pourtant, cette bataille n’aura peut-être pas lieu en Europe. Pourquoi ? Car l’Union Européenne a déjà tranché ! Une exception au droit d’auteur a été ajoutée par la Directive du 17 avril 2019 (2019/790) portant sur le droit d’auteur et les droits voisins. La « fouille de textes et de données » – comme le dit la directive dans sa version française – est autorisée pour tous les contenus librement accessibles.

Un mécanisme d’opt-out est heureusement mis en place par la directive en son article 4. En clair, pour interdire les techniques TDM sur votre site, vous devez signaler votre refus. Par défaut, tous les outils de la terre sont autorisés à fouiller dans vos publications. 

Comment faire pour signifier votre refus ? C’est là qu’intervient le TDM Reservation Protocol ou TDMRep. Ce standard permet aux titulaires de droit de faire valoir la clause d’opt-out via un procédé « lisible par machine » comme le prévoit la directive. Ce protocole a reçu l’aval du W3C, l’organisme chargé d’édicter et de faire évoluer les standards du web.

Mettre en place le TDMRep sur votre site

Il y a trois manières différentes pour implanter le protocole TDMRep sur un site web. Les SEO ne seront pas dépaysés en apprenant qu’on peut tout d’abord utiliser des balises HTML meta. Il est aussi possible d’utiliser un entête HTTP ou un fichier JSON, ce qui a l’avantage d’être indépendant du format des contenus. 

Balises HTML meta

Je ne vous apprends rien en disant que les balises HTML meta se situent dans la balise head de la page. Pour implanter le protocole TDMRep, il faut simplement utiliser des balises meta dotées d’un attribut name et d’un attribut content.

Pour indiquer qu’une page voit son contenu réservé (opt-out), il faut attribuer la valeur tdm-reservation à l’attribut name et la valeur 1 à l’attribut content (ou la valeur 0 pour confirmer le non usage de l’opt-out). Ce simple code est donc apte à indiquer qu’une page ne doit pas faire l’objet de techniques TDM :

<meta name="tdm-reservation" content="1">

De manière optionnelle, il est aussi possible d’indiquer une politique en matière de TDM. Une telle politique sert à dire que si, par principe, l’usage de ces techniques est interdit, il y a un moyen pour obtenir une licence. Vous avez compris qu’il s’agira bien souvent de demander une rémunération contre l’usage des contenus. Vous pouvez toutefois très bien ne pas fournir de politique TDM ce qui vaut opt-out sans moyen d’obtenir une licence. 

Pour indiquer cette politique, il faut créer une autre balise meta avec en attribut name la valeur dm-policy et en attribut content l’URL où cette politique peut être consultée. Comme ceci :

<meta name="tdm-policy" content="https://example.com/policies/policy.json">

L’URL de l’attribut content peut pointer vers un fichier texte qui sera alors réputé devoir être lu par un humain ou vers un fichier JSON qui devra être directement interprétable par une machine. Dans ce dernier cas, le fichier devra suivre le modèle ODRL (http://www.w3.org/ns/odrl.jsonld).

Si vous avez bien suivi, votre fichier HTML devrait ressembler à ça :

<!DOCTYPE html>
<html lang="fr">
  <head>
    <meta name="tdm-reservation" content="1">
    <meta name="tdm-policy" content="https://example.com/policies/policy.json">
    <title>Intelligence humaine inside</title>
  </head>
  ...
</html>

Entêtes HTTP

Pour s’émanciper du format HTML, il est également possible de fournir les informations directement dans la réponse HTTP. Le principe est exactement le même que pour les balises meta.

Voyez cet exemple de réponse HTTP précédant une image au format jpeg :

HTTP/1.1 200 OK
Date: Wed, 15 May 2024 13:47:26 GMT
Content-type: image/jpg
tdm-reservation: 1
tdm-policy: https://example.com/policies/policy.json

Ce sont bien entendu les deux dernières lignes qui nous intéressent. Le champ tdm-reservation contient un booléen : 1 (opt-out) ou 0 (par défaut). Le champ tdm-policy est ici aussi optionnel. Il contient donc l’URL de la politique en matière de TDM. Cette adresse peut là encore mener vers un fichier texte (human readable) ou un fichier JSON (machine readable) au format ODRL.

Si vos pages sont servies par du code PHP, voici deux lignes qui permettent de modifier vos entêtes HTTP :

header('tdm-reservation: 1');
header('tdm-policy: https://example.com/policies/policy.json');

Fichier JSON sur le serveur

Il est également possible avec un seul fichier placé sur le serveur de donner des directives pour tout un site ; même si chaque page du site ne précise rien en la matière. Ça fonctionne de la même manière qu’un fichier robots.txt, mais pour les techniques TDM.

En pratique, il s’agit de placer un fichier JSON nommé tdmrep.json dans le répertoire .well-known à la racine du site. Pour illustrer la chose, si l’adresse de votre site est www.example.com, ce fichier doit être accessible par www.example.com/.well-known/tdmrep.json

La norme précise que consulter ce fichier est la première chose que doit faire un robot TDM lorsqu’il s’apprête à explorer un site. Si ce fichier indique que le site choisit l’opt-out en matière de TDM, le robot doit arrêter là sa visite.

Si vous n’êtes pas familier avec le format JSON, sachez que ce n’est pas bien compliqué. Techniquement, il s’agit d’un objet Javascript représenté sous la forme d’une chaîne de caractère. Le fichier tdmrep.json typique permettant de réserver ses droits pour l’ensemble d’un site ressemble à ça :

[
  {
    "location": "/",
    "tdm-reservation": 1,
    "tdm-policy":"https://example.com/policies/policy.json"
  }
]

Vous voyez tout de suite les propriétés tdm-reservation et tdm-policy. Elles ont exactement le même rôle que les balises meta ou entêtes HTTP ; à savoir : tdm-reservation doit contenir la valeur 1 pour indiquer l’opt-out et tdm-policy, qui reste optionnel, doit contenir l’URL où la politique du site en matière de TDM peut être consultée. Ici encore, cette URL peut mener à un fichier texte lisible par un humain ou un fichier JSON au format ODRL.

La propriété location est par contre spécifique à cette méthode. Dans l’exemple ci-dessus, elle contient la valeur / qui représente la racine du site. La règle s’applique donc sur l’ensemble du site.

La propriété location peut aussi être une chaîne de caractères plus longue pour définir le chemin où la règle va s’appliquer. Par exemple, si location contient « /pdf/ » les règles de réservation et de politique ne s’appliqueront que pour les fichiers présents dans le répertoire example.com/pdf/. Cette chaîne de caractère peut aussi contenir des expressions régulières très basiques comme on les rencontre dans les fichiers robots.txt. Il est ainsi possible d’utiliser l’astérisque (*) pour représenter zéro, un ou plusieurs caractères. Le caractère dollar ($) sert lui à indiquer une fin de ligne. 

Ce fichier pourra donc être utilisé pour réserver les droits sur tous les fichiers PDF d’un site sans possibilité d’obtenir une licence :

[
  {
    "location": "/*.pdf$",
    "tdm-reservation": 1,
  }
]

Enfin, vous avez sans doute remarqué les accolades [] au début et à la fin du fichier. Elles indiquent que l’objet est contenu dans un array (tableau). Il est donc possible de combiner plusieurs règles en séparant les éléments de l’array par des virgules. Libre à vous de combiner ces règles pour définir, par exemple, une politique pour tout le site (location = /) et une politique spécifique pour les fichiers PDF (location = /*.pdf$) :

[
  {
    "location": "/",
    "tdm-reservation": 1,
    "tdm-policy":"https://example.com/policies/policy-global.json"
  },
  {
    "location": "/*.pdf$",
    "tdm-reservation": 1,
    "tdm-policy":"https://example.com/policies/policy-pdf.json"
  }

]

Toutes autres combinaisons sont bien entendu possibles !

Utilités et dangers du TDMRep

L’utilité de ce protocole est assez évidente. Il s’agit de ne pas voir ses contenus utilisés par des IA sans contrepartie. Une IA qui apprend des choses en consultant vos textes, vos vidéos ou vos images ne va pas vous citer en retour et encore moins vous rémunérer. Le TDMRep a pour but, non seulement d’interdire aux robots des IA de se nourrir de vos créations, mais aussi de fournir un moyen d’obtenir une licence. Bien entendu, pour espérer pouvoir obtenir quelque chose en retour, il faut que votre site comporte du contenu – beaucoup de contenu ! – susceptible d’enrichir une IA. C’est le cas de nombreux sites d’actualités français qui utilisent déjà le protocole TDMRep (voir ci-dessous).

À noter que l’usage de ce protocole n’est pas rétroactif. Autrement dit, les IA qui sont venues faire un tour sur votre site il y a quelque temps n’oublieront pas ce qu’elles y ont appris, même si vous utilisez par la suite TDMRep. Ce qui est fait est fait. 

Pour l’heure, la principale limitation du protocole TDMRep est qu’il n’est pas largement adopté par les principaux acteurs du secteur (des tests me montrent toutefois des consultations régulières du fichier tdmrep.json). Il faut dire que son adoption par le W3C est encore très récente. Si légalement je ne vois pas comment les acteurs de l’IA peuvent ignorer ce protocole lorsqu’ils procèdent sur des sites situés en Europe, son adoption dépend aussi des éditeurs. C’est donc à vous de décider. De nombreux sites d’actualité de premier plan ne s’y sont pas trompés. La liste des sites utilisant le protocole TDMRep élaborée par Olivier Martinez est déjà impressionnante.

Enfin, y a‑t-il un danger à utiliser ce protocole ? L’intégration de l’IA dans les moteurs de recherche peut faire craindre que l’usage du TDMRep fasse perdre en visibilité. En particulier, la Search Generative Experience (SGE) mise en avant par Google pour intégrer l’IA à son moteur pourrait ne pas inclure les sites se réservant leurs droits en matière de TDM.

Pour l’instant, rien n’indique que ça sera le cas. Le moteur de recherche de Google reste basé sur GoogleBot et non sur Google-Extended qui serait seulement utilisé pour nourrir Gemini et Vertex AI. La documentation de Google dit explicitement que « Google-Extended n’a aucune incidence sur l’inclusion ou le classement d’un site dans la recherche Google ». Le plus probable est que la SGE va être considérée comme une sorte de snippet. Google indique d’ailleurs que la balise meta nosnippet permet de ne pas apparaître dans les résumés SGE. À utiliser si ces résumés passent l’envie aux visiteurs d’aller visiter vos pages (codes promo et autres informations brèves et suffisantes en elles-mêmes). Plus surprenant, si on se base sur ce que fait Bing, ça serait la balise meta noarchive qui permettait de ne pas apparaître dans les résultats de recherche enrichis par l’IA. J’en conclus que ces résultats seraient générés en travaillant sur la version archivée des pages au moment même de la requête.

Il faut toutefois rester prudent. La SGE n’est pas encore déployée en Europe et nous avons vu que le TDMRep est un protocole destiné avant tout à ce territoire. Tant que la SGE ne sera pas pleinement déployée, et tant que Google n’aura pas dévoilé tous ses efforts en matière d’IA sur son moteur de recherche, il n’y aura pas de réponse certaine. Restons optimistes, le géant de web abuserait clairement de sa position s’il venait à considérer que l’usage du TDMRep ne permet pas d’apparaître correctement dans ses résultats de recherche, il s’exposait alors à de lourdes sanctions. Dissuasives ? Telle est la question…

Vérifiez votre implantation avec Alyze

Si vous souhaitez utiliser votre faculté d’opt-out, Alyze a tout en place pour vous aider à vérifier votre implantation. Vous pouvez bien entendu aussi regarder ce que font vos concurrents, c’est souvent riche d’enseignement.

Lorsque vous faites une analyse de page, un nouvel élément « IA et data mining » est présent dans l’onglet Configuration.

Ce protocole devrait prochainement être intégré aux autres outils Alyze. En attendant, n’hésitez pas à me faire part de vos retours sur l’utilisation de TDMRep ou sur le blocage des bots IA par robots.txt. Les informations publiques sur ces questions pourtant brulantes sont rares. Vos retours d’expérience en sont d’autant plus précieux !