🔒 Empêcher certains outils d'accéder au HTML d'une page

Oui, on peut mettre en place en PHP ou avec .htaccess un système qui refuse certaines requêtes HTTP avant que la page HTML ne soit envoyée.

⚠️ Il faut toutefois distinguer deux choses :

1. Avec .htaccess — solution simple

On peut examiner le User-Agent envoyé par le client.

Par exemple :

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} beautifier [NC]
RewriteRule ^ - [F,L]

Si le client envoie un User-Agent contenant beautifier, Apache renvoie :

HTTP 403 Forbidden

Le fonctionnement est alors :

Navigateur Chrome
      ↓
   requête HTTP
      ↓
   .htaccess
      ↓
User-Agent = Chrome
      ↓
   AUTORISÉ
      ↓
   PHP / HTML

Alors que :

HTML Beautifier
      ↓
   requête HTTP
      ↓
   .htaccess
      ↓
User-Agent = HTML Beautifier
      ↓
    REFUSÉ
      ↓
    HTTP 403

2. Bloquer plusieurs clients connus

On peut également écrire :

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} (beautifier|curl|wget|python|scrapy|httpclient) [NC]
RewriteRule ^ - [F,L]

Cela bloque les requêtes dont le User-Agent contient l'un de ces termes.

3. Faire le contrôle en PHP

Le même principe peut être réalisé directement dans index.php :

<?php

$userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';

if (preg_match('/beautifier|curl|wget|python|scrapy|httpclient/i', $userAgent)) {
    http_response_code(403);
    exit('Access denied');
}

Le PHP récupère le User-Agent avec :

$_SERVER['HTTP_USER_AGENT']

et peut décider de refuser ou d'autoriser la requête.

4. ⚠️ Limite importante du User-Agent

Cette protection est facile à contourner.

Par exemple, HTML Beautifier pourrait envoyer :

User-Agent: Mozilla/5.0

au lieu de :

User-Agent: HTML Beautifier

Le serveur ne pourrait alors plus distinguer ce client d'un navigateur classique avec ce seul critère.

Le User-Agent ne constitue donc pas une véritable protection contre le scraping.

5. 🔐 Une protection plus sérieuse

Pour se rapprocher du comportement d'un véritable système anti-bot, on peut combiner plusieurs informations :

Adresse IP
     +
User-Agent
     +
Cookies
     +
Session
     +
Referer
     +
fréquence des requêtes
     +
nombre de pages demandées
     +
éventuellement un token

Le serveur peut alors établir une règle du type :

requête
   ↓
vérifier IP
   ↓
vérifier User-Agent
   ↓
vérifier cookie/session
   ↓
vérifier fréquence des requêtes
   ↓
┌───────────────────┐
│ comportement      │
│ normal ?           │
└───────────────────┘
   ↓             ↓
  OUI            NON
   ↓             ↓
envoyer HTML    HTTP 403

6. Ce que cela protège réellement

Cette technique ne cache pas le HTML envoyé au navigateur.

Si Chrome reçoit :

<h1>Ma page</h1>

l'utilisateur pourra toujours examiner ce HTML avec les outils de développement du navigateur.

En revanche, le serveur peut empêcher un client donné de recevoir la page :

Client HTTP
      ↓
   requête
      ↓
   serveur
      ↓
contrôle anti-bot
      ↓
   refus 403

Dans ce cas, le client n'obtient tout simplement pas le contenu.

7. Pour un CMS PHP

Pour un CMS comme celui que j'utilise avec des pages Markdown, l'architecture peut être :

/pages/
    accueil.md
    mairie.md
    citations.md

          ↓

       index.php

          ↓

    contrôle anti-bot

          ↓

       Parsedown

          ↓

    HTML final

          ↓

      navigateur

Le visiteur ne reçoit donc jamais directement :

accueil.md
mairie.md
citations.md

ni le code PHP qui effectue le traitement.

Il reçoit uniquement le résultat HTML généré par PHP.

8. La distinction essentielle

Il faut donc distinguer :

Objectif Possible ?
Empêcher Chrome de voir le HTML qu'il reçoit ❌ Non
Empêcher Ctrl+U de fonctionner ❌ Pas réellement
Désactiver F12 ❌ Pas réellement
Bloquer le clic droit ❌ Protection très faible
Bloquer un User-Agent particulier ✅ Oui
Refuser certaines adresses IP ✅ Oui
Limiter les requêtes répétitives ✅ Oui
Exiger une session/cookie ✅ Oui
Refuser certains clients avant d'envoyer le HTML ✅ Oui
Cacher le PHP au visiteur ✅ Oui, normalement le PHP reste côté serveur
Cacher le Markdown original ✅ Oui, s'il reste côté serveur

9. Dans le cas de Babelio

Le comportement observé avec HTML Beautifier est compatible avec un filtrage HTTP côté serveur / système anti-bot ou anti-scraping.

Ce n'est donc pas nécessairement :

« Babelio cache son code HTML »

mais plutôt :

« Babelio refuse certaines requêtes qui cherchent à récupérer son contenu »

Le navigateur normal reçoit la page et peut donc en examiner le DOM.

Un outil externe comme HTML Beautifier peut, lui, recevoir un refus ou une réponse différente.

En résumé

Le mécanisme de base est très simple :

requête HTTP
     ↓
contrôle côté serveur
     ↓
┌──────────────┐
│ autorisée ?  │
└──────────────┘
   ↓       ↓
  OUI      NON
   ↓       ↓
HTML      403
envoyé    refus

Avec Apache, le premier niveau peut être réalisé directement dans .htaccess.

Avec PHP, le même contrôle peut être effectué dans index.php.

Pour obtenir une protection réellement efficace contre les outils de récupération automatique, il faut cependant aller au-delà du simple User-Agent et combiner plusieurs critères de détection.