Refuser l'entraînement des IA sur votre site ne demandera qu'une ligne

Un client vous envoie une capture d'écran. Un assistant en ligne vient de résumer votre catalogue, et deux phrases sont reprises presque mot pour mot de votre site. Vous voulez savoir ce que vous pouvez refuser, et à qui le dire. Depuis le 30 octobre 2026, une partie de la réponse est publique. Les principaux fournisseurs d'assistants acceptent de lire la même consigne, déposée dans un fichier de votre site.

Cette consigne ne dit pas « ne recopiez pas mes pages ». Elle dit « ne les utilisez pas pour entraîner vos modèles ». La différence est décisive. Elle sépare ce qui reste cité dans les réponses des assistants de ce qui disparaît de leurs sources.

Un mot de vocabulaire avant d'aller plus loin. Entraîner un modèle consiste à lui faire lire des quantités de textes pour qu'il en apprenne les régularités. C'est la fabrication du modèle, pas son usage quotidien. Une fois entraîné, il peut répondre sans revoir votre site.

Ce qui change pour votre site

Jusqu'ici, chaque fournisseur avait son propre nom de robot. Pour refuser l'entraînement, il fallait connaître ces noms et écrire une règle par fournisseur. Un site sérieux finissait avec dix lignes à maintenir à chaque nouvel acteur.

Le 30 octobre 2026, OpenAI, Google et Microsoft ont annoncé qu'ils liraient un signal commun. Un seul bloc, dans un seul fichier, exprime la même préférence à tous les fournisseurs participants. Le texte qui définit ce signal est écrit par Kevin Kelley, ingénieur chez Anthropic, dans le groupe de travail sur les préférences d'IA de l'IETF, l'organisme qui produit les standards d'Internet.

L'analogie est celle d'un panneau à l'entrée d'un magasin. Au lieu d'expliquer à chaque photographe que les photos sont interdites pour la publicité, vous affichez un panneau lisible par tous. Le panneau ne ferme pas la porte. Il informe ceux qui acceptent de le lire.

Le fichier que personne ne lit

Le fichier en question s'appelle robots.txt. C'est un fichier texte public, placé à la racine d'un site, que les programmes automatiques consultent avant de parcourir les pages. Il est utilisé depuis les débuts du web et a été normalisé en 2022 dans un document de référence numéroté, le RFC 9309.

Sa particularité tient en une phrase : ce n'est pas une serrure, c'est une consigne. Un programme qui l'ignore ne rencontre aucun mur. La norme le dit explicitement : le fichier n'est pas un mécanisme d'autorisation d'accès. Votre serveur ne bloque rien.

Pensez à une note affichée dans le hall d'un immeuble pour les livreurs : « merci de ne pas utiliser l'entrée de service ». La note n'empêche physiquement personne d'entrer. Elle fonctionne parce que les livreurs sérieux la lisent.

Cette faiblesse est aussi sa force. Le fichier est simple, public, et tous les robots connus le lisent depuis des années.

La ligne exacte, et ce qu'elle dit

Le signal ajoute un jeton, c'est-à-dire une étiquette, à l'endroit où l'on écrit normalement le nom d'un robot. Ce jeton s'appelle __usage_ai-training. Le bloc tient en deux lignes : User-Agent: __usage_ai-training, puis Disallow: /.

Pour refuser l'entraînement partout, c'est tout. Pour garder une exception, par exemple un dossier de presse que vous voulez voir circuler, ajoutez une ligne Allow: /presse/ dans le même bloc. La règle la plus précise l'emporte, comme dans un fichier robots.txt ordinaire.

Trois détails comptent, et ils sont contre-intuitifs.

D'abord, l'étoile ne marche pas. Un bloc qui vise tous les robots d'un coup n'exprime aucune préférence sur l'entraînement. Le texte du groupe de travail l'interdit explicitement : l'étoile ne doit pas être interprétée comme couvrant ce jeton. Beaucoup de sites croient donc être protégés alors qu'ils ne disent rien.

Ensuite, le silence n'est ni un oui ni un non. Si le jeton est absent, aucune préférence n'est exprimée. Chaque fournisseur applique alors son comportement par défaut. Chez Microsoft, ce défaut est d'autoriser.

Enfin, le signal ne crée aucune nouvelle grammaire. Les robots qui ne le connaissent pas l'ignorent simplement, comme ils ignorent le nom d'un robot inconnu. Rien ne casse.

Ce que le signal ne fait pas

Il ne bloque pas la visite. Le texte précise que ce jeton n'est pas une consigne de parcours. Un fournisseur peut en tenir compte pour décider de visiter ou non, mais rien ne l'y oblige. Si vous voulez empêcher la visite, il faut les règles classiques, par nom de robot.

