Robots.txt et IA : comment décider ce que votre site autorise

Le 30 octobre 2026, Google Search Central a annoncé son intention de prendre en charge, avec d'autres fournisseurs, un signal partagé de préférence d'entraînement dans robots.txt. L'objectif est de permettre à un site d'exprimer une préférence commune plutôt que de répéter une règle pour chaque opérateur. La prise en charge est annoncée pour 2027 : ce n'est donc pas encore une consigne universellement reconnue.

Ce qui change avec le signal proposé

robots.txt est un fichier placé à la racine d'un site. Il indique aux robots qui les consultent quelles adresses ils peuvent explorer. Le protocole repose notamment sur des groupes User-agent, des règles Allow et Disallow, ainsi que sur la priorité de la règle la plus précise. Il ne constitue pas un dispositif d'authentification : un opérateur qui ne respecte pas les règles peut toujours envoyer des requêtes.

La proposition portée dans un Internet-Draft de l'IETF consiste à utiliser un jeton de politique dans la ligne User-agent, puis à appliquer les règles de chemin déjà prévues par robots.txt. Elle n'ajoute pas une nouvelle directive au fichier. Le document est un brouillon de travail, sans statut de norme, et peut encore évoluer.

Dans son annonce, Google indique qu'un site pourrait exprimer une préférence large à l'aide de ce signal partagé. Google prévoit de l'interpréter, en l'absence d'une règle explicite pour Google-Extended, comme une interdiction de ce robot dédié à certains usages d'IA. Les contrôles propres à chaque entreprise resteraient disponibles en parallèle. Cette nuance est importante : le signal commun ne remplacerait pas automatiquement toutes les règles particulières.

Ne pas confondre recherche, réponse et entraînement

Le même contenu peut être rencontré par plusieurs types de services, qui n'ont pas le même objectif. Un robot peut explorer une page pour alimenter un index de recherche. Un autre peut récupérer son contenu pour fournir une réponse avec une citation. Un troisième peut utiliser des données dans la préparation ou l'entraînement d'un modèle. Une règle destinée à l'un de ces usages ne produit pas nécessairement le même effet sur les autres.

Cette distinction évite deux erreurs fréquentes. La première consiste à bloquer indistinctement tous les robots et à dégrader la visibilité du site, alors que l'organisation voulait seulement encadrer l'entraînement. La seconde consiste à croire qu'autoriser un robot de recherche revient à autoriser toutes les réutilisations du contenu. Les règles doivent être définies à partir de la finalité recherchée, pas du seul mot « IA ».

Les indications publiées par Google montrent également qu'une autorisation de Google-Extended peut avoir une conséquence sur l'utilisation des pages dans certaines expériences de réponse de Gemini. Là encore, il faut séparer ce qui est documenté aujourd'hui de ce que le futur signal partagé permettra après son déploiement et son adoption par plusieurs fournisseurs.

Pourquoi le sujet concerne aussi une PME

Une organisation n'a pas besoin de produire un modèle d'IA pour être concernée. Son site contient peut-être des fiches produits, des dossiers techniques, des articles, des photographies, des conditions commerciales ou des documents rédigés avec l'aide de partenaires. Chaque élément a une valeur différente et peut être soumis à des obligations contractuelles, au droit d'auteur ou à des engagements de confidentialité.

Le choix peut également dépendre de la stratégie de visibilité. Une entreprise peut vouloir que ses pages soient trouvées et citées par des assistants, tout en refusant qu'elles servent à l'entraînement. Une autre peut privilégier la maîtrise de la réutilisation de ses dossiers, sans renoncer à la présence dans les moteurs. Il n'existe pas de réglage raisonnable sans décision explicite sur le but poursuivi.

Le premier travail n'est donc pas de copier une ligne dans le fichier. Il consiste à recenser les contenus concernés et les acteurs qui les exploitent. Le marketing, la communication, la direction juridique, l'informatique et le prestataire qui maintient le site peuvent chacun détenir une partie de la réponse.

Une méthode de décision en cinq étapes

1. Classer les contenus

