robots.txt et IA : cadre juridique européen et opt-out TDM

Pourquoi robots.txt et la gestion des crawlers IA ont désormais une portée juridique

Longtemps, robots.txt n'a été qu'un outil purement technique pour piloter les crawlers. Avec l'essor des données d'entraînement pour l'IA, c'est devenu une question juridique. Le 10 décembre 2025, dans l'affaire Kneschke contre LAION, le tribunal régional supérieur (OLG) de Hambourg a jugé qu'une réservation en matière de fouille de textes et de données (opt-out TDM) n'est valable que si elle est exprimée sous une forme lisible par machine. Dans le cas d'espèce, des mentions en langage naturel dans des conditions d'utilisation ou des avertissements ne suffisaient pas. C'est la première décision d'une juridiction supérieure allemande sur les exceptions au droit d'auteur appliquées à l'entraînement de l'IA. Elle n'est pas définitive. L'OLG a admis le pourvoi en révision, et la Cour fédérale de justice (I ZR 281/25) l'a examiné en audience le 3 septembre 2026 ; elle entend rendre sa décision le 17 décembre 2026 (état : octobre 2026). Lors de l'audience, la première chambre civile a laissé entrevoir un besoin de clarification au regard du droit européen ; il est possible qu'elle saisisse la Cour de justice de l'Union européenne de questions sur la fouille de textes et de données.

Pour les sites B2B en Allemagne et en Autriche, cela déplace les priorités. Si tu veux éviter que tes contenus finissent sans autorisation dans des données d'entraînement d'IA, tu devrais exprimer cette réservation techniquement, sous une forme lisible par machine. Depuis l'arrêt de l'OLG de Hambourg, une phrase en langage naturel dans les mentions légales n'offre aucune garantie en Allemagne, et en Autriche elle reste pour le moins incertaine. Dans le même temps, l'appétit des crawlers IA pour les données augmente de façon mesurable : selon Cloudflare, en moyenne annuelle 2025, environ 4,2 % de toutes les requêtes HTML provenaient de bots IA, tandis que Googlebot représentait à lui seul 4,5 % (international). robots.txt ne relève donc plus uniquement du crawl budget : il touche désormais à l'application du droit et à la souveraineté des données.

Une précision sur les données : les principales affirmations juridiques de cet article portent sur le droit de l'UE et sa transposition en Allemagne et en Autriche, et sont signalées comme telles. Les statistiques sur les crawlers et leur adoption proviennent pour la plupart d'enquêtes internationales (Cloudflare, HTTP Archive, Pew) et servent de point de comparaison.

La base juridique : l'art. 4 de la directive DSM et sa transposition en Autriche et en Allemagne

La base juridique de l'opt-out TDM est l'article 4 de la directive européenne sur le droit d'auteur dans le marché unique numérique (directive DSM, 2019/790). Elle autorise en principe la fouille de textes et de données, y compris à des fins commerciales, et donc aussi la collecte de contenus web pour l'entraînement de l'IA. Le point décisif est l'art. 4, paragraphe 3 : les titulaires de droits peuvent interdire cette utilisation en se réservant leurs droits expressément et de manière appropriée, notamment par des procédés lisibles par machine pour les contenus mis à la disposition du public en ligne. Dans le texte de l'article, la lisibilité par machine n'est qu'un exemple. Le considérant 18 est plus strict, du moins dans sa version anglaise : pour les contenus en ligne, une réservation ne devrait être considérée comme appropriée que si elle est exprimée par des procédés lisibles par machine. Il y inclut expressément les métadonnées et les conditions générales d'un site web ou d'un service. Dans la version allemande, ce « seulement » fait défaut. Savoir si une réservation en langage naturel dans des conditions générales compte comme lisible par machine, voilà le cœur de tout le débat.

