Voici le mécanisme technique, les chiffres, et ce que ça change pour vous en tant que lecteurs.
1. La bascule : les machines sont devenues majoritaires
L'ordre de grandeur a changé en deux ans. D'après les données Cloudflare Radar, environ un tiers de l'ensemble du trafic web est désormais automatisé, et sur le trafic HTML seul — c'est-à-dire les pages, hors images et scripts — le trafic automatisé a été mesuré autour de 57 % en juin 2026, contre environ 42 % pour les humains.
Autrement dit : sur une page de forum servie aujourd'hui, il y a statistiquement plus de chances que le lecteur soit un programme qu'une personne.
Les principaux acteurs sont identifiés dans les logs par leurs user-agents : GPTBot, ClaudeBot et Claude-SearchBot, Meta-ExternalAgent, PerplexityBot, Bytespider, sans compter Googlebot qui reste le premier volume et qui, lui, envoie encore du trafic en retour. Le classement entre ces robots change littéralement d'un mois à l'autre, au rythme des campagnes d'entraînement des différents laboratoires.
2. Pourquoi un robot coûte beaucoup plus cher qu'un humain
C'est le point contre-intuitif, et c'est le cœur du problème.
Un site est optimisé pour le comportement humain : les visiteurs consultent en majorité les mêmes pages populaires, qui restent donc en cache, servies instantanément sans toucher à la base de données. Un robot d'entraînement fait exactement l'inverse : il veut la totalité de l'archive, y compris les pages les plus obscures, celles que personne n'a ouvertes depuis 2011.
Wikimedia a chiffré cet effet de façon frappante : les robots représentaient environ 35 % des pages vues, mais 65 % des requêtes les plus coûteuses pour leur infrastructure centrale. Un robot qui parcourt la longue traîne contourne mécaniquement toutes les couches de cache et va taper directement sur la base.
Sur nos serveurs, le résultat est direct : saturation du pool de connexions MySQL, files d'attente PHP, et erreur 500 renvoyée au premier arrivé — souvent un humain.
3. Pourquoi un forum est la pire cible possible
Un forum phpBB accumule plusieurs caractéristiques qui en font une machine à générer des requêtes coûteuses :
- Une archive massive et intégralement publique. Ici, environ 86 000 messages depuis 2008. Chacun est une page à crawler, et aucune n'est cacheable très longtemps puisque le contenu est dynamique.
- Un espace d'URL quasi infini. Entre les paramètres de tri, d'ordre, de pagination, les vues par sujet, par auteur, par date, les pages de profil et le moteur de recherche interne, un crawler naïf peut générer des centaines de milliers d'URL distinctes à partir de quelques milliers de contenus réels.
- La recherche interne, qui est la requête la plus lourde de tout le système. Un robot qui explore mécaniquement des combinaisons de recherche fait tourner des requêtes SQL complexes en boucle.
- Un contenu textuel dense, structuré et rédigé par des humains — exactement ce que les modèles de langage cherchent en priorité.
4. Ce que ça change concrètement pour vous
La dégradation n'est pas théorique :
- Erreurs 500 intermittentes, typiquement en rafales de quelques minutes, quand plusieurs crawlers tombent en même temps.
- Temps de réponse qui s'allonge sur les pages non cachées — celles justement où vous écrivez et répondez.
- Sessions parfois perdues, messages en cours de rédaction qui échouent à l'envoi.
- Et un effet moins visible : les statistiques de fréquentation deviennent illisibles, puisque la moitié du trafic ne correspond à personne.
5. Le déséquilibre économique, en une métrique
Le rapport entre pages aspirées et visiteurs renvoyés — le « crawl-to-refer ratio » — résume tout.
Les mesures publiées à partir de Cloudflare Radar donnent des ordres de grandeur qui varient énormément selon l'opérateur et le mois, mais la hiérarchie est constante : Googlebot tourne autour de quelques pages crawlées pour un visiteur renvoyé, tandis que les crawlers d'IA se comptent en centaines, en milliers, voire davantage selon les périodes et les méthodologies. Les chiffres exacts sont à prendre avec des pincettes — les méthodes de calcul diffèrent d'une étude à l'autre — mais l'écart d'échelle, lui, n'est pas contesté.
Traduit en français : le modèle historique du web était un échange. Vous laissez le robot indexer, il vous envoie des lecteurs. Ce contrat est rompu. Le contenu est absorbé, reformulé dans une réponse d'assistant, et le lecteur n'arrive jamais jusqu'à la source.
6. Nous ne sommes pas un cas isolé
Le phénomène a d'abord frappé les projets open source, qui ont documenté publiquement leurs déboires :
- SourceHut a subi des coupures répétées et a fini par bloquer en bloc plusieurs fournisseurs cloud ; son fondateur a décrit y consacrer une part considérable de son temps de travail hebdomadaire.
- Le GitLab de GNOME a dû déployer Anubis, un système de preuve de travail qui impose au navigateur de résoudre un calcul avant d'accéder au contenu.
- Le dépôt Pagure de Fedora a été contraint de bloquer le trafic de pays entiers après l'échec des mesures classiques.
- Wikimedia a constaté une hausse d'environ 50 % de la bande passante consacrée aux médias depuis janvier 2024, sans augmentation du lectorat humain, et a inscrit la réduction du trafic de crawlers dans son plan annuel.
7. Ce qui a été mis en place ici
Sans entrer dans le détail de configuration, les chantiers menés sur videobourse.fr vont tous dans le même sens : encaisser un trafic dont la majorité n'est pas humaine.
- Migration de la base vers une infrastructure MariaDB plus performante, précisément pour tenir la charge de connexions.
- Mise en place de règles de cache au niveau de Cloudflare, y compris sur le HTML côté WordPress, pour éviter que chaque requête ne descende jusqu'à MySQL.
- Maintien de phpBB à jour et vérification de la santé de l'index de recherche.
8. Les parades possibles, et pourquoi aucune n'est parfaite
- robots.txt : gratuit, mais purement déclaratif. Il n'arrête que ceux qui acceptent d'être arrêtés.
- Blocage au niveau du CDN. Depuis juillet 2025, Cloudflare bloque par défaut les crawlers d'IA sur les nouveaux domaines, et propose des mécanismes de facturation à la requête. C'est aujourd'hui la parade la plus efficace.
- Limitation de débit et blocage des URL paramétrées, en particulier sur la recherche interne — c'est le levier le plus rentable sur un forum.
- Preuve de travail façon Anubis : très efficace, mais ajoute une friction pour tout le monde, y compris les lecteurs légitimes.
Et vous ?
- Avez-vous rencontré ces erreurs 500 sur le forum, et si oui à quels moments de la journée ? Les horaires sont une information utile : les rafales de crawl ont des créneaux.
- Ceux d'entre vous qui gèrent un site ou un blog : constatez-vous la même chose dans vos logs, et avez-vous mis en place des parades qui fonctionnent réellement ?
- Et sur le fond : préférez-vous un forum plus rapide mais absent des réponses d'IA, ou l'inverse ?
Ce message est un retour d'expérience technique. Les chiffres cités proviennent de données publiées par Cloudflare Radar, la Wikimedia Foundation et plusieurs projets open source ; les méthodologies varient d'une source à l'autre et ces mesures évoluent très vite.