Commencez par distinguer les pages publiques de présentation, les ressources éditoriales, les catalogues, les documents téléchargeables et les espaces nécessitant une connexion. Notez les contenus dont vous détenez les droits et ceux qui comportent des contributions de tiers. Cette cartographie évite d'appliquer la même politique à des contenus qui n'ont ni la même valeur ni les mêmes contraintes.

2. Définir les finalités acceptées

Pour chaque famille de contenu, écrivez séparément votre position sur l'exploration par les moteurs, l'affichage dans une réponse, l'utilisation comme source et l'entraînement. Si une décision est temporaire, indiquez sa date de révision. Une politique claire peut être plus utile qu'un blocage général impossible à expliquer aux équipes.

3. Vérifier les contrôles disponibles aujourd'hui

Le fichier robots.txt est un point de départ, pas l'unique moyen de protection. Les accès authentifiés, les droits sur les fichiers, les balises et en-têtes de contrôle de l'indexation, ainsi que les clauses contractuelles ont chacun leur rôle. Ils ne répondent pas à la même question. Un document public ne devient pas confidentiel parce qu'il est exclu d'un moteur ; inversement, une zone privée ne devrait pas dépendre seulement d'une consigne destinée aux robots.

Pour les règles propres à Google, l'organisation doit aussi regarder la documentation de Google-Extended. Pour les autres fournisseurs, elle doit vérifier leurs noms de robots, leurs engagements et leur capacité réelle à appliquer une préférence. Ne déduisez pas leur comportement d'une annonce concernant un autre acteur.

4. Préparer le changement sans l'activer trop tôt

Le signal partagé annoncé par Google est en préparation et son Internet-Draft n'est pas une norme finalisée. Il serait imprudent de le présenter comme une règle déjà comprise par tous les robots. Vous pouvez toutefois préparer un inventaire, une politique interne et un processus de validation. Le moment venu, le prestataire saura quelle décision traduire dans robots.txt et comment la tester.

5. Contrôler et documenter

Conservez la version active du fichier, la date de modification, la personne qui a validé la politique et les raisons du choix. Vérifiez après chaque mise en ligne la réponse de /robots.txt, les journaux du serveur et les principaux parcours de recherche. Un contrôle régulier permet de repérer une migration de site, un changement de domaine ou une nouvelle règle qui contredit la décision initiale.

Les limites à intégrer dans la décision

Un signal dans robots.txt exprime une préférence à l'intention des opérateurs qui choisissent de la respecter. Il ne retire pas une copie déjà publiée, ne contrôle pas les captures réalisées avant la règle et ne remplace pas les mesures de sécurité. Il faut également anticiper les effets d'une règle trop large : une page importante peut cesser d'être explorée, une réponse peut perdre une source utile ou une équipe peut ne plus savoir pourquoi la visibilité a changé.

La proposition elle-même va évoluer. L'IETF précise qu'un Internet-Draft est un document de travail susceptible d'être remplacé et qu'il n'a pas de valeur normative. Google parle de son côté d'une prise en charge visée en 2027, avec d'autres fournisseurs, et annonce que des mises à jour suivront. La bonne décision, aujourd'hui, est de distinguer une préparation réversible d'une promesse de compatibilité.

Les prochaines décisions à prendre

Pour avancer, une organisation peut réunir les responsables du site et répondre à quatre questions : quels contenus voulons-nous rendre trouvables, lesquels voulons-nous voir cités, quelles réutilisations refusons-nous, et qui révisera cette politique ? Les réponses doivent être conservées avec la liste des domaines, sous-domaines et prestataires concernés.

Ensuite, faites relire le fichier actuel par la personne qui maîtrise le référencement et par celle qui administre l'hébergement. Vérifiez que le site ne mélange pas plusieurs fichiers ou plusieurs environnements. Enfin, surveillez la documentation des fournisseurs et les travaux de standardisation avant d'adopter un signal encore en préparation.

Le sujet n'est pas de choisir entre « tout autoriser » et « tout bloquer ». Il s'agit de rendre un choix compréhensible, proportionné et révisable. C'est cette méthode qui permettra d'utiliser les contrôles disponibles aujourd'hui, puis d'évaluer sereinement le signal partagé lorsqu'il sera effectivement pris en charge.