La transposition en droit national a eu lieu, mais pas dans des termes identiques. En Allemagne, le § 44b UrhG régit la fouille de textes et de données. Son alinéa 3 transforme l'exemple de la directive en condition de validité : une réservation d'usage portant sur des œuvres accessibles en ligne n'est valable que si elle est exprimée sous une forme lisible par machine. En Autriche, c'est le § 42h de la loi sur le droit d'auteur (UrhG). Selon son alinéa 6, l'exception ne s'applique pas lorsque la reproduction est expressément interdite et que cette interdiction est signalée de manière appropriée par une réservation d'usage, par exemple par des procédés lisibles par machine pour les œuvres mises à la disposition du public sur Internet. L'Autriche reprend ainsi la formulation de la directive. Reste à savoir si une mention en langage naturel dans des conditions générales y suffit comme réservation appropriée. Il en découle la logique suivante :

• Règle de base : Le TDM commercial est autorisé. Sans réservation valable, les fournisseurs d'IA peuvent utiliser les contenus accessibles au public pour l'entraînement.
• Opt-out plutôt qu'opt-in : La protection ne s'applique pas automatiquement. Les titulaires de droits doivent s'y opposer activement.
• Forme en ligne : En Allemagne, la réservation n'est valable pour les contenus en ligne que si elle est lisible par machine. En Autriche, la loi cite les procédés lisibles par machine comme exemple de réservation appropriée.

Pour les entreprises autrichiennes, cela signifie concrètement que la protection prévue au § 42h UrhG ne naît pas d'elle-même. Elle doit être déclarée activement, idéalement de façon qu'une machine puisse la lire et l'interpréter. C'est la forme que la loi mentionne expressément, et elle satisfait aussi au critère allemand, plus strict.

Le droit suisse ne prévoit pas cette règle. La Suisse n'est pas membre de l'UE, et la directive DSM n'y est pas applicable. D'après le rapport du groupe suisse de l'AIPPI sur le droit d'auteur et l'IA, la loi suisse sur le droit d'auteur ne contient aucune exception créée spécifiquement pour l'entraînement de modèles d'IA. La fouille de textes et de données à des fins de recherche relève de l'art. 24d LDA, sans possibilité de réservation d'usage. Un opt-out sur le modèle de l'art. 4, paragraphe 3, de la directive DSM n'existe pas en droit suisse.

Une réservation lisible par machine n'est pas pour autant sans intérêt pour les sites suisses. Selon le considérant 106 du règlement sur l'IA, les fournisseurs qui mettent sur le marché de l'UE un modèle d'IA à usage général doivent respecter les réservations prévues à l'art. 4, paragraphe 3, de la directive DSM, quel que soit le pays dans lequel l'entraînement a lieu. Une telle réservation peut donc aussi produire des effets pour les contenus de sites suisses.

Que signifie « lisible par machine » ? Méthodes courantes et leurs limites

La notion de lisibilité par machine n'est pas définie de manière exhaustive dans la loi. En pratique, plusieurs procédés sont répandus, mais tous n'expriment pas une réservation de droits d'auteur. robots.txt et TDMRep peuvent être combinés pour étayer l'effet juridique.

• robots.txt : Ce fichier placé à la racine du site définit, par des directives User-Agent, quels crawlers peuvent consulter quels chemins. C'est le mécanisme le plus connu et le plus répandu, et la plupart des fournisseurs d'IA l'acceptent comme signal d'opt-out.
• Balises meta HTML et directives robots : Des balises comme noindex, nosnippet ou max-snippet pilotent l'indexation et les extraits. Selon Google, elles limitent ce que la recherche, y compris ses fonctions d'IA, affiche d'une page. Elles ne constituent pas une réservation TDM explicite, et elles coûtent de la visibilité : noindex retire complètement la page de la recherche Google.
• En-têtes HTTP : L'en-tête X-Robots-Tag permet de définir les mêmes directives côté serveur, y compris pour des ressources non HTML comme les PDF ou les images. La même limite s'applique.
• TDM Reservation Protocol (TDMRep) : Une spécification du W3C Community Group TDM Reservation Protocol, et non un standard officiel du W3C. Elle exprime explicitement la réservation prévue à l'art. 4 de la directive DSM, par en-tête HTTP, par fichier sous /.well-known/tdmrep.json ou par balise meta HTML. TDMRep a été conçu spécifiquement pour l'exigence juridique de l'art. 4.

