Le trafic généré par les robots n’est plus un problème secondaire pour les propriétaires de sites WordPress. Dans notre rapport sur l’IA et le trafic généré par les robots, nous avons analysé plus de 10 milliards de requêtes sur l’infrastructure gérée par Kinsta et avons constaté que ce trafic automatisé constitue désormais un véritable problème d’infrastructure, et non plus une simple note de bas de page dans les domaines de la sécurité ou de l’analyse.
Les robots d’indexation accèdent à des points de terminaison dynamiques, se retrouvent piégés dans des boucles de chaînes de requête, contournent le cache et génèrent des schémas de trafic qui s’apparentent moins à une indexation normale qu’à une automatisation défaillante à grande échelle.
Cette évolution a fait de la protection contre les robots un élément essentiel de la gestion d’un site WordPress. C’est également la raison pour laquelle nous avons lancé la protection anti-robots de Kinsta, un outil intégré qui aide les propriétaires de sites WordPress à identifier et à gérer le trafic automatisé indésirable directement depuis MyKinsta.
Mais si vous utilisez déjà Cloudflare, vous vous demandez peut-être comment la protection anti-robots de Kinsta s’intègre dans ce contexte. S’agit-il de la même chose que le « Bot Fight Mode » de Cloudflare ? Devriez-vous utiliser les deux ? L’un remplace-t-il l’autre ? Et si vous utilisez votre propre compte Cloudflare en amont de votre site, que se passe-t-il lorsque vous activez également la protection Kinsta ?
Nous avons reçu de nombreuses questions de ce type lors de notre récent webinaire « Bot Traffic Reality Check » ; cet article y répond donc directement, avec la contribution de Laszlo Farkas, notre directeur de l’ingénierie.
TL;DR
- La protection anti-robots de Kinsta n’est pas simplement le « Bot Fight Mode » de Cloudflare rebaptisé Kinsta. Elle utilise les capacités de détection et de vérification des robots de Cloudflare, mais y ajoute les réglages spécifiques à WordPress et les réglages par défaut gérés par Kinsta.
- Pour la plupart des sites WordPress hébergés chez Kinsta, la protection anti-robots de Kinsta constitue le meilleur point de départ. Elle est intégrée à MyKinsta, optimisée pour le trafic WordPress et ne vous oblige pas à créer ni à gérer des règles anti-robots personnalisées.
- La gestion des robots de Cloudflare peut s’avérer plus adaptée aux équipes expérimentées. Si vous avez besoin de règles au niveau des points de terminaison, de scores de robots personnalisés, d’une analyse approfondie et que vous disposez de l’expertise nécessaire pour gérer vous-même les règles, Cloudflare vous offre davantage de flexibilité.
- Il n’est généralement pas nécessaire d’utiliser les deux. L’utilisation simultanée d’outils de protection contre les robots qui se chevauchent peut créer des difficultés redondantes ou générer des frictions pour les visiteurs légitimes.
- Le principal compromis se situe entre le contrôle et la simplicité opérationnelle. Cloudflare offre davantage de contrôle aux équipes expérimentées. Kinsta propose aux équipes WordPress une solution infogérée qui fonctionne dès son installation pour la plupart des cas d’utilisation.
La protection anti-robots de Kinsta et Cloudflare ne sont pas la même chose
L’infrastructure d’hébergement de Kinsta s’appuie sur Cloudflare pour le CDN, le WAF et la protection contre les attaques DDoS. Ce n’est pas quelque chose que nous cherchons à cacher.
La protection contre les robots repose sur la même base. Ainsi, si la question est de savoir si la protection contre les robots de Kinsta utilise en arrière-plan le moteur de détection de Cloudflare, la réponse est oui.
Mais « utiliser le même moteur » et « être le même produit » ne reviennent pas au même, et c’est en confondant ces deux notions que naît la confusion. Comme l’a expliqué Laszlo lorsque nous lui avons posé directement la question :
Nous utilisons la même infrastructure que Cloudflare. Nous disposons des mêmes connaissances et des mêmes options que Cloudflare, mais notre expertise approfondie nous permet de proposer à nos clients de meilleurs réglages par défaut pour gérer le trafic WordPress.
Kinsta superpose ses propres règles de classification à la liste des robots de Cloudflare, et cette superposition a une importance concrète. Cloudflare attribue à chaque requête un score de robot basé sur l’apprentissage automatique, compris entre 1 et 99, où 1 indique une forte probabilité d’automatisation et 99 indique une probabilité maximale d’intervention humaine. Kinsta utilise ce score comme base, mais y ajoute sa propre logique, de sorte qu’un robot d’indexation IA générant un volume de requêtes anormalement élevé puisse être reclassé en tant que « robot d’indexation IA à taux excessif » et faire l’objet d’une vérification, même si la liste de Cloudflare le classe comme un robot vérifié.
Les outils anti-robots de Cloudflare sont conçus pour un large éventail de sites web, d’applications et de profils de trafic. La protection anti-robots de Kinsta est spécialement optimisée pour les sites WordPress hébergés chez Kinsta ; ses réglages par défaut reflètent ainsi les profils de trafic, les points de terminaison, les automatisations et les intégrations WordPress que nous observons au quotidien.
Comprendre les options de protection contre les robots de Cloudflare
Avant de comparer la protection anti-robot de Kinsta à celle de Cloudflare, il est utile de préciser ce que signifie réellement la « protection anti-robot de Cloudflare », car Cloudflare ne propose pas un seul produit. Il existe trois niveaux, chacun présentant un degré de contrôle et une complexité opérationnelle différents.
Mode « Bot Fight » de Cloudflare
Le mode « Bot Fight » est l’option la plus simple ; il s’active ou se désactive d’un simple clic et est inclus dans tous les forfaits Cloudflare, y compris la version gratuite. Son principal avantage réside dans sa simplicité : vous pouvez l’activer et bénéficier d’une protection de base contre les robots sans avoir à définir la moindre règle.
Le compromis réside dans le contrôle. La documentation de Cloudflare indique clairement que le « Bot Fight Mode » protège des domaines entiers et ne peut être contourné ni ignoré à l’aide de règles WAF personnalisées ou de « Page Rules », car il ne s’exécute absolument pas sur le moteur de règles (Ruleset Engine) de Cloudflare. Concrètement, si le mode « Bot Fight » bloque du trafic que vous ne souhaitiez pas voir bloqué, vos seules options réelles consistent à le désactiver complètement ou à passer à un forfait supérieur.
Ce compromis peut poser problème pour les sites WordPress générant un trafic automatisé légitime, tel que les clients API, les outils de surveillance, les intégrations d’extensions, les flux de paiement ou d’autres services nécessitant un accès prévisible.
Mode Super Bot Fight de Cloudflare
Le mode « Super Bot Fight » (disponible sur les formules Pro, Business et Enterprise sans le module « Bot Management ») vous offre davantage de contrôle que le simple bouton de bascule. Il vous permet de choisir des actions distinctes telles qu’« autoriser », « vérifier » ou « bloquer » pour des catégories de trafic générales telles que « clairement automatisé », « probablement automatisé » et « robots vérifiés ».
Contrairement au mode « Bot Fight », il s’exécute sur le moteur Ruleset Engine, ce qui signifie que vous pouvez utiliser des règles WAF personnalisées avec une action « Ignorer » pour définir des exceptions pour un trafic spécifique.
Ce contrôle supplémentaire est utile, mais il s’agit tout de même d’un outil à large spectre. Il n’offre pas de ciblage par point de terminaison ni l’évaluation granulaire des robots par requête que propose la gestion des robots. Pour bénéficier de ce niveau de contrôle, Cloudflare recommande lui-même à ses utilisateurs de recourir à la gestion des robots.
Cloudflare Bot Management et les règles personnalisées
La gestion des robots est l’option la plus flexible de Cloudflare, disponible sous forme de module Enterprise. Elle génère un score de robot compris entre 1 et 99 pour chaque requête et vous permet d’agir en conséquence à l’aide de règles WAF personnalisées ou de Workers, en tenant compte de signaux tels que le score de robot, le chemin URI, le pays, l’ASN, la plage d’adresses IP, les en-têtes et l’agent utilisateur.
C’est là que Cloudflare révèle toute sa puissance. Vous pouvez, par exemple, filtrer les requêtes à faible score sur une page de connexion tout en laissant un blog public intact.
Mais cette flexibilité s’accompagne d’une réelle responsabilité. Vous devez comprendre votre trafic, définir les règles, tester les faux positifs, surveiller les résultats et continuer à affiner vos réglages à mesure que le comportement des robots évolue.
La place de la protection anti-robots de Kinsta
La protection anti-robots de Kinsta se situe à mi-chemin entre le mode « Bot Fight » de Cloudflare et la gestion des robots de Cloudflare avec des règles personnalisées. Elle tient davantage compte des spécificités de WordPress qu’un simple bouton marche/arrêt, mais ne vous oblige pas à élaborer et à maintenir une stratégie personnalisée de gestion des robots à partir de zéro.
Au lieu de partir de scores bruts attribués aux robots, d’expressions de règles ou d’une logique au niveau des points de terminaison, la protection anti-robots de Kinsta s’appuie sur le contexte d’hébergement WordPress : visiteurs normaux, robots d’indexation, robots d’IA, outils de surveillance de la disponibilité, automatisations WordPress, intégrations d’extensions, activité e-commerce, workflows d’administration et requêtes automatisées suspectes.
Pour résumer simplement :
| Approche | Ce qu’elle vous apporte | Ce qu’elle vous demande |
| Mode « Bot Fight » de Cloudflare | Lutte étendue contre les robots | Configuration très simple, mais contrôle limité |
| Protection contre les robots de Kinsta | Protection infogérée spécifique à WordPress | Choisissez le niveau de protection adapté et surveillez son impact |
| Gestion des robots par Cloudflare | Personnalisation approfondie | Créez, testez, surveillez et gérez vous-même les règles |
Ce que Kinsta apporte en plus des fonctionnalités de Cloudflare
La protection anti-robots de Kinsta ajoute une couche infogérée spécifique à WordPress aux fonctionnalités de détection et de vérification des robots de Cloudflare. Voici comment cela se traduit concrètement.
Quatre niveaux de protection au lieu d’un simple bouton
La protection anti-robots de Kinsta propose quatre niveaux prédéfinis, appliqués par environnement :
Les quatre niveaux sont les suivants :
- Blocage du trafic malveillant : le niveau de base appliqué par défaut à tous les sites Kinsta, sans configuration supplémentaire. Cela inclut la protection contre les attaques DDoS ainsi que des règles globales pour les adresses IP et les points de terminaison utilisés exclusivement par le trafic malveillant. À elle seule, cette couche de base filtre généralement environ 15 à 20 % du trafic clairement malveillant avant même qu’il n’atteigne votre site.
- Blocage des automatisations : bloque à la fois le trafic automatisé et le trafic malveillant.
- Défier les robots : bloque le trafic automatisé et malveillant, puis soumet à un contrôle les robots potentiels et le trafic non classifié.
- Défier tout le monde : le réglage le plus strict. Bloque le trafic automatisé et malveillant, et soumet à un contrôle les visiteurs susceptibles d’être des humains, des robots ou du trafic non classé. À réserver de préférence à un site faisant l’objet d’une attaque active ou subissant un pic inhabituel nécessitant une atténuation immédiate.
Ces niveaux étant définis par environnement, vous pouvez appliquer un réglage plus strict en production tout en conservant un réglage plus souple en staging, ou inversement.
Une vérification ne se traduit pas toujours par l’affichage d’un CAPTCHA. Il peut s’agir d’une vérification au niveau du navigateur, d’une validation en arrière-plan ou d’un test interactif. Les visiteurs humains légitimes passent généralement le test sans interruption visible, ou presque, et une fois qu’un visiteur a réussi un test, il ne sera plus soumis à un nouveau test pendant au moins 10 jours, à condition qu’il continue à utiliser le même navigateur et la même adresse IP.
Classification du trafic
Les statistiques de MyKinsta indiquent comment chaque requête a été classée : utilisateurs humains probables, robots vérifiés, robots probables, trafic non classé, trafic automatisé, trafic malveillant et robots d’indexation IA à fréquence excessive.
Il indique également comment chaque requête a finalement été traitée : autorisée, soumise à un test ou bloquée.
Cette distinction est importante car « automatisé » ne signifie pas automatiquement « indésirable ». Le trafic automatisé peut inclure des outils parfaitement légitimes qui ne figurent pas encore sur la liste des bots vérifiés, tels que des intégrations d’API personnalisées, des outils de surveillance de la disponibilité ou des scripts de déploiement.
Un système qui ne raisonne qu’en termes d’« autorisation ou de blocage » est trop simpliste au regard du fonctionnement réel des sites WordPress.
Une liste d’autorisation gérée spécialement conçue pour WordPress
Les sites WordPress dépendent de nombreuses activités automatisées légitimes, telles que les requêtes API REST, les tâches planifiées, les intégrations d’extensions, les envois de formulaires, les outils de référencement, les outils de synchronisation et les workflows de commerce électronique.
Si une protection anti-robot plus stricte commence à interférer avec l’un de ces éléments, vous pouvez activer l’option « Autoriser les automatisations WordPress courantes », qui active la liste d’autorisations gérée par Kinsta des points de terminaison et services WordPress de confiance.
Vous pouvez également ajouter une exception spécifique sous « Toujours autoriser » en utilisant une adresse IP, un chemin d’accès ou un agent utilisateur.
Nous ne demandons pas à chaque client de redécouvrir par lui-même quelles intégrations nécessitent une protection contre des règles anti-robots plus strictes. La liste d’autorisations est gérée et enrichie pour vous.
Un contrôle distinct pour les robots d’indexation IA
La gestion des robots d’indexation basés sur l’IA est délibérément dissociée du niveau de protection général, car ces robots ne sont pas systématiquement assimilables à des robots malveillants. Certains s’identifient clairement et respectent les limites d’indexation. D’autres génèrent une charge simplement en effectuant une indexation agressive ou en accédant à des chemins coûteux et non mis en cache.
Le bouton dédié « Bloquer les robots d’exploration IA » de Kinsta bloque entièrement les robots d’exploration IA, y compris ceux qui ont été vérifiés, sans affecter les robots d’exploration des moteurs de recherche tels que Googlebot ou Bing. Il s’agit d’un levier distinct précisément parce que le trafic des robots d’exploration IA et celui des robots en général nécessitent souvent des décisions différentes.
Contrôles groupés sur l’ensemble des environnements
Pour les agences, le trafic des robots est rarement un problème limité à un seul site. Kinsta prend en charge les actions groupées à partir de la liste des sites WordPress ; vous pouvez ainsi modifier les niveaux de protection, autoriser ou bloquer les robots d’indexation IA et mettre à jour la liste d’autorisation d’automatisation WordPress sur plusieurs environnements à la fois, sans avoir à ouvrir chaque site individuellement.
Un support assuré par des experts en hébergement WordPress
Les problèmes liés au trafic des robots sont rarement isolés du reste de la pile WordPress. Un pic soudain peut être dû à des robots malveillants, à un robot d’exploration IA, à une intégration mal configurée, à un conflit entre extensions, à une tâche de synchronisation WooCommerce ou à une campagne marketing légitime.
Avec la protection anti-robots de Kinsta, le support est assuré par la même équipe qui connaît déjà votre environnement d’hébergement, ce qui vous évite d’avoir à recouper les informations de deux tableaux de bord distincts provenant de deux fournisseurs différents.
Si vous utilisez déjà votre propre compte Cloudflare
C’est la question qui nous a été le plus souvent posée lors du webinaire ; il convient donc d’y répondre avec précision, plutôt que de la résumer par une simple recommandation générale du type « n’utilisez pas les deux en même temps ».
Concernant l’utilisation des fonctionnalités anti-robots de Cloudflare (Bot Fight Mode, Super Bot Fight Mode ou Bot Management) en parallèle de la protection anti-robots de Kinsta, Laszlo a clairement indiqué que cela fonctionnait techniquement, mais qu’il ne le recommandait pas :
Techniquement, elles fonctionnent ensemble, mais je ne recommanderais généralement pas de les activer toutes les deux… L’utilisation simultanée des deux peut également entraîner des complications inutiles. Par exemple, un visiteur pourrait se retrouver confronté à plusieurs défis de gestion au lieu d’un seul lors de sa première visite.
Interrogé en direct lors du webinaire, notre directeur technique, Daniel Pataki, l’a formulé encore plus simplement : « Vous pouvez utiliser les deux, mais il n’y a aucune raison valable de le faire. Il est bien plus sûr de n’utiliser que l’un ou l’autre. » Dans ce scénario, l’inconvénient réside donc dans les frictions et les défis redondants pour les véritables visiteurs, et non dans une configuration défaillante.
Nous vous déconseillons également d’installer un autre CDN, un proxy inverse ou un WAF en amont de votre site en plus de la protection anti-robots de Kinsta. Cela inclut votre propre compte Cloudflare s’il achemine activement le trafic via son proxy avec ses fonctionnalités WAF ou de protection contre les robots activées, ainsi que d’autres services tels qu’AWS, Microsoft Azure, Sucuri ou Fortinet qui agissent en tant que proxies inversés. Lorsqu’un autre élément se trouve en amont de votre trafic et le traite en premier, Kinsta ne peut plus identifier la véritable origine de chaque requête, ce qui signifie que la protection contre les robots ne peut plus distinguer de manière fiable le trafic automatisé du trafic humain.
Si vous utilisez actuellement votre propre compte Cloudflare avec des règles personnalisées de protection contre les robots ou de pare-feu d’application web (WAF) en amont d’un site Kinsta et que vous ne savez pas laquelle de ces deux situations s’applique à votre configuration, le plus prudent est de vérifier auprès du support Kinsta avant d’effectuer des modifications, plutôt que de vous lancer à l’aveuglette.
Surveillance : Cloudflare vs Kinsta
Où devriez-vous réellement surveiller votre trafic au quotidien ? Cela dépend de ce que vous recherchez.
Cloudflare vous offre une flexibilité nettement supérieure pour vos analyses. Vous pouvez analyser en détail chaque requête à l’aide de filtres personnalisés et effectuer des recherches sur pratiquement n’importe quel attribut de requête. Cependant, les analyses de bots de Cloudflare reposent sur des données échantillonnées, et non sur un décompte exhaustif de chaque requête, ce qui en fait un excellent outil pour repérer des tendances et enquêter sur des incidents, mais une source moins fiable pour obtenir des chiffres de trafic exacts.
Kinsta, en revanche, rend compte de 100 % des requêtes reçues par votre site, avec des statistiques agrégées par heure et par jour disponibles dans MyKinsta. Cela en fait la meilleure source pour obtenir des chiffres et des tendances précis au niveau de la plateforme, même si elle ne vous offre pas les filtres ad hoc et détaillés de Cloudflare.
Ainsi, si vous avez besoin d’une analyse approfondie d’un incident spécifique, les outils de Cloudflare s’imposent. Si vous souhaitez disposer de mesures précises et fiables sur ce qui affecte réellement votre site au fil du temps, Kinsta a l’avantage.
À quelle couche la protection anti-robots de Kinsta s’applique-t-elle ?
La protection anti-robots de Kinsta s’exécute en périphérie, au niveau de la couche 7 (la couche application), la même couche où les requêtes HTTP sont évaluées.
Lorsque la protection Cloudflare d’un client et la protection anti-robots de Kinsta sont toutes deux actives sur le même chemin de requête, le traitement de Cloudflare s’effectue en premier, puis la logique de Kinsta s’exécute ensuite. C’est une raison supplémentaire pour laquelle le chevauchement des deux solutions apporte rarement une valeur ajoutée. Au moment où une requête atteint la logique de Kinsta, Cloudflare a déjà pris sa propre décision.
Quelle approche devez-vous adopter ?
Le choix approprié dépend du niveau de contrôle dont vous avez besoin et de la part de la gestion des robots que votre équipe souhaite prendre en charge.
Utilisez la protection anti-robots de Kinsta si vous souhaitez bénéficier d’une protection WordPress infogérée
Si vous hébergez WordPress sur Kinsta et que vous ne souhaitez pas que la lutte contre les robots devienne une tâche récurrente dans l’agenda de l’un de vos collaborateurs, la protection anti-robots de Kinsta est la solution par défaut qu’il vous faut.
Cela couvre la plupart des sites WordPress : les agences gérant le trafic de dizaines de clients, les équipes ne disposant pas d’un service de sécurité dédié, et tous ceux qui préfèrent consacrer leur temps à la gestion de leur activité plutôt qu’à la mise à jour des règles anti-robots.
Utilisez les outils avancés de Cloudflare contre les robots si vous avez besoin d’un contrôle total
Cloudflare peut s’avérer le meilleur choix si vous utilisez ses contrôles anti-robots plus avancés, tels que le « Super Bot Fight Mode » associé à un WAF et à des règles personnalisées, et si vous disposez du temps et de l’expertise nécessaires pour gérer correctement cette configuration.
Cela ne correspond pas au « Bot Fight Mode » de base de Cloudflare, qui s’apparente davantage à un simple contrôle « activé/désactivé ». L’approche avancée de Cloudflare s’avère pertinente lorsque vous connaissez votre trafic en détail, que vous disposez de points de terminaison spécifiques nécessitant un traitement différent et que vous souhaitez définir un comportement personnalisé pour certains modèles de requêtes.
Cette précision est bien réelle, mais elle s’accompagne d’un coût récurrent, car elle nécessite une attention constante plutôt qu’une configuration ponctuelle. Comme l’a dit Laszlo :
Si vous disposez de l’expertise et du temps nécessaires pour affiner vous-même ces réglages, c’est probablement le meilleur choix pour vous. Si ce n’est pas le cas et que vous souhaitez vous concentrer sur votre activité plutôt que sur les détails techniques du contrôle du trafic, la solution de Kinsta est la meilleure option, car elle est infogérée, optimisée pour WordPress et entretenue à votre place.
Évitez d’utiliser les deux à moins d’avoir une raison précise
Dans la plupart des cas, choisissez une seule couche principale de protection contre les robots :
- Si vous utilisez le mode « Bot Fight » ou le mode « Super Bot Fight » de Cloudflare sur un site hébergé par Kinsta, la protection anti-robots de Kinsta est généralement la meilleure solution, car elle est optimisée pour WordPress et gérée au sein de votre plateforme d’hébergement.
- Si vous utilisez la gestion des robots de Cloudflare avec un ensemble de règles personnalisées déjà défini, la décision dépend davantage du contexte ; elle dépend de ce que font ces règles, de la manière dont elles interagiraient avec la protection anti-robots de Kinsta, et de la nécessité de les conserver une fois que la protection gérée par Kinsta est activée. Vérifiez cette configuration avec le support Kinsta plutôt que de vous fier à une réponse générale.
- Si vous utilisez votre propre compte Cloudflare distinct comme proxy en amont de Kinsta, reportez-vous à la section ci-dessus ; c’est le seul cas où la combinaison des deux ne constitue pas seulement une « friction inutile », mais peut activement empêcher la protection contre les robots de fonctionner comme prévu.
La protection contre les robots fait désormais partie intégrante de l’exploitation de WordPress
La protection contre les robots n’est plus un paramètre de sécurité ponctuel que les propriétaires de sites peuvent traiter comme tel. Comme l’a expliqué Daniel Pataki lors de notre webinaire, les bots sont une arme à double tranchant : ils peuvent entraîner des problèmes de performances, de coûts et d’analyse, mais ils contribuent également à rendre le Web utile.
À mesure que les robots d’indexation, les outils d’IA, les scrapers et les systèmes automatisés gagnent en activité sur le Web, les équipes WordPress ont besoin d’un moyen de gérer le trafic non humain sans transformer chaque site en un projet de création de règles personnalisées. C’est précisément le rôle que la protection contre les robots de Kinsta est conçue pour remplir : un point de départ géré, offrant des niveaux de protection, des contrôles des robots d’indexation par IA, des réglages par défaut adaptés à WordPress et une visibilité au sein de MyKinsta.
Pour approfondir le sujet, regardez le webinaire « Bot Traffic Reality Check », lisez le rapport de Kinsta sur l’IA et le trafic de robots, ou activez la protection contre les robots depuis votre tableau de bord MyKinsta pour voir quel trafic automatisé affecte réellement votre site.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
