Quand on parle de sécuriser un site WordPress, on pense souvent au durcissement “classique” : mots de passe, mises à jour, sauvegardes, limites de tentatives. Le blocage par pays, lui, est une approche plus “frontale”, parfois très efficace, parfois trompeuse. Elle peut réduire la surface d’attaque et le bruit applicatif, surtout contre les vagues automatisées. Mais si vous le faites sans nuance, vous risquez de bloquer des vrais utilisateurs, des agents relais, ou de casser certains parcours (paiement, support, téléchargements) selon votre audience.
J’ai déjà vu des sites qui ont réduit de façon spectaculaire le volume de requêtes suspectes en quelques heures, puis qui ont découvert deux jours plus tard qu’une partie des connexions venait de partenaires, de CRM, ou de services de messagerie situés dans des pays “différents” de ceux visés. Le blocage par pays n’est pas un remède universel, c’est un levier. La clé est de le calibrer, de comprendre ce qu’il bloque réellement, et de prévoir des exceptions intelligentes.
Ce que le blocage par pays fait vraiment (et ce qu’il ne fait pas)
Le blocage par pays consiste à filtrer les requêtes entrantes en fonction de la géolocalisation IP, généralement à l’échelle de l’adresse réseau. En pratique, on parle d’un “proxy” implicite : le serveur (ou un service en amont comme un pare-feu applicatif) décide d’autoriser ou de refuser la requête selon le pays supposé de l’IP.
Ce point est crucial : la géolocalisation n’est pas une vérité absolue. Elle peut se tromper, surtout avec des IP de type cloud, des VPN, des réseaux d’entreprise, ou des infrastructures d’hébergement partagées. Donc, ce blocage réduit le trafic opportuniste et les campagnes basées sur des plages IP “typées”, mais il ne stoppe pas toute attaque.
En revanche, sur des sites WordPress exposés, les attaques “brutes” sont souvent des scripts qui balayent des endpoints, tentent des connexions, envoient des requêtes d’énumération, ou essaient des identifiants connus. Même quand elles viennent de partout, une partie du bruit reste concentrée sur certains pays. Si votre audience est majoritairement localisée ailleurs, filtrer peut améliorer nettement la situation.
Autre élément concret : le blocage par pays peut aussi réduire la charge et le nombre de logs inutiles. Sur des hébergements modestes, l’impact sur la latence et la taille des journaux peut être sensible. C’est un gain opérationnel autant que sécurité.
Dans quels cas le blocage par pays est pertinent
La règle la plus pragmatique, c’est d’évaluer votre “profil” d’accès. Si vous vendez à un pays, ou si votre trafic est essentiellement local, le blocage peut être cohérent. À l’inverse, si vous avez une audience internationale, ou si vous opérez un service global, l’approche risque d’être trop punitive.
Il y a aussi un cas que beaucoup oublient : les utilisateurs ne sont pas les seules “machines” qui visitent votre site. Les outils de surveillance, les services marketing, certains formulaires et mécanismes de vérification, voire des partenaires techniques peuvent déclencher des connexions depuis des pays inattendus. Dans un projet e-commerce, nous avions bloqué deux pays “par défaut”. Le jour du lancement, un prestataire de suivi a cessé de remonter des événements, parce que ses sondes sortaient depuis une région non autorisée. Rien de dramatique côté données produit, mais assez pour perdre des heures à diagnostiquer.
En général, le blocage est le plus utile quand :
- vous avez une connaissance assez fine de vos pays réels (pas supposés), vous pouvez accepter des exceptions, vous le déployez en mode progressif (d’abord observation, ensuite restriction).
Choisir l’endroit où appliquer le blocage
Le blocage par pays peut se faire à différents niveaux, et c’est là que la stratégie change.
1) En amont (pare-feu réseau ou CDN) C’est souvent la meilleure option. La requête est filtrée avant d’atteindre WordPress. Le site subit moins de charge, et vous évitez que WordPress génère des logs et des réponses applicatives inutiles. Beaucoup de solutions “cloud” permettent des règles simples par pays, parfois avec une gestion fine des exceptions.
2) Au niveau web server (Nginx, Apache) Vous pouvez filtrer au niveau du serveur, via des modules géolocalisation ou un ensemble de règles. L’efficacité est correcte, mais la mise en œuvre dépend fortement de l’hébergement et de la qualité du mapping IP vers pays.
3) Dans WordPress C’est rarement mon choix. Filtrer dans l’application, c’est tard. Vous consommez quand même des ressources, vous exposez des endpoints de WordPress à des requêtes potentiellement malicieuses, et vous rendez la https://gardewp.fr/securite-wordpress/ maintenance plus fragile (règles logiques, plugins, caches). C’est possible, mais ça doit rester une stratégie “complémentaire”, pas la base.
Si votre objectif est de sécuriser WordPress efficacement, commencez en amont, ou au minimum au niveau web server. WordPress doit rester un dernier rempart, pas le filtre principal.
Calibrer les pays : méthode simple, mais fiable
Le piège, c’est de décider “au feeling”. Un blocage par pays “au hasard” devient vite une source d’incidents. Voici une méthode qui marche bien en pratique, parce qu’elle s’appuie sur des données observables.
D’abord, observez vos logs d’accès pendant une période représentative. Une semaine suffit souvent pour dégager des tendances. Regardez :
- le volume par pays, les pages les plus touchées (front, login, wp-admin, wp-login.php), l’évolution en temps réel (pics après un post, après une campagne, etc.).
Ensuite, définissez votre politique en deux temps. Pendant la phase d’observation, vous ne bloquez pas encore, vous étiquetez. Puis, quand vous êtes sûr que le pays “non cible” représente surtout du bruit, vous passez au filtrage.
Enfin, acceptez qu’il y ait des exceptions. Dans un contexte réel, il y a rarement une correspondance parfaite “un pays = une audience”. Les IP peuvent être partagées, les services sortants peuvent changer, et la géolocalisation varie. On bloque pour réduire, pas pour garantir.
Mise en place progressive : éviter les mauvaises surprises
Le déploiement “direct” d’un blocage peut être tentant. Pourtant, j’ai plus souvent vu des soucis quand la règle a été activée d’un coup, surtout sur des sites avec comptes utilisateurs à l’étranger ou des échanges avec des partenaires.
Une approche progressive limite les dégâts. Par exemple, au lieu de bloquer tout le reste, commencez par surveiller le trafic de vos pays non prioritaires et vérifiez ce que font les requêtes. Sur certains sites, vous verrez des robots qui ne touchent que les pages publiques, et d’autres cas où il y a des tentatives répétées sur les zones d’authentification. C’est là que la règle apporte un gain net.
Si vous pouvez, commencez par un mode “challenging” ou une interdiction plus douce (selon l’outil) avant de passer à un refus sec. Pour WordPress, un refus au niveau réseau peut aussi limiter les tentatives de brute force en amont, mais si vous bloquez trop large, vous coupez aussi les contrôles légitimes.
Exemples de politiques réalistes
Une bonne politique dépend de votre business. Quelques scénarios fréquents :
- Site local (service régional, billetterie, association) Vous pouvez souvent autoriser un ou deux pays, et bloquer largement le reste. Dans ce cas, vous gagnez beaucoup sur le bruit, et l’impact utilisateur est réduit. E-commerce transfrontalier Vous autorisez plusieurs pays, mais vous bloquez surtout les zones qui n’ont presque aucun trafic. Là encore, la clé est de vérifier les sources exactes du trafic : si vous recevez des connexions depuis des pays inattendus mais avec des patterns humains (navigation, formulaires), bloquer risque de vous coûter des ventes. Blog ou média avec audience internationale Le blocage par pays est rarement total. Vous pouvez plutôt l’utiliser comme couche temporaire en période de risque (lancement, pics de trafic, incident). J’ai déjà utilisé cette logique sur un site éditorial après une série de tentatives de connexion liées à une campagne de mot de passe. Le blocage ciblé a réduit le bruit, puis nous avons relâché lorsque la menace s’est calmée.
Règles par pays plus efficaces quand elles s’additionnent au reste
Le blocage par pays n’est pas isolé. Pour sécuriser WordPress de manière crédible, il s’articule avec d’autres protections.
Par exemple, si vous bloquez certains pays mais laissez wp-login.php exposé, vous réduisez seulement une partie des tentatives. Si, en plus, vous avez des mécanismes de limitation (taux de requêtes, verrouillage temporaire, filtrage du contenu), vous obtenez une défense en profondeur. Et si vous avez une authentification renforcée pour les comptes administrateurs (par exemple l’usage d’une solution MFA), vous transformez les attaques de brute force en tentatives plus coûteuses pour l’attaquant.
Côté configuration, retenez aussi que WordPress a souvent des endpoints “intéressants” pour les bots :
- wp-login.php, l’accès aux pages d’administration (wp-admin), les requêtes liées au REST API, selon votre configuration, les tentatives d’énumération via paramètres, sitemaps et fichiers.
Le blocage par pays agit sur les sources de requêtes, mais il ne remplace pas le contrôle de ces surfaces.
Mettre en place une règle : exemple concret côté pare-feu/CDN
Je ne vais pas vous donner une interface spécifique d’un produit particulier, car elle varie d’un fournisseur à l’autre. Mais le principe est le même : vous créez une politique géographique, puis vous testez en conditions réelles.
Voici comment j’aborde généralement le déploiement.
- Je commence par une règle “monitoring” si l’outil le permet, sinon je m’appuie sur les logs existants. J’identifie les pays réellement non désirés, en gardant en tête les exceptions. Je bascule en “blocage” par paliers, puis je surveille pendant 24 à 72 heures. Je garde une porte de secours, un moyen de désactiver rapidement, au cas où l’audience ou un partenaire soit impacté.
Si vous n’avez qu’une fenêtre de maintenance, il vaut mieux bloquer “moins” le premier jour, puis affiner ensuite. On apprend beaucoup en observant les logs après activation, car les patterns révèlent souvent ce qui était mal compris au départ.
Une checklist de pré-déploiement (rapide, mais utile)
- Vérifier les pays dans vos logs sur une période récente, hors jours atypiques. Définir des exceptions claires pour vos partenaires techniques et vos outils de mesure. Confirmer que l’administration (wp-admin, wp-login.php) est bien protégée par des contrôles complémentaires. Prévoir un rollback rapide, avec accès admin hors règle si possible.
C’est ce qui évite la situation classique : “ça fonctionnait jusqu’au moment où…”. Le rollback est votre assurance psychologique.
Comment gérer les exceptions sans ruiner la règle
Les exceptions sont inévitables. Mais elles doivent rester propres, sinon vous transformez un filtre simple en gruyère.
Le bon réflexe est de distinguer les cas :
- exceptions “humaines” : vos utilisateurs attendus, même s’ils viennent d’un pays minoritaire, exceptions “techniques” : outils de monitoring, CDN, email validation, services analytics, exceptions “fonctionnelles” : intégrations de paiement, webhooks, support.
Si votre outil le permet, vous pouvez créer des règles prioritaires. Par exemple, autoriser explicitement une liste d’IP de partenaires, ou autoriser un pays pour des chemins précis, comme un endpoint de webhook.
Évitez de faire l’inverse, autoriser un pays en général “juste au cas où”, car vous annulez une bonne partie du gain de sécurité. Mieux vaut autoriser un point précis que tout un pays.
Un détail qui compte : certains outils changent d’IP ou utilisent des IP partagées. Si vous faites des exceptions par IP “figées”, surveillez. En production, j’ai déjà vu des webhooks échouer deux jours après un changement d’infrastructure côté prestataire. Dans ce cas, le blocage par pays continuait à tenir, mais l’exception devenait obsolète.
Surveiller après activation : ce que vous devez regarder
Après mise en place d’un blocage par pays, l’objectif n’est pas juste “voir que ça bloque”. Il faut vérifier que :
- le trafic légitime continue, les tentatives suspectes diminuent, les erreurs côté front ne montent pas.
Concrètement, je regarde trois choses en priorité :
- le volume des requêtes vers wp-login.php et wp-admin, le taux d’erreur HTTP (en particulier 403/404 si vous les utilisez comme rejet), la stabilité des pages publiques (temps de chargement, retours d’erreur, abandon de formulaires).
Si vous constatez une hausse de 403 sur des pages publiques par exemple, c’est parfois un signe de problème de géolocalisation ou d’IPs “transit” qui viennent d’un pays non autorisé. À ce moment, il faut affiner, soit en ajoutant une exception, soit en ajustant la granularité de la règle.
Attention aux faux positifs : cas typiques
Le blocage par pays peut produire des faux positifs, pas toujours visibles à la première minute. Voici les plus fréquents.
D’abord, les VPN et proxys. Si une partie de vos utilisateurs se connecte via VPN, ils peuvent apparaître dans un pays non autorisé. Ensuite, les IP “cloud” de certains fournisseurs. Beaucoup d’IP de serveurs sortants se regroupent sur des localisations imprécises, et il arrive qu’un bot ou un service légitime se fasse géolocaliser “dans le mauvais pays”.
Enfin, les réseaux d’entreprise ou les universités. Selon leurs sorties internet, des utilisateurs attendus peuvent sortir depuis une région différente. Ce n’est pas un problème si vous l’anticipez et si vous autorisez certains pays ou certaines plages de manière raisonnable.
Une règle trop agressive peut aussi perturber des opérations de maintenance ou de support. Un exemple : une équipe support interne qui utilise un poste avec egress dans un pays non autorisé peut se retrouver bloquée lors d’une intervention. Donc, avant d’activer, vérifiez où vous vous connectez vous-même, pas seulement vos visiteurs.
Combiner avec d’autres protections pour un résultat concret
Pour être efficace, le blocage par pays doit être vu comme un filtre en amont dans une stratégie globale. Une combinaison souvent payante :
- Limiter les tentatives de connexion sur wp-login.php, Réduire les informations exposées (hardening WordPress, désactivation de fonctions inutiles), Mettre à jour thèmes et plugins régulièrement, Protéger l’accès admin (MFA, limitations, IP allowlist si approprié), Surveiller et corriger les extensions à risque.
Ici, j’insiste sur un point d’expérience : quand on ajoute plusieurs couches en même temps, on ne sait plus quelle couche a fait le travail. Pour le blocage par pays, gardez une logique de “validation par observation”. Activez, surveillez, puis ajustez. Cela évite de multiplier les changements dans le noir.
Et si vous cherchez à sécuriser WordPress sans sacrifier la qualité utilisateur, le compromis se trouve dans ce que vous bloquez, à quel niveau, et pendant combien de temps.
Comment tester sans casser votre site
Un test rapide vaut mieux qu’une journée de tickets clients.
Idéalement, testez depuis un environnement contrôlé :
- vérifiez l’accès aux pages publiques, testez le login, testez l’accès aux formulaires critiques, vérifiez que vos webhooks ou intégrations de paiement ne sont pas impactées.
Si vous pouvez simuler des pays, faites-le sur une page de test ou sur un environnement de préproduction relié au même fournisseur de géoblocage. Sinon, vous pouvez au moins vérifier les logs après activation pour confirmer que les requêtes provenant des pays “bloqués” montent bien en rejets et que les utilisateurs légitimes ne sont pas touchés.
Dans les environnements avec cache CDN, pensez à tester après purge ou en tenant compte du fait que certaines réponses sont mises en cache. Une confusion de cache peut vous faire croire à tort que tout fonctionne alors que le blocage ne s’applique qu’à certaines requêtes non cachées.
Une deuxième checklist : déploiement en production sans panique
- Activez la règle sur un périmètre limité (ou en durcissant progressivement). Surveillez pendant 48 à 72 heures : erreurs, accès login, comportements front. Documentez vos exceptions et la logique associée, pour pouvoir ajuster plus vite. Prévoyez un accès “hors règle” pour l’administration (compte test, accès direct, procédure de rollback).
Les limites pratiques, celles qu’on ne lit pas dans les guides
Même bien configuré, le blocage par pays a des limites qui finissent par se voir en maintenance.
La première, c’est la géolocalisation qui bouge. Une IP peut être reclassée, un fournisseur peut modifier l’assignation, et certains assaillants exploitent des relais pour apparaître “dans le bon pays”. Donc, vous n’obtenez pas un mur absolu, vous obtenez un tri statistique.
La seconde limite, c’est la complexité opérationnelle quand l’audience s’élargit. Une équipe marketing lance une campagne internationale, soudain des connexions de nouveaux pays montent. Si vous aviez bloqué “tout le reste”, vous devez réajuster. C’est faisable, mais il faut intégrer ce sujet dans votre cycle de déploiement, pas seulement en réaction après un problème.
Enfin, il y a la dimension “conformité” et “droit d’accès”. Selon le contexte, vous devez être capable d’expliquer votre politique de filtrage, surtout si elle impacte l’expérience utilisateur. Cela ne veut pas dire que vous ne pouvez pas le faire, mais vous devez garder une justification logique et une procédure claire.
Conclusion implicite : le blocage par pays comme levier, pas comme religion
Si vous voulez sécuriser site WordPress de manière pragmatique, le blocage par pays est un levier intéressant, surtout contre le bruit automatisé et les tentatives répétées. Il devient vraiment utile quand vous l’appliquez en amont, que vous calibrez sur vos logs, et que vous le déployez progressivement avec des exceptions maîtrisées.
Le bon résultat, ce n’est pas “zéro requête étrangère”, c’est “moins de tentatives inutiles, moins de charge, et une expérience utilisateur intacte”. C’est exactement le genre de compromis que j’aime : il apporte un gain mesurable, sans transformer votre WordPress en usine à règles.