Il faut distinguer la finalité et la forme. robots.txt pilote techniquement le crawl. TDMRep cible spécifiquement la réservation de droits d'auteur. Si tu veux être solide sur le plan juridique, mets en place les deux, car l'OLG de Hambourg exige expressément la forme lisible par machine sans imposer de format particulier.

L'arrêt Kneschke contre LAION et ses conséquences pour l'Allemagne et l'Autriche

Le tribunal régional (Landgericht) de Hambourg a rejeté la demande le 27 septembre 2024 (310 O 227/23). En appel, l'OLG de Hambourg (numéro de rôle 5 U 104/24) a statué le 10 décembre 2025. Le photographe Robert Kneschke contestait le fait qu'une de ses images se soit retrouvée dans le jeu de données d'entraînement de l'organisation LAION. Son opt-out figurait dans les conditions d'utilisation de la plateforme d'images, donc en langage naturel.

L'OLG de Hambourg a jugé cette réservation inopérante. Motif : la mention figurant sur le site de l'agence photo n'avait pas, au moment du téléchargement, la forme lisible par machine prévue par la loi (§ 44b, al. 3, phrase 2 UrhG). L'exception du § 44b UrhG, qui transpose l'art. 4 de la directive DSM, était donc applicable en faveur de LAION. Selon Freshfields, le critère retenu était la situation au moment du téléchargement, en 2021. Le tribunal n'a donc pas tranché la question de savoir comment une telle mention devrait être appréciée avec les techniques actuelles. L'OLG a en outre fondé l'utilisation sur l'exception pour la recherche scientifique du § 60d UrhG, à laquelle aucune réservation ne peut être opposée. Cette partie vaut pour LAION, association de recherche non commerciale, mais en règle générale pas pour les fournisseurs d'IA commerciaux. Pour eux, c'est le § 44b UrhG qui compte, et donc la réservation lisible par machine. L'arrêt n'est pas définitif (voir plus haut). Selon l'analyse de Norton Rose Fulbright, plusieurs points restent ouverts, notamment la charge de la preuve et la question de savoir ce qui compte exactement comme lisible par machine.

Les conséquences pour l'Allemagne et l'Autriche sont considérables :

• En Allemagne, la lisibilité par machine est obligatoire : Si tu veux une réservation valable, tu ne peux pas te reposer sur des conditions générales ou des avertissements. L'opt-out doit être inscrit techniquement.
• En Autriche, elle est vivement recommandée : La loi cite les procédés lisibles par machine comme exemple. Reste à savoir si une mention dans des conditions générales suffit ; une réservation technique t'évite cette question.
• Première ligne directrice d'une juridiction supérieure : S'agissant de la première décision rendue en appel en Allemagne, elle a valeur de signal aussi pour l'Autriche, même si les tribunaux autrichiens ne sont formellement pas liés par elle.
• Pression sur les titulaires de droits : Si jusqu'ici ton opposition n'était formulée qu'en langage naturel, tu ne peux te fier à cette réservation ni en Allemagne ni en Autriche. Une mise à niveau technique vaut la peine dans les deux pays.

Un contre-exemple venu des États-Unis montre la différence de cadre juridique. Dans l'affaire Ziff Davis contre OpenAI, la procédure américaine a comparé robots.txt à un panneau « Défense d'entrer » dépourvu de force exécutoire propre. Contrairement à l'UE, le droit américain ne prévoit pas d'opt-out TDM au sens de l'art. 4. Les réservations lisibles par machine n'y produisent pas les mêmes effets en matière de droit d'auteur que dans l'UE.

Règlement européen sur l'IA, art. 53 : l'obligation des fournisseurs d'IA en matière de droit d'auteur

