# Robots d'IA sur IIS - robots.txt, URL Rewrite, Request Filtering et restrictions IP

> Sur IIS, publier robots.txt, refuser les robots d'entraînement avec une règle URL Rewrite dans web.config et voir les limites des filtres et restrictions IP.

Source : https://iabig.com/fr/plateformes/robots-ia-iis/ — Guides CC BY 4.0, extraits de code MIT

Sur un serveur Windows avec IIS, les robots d'IA se gèrent avec des outils qui n'ont pas été conçus pour eux : un fichier robots.txt statique, le module URL Rewrite, le filtrage des requêtes (Request Filtering) et les restrictions par adresse IP. Chacun a ses forces et ses angles morts, et le choix du mauvais outil peut bloquer robots.txt lui-même ou ralentir tout le site. Ce guide propose une configuration qui refuse l'entraînement tout en laissant passer les robots de recherche de ChatGPT, Claude et Perplexity, explique ce que chaque module sait faire d'après la documentation de Microsoft, et dit clairement ce qu'IIS ne sait pas faire seul. Nous n'avons pas pu exécuter ces configurations sur un serveur IIS : elles suivent la documentation officielle et le fichier `web.config` a été contrôlé comme XML valide, mais testez-les d'abord sur un site de préproduction.

## Publier robots.txt

Déposez `robots.txt` dans le dossier physique du site (souvent sous `C:\inetpub\wwwroot` pour le site par défaut). IIS le sert comme n'importe quel fichier statique. Vérifiez qu'il répond en 200, en texte brut, et qu'aucune règle ne le bloque : un robot qui ne peut pas lire le fichier ne peut pas y découvrir votre refus, et la RFC 9309 assimile une erreur 5xx sur ce fichier à une interdiction totale.

C'est robots.txt qui porte votre politique auprès des robots qui la respectent, ce que déclarent OpenAI, Anthropic et Perplexity pour leurs robots d'exploration. C'est aussi le seul moyen de refuser l'entraînement à Google (`Google-Extended`) et à Apple (`Applebot-Extended`), jetons qui ne correspondent à aucun robot distinct. Les règles serveur qui suivent ne servent qu'en complément, contre les robots qui ignorent le fichier.

## Refuser par User-Agent avec URL Rewrite

Le module URL Rewrite ne fait pas partie de l'installation par défaut d'IIS : il s'installe séparément depuis le site iis.net. Ses règles « distribuées » se placent dans `web.config`, sous `system.webServer/rewrite/rules`, et sont évaluées dans l'ordre. Une condition peut lire n'importe quel en-tête de la requête sous la forme `{HTTP_NOM_DE_L_EN_TETE}`, donc `{HTTP_USER_AGENT}` pour le User-Agent.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- web.config à la racine du site - nécessite le module URL Rewrite -->
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <!-- Refus des robots d'entraînement (liste à adapter) -->
        <rule name="Refus robots entrainement IA" stopProcessing="true">
          <!-- Toutes les URL sauf robots.txt.
               Au niveau du site, le motif reçoit le chemin sans la barre initiale. -->
          <match url="^robots\.txt$" negate="true" />
          <conditions logicalGrouping="MatchAll">
            <add input="{HTTP_USER_AGENT}"
                 pattern="GPTBot|ClaudeBot|CCBot|Bytespider|meta-externalagent"
                 ignoreCase="true" />
          </conditions>
          <!-- Réponse 403 ; AbortRequest couperait la connexion sans réponse -->
          <action type="CustomResponse" statusCode="403"
                  statusReason="Forbidden"
                  statusDescription="Access denied to AI training crawlers." />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>
