Nous allons nous concentrer ici sur les moyens mis à la disposition des auteurs de contenus afin de tenter de maîtriser cette fouille, apparentée par beaucoup à un vol de données. En effet, grâce à cette fouille, l'IA (Intelligence Artificielle) permet de réaliser des "créations" de plus en plus réalistes. Nos propres productions sont de ce fait concurrencées par ce que l'on nous a pris, sans notre avis. La question posée étant, que pouvons-nous faire face à l'utilisation de nos données destinées, sans aucune contrepartie, à enrichir les gigantesques bases de l'IA ? Quels sont les moyens que nous pouvons engager afin de faire respecter notre travail d'auteur de contenus ? Le but n’étant pas de se dresser contre l’IA, mais d’en obtenir reconnaissance, voire rémunération, lorsque nous y sommes entraînés, de gré ou de force. Ces questions seront posées tôt ou tard aux développeurs professionnels par des clients inquiets de l'utilisation de leur contenu, ainsi qu’aux amateurs qui mettent en place leur propre site web. Y être préparé le plus tôt sera le mieux. L’IA a pris de l’avance et chaque seconde, des millions de données sont aspirées du web dans la plus totale opacité, sans que les auteurs de ces productions n'en connaissent la finalité.
Dans cet article sera abordé la mise en place de deux procédés, l’opt-out, à travers le protocole TDMRep et le blocage des robots aspirateurs. La procédure décrite ici est simple, il n’y a pas de code à réaliser. Il suffira de respecter l’emplacement des dossiers et des chemins permettant de les atteindre.
L'opt-out, l'exception à l'exception
Il est important de comprendre l'opt-out et l'opt-in, deux termes omniprésents sur le net. Dans le contexte de la fouille de données, l'opt-out est un procédé déclaratif qui permet à une personne détentrice des droits sur une œuvre (écrit, musique, audio, vidéo, image) d'avertir un robot aspirateur qu'elle refuse que son travail soit utilisé afin d’enrichir les bases de données de l'IA. L’opt-out n’est qu'une déclaration, aucun procédé technique n'intervient pour empêcher une fouille des données. À contrario, l'opt-in l’autorise sans restrictions. Le fait de ne rien déclarer entraîne de facto l'opt-in, comme le précise le texte de loi ci-dessous. Pour résumer, l’opt-out est un jalon pour l’avenir, une précaution à prendre.
Voici le texte de loi qui régit l’utilisation des fouilles de données et l’opt-out.
« Sans préjudice des dispositions du II, des copies ou reproductions numériques d'œuvres auxquelles il a été accédé de manière licite peuvent être réalisées en vue de fouilles de textes et de données menées à bien par toute personne, quelle que soit la finalité de la fouille, sauf si l'auteur s'y est opposé de manière appropriée, notamment par des procédés lisibles par machine pour les contenus mis à la disposition du public en ligne » (Article L. 122-3 III du Code de la propriété intellectuelle)
On aura compris que l’opt-out consiste à dire au robot « Je refuse la réutilisation de mes données dont la finalité est d’alimenter l’entraînement d’une IA ».
Certains organismes de gestion collective de droits, de même que des médias, ont d'ores-et-déjà soit engagé le blocage des robots, soit précisé avoir exercé leur droit d'opt-out sur les contenus qu'ils gèrent : La SACEM, La SAIF, L'ADAGP, La SABAM, pour n'en citer que quelques-uns. La liste complète et déjà conséquente est en fin de page. L'opt-out n'est pas une lubie, de grands noms des médias s'y sont engagés.
Comment déclarer l'opt-out sur un site web ?
Cette déclaration peut être faite sous forme de texte dans les conditions générales d'utilisation du site. Cependant, il est fortement conseillé qu'en parallèle la déclaration puisse être lisible par les machines. C’est ce que nous allons mettre en place.
1 - Une balise meta dans le head du site.
<meta name="tdm-reservation" content="1">
Attention, le fait de mettre content="0" engagera l'opt-in.
C’est tout, la déclaration de l'opt-out est faite sur votre site. Elle ne prend qu’une minute et ne bloque aucun robot. Elle a une valeur juridique en Europe en vertu de la Directive 2019/790 La directive précise que la « fouille de textes et de données » est autorisée pour tous les contenus librement accessibles. Un mécanisme d’opt-out a été heureusement mis en place par la directive en son article 4. En clair, pour interdire les techniques TDM sur votre site, vous devez signifier votre refus. À défaut, tous les robots de la terre seront autorisés à fouiller dans vos publications afin d'entraîner les modèles d'IA.
Si le but est de mettre en place l’opt-out simple, cette balise se suffit à elle-même. On la copie telle qu’elle dans le head de son site web. Afin d'effectuer la déclaration sur la totalité du site, il faudra la répliquer sur toutes les pages. On pourra aussi décider de ne cibler que certaines pages avec cette balise. Si par contre, on désire ajouter à l’opt-out une directive, une « policy » en anglais, on devra insérer une seconde balise meta, qui pointera vers un script JSON. Ce script pourra aussi être atteint par un autre chemin, présenté plus loin sur cette page.
2 - Opt-out avec directive et seconde balise meta
Voici comment la déclaration d'opt-out peut-être complétée, afin de préciser les conditions dans lesquelles les œuvres pourraient être utilisées, ainsi que les contacts de l'auteur. On est toujours dans l'opt-out, mais une porte est ouverte, permettant de négocier soit une reconnaissance, soit une éventuelle rémunération avec le fournisseur d’IA. De grands groupes l'ont déjà fait (Le Monde). Cette déclaration revient à dire à l’IA « je peux travailler pour toi et être rémunéré ». Ce vœu formulé peut paraître utopique au vu du rapport de force inégal entre un particulier et une multinationale. En l’état actuel, c’est le cas, mais il est louable de croire à une évolution en faveur des auteurs. D'où l'intérêt d'être adhérant d'une société de perception des droits ou de protection du travail de création.
3 - Les deux balises meta avec "policy" et le script JSON
<meta name="tdm-reservation" content="1">
<meta name="tdm-policy" content="https://monsite.fr/policies/policy.json">
Le script JSON policy.json est donné ci-dessous. Comme le chemin du lien l’indique, ce script est à installer dans un dossier policies que vous aurez créé et placé à la racine de votre site. Attention à ne pas confondre policies et policy.
[{
"@context": [
"http://www.w3.org/ns/odrl.jsonld",
{"tdm": "http://www.w3.org/ns/tdmrep#"}
],
"@type": "Offer",
"profile": "http://www.w3.org/ns/tdmrep",
"uid": "https://monsite.fr/policies/policy.json",
"assigner": {
"uid": "https://monsite.fr",
"vcard:fn": "nom_auteur",
"vcard:hasEmail": "mailto:auteur@free.fr",
"vcard:hasAddress": {
"vcard:street-address": "Rue là-bas",
"vcard:postal-code": "90000",
"vcard:locality": "Brest",
"vcard:country-name": "France"
},
"vcard:hasTelephone": "tel:+330000000000",
"vcard:hasURL": "https://monsite.fr/CGU.html"
},
"permission": [{
"target": "https://monsite.fr",
"action": "tdm:mine",
"duty": [{
"action": "compensate"}
]
}
]
}]
Il faudra prendre soin de donner les informations correctes dans le script JSON. Le test proposé plus bas ne vérifie pas leur exactitude, alors que ces informations seront le seul moyen pour vous contacter et rendre pérenne vos intentions. De même, le script passe le test de validité JSON, bien que les informations inscrites soient fantaisistes sur cet exemple. Vérifiez bien les informations personnelles que vous entrez dans le script. Ce script n'est pas figé, les personnes ayant une connaissance de JSON pourront soit retirer des informations soit en ajouter.
4 - Directives à travers le dossier .well-known
Avec le même script JSON, il est possible d’obtenir un résultat identique, mais à travers un autre chemin. Cette solution comporte quelques avantages. On doit créer à la racine de son site un autre répertoire, nommé .well-known, qui contiendra le script tdmrep.json ci-dessous, sur lequel il faudra mettre le lien adéquat.
[ { "location": "/",
"tdm-reservation": 1,
"tdm-policy":"https://monsite.fr/policies/policy.json"
} ]
Le dossier .well-known devra être placé à la racine du site de l'hébergement. Attention, plusieurs hébergeurs installent d'office un dossier .well-known à la racine de tout site hébergé chez eux. Il y aura conflit sur deux noms de dossiers identiques. Dans ce cas, il ne faudra que copier le script tdmrep.json dans le dossier .well-known de l'hébergeur, à côté des autres fichiers déjà présents. Il ne faut surtout pas remplacer ni écraser ce dossier .well-know, il a été placé par l'hébergeur pour la validation des certificats SSL, Let’s Encrypt ou autre. Bien sûr, sur votre propre disque dur, vous pouvez installer le dossier .well-known sans problème. Ci-dessous, l'emplacement de l'ensemble, à la racine de votre site.
|---- Racine du site web/
| |---- policies/
| | |---- policy.json
| |---- .well-known/
| | |---- tdmrep.json
Pourquoi un chemin différent ?
On peut se poser la question de la nécessité d’atteindre le script JSON par des chemins supplémentaires, alors qu’une simple balise meta suffit. L’avantage ici est de déclarer la règle pour l’ensemble du site grâce à la valeur /. Il n’y aura pas à répliquer la règle sur toutes les pages. D’autre part, et d’après la norme, consulter le dossier .well-known est la première chose que doit faire un robot TDM. Face à une règle opt-out, ce robot peut continuer sa visite, mais il est averti et devra lire la " policy ". En donnant le chemin uniquement avec des balises meta, il y a le risque d’oublier une page sur les sites importants. Le robot pourrait atteindre directement la page non protégée.
De plus, dans le script tdmrep.json, en lieu et place de la racine du site, il est possible d’indiquer des cibles plus précises (répertoires, expressions régulières, fichiers PDF). Ces options offrent toutes sortes de combinaisons relatives à l’utilisation des données. On se reportera à la publication du W3C, qui décrit en détail les très nombreuses possibilités offertes par le protocole TDMRep
Que peut-on attendre de l’opt-out ?
L'efficacité de l'opt-out par contre ne vaut que ce que le plaignant pourra engager comme procédures contre un fournisseur d'IA qui ne l'aura pas respecté. Une entreprise puissante pourra engager des avocats. Un particulier devra s'appuyer sur une société de perception des droits des auteurs (SACEM ou autre). En l'état actuel, les auteurs isolés sont assez démunis face aux entreprises d'IA, mais il faut anticiper l'avenir et l'évolution du droit.
Bloquer les robots aspirateurs
Le fichier robots.txt
La première méthode à laquelle tout le monde pense, c'est d'utiliser le fichier robots.txt afin d'opérer un blocage des robots. On est hélas à la merci du bon vouloir des sociétés qui engagent ces fouilles. Les plus connues ont annoncé tenir compte des refus mentionnés dans le fichier robots.txt. Pour les autres, c'est selon leur volonté. Par conséquent, il ne faut pas trop compter sur robots.txt et les bonnes intentions du monde de l'IA. Pourtant, ce blocage par le robots.txt est proposé par de très nombreux sites web. Il ne sera décrit ici qu’à titre d’information, son efficacité étant toute relative.
À titre d’exemple, voici à quoi ressemble un blocage sur robots.txt
# Block AI bots
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
# Allow everything else
User-agent: *
Allow: /
Il existe aussi un fichier qui permet le blocage des images. Il se nomme ai.txt et se place à la racine du site. Il a l’avantage de ne cibler que certaines ressources, contrairement au fichier robots.txt.
Bloquer les images avec ai.txt
User-agent: MidJourney
Disallow: /
User-agent: StableDiffusion
Disallow: /
User-agent: Dall-E
Disallow: /
De même qu’avec le fichier robots.txt, on ne sait pas trop qui va respecter ou pas ces directives.
Passer au stade supérieur en bloquant l'user-agent des robots
Ici, on bloque les robots aspirateurs directement sur le fichier htaccess du serveur.
Script à installer sur le htaccess de son serveur Apache
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} (AdsBot-Google|Amazonbot|anthropic-ai|Applebot|Applebot-Extended|AwarioRssBot|AwarioSmartBot|Bytespider|CCBot|ChatGPT|Claude-Web|ClaudeBot|cohere-ai|DataForSeoBot|Diffbot|FacebookBot|Google-Extended|GPTBot|ImagesiftBot|magpie-crawler|omgili|Omgilibot|peer39_crawler|PerplexityBot|YouBot) [NC]
RewriteRule ^ – [F]
</IfModule>
On pourra ajouter des user-agents si de nouvelles sociétés d'IA apparaissent. Le blocage peut être sélectif. Cette approche est beaucoup plus robuste que celle qui fait appel au fichier robot.txt.
Pour configurer le serveur ngnix, voici le lien ngnixtdmprep
En-têtes HTTP
Il est également possible de bloquer les robots aspirateurs dans l'en-tête HTTP. Ce protocole ne sera pas développé ici, car il est nécessaire d’avoir accès au serveur pour le mettre en place. Cette possibilité n’est jamais offerte sur les hébergements mutualisés. Le blocage par adresses IP parfois proposé n’est pas fiable. Ces adresses peuvent changer, volontairement ou pas.
Le résultat du test effectué sur l'un de mes sites :
Deux finalités à ne pas confondre
- TDMRep : Text and Data Mining Reservation Protocol, afin de mettre en place l’opt-out.
- Blocage des robots aspirateurs : robots.txt, ai.txt, htaccess, en-têtes http, adresses IP, plugin.
Les effets du blocage des robots sur le référencement
Est-il risqué de bloquer complètement les robots aspirateurs ? La question n'a pour le moment pas de réponse franche.
Google et d’autres acteurs importants du web ont expressément annoncé que bloquer leurs robots de fouilles de données n’avait aucune incidence sur la position du site sur leur moteur de recherches. Ces déclarations ne seront pas forcément valables dans le temps. Nous ne connaissons pas l’avis de tous les acteurs du secteur et les vérifications sont très difficiles à engager. Sans oublier que ChatGPT possède son propre moteur de recherches. Bien que les robots ne soient pas les mêmes, qu’en est-il des conséquences du blocage de la fouille de données ?
Ne pas en arriver là !
Préférer l’opt-out au blocage ?
À moins d’être déterminé à faire barrage, l’opt-out sans blocage des robots, mais avec une « policy » semble préférable. Supposons que dans un avenir pas très lointain, les fournisseurs d'IA, échaudés par l'opt-out et les procès à venir, soient contraints de rémunérer ou au moins citer certains auteurs de contenus. L'opt-out mis en place sera non seulement suffisant, mais indispensable. On ne peut pour le moment qu'attendre une évolution du rapport de force entre les différents acteurs.
Installer l'opt-out sans blocage sur son site est peut-être une sage décision ; les fournisseurs d'IA ne sont pas agressés par un blocage brutal de leurs robots, ils sont seulement avertis que la situation pourrait tourner un jour à leur désavantage s’ils contrevenaient aux règles fixées. À défaut d'avoir à sa disposition une équipe d'avocats spécialisés, on peut déjà se satisfaire en signifiant son refus de voir ses œuvres pillées. Ça ne coûte que deux balises meta d'une demi-ligne, un script JSON, et ça permet de dormir en pensant à l’avenir.
Chacun décidera en pleine conscience, mais il ne faut pas oublier que l’opt-out et le blocage sont deux options ayant une finalité différente, bien qu’elles puissent se révéler parfois complémentaires. Supposons qu’après un blocage engagé, un robot arrive à passer à travers les filtres. Si l’opt-out est présent par ailleurs sur le site, l’avertissement sera donné. Par contre, si l’opt-out n’est pas déclaré, il n’y a aucune protection juridique. Le blocage des robots aspirateurs n’engage pas l’opt-out, contrairement à ce qui est dit dans de nombreux articles sur le net.
Décider de bloquer tous les robots aspirateurs de données, c'est se fermer définitivement la porte à toute collaboration avec l'IA. Afin d'être honnête, il faudrait alors se refuser à l'utiliser (correcteurs grammaticaux, aide à la rédaction de textes, conduite automatique de véhicules, etc). Une IA qui continuerait à fonctionner avec les données des autres. La posture devient difficile à défendre, et ne tient pas, moralement.
Bloquer les robots de données devrait plutôt se concevoir comme ultime décision. Par exemple, une IA qui n'a pas respecté l'opt-out d'un site web et qui ne veut rien entendre, mérite en retour un blocage.
Conclusion
La technologie de l’IA est relativement récente, elle a pris de court l’ensemble des producteurs de données. Le droit tente de suivre, mais le rapport de force est pour le moment inégal et en défaveur des auteurs de contenus isolés. Rien n'est encore stabilisé à ce sujet, même si des procès retentissants sont déjà en cours. Il ne faut pas oublier que le droit européen cité plus haut ne s'applique pas aux États-Unis, pays d'où proviennent la majorité des sociétés d'IA. Il est par conséquent crucial de suivre l'évolution du droit international, les procès en cours, ainsi que la jurisprudence. Une chose est certaine, les inquiétudes liées à la fouille de données ne sont pas une simple révolte de geeks, de grands noms du web - Cloudflare, WordPress, proposent des plugins de protection.
Cet article n'a pas la prétention d'aborder l'ensemble des défis posés par l'IA. Plus modestement, les scripts décrits dans ces pages posent des règles de droit, afin que tout un chacun puisse bénéficier sereinement de l'intelligence artificielle.
Quelques procès en cours :
Commenter
Vous devez être inscrit et identifié pour utiliser cette fonction.
Connectez-vous (déjà inscrit)
Pas encore inscrit ? C'est très simple et gratuit.