Le deuxième pilier, à côté de la directive DSM, est le règlement européen sur l'IA. Il oblige les fournisseurs de modèles d'IA à usage général (General-Purpose AI, GPAI) à respecter les réservations de droits d'auteur. Selon l'art. 53, paragraphe 1, les fournisseurs de GPAI doivent mettre en place une politique visant à se conformer au droit de l'Union en matière de droit d'auteur et, notamment, à identifier et à respecter, y compris au moyen de technologies de pointe, une réservation de droits exprimée conformément à l'art. 4, paragraphe 3, de la directive 2019/790 (UE). Le règlement sur l'IA est en vigueur depuis le 1er août 2024, et cette obligation s'applique depuis le 2 août 2025. Pour les modèles déjà sur le marché auparavant, une période transitoire court jusqu'au 2 août 2027.

Les deux textes forment ainsi un système. La directive DSM donne au titulaire de droits l'outil de la réservation lisible par machine. Le règlement sur l'IA oblige les fournisseurs d'IA à identifier activement ces réservations et à les respecter. En pratique, la formule « au moyen de technologies de pointe » signifie que les fournisseurs doivent interpréter précisément les signaux lisibles par machine qu'un exploitant de site met en place : robots.txt, TDMRep et standards comparables.

S'y ajoute le code de bonnes pratiques facultatif pour les GPAI (Code of Practice), publié le 10 juillet 2025. Ses signataires s'engagent, dans le chapitre sur le droit d'auteur (mesure 1.3), à utiliser des crawlers qui lisent et respectent robots.txt selon le standard RFC 9309 (Robots Exclusion Protocol). Pour les exploitants de sites, c'est le pont décisif : une entrée robots.txt correctement configurée est le signal lisible par machine le plus répandu pour exprimer une réservation. Les fournisseurs de GPAI doivent identifier et respecter ces réservations en vertu de l'art. 53 du règlement sur l'IA, et les signataires du code se sont en outre engagés sur robots.txt.

Configurer robots.txt pour les crawlers IA : guide pratique

Un pilotage efficace commence par la connaissance des user-agents pertinents. Chaque grand fournisseur d'IA exploite ses propres crawlers, souvent avec des bots distincts pour l'entraînement et pour les consultations en temps réel. Les opt-out se répandent : selon le Web Almanac 2024, les fichiers robots.txt sur desktop mentionnaient GPTBot dans 2,9 % des cas, CCBot dans 2,7 %, Google-Extended dans 2,5 % et Anthropic-ai dans 2,1 % (international). Ces chiffres reflétaient en 2024 une pratique encore récente, qui progresse depuis.

Les principaux user-agents et leur fonction :

• GPTBot : Crawler d'OpenAI dédié à l'entraînement. Le bloquer empêche l'intégration dans les futures données d'entraînement.
• ChatGPT-User : Consulte des pages lorsqu'un utilisateur de ChatGPT le déclenche. Selon OpenAI, les règles robots.txt peuvent ne pas s'appliquer dans ce cas. La présence des contenus dans la recherche ChatGPT est pilotée par OAI-SearchBot.
• ClaudeBot : Crawler d'entraînement d'Anthropic. Anthropic-ai est un ancien identifiant qui lui est associé.
• Google-Extended : Ce n'est pas un crawler à part entière, mais un token robots.txt. Il détermine si Google utilise les contenus pour l'entraînement des modèles Gemini et pour le grounding dans Gemini Apps et Vertex AI.
• CCBot : Crawler de Common Crawl, dont les jeux de données ouverts servent de source d'entraînement à de nombreux modèles d'IA.
• PerplexityBot : Crawler de Perplexity pour son index de recherche IA.

Voici à quoi ressemble une stratégie de blocage typique pour les crawlers d'entraînement :

```
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /
```