```

Plusieurs points de la documentation de Microsoft éclairent cette règle. Le motif de `<match>` est comparé au chemin relatif à l'emplacement du `web.config`, sans la chaîne de requête : à la racine du site, `/robots.txt` arrive sous la forme `robots.txt`, d'où l'absence de barre dans le motif. L'action `CustomResponse` répond avec le code choisi et arrête l'évaluation des règles suivantes. Si votre `web.config` contient déjà un bloc `<rewrite>`, n'en ajoutez pas un second : insérez la règle en tête de la liste existante.

Un effet de bord mérite d'être connu avant la mise en production : selon la documentation, une règle qui utilise une variable serveur absente d'une liste précise (`HTTP_USER_AGENT` n'y figure pas) rend l'ensemble des règles « non sûr » pour le cache de sortie. Le module désactive alors le cache en mode noyau pour toutes les requêtes, réécrites ou non. Sur un site très fréquenté qui s'appuie sur ce cache, mesurez l'impact.

## Request Filtering : possible, mais moins adapté

Le filtrage des requêtes, installé par défaut, sait aussi inspecter un en-tête grâce aux règles de filtrage (`filteringRules`, disponibles depuis IIS 7.5) :

```xml
<!-- Dans <system.webServer><security> du web.config -->
<requestFiltering>
  <filteringRules>
    <filteringRule name="Refus robots entrainement IA"
                   scanUrl="false" scanQueryString="false" scanAllRaw="false">
      <scanHeaders>
        <add requestHeader="User-Agent" />
      </scanHeaders>
      <!-- appliesTo vide : la règle vaut pour toutes les requêtes -->
      <denyStrings>
        <add string="GPTBot" />
        <add string="ClaudeBot" />
        <add string="CCBot" />
      </denyStrings>
    </filteringRule>
  </filteringRules>
</requestFiltering>
```

Deux limites nous font préférer URL Rewrite. Une requête bloquée reçoit une erreur 404, inscrite dans le journal avec le sous-code 404.19 (« Denied by filtering rule ») : le robot ne comprend pas qu'il est refusé. Surtout, une règle ne peut être restreinte que par extension de fichier (`appliesTo`), pas par chemin : sans précaution, elle bloque aussi `robots.txt`. La documentation ne précise pas non plus si la comparaison des chaînes tient compte de la casse ; vérifiez-le sur votre serveur avant de compter dessus.

## Restrictions par adresse IP

Le module **IP and Domain Restrictions** n'est pas installé par défaut : il s'ajoute comme service de rôle (**Web Server** > **Security** > **IP and Domain Restrictions**). Il refuse ou autorise des adresses ou des plages, exprimées avec un masque de sous-réseau et non en notation CIDR. La documentation de l'élément `<ipSecurity>` ne mentionne que l'IPv4. Microsoft configure ce module dans `applicationHost.config` : avec AppCmd, il faut ajouter `/commit:apphost`, ou passer par **IP Address and Domain Restrictions** dans le Gestionnaire IIS.

```text
:: Refuser une plage abusive (exemple : 203.0.113.0/24 = masque 255.255.255.0)
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/ipSecurity /+"[ipAddress='203.0.113.0',subnetMask='255.255.255.0',allowed='False']" /commit:apphost
```

Ce module ne sait pas combiner adresse et User-Agent. IIS ne permet donc pas, avec ses seuls modules, de reproduire la vérification décrite dans nos guides nginx et Apache, qui n'accepte un robot de recherche que s'il vient des plages publiées par son éditeur : URL Rewrite compare des expressions régulières, pas des plages CIDR. Si cette vérification vous importe, placez-la en amont, sur un CDN, un pare-feu applicatif ou un proxy inverse.

Pour limiter le débit, le même module propose depuis IIS 8.0 des restrictions dynamiques (`dynamicIpSecurity`) : refus d'une adresse au-delà d'un nombre de requêtes simultanées ou d'un nombre de requêtes sur une période. Elles s'appliquent à tous les visiteurs, robots ou non. Activez d'abord `enableLoggingOnlyMode`, qui journalise les refus sans les appliquer.

## X-Robots-Tag

```xml
<!-- Dans web.config : en-tête sur tout le dossier /documents -->
<location path="documents">
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="X-Robots-Tag" value="noindex" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</location>
```

Google documente cet en-tête ; les pages d'OpenAI, d'Anthropic et de Perplexity consultées pour ce guide ne le mentionnent pas. Pour ces robots, robots.txt reste la seule consigne documentée.

## Tester

Sous Windows PowerShell 5.1, `curl` est un alias d'`Invoke-WebRequest` : appelez explicitement `curl.exe`, fourni avec les versions récentes de Windows.

```text
:: Robot d'entraînement : 403 attendu
curl.exe -s -o NUL -w "%{http_code}\n" -A "compatible; GPTBot/1.4" https://www.example.com/
:: Le même robot sur robots.txt : 200 attendu
curl.exe -s -o NUL -w "%{http_code}\n" -A "compatible; GPTBot/1.4" https://www.example.com/robots.txt
:: Robot de recherche : 200 attendu
curl.exe -s -o NUL -w "%{http_code}\n" -A "compatible; OAI-SearchBot/1.4" https://www.example.com/
```

Ces tests sont indicatifs : curl reproduit le User-Agent, pas l'adresse du robot. Les journaux W3C se trouvent par défaut sous `%SystemDrive%\inetpub\logs\LogFiles`, dans un sous-dossier par site, et le User-Agent fait partie des champs enregistrés par défaut ; dans ces fichiers, les espaces du User-Agent apparaissent remplacés par des `+`. Pour repérer les refus :

```text
Select-String -Path "$env:SystemDrive\inetpub\logs\LogFiles\W3SVC1\*.log" -Pattern "GPTBot|ClaudeBot|CCBot" |
  Select-String -Pattern " 403 | 404 19 "
