La limitation de débit traditionnelle compte combien de requêtes envoie chaque IP et bloque celle qui dépasse la limite. Cela fonctionne à merveille contre un attaquant isolé et persistant — et c’est complètement inutile contre une vraie attaque par déni de service, car un botnet utilise des centaines ou des milliers d’IP différentes à la fois : chacune n’envoie qu’une poignée de requêtes et démarre son propre compteur vierge. DDoS Resilience a été conçu exactement pour ce scénario.
Pourquoi compter par IP ne suffit pas
Si votre seuil de limitation de débit est “bloquer après 100 requêtes par minute”, un botnet de 1 000 IP envoyant chacune 50 requêtes ne déclenche jamais la limite sur une seule IP — et pourtant, ce sont 50 000 vraies requêtes par minute qui tombent sur votre serveur. Le problème n’est pas un chiffre mal calibré : c’est de mesurer la mauvaise unité.
Comment fonctionne DDoS Resilience
Il compte le trafic global du site, pas IP par IP
Au lieu d’un compteur par adresse, DDoS Resilience additionne toutes les requêtes de tout le site, de toutes les IP réunies, sur des fenêtres de 10 secondes. Quand ce total dépasse le seuil que vous configurez (requêtes par minute, pour tout le site), le “mode flood” s’active — et reste actif quelques minutes de plus même si le trafic baisse un instant, pour ne pas s’allumer et s’éteindre sans cesse pendant qu’une attaque oscille près de la limite.
Un défi qu’un bot ne résout jamais, et qu’un humain ne remarque jamais
Une fois le mode flood actif, tout nouveau visiteur reçoit une page légère au lieu de votre WordPress complet : un bref message “Vérification de votre navigateur…” avec un minuscule script qui additionne deux nombres aléatoires et envoie la réponse tout seul, en moins d’une seconde. Un vrai navigateur le résout sans que le visiteur fasse quoi que ce soit ni ne s’en aperçoive. Un bot de flood classique — un script qui n’envoie que des requêtes HTTP brutes, sans moteur JavaScript — n’exécute jamais ce script, n’envoie jamais de réponse, et reste bloqué pour de bon.
Signé et à durée limitée — impossible à falsifier ou à rejouer
La réponse est signée avec HMAC en utilisant le propre secret interne de WordPress, et expire au bout de 60 secondes. Cela exclut de pré-calculer une réponse valide ou d’en rejouer une ancienne. Une fois le défi résolu, le visiteur reçoit un cookie — signé lui aussi — qui le laisse passer sans nouveau défi pendant la durée que vous configurez (15 minutes par défaut).
Qui ne voit jamais le défi
Avant même d’être montré à qui que ce soit, sont exemptés : les administrateurs déjà connectés, les IP de votre liste blanche, les robots d’indexation réellement vérifiés (Google, GPTBot… confirmés par DNS inversé, pas seulement déclarés via le User-Agent), et les routes internes de WordPress — connexion, cron, admin-ajax, API REST — dont le blocage accidentel casserait la gestion de votre propre site. Seules les requêtes de navigation (GET) sont soumises au défi ; les formulaires et les appels API passent sans encombre, pour ne pas casser les paiements ni les intégrations en pleine attaque.
Ce qui se passe sur votre serveur pendant l’attaque
Le point important : ce défi est servi avant même que WordPress ne se charge. Un bot coincé dans la boucle du défi ne fait jamais vraiment travailler votre base de données ni votre PHP — il reçoit une page statique de quelques kilo-octets et un code 503, pas une exécution complète de WordPress. C’est ce qui permet à votre site de continuer à répondre normalement aux vrais visiteurs, même quand le volume total de requêtes est énorme.
Questions fréquentes
Cela bloque-t-il Google ou mes vrais visiteurs ?
Non. Les robots réellement vérifiés sont exemptés, et tout vrai visiteur avec JavaScript activé (l’immense majorité) résout le défi tout seul, en moins d’une seconde, sans voir de CAPTCHA ni rien avoir à faire.
Dois-je faire quelque chose quand une attaque commence ?
Non — cela s’active et se désactive tout seul, selon le trafic global du site en temps réel. Vous pouvez ajuster le seuil, la durée pendant laquelle un visiteur reste vérifié, et le délai de retour au calme après un pic, depuis le tableau de bord.
Cela remplace-t-il un CDN comme Cloudflare ?
Pas entièrement, et c’est important de le savoir : DDoS Resilience protège la couche applicative (couche 7) — le trafic HTTP qui arrive jusqu’à WordPress. Cela ne remplace pas un réseau de périphérie conçu pour absorber les attaques au niveau réseau (couche 3/4) avant même qu’elles n’atteignent votre serveur. C’est une couche supplémentaire, pas la seule que vous devriez avoir si le risque DDoS est élevé pour votre activité.