Dans la pratique, le tableau est nuancé. Selon Cloudflare, en 2025, la plupart des directives Disallow complètes visaient des crawlers IA comme GPTBot, ClaudeBot et CCBot, tandis que Googlebot et Bingbot n'étaient le plus souvent bloqués que partiellement (international). Les exploitants bloquent donc de façon ciblée les bots purement dédiés à l'entraînement IA, mais laissent passer les crawlers de recherche classiques pour ne pas perdre leur visibilité organique.

Les limites de robots.txt : respect volontaire et crawlers furtifs

robots.txt a une faiblesse fondamentale : son respect est volontaire. Le fichier est une demande, pas un verrou technique. Les fournisseurs sérieux s'y conforment. Dans l'UE, les fournisseurs de GPAI doivent identifier et respecter les réservations de droits en vertu du règlement sur l'IA ; les signataires du code de bonnes pratiques se sont en outre engagés à respecter robots.txt. Mais techniquement, le fichier peut être ignoré.

Le cas Perplexity l'a clairement montré. Le 4 août 2025, Cloudflare a documenté que Perplexity utilisait des crawlers furtifs non déclarés, qui recouraient à un navigateur générique imitant Google Chrome sous macOS lorsque le crawler déclaré était bloqué, et qui ignoraient robots.txt ou, parfois, ne le consultaient même pas (international). Ces bots utilisaient des adresses IP situées hors de la plage officielle et passaient d'un ASN à l'autre pour contourner les blocages. Cloudflare a alors retiré à Perplexity son statut de Verified Bot et bloqué les crawlers furtifs à l'aide de ses propres heuristiques.

Il en découle des limites claires :

• Aucune application technique : robots.txt n'empêche pas l'accès, il exprime seulement un souhait.
• Bots non déclarés : Les crawlers qui se font passer pour un navigateur ordinaire ne peuvent pas être arrêtés de manière fiable par une règle User-Agent.
• Rotation d'IP et d'ASN : Un crawler qui accède au site depuis des plages d'adresses changeantes contourne les blocages d'IP simples.

Pour l'appréciation juridique, la réservation reste néanmoins importante. Même si un crawler l'ignore techniquement, l'opt-out lisible par machine atteste que le titulaire de droits s'y est opposé. C'est la condition pour pouvoir invoquer l'art. 4, paragraphe 3, de la directive DSM.

Standards complémentaires : ai.txt, llms.txt et Really Simple Licensing

Plusieurs standards complémentaires sont apparus à côté de robots.txt. Ils poursuivent des objectifs différents, du simple blocage à l'octroi de licences.

• ai.txt : Un fichier distinct censé exprimer spécifiquement la réservation TDM prévue à l'art. 4. Il ajoute à robots.txt une dimension explicitement liée au droit d'auteur.
• llms.txt : Fonctionne plutôt comme un sitemap pour les systèmes d'IA. Il doit rendre les contenus repérables de manière structurée pour un usage par l'IA : ce n'est donc pas un standard de blocage, mais un standard de découverte. Son adoption reste faible et n'en est qu'à ses débuts.
• Really Simple Licensing (RSL) : Sans doute le nouveau standard le plus important. RSL 1.0 a été publié le 10 décembre 2025 comme spécification officielle. Selon l'annonce, RSL 1.0 définit les catégories d'usage supplémentaires ai-all, ai-input et ai-index pour donner aux éditeurs un contrôle plus fin, et inclut une nouvelle option de paiement appelée contribution, qui permet d'obliger les systèmes d'IA à verser des contributions monétaires ou en nature (international). Parmi ses soutiens figurent Yahoo, Ziff Davis et O'Reilly Media.

La différence conceptuelle décisive se situe entre bloquer et concéder des licences. robots.txt et ai.txt se contentent de dire oui ou non au crawl. RSL va plus loin : il permet de mettre des contenus à disposition moyennant des conditions ou une rémunération. On obtient ainsi une voie médiane entre blocage total et accès gratuit, qui peut intéresser les fournisseurs de contenus commerciaux en B2B.

Le conflit d'objectifs : opt-out de l'entraînement IA contre visibilité GEO

Une question stratégique centrale est souvent mal comprise. Bloquer les crawlers d'entraînement et être trouvable dans les réponses de l'IA sont deux choses différentes. Si tu bloques GPTBot ou Google-Extended, tu empêches l'intégration de tes contenus dans les données d'entraînement. Cela ne détermine pas forcément s'ils apparaissent dans les résultats de recherche IA ou dans les aperçus.

Google-Extended l'illustre bien. Il s'agit d'un token robots.txt permettant de refuser l'entraînement IA de Gemini et de Vertex AI, qui n'a toutefois aucun effet sur l'inclusion dans la recherche Google et n'est pas un signal de classement (international). Selon Google, ce token pilote en outre le grounding dans Gemini Apps et dans Grounding with Google Search sur Vertex AI, c'est-à-dire le fait que des contenus de l'index de recherche alimentent ou non la réponse du modèle lors d'une requête. Si tu bloques Google-Extended, tu restes visible dans la recherche classique et dans les AI Overviews. Gemini n'utilise alors tes contenus ni pour l'entraînement ni comme base de ses réponses.

La visibilité dans les réponses de l'IA est en même temps le facteur économiquement déterminant, car les aperçus IA captent des clics. Selon une analyse internationale de Pew, les utilisateurs ont cliqué sur un résultat classique dans 8 % des cas lors d'une recherche avec aperçu IA, contre 15 % sans aperçu IA, et seulement 1 % a cliqué sur un lien à l'intérieur de l'aperçu IA (international, États-Unis, mars 2025). Le taux de clic est donc presque divisé par deux. Dans ce contexte, il peut être judicieux pour un acteur B2B d'être cité dans les réponses de l'IA pour rester visible, tout en protégeant ses propres contenus contre un entraînement incontrôlé. C'est précisément cette séparation que permettent des directives distinctes pour les crawlers d'entraînement et les crawlers de recherche.

Application technique au-delà de robots.txt

Comme robots.txt n'est qu'une demande, une stratégie sérieuse a besoin d'un second niveau : l'application côté serveur. C'est là qu'interviennent l'edge, le CDN et le bot management.

• Blocage par WAF et en edge : Un Web Application Firewall ou une règle edge peut bloquer des requêtes selon le user-agent, la plage d'IP ou le schéma de comportement, avant qu'elles n'atteignent le serveur d'origine. Cela fonctionne aussi contre les crawlers qui ignorent robots.txt.
• Bot management : La détection comportementale identifie les accès automatisés à partir de signaux comme la fréquence des requêtes ou l'absence de caractéristiques propres aux navigateurs, et pas uniquement à partir du user-agent déclaré.
• Contrôles des crawlers IA de Cloudflare : Cloudflare propose des interrupteurs dédiés pour bloquer de manière centralisée les crawlers IA connus, et a réagi dans le cas Perplexity avec ses propres heuristiques contre le crawl furtif.
• Approches pay-per-crawl : Des modèles plus récents permettent de n'accorder l'accès aux crawlers IA que contre paiement. Cela associe le blocage technique à une logique de licence, à la manière de RSL.

Ce niveau est le seul à avoir un véritable effet technique. Il ne remplace pas la réservation juridique, il la complète. Seule la combinaison d'un opt-out documenté et d'un blocage effectif couvre à la fois le volet juridique et le volet pratique.

Erreurs fréquentes dans la gestion des crawlers IA

• Opt-out uniquement dans les conditions générales : L'erreur la plus fréquente et, au vu de l'arrêt de l'OLG de Hambourg, la plus grave. En Allemagne, cet arrêt ne permet plus de se fier à une mention en langage naturel ; en Autriche, elle reste pour le moins incertaine.
• Prendre robots.txt pour un verrou : Le fichier n'empêche aucun accès. Croire que la protection est ainsi garantie techniquement est une erreur.
• Confondre entraînement et recherche : Bloquer indistinctement tous les bots IA, c'est risquer de perdre de la visibilité GEO sans le vouloir. Les crawlers d'entraînement et de recherche ont besoin de règles distinctes.
• Listes de user-agents obsolètes : Les fournisseurs d'IA lancent de nouveaux crawlers et modifient leurs identifiants. Un robots.txt rédigé une fois pour toutes devient vite obsolète.
• Aucun filet de sécurité côté serveur : Se reposer uniquement sur robots.txt laisse passer sans obstacle les crawlers furtifs et les bots non déclarés.
• Documentation absente : Sans preuve de la date à laquelle chaque réservation a été mise en place, il est difficile, en cas de litige, de démontrer qu'une opposition active a été exprimée.

Indicateurs et mesure : rendre visibles les accès des crawlers

La gestion des crawlers IA se mesure, même s'il n'existe pas d'indicateur de réussite unique. Indicateurs et points de contrôle utiles :

• Part des bots IA dans le trafic : Analyse les logs de ton serveur ou de ton CDN par user-agent IA. La moyenne d'environ 4,2 % des requêtes HTML en 2025 mesurée par Cloudflare sert de point de comparaison.
• Efficacité du blocage : Vérifie que les crawlers bloqués n'effectuent plus aucune requête réussie. Des accès persistants malgré un Disallow indiquent des bots non conformes ou furtifs.
• Détection d'anomalies : Surveille les schémas atypiques, comme des user-agents de navigateur au comportement typique d'un serveur ou des accès depuis des ASN tournants.
• Exhaustivité de la réservation : Contrôle régulièrement que robots.txt, le signal TDMRep et, le cas échéant, RSL sont cohérents et à jour.
• Visibilité GEO : Observe si et comment tes contenus sont cités dans les réponses de l'IA et dans les AI Overviews, afin de piloter le conflit d'objectifs entre protection et découvrabilité.

Pour commencer, il suffit d'analyser tes propres logs en les croisant avec les rapports sur les bots de ton CDN. L'essentiel est de répéter l'exercice régulièrement, car le paysage des crawlers comme les exigences juridiques évoluent vite.

Recommandations et pour aller plus loin

Pour les sites B2B, en particulier sur des architectures Next.js et edge, une stratégie à plusieurs niveaux est recommandée. Elle couvre à la fois le volet juridique et le volet technique.

• Réservation lisible par machine : Exprime une réservation TDM au sens de l'art. 4, paragraphe 3, de la directive DSM sous une forme lisible par machine. Un robots.txt avec des directives Disallow ciblées pour les crawlers d'entraînement constitue la base, complétée par un signal TDMRep via en-tête HTTP ou balisage.
• Logique de crawlers distincte : Sépare les bots d'entraînement comme GPTBot, ClaudeBot, CCBot et Google-Extended des crawlers de recherche comme OAI-SearchBot et PerplexityBot, pour que la protection contre l'entraînement ne nuise pas à ta visibilité GEO.
• Blocage côté serveur : Complète la réservation par une application effective via un WAF, l'edge ou le bot management de ton CDN, afin d'intercepter les crawlers furtifs et les bots non déclarés.
• Documentation : Consigne la date à laquelle chaque réservation a été mise en place. En cas de litige, l'opt-out documenté et lisible par machine est la base pour invoquer l'art. 4.

Le cadre juridique est encore récent et évolue. L'OLG de Hambourg a posé une première ligne, sur laquelle vont désormais se prononcer la Cour fédérale de justice et peut-être la Cour de justice de l'Union européenne. Le règlement sur l'IA rend les obligations des fournisseurs contraignantes depuis août 2025, et à partir d'août 2027 pour les modèles plus anciens. De nouveaux standards comme RSL apparaissent rapidement. Si tu agis dès aujourd'hui, mets en œuvre la stratégie à plusieurs niveaux et suis l'évolution. Parmi les sujets connexes figurent le crawl budget et la gouvernance multi-bots pour les crawlers IA, les données structurées comme couche de compréhension pour l'IA, le traitement des données conforme au RGPD, ainsi que le GEO et la visibilité dans les réponses de l'IA.