Il ne revient pas sur le passé. Une préférence s'applique au contenu tel qu'il a été récupéré, avec le fichier en vigueur à ce moment-là. Ce qui est déjà entré dans un corpus d'entraînement n'en sort pas parce que vous publiez une ligne aujourd'hui.

Il ne vaut pas contrat. Le texte est un brouillon individuel, non endossé par l'IETF, et il expire le 3 mai 2027. Il prévoit d'ailleurs que des accords privés puissent primer sur la préférence publique. Un fournisseur qui ne participe pas peut l'ignorer sans enfreindre quoi que ce soit.

Il ne concerne pas les réponses générées. C'est la distinction la plus utile, et la plus mal comprise. Microsoft la traite séparément : l'entraînement d'un côté, ce qu'il appelle le grounding de l'autre, c'est-à-dire l'usage de vos pages pour documenter une réponse au moment où elle est écrite. Google va dans le même sens : un site qui autorise explicitement Google-Extended reste éligible aux réponses de Gemini. Microsoft ajoute même un réglage page par page, qui permet d'ouvrir un catalogue et de fermer des fiches techniques.

Pourquoi les fournisseurs acceptent un cadre commun

Trois raisons apparaissent dans les annonces.

La première est la charge de travail. OpenAI écrit que les éditeurs devaient jusqu'ici identifier chaque robot et tenir une règle par fournisseur. Un signal partagé réduit ce travail.

La deuxième est réglementaire. Google rattache explicitement sa décision au code de bonnes pratiques européen sur les modèles d'IA à usage général, qui reconnaît le fichier robots.txt comme moyen d'expression des préférences. Le cadre existe, les fournisseurs s'y alignent.

La troisième est le coût technique. Le signal réutilise un standard que tous les robots implémentent déjà. L'effort est modeste pour un fournisseur, visible pour un éditeur.

Les calendriers, eux, ne sont pas synchronisés. OpenAI vise une mise en œuvre « dans les prochains mois ». Google annonce 2027. Microsoft rend ses préférences effectives au fil de ses visites à partir du 1er février 2027. Ceux qui utilisent encore les anciennes balises NoArchive et NoCache ont jusqu'au 1er mars 2027 pour basculer.

Ce qu'il faut faire cette semaine

Vérifiez ce que votre site dit aujourd'hui. Ouvrez votre-site.com/robots.txt dans un navigateur. Le fichier est public. Cherchez le jeton. S'il est absent, votre site n'exprime aucune préférence, même s'il contient un bloc qui interdit tout à l'étoile.

Ne supprimez pas les règles existantes. OpenAI et Google précisent que les contrôles par fournisseur continuent de s'appliquer. Le signal partagé s'ajoute, il ne remplace pas. Tant que les calendriers ne sont pas tous tenus, les anciennes lignes restent la seule protection effective.

Tranchez par type de page, pas par principe. Refuser l'entraînement, c'est accepter que votre expertise pèse moins dans les prochains modèles. Autoriser la citation, c'est garder une chance d'apparaître dans une réponse, avec un lien. Chez Microsoft, les deux réglages sont séparés. Chez Google, ils passent par le même interrupteur, Google-Extended.

Si vous dépendez de Google pour vos réponses générées, gardez une autorisation explicite. Google précise qu'un site qui autorise nommément Google-Extended reste éligible aux réponses de Gemini. Un refus global, sans cette exception, peut donc vous retirer des citations.

Mettez-le aussi dans vos contrats. Le fichier exprime une préférence. Un contrat exprime une obligation. Pour un partenaire qui compte, la clause utile est celle qui interdit l'usage des contenus, pas la ligne dans le fichier.

Revérifiez après chaque mise à jour du site. Un changement de thème, un module d'optimisation ou une migration peut écraser le fichier sans prévenir. La vérification prend dix secondes.

Ce qu'il faut retenir

• Depuis le 30 octobre 2026, OpenAI, Google et Microsoft s'engagent à lire un signal commun, placé dans un fichier public du site, qui permet de refuser l'entraînement des modèles en une seule déclaration.
• Ce signal ne bloque rien : c'est une préférence lue par les fournisseurs participants, pas un verrou technique. Les règles par fournisseur restent nécessaires.
• Un bloc qui interdit tout à tous les robots n'exprime aucun refus d'entraînement : l'étiquette prévue doit être écrite telle quelle, sinon votre site ne dit rien.
• Refuser l'entraînement n'empêche pas vos pages d'être citées dans les réponses générées, à condition de traiter séparément l'autorisation de citation, chez Microsoft comme chez Google.
• Le texte reste un brouillon, pas encore un standard : les calendriers s'échelonnent jusqu'en 2027, à vérifier chez chaque fournisseur avant de compter dessus.
• Une préférence publiée ne retire pas les contenus déjà collectés. Pour un partenaire important, la protection utile reste contractuelle.