```

Pour écrire un robots.txt sans faute de jeton, vous pouvez partir du [générateur de robots.txt pour les IA](/fr/outils/generateur-robots-txt/).

## Pièges à éviter

- **Le User-Agent seul ne prouve rien.** Une règle par nom n'arrête que les robots honnêtes, que robots.txt arrêtait déjà ; un collecteur qui se présente comme un navigateur passe.
- **Un motif trop large.** `bot` refuserait Googlebot et Bingbot, et vous retirerait des moteurs de recherche.
- **Bloquer robots.txt sans le vouloir**, en particulier avec Request Filtering.
- **Bloquer les plages d'un éditeur pour refuser l'entraînement.** Anthropic indique que cette méthode n'est pas fiable, car elle empêche aussi la lecture de robots.txt.
- **Oublier le proxy.** Derrière un répartiteur de charge, IIS voit l'adresse de l'intermédiaire ; le module de restrictions IP propose un mode proxy (`enableProxyMode`) qui lit l'en-tête `x-forwarded-for`.

## Revenir en arrière

Supprimez la règle dans le `web.config` (ou dans **URL Rewrite** du Gestionnaire IIS), retirez la règle de l'onglet **Rules** de **Request Filtering**, et supprimez les entrées ajoutées dans **IP Address and Domain Restrictions**. Gardez une copie du fichier avant chaque changement : c'est le retour arrière le plus rapide.

## Sources officielles

- Microsoft, URL Rewrite Module Configuration Reference : <https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/url-rewrite-module-configuration-reference>
- Microsoft, URL Rewrite (téléchargement) : <https://www.iis.net/downloads/microsoft/url-rewrite>
- Microsoft, Request Filtering Rule (filteringRule) : <https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/filteringrules/filteringrule/>
- Microsoft, IP Security (ipSecurity) : <https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/ipsecurity/>
- Microsoft, Adding IP Security (add) : <https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/ipsecurity/add>
- Microsoft, Dynamic IP Security : <https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/dynamicipsecurity/>
- Microsoft, Custom Headers : <https://learn.microsoft.com/en-us/iis/configuration/system.webserver/httpprotocol/customheaders/>
- Microsoft, Default Log File Settings (logFile) : <https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/sitedefaults/logfile/>
- RFC 9309, Robots Exclusion Protocol : <https://www.rfc-editor.org/rfc/rfc9309>
- OpenAI, Overview of OpenAI Crawlers : <https://developers.openai.com/api/docs/bots>
- Anthropic, Does Anthropic crawl data from the web : <https://support.claude.com/en/articles/8896518>
- Perplexity, Perplexity Crawlers : <https://docs.perplexity.ai/docs/resources/perplexity-crawlers>
- Google, Robots meta tag et X-Robots-Tag : <https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag>