Le tableau de bord est vert, l'uptime est de 99,9 %, et le support reçoit des plaintes telles que « le site ne s'ouvre pas » ou « la page est bloquée dans ma région ». Ce n'est pas un bug de la surveillance — c'est une caractéristique architecturale : les bots des services de surveillance de l'uptime vérifient le site avec des IP de centres de données, tandis que les visiteurs réels accèdent via Internet domestique, réseau mobile ou par un fournisseur spécifique qui est bloqué séparément. Nous examinons pourquoi cela se produit et quelles sont les 5 vérifications à ajouter pour voir les blocages avant les clients.
Pourquoi la surveillance de l'uptime classique trompe
Les services tels que UptimeRobot, Pingdom, StatusCake et la plupart des solutions auto-hébergées sur Zabbix ou Grafana envoient des requêtes depuis des serveurs situés dans des centres de données AWS, Hetzner, DigitalOcean et similaires. Ces serveurs ont des IP statiques, qui appartiennent à l'ASN du fournisseur d'hébergement — et c'est le problème clé. Tout système de protection (anti-fraude Facebook, filtre géographique Wildberries, règle Cloudflare, blocage au niveau de Roskomnadzor ou d'un opérateur local) distingue le trafic précisément par l'origine de l'IP, et non par la disponibilité du code HTTP.
En conséquence, il en résulte une zone aveugle classique : un bot avec une IP de centre de données reçoit un 200 OK, car il ne tombe pas sous le filtre — il ne ressemble même pas à un « utilisateur normal » que le système essaie de bloquer. En revanche, une personne réelle avec Internet mobile, Wi-Fi domestique dans un autre pays ou via un fournisseur spécifique reçoit un 403, une redirection vers une page « non disponible dans votre région » ou un captcha infini. La surveillance ne le voit pas, car techniquement le site répond — juste pas à celui qui en a besoin.
Ce problème est critique pour trois groupes : les arbitragistes, dont les plateformes publicitaires et les systèmes anti-fraude bloquent les landing pages précisément par IP d'hébergement ; les vendeurs sur les marketplaces, où le contenu et les prix sont affichés différemment selon la région ; et les SMM/marketeurs, qui testent la publicité pour différents pays et ne remarquent pas que l'audience dans la zone géographique cible ne voit physiquement pas la page.
Vérification 1 : géo-blocages par pays et régions
La raison la plus fréquente de la divergence entre le rapport de surveillance et la réalité est le blocage par géolocalisation IP. Un site peut être entièrement accessible depuis les États-Unis, mais fermé aux visiteurs d'Allemagne en raison des exigences du RGPD, ou vice versa — fermé aux pays de la CEI en raison des restrictions de sanctions de la plateforme publicitaire. Le bot classique de l'uptime est lancé depuis un seul point (généralement les États-Unis ou l'Europe) et n'est physiquement pas capable de voir ce qui se passe dans d'autres pays.
La solution consiste à lancer la vérification simultanément depuis 5 à 10 pays à l'aide de proxies résidentiels, qui ont des IP de véritables utilisateurs domestiques dans la région souhaitée. Contrairement aux adresses de centres de données, l'IP résidentielle passe tous les mêmes filtres géographiques qu'un visiteur normal, donc le résultat de la vérification est le plus proche de ce que voit le client.
En pratique, cela se présente comme suit : vous prenez une liste de géos cibles (par exemple, Russie, Kazakhstan, Allemagne, Brésil, Inde), configurez un script ou un service de surveillance pour faire tourner les IP par pays et comparez les statuts HTTP et le contenu de la page. Si au moins dans une région la réponse diffère de la référence — c'est un signal de géo-blocage que le vérificateur d'uptime classique ne montrera jamais.
Vérification 2 : accessibilité depuis les opérateurs mobiles
Le deuxième point aveugle est le trafic mobile. De nombreuses plateformes publicitaires et systèmes anti-fraude (surtout sur Facebook Ads et TikTok Ads) appliquent des règles plus strictes précisément aux réseaux mobiles, car c'est de là que provient la majeure partie du trafic utilisateur « vivant ». Si le landing est bloqué par un opérateur spécifique (MTS, Beeline, MegaFon, T-Mobile, Vodafone) en raison de plaintes ou de filtrage automatique, la surveillance de bureau depuis un centre de données ne le montrera pas du tout — il n'y a tout simplement pas de notion d'« opérateur ».
Pour cette vérification, des proxies mobiles sont nécessaires, qui fournissent des IP de véritables réseaux 4G/5G des opérateurs. Les arbitragistes les utilisent non seulement pour créer des comptes, mais aussi pour contrôler l'accessibilité de leurs offres précisément dans le trafic mobile, car la majeure partie des clics sur les publicités Facebook Ads et TikTok Ads provient des téléphones.
Schéma pratique : configurez une vérification horaire de l'accessibilité du landing via des IP mobiles des 3-4 plus grands opérateurs dans votre géo cible. Si le code d'état change en 403 ou redirection précisément sur les proxies mobiles alors que la réponse reste inchangée sur les proxies de centre de données — vous avez trouvé un blocage que la surveillance classique ne montrera sous aucun paramètre.
Vérification 3 : blocage par fournisseur Internet spécifique
Il arrive qu'un site soit accessible dans le pays dans son ensemble, mais bloqué par un fournisseur spécifique en raison d'un filtrage DNS, d'une inscription dans un registre ou de règles locales. Cela est particulièrement pertinent pour la Russie et la CEI, où les blocages sont souvent appliqués de manière sélective : un opérateur filtre la ressource, un autre — non. La surveillance de l'uptime avec une IP de centre de données ne voit qu'un seul « chemin » vers le site et n'est pas capable de détecter une telle inégalité.
Pour combler cette vérification, il faut tester l'accessibilité via des proxies résidentiels de plusieurs fournisseurs dans une même région — par exemple, Rostelecom, MTS, Beeline pour la Russie. Si au moins un fournisseur montre un refus, tandis que les autres ouvrent la page normalement — c'est un blocage ponctuel au niveau DNS ou IP-filtre, qu'il faut contourner séparément, et non avec une solution de masse.
Pour les vendeurs sur Wildberries, Ozon et Avito, cela est particulièrement important : parfois, la fiche produit ou tout le compte personnel devient inaccessible précisément pour les utilisateurs d'un fournisseur en raison d'un problème technique du côté du marketplace, et le service client répond « tout fonctionne chez nous », car il vérifie depuis un autre canal de communication.
Vérification 4 : comportement des CDN et WAF (Cloudflare, Qrator)
Les systèmes de protection contre les DDoS et les filtres de bots, tels que Cloudflare, Qrator, StormWall, utilisent activement la réputation de l'adresse IP pour décider d'afficher un captcha ou de bloquer la requête. Les plages de centres de données AWS, Google Cloud et DigitalOcean sont bien connues de ces systèmes et reçoivent souvent un passage simplifié pour les bots de confiance (y compris la surveillance de l'uptime), car les fournisseurs de WAF maintiennent eux-mêmes des listes blanches pour de tels services.
Un utilisateur normal avec une IP résidentielle ou mobile n'a pas ce privilège et peut se heurter à un défi JS, un captcha ou un blocage temporaire si des règles de protection agressives sont configurées sur le site. Cela crée un paradoxe : plus le WAF fonctionne bien contre les bots, moins la surveillance de l'uptime voit la réalité, car elle utilise elle-même un trafic similaire à celui des bots avec des IP de confiance.
La vérification ici est simple — envoyez une requête au site via des proxies de centres de données et via des proxies résidentiels en parallèle, comparez les codes de réponse et la présence de la page de défi JS. Si l'IP de centre de données reçoit un 200 instantané, tandis que l'IP résidentielle obtient une page de vérification du navigateur, cela signifie que le WAF est configuré de telle manière que les utilisateurs réels perdent du temps ou abandonnent complètement à cette étape, et la surveillance standard ne montrera jamais cela.
Vérification 5 : rendu avec un véritable fingerprint dans un navigateur anti-détection
La dernière et la plus délicate vérification — ce n'est pas seulement l'IP, mais un véritable fingerprint numérique du navigateur : User-Agent, résolution d'écran, fuseau horaire, polices, rendu WebGL. De nombreux systèmes anti-fraude (surtout sur Facebook Ads, TikTok Ads et services bancaires) prennent des décisions de blocage basées sur une combinaison d'IP et de fingerprint, et non sur un seul paramètre. Une simple requête HTTP depuis un script de surveillance ne reproduit pas cette combinaison, donc ne voit pas les blocages qui ne se déclenchent que dans un navigateur avec un véritable rendu de page.
Pour cette vérification, un véritable navigateur anti-détection est nécessaire — Dolphin Anty, AdsPower, Multilogin, GoLogin ou Octo Browser — configuré sur une IP résidentielle ou mobile de la région cible. Vous créez un profil avec un fingerprint réaliste, connectez le proxy et ouvrez le site comme le ferait un visiteur normal. Si la page se charge normalement via une requête HTTP classique, mais montre un blocage ou une redirection dans le navigateur anti-détection avec une IP résidentielle — le problème réside précisément dans la combinaison du fingerprint et de l'anti-fraude, et il doit être résolu au niveau du compte publicitaire ou de la protection du site, et non de l'hébergement.
Comment configurer la surveillance avec des IP résidentielles et mobiles
Pour combler toutes les cinq zones aveugles, il n'est pas nécessaire d'écrire un code complexe — il suffit d'un schéma étape par étape que vous pouvez répéter dans n'importe quel service de surveillance ou même manuellement avec un petit nombre de vérifications.
Étape 1. Déterminez la liste des géos et fournisseurs critiques — généralement, ce sont 3-5 pays où vous avez le principal trafic ou publicité, et 2-3 des plus grands opérateurs mobiles dans chacun.
Étape 2. Connectez un pool de proxies résidentiels et mobiles avec rotation par les pays nécessaires. Pour une surveillance automatique régulière, des proxies résidentiels liés à une ville ou un opérateur spécifique conviennent — cela permet de répéter la vérification depuis le même point et de voir la dynamique, et non un instantané unique.
Étape 3. Configurez un script ou un service prêt (tâche cron, Zapier, votre propre surveillance basée sur curl ou requests) pour que la requête au site soit envoyée successivement via chaque proxy du pool, avec un intervalle de 15 à 30 minutes. Enregistrez le code HTTP, le temps de réponse et, si possible, une capture d'écran de la page pour une vérification visuelle.
Étape 4. Pour vérifier les blocages dépendants du fingerprint, ajoutez une couche distincte — ouverture de la page dans un navigateur anti-détection selon un calendrier, au moins une fois par jour pour chaque géo critique. Cela peut être automatisé via les API intégrées de Dolphin Anty ou AdsPower, qui permettent de lancer des profils selon un calendrier sans intervention humaine constante.
Étape 5. Configurez des alertes non seulement pour les HTTP 5xx, mais aussi pour les changements de contenu de la page (par exemple, l'apparition des mots « non disponible », « blocage », « région restreinte ») et pour l'augmentation du temps de réponse, qui signale souvent un défi JS de la part du WAF.
Cas réels : arbitrage, e-commerce, SMM
Un arbitragiste lance une campagne dans Facebook Ads sur un landing qui est hébergé sur un VPS classique. Le vérificateur d'uptime standard montre une disponibilité de 100 %, mais le CTR de la publicité chute brusquement dans un géo. La vérification via des proxies mobiles de cette région montre que Facebook bloque précisément le trafic mobile sur cette plage d'IP d'hébergement — les utilisateurs de bureau voient la page, tandis que l'audience principale sur les téléphones reçoit un message d'erreur. La solution consiste à transférer le landing sur une autre plage d'IP et à contrôler en permanence via des proxies mobiles des opérateurs cibles.
Un vendeur sur Wildberries configure la surveillance de son compte personnel et des fiches produits pour détecter à temps les pannes techniques. Un vérificateur d'uptime classique depuis un centre de données montre que le site fonctionne, mais les acheteurs de plusieurs régions rapportent que la fiche produit ne s'ouvre pas. La vérification via des proxies résidentiels de différentes villes montre que le problème se situe au niveau d'un nœud CDN spécifique, qui ne dessert qu'une partie du pays — après le passage à un nœud de secours, le problème disparaît.
Une agence SMM gère la publicité d'un client dans TikTok Ads sur un landing avec un formulaire de demande. Le formulaire fonctionne techniquement, le code HTTP 200 est stable pour la surveillance classique. Lors de la vérification dans le navigateur anti-détection Dolphin Anty avec une IP résidentielle du pays cible, le formulaire ne s'envoie pas — l'anti-fraude de TikTok le considère comme un bot en raison de l'incompatibilité du fingerprint avec le modèle d'appareil attendu. Après avoir configuré les paramètres corrects du profil et une nouvelle vérification avec une véritable IP mobile, le formulaire commence à accepter les demandes sans erreurs.
Tableau : quel type d'IP pour quelle vérification
| Type de vérification | Type d'IP recommandé | Ce que cela montre |
|---|---|---|
| Géo-blocages par pays | Proxies résidentiels | Accessibilité dans une région spécifique, comme un utilisateur réel |
| Blocages des réseaux mobiles | Proxies mobiles | Accessibilité pour l'audience Facebook Ads / TikTok Ads sur téléphones |
| Filtrage par fournisseur spécifique | Proxies résidentiels liés à l'ASN du fournisseur | Blocages DNS ponctuels chez certains opérateurs |
| Comportement CDN/WAF | Comparaison des IP de centres de données et résidentielles | Différence de réaction de la protection au trafic de confiance et normal |
| Blocages de fingerprint | IP résidentielle/mobiles + navigateur anti-détection | Réaction de l'anti-fraude à la combinaison d'IP et de fingerprint numérique |
Liste de contrôle avant le lancement de la surveillance
Avant de considérer la surveillance comme fiable, passez en revue cette liste :
- La vérification est lancée depuis au moins 3-5 pays de l'audience cible, et non seulement depuis le point de localisation du service de surveillance.
- Il y a une couche distincte de vérification via des IP mobiles d'au moins deux opérateurs dans chaque géo clé.
- L'accessibilité a été testée via des proxies résidentiels de différents fournisseurs dans un même pays.
- Une comparaison de la réponse entre l'IP de centre de données et l'IP résidentielle a été effectuée pour évaluer le comportement du WAF/CDN.
- Au moins une fois par jour, une vérification est effectuée via un navigateur anti-détection avec un fingerprint réaliste.
- Les alertes sont configurées non seulement pour le code de réponse, mais aussi pour les changements de contenu et le temps de chargement de la page.
- Les résultats des vérifications sont enregistrés avec des liens vers le pays, l'opérateur et le type d'IP pour une analyse ultérieure.
Conclusion
La surveillance classique de l'uptime résout une tâche étroite — elle vérifie si le serveur répond. Mais elle ne répond pas à la question principale des affaires : un utilisateur réel du pays souhaité, avec l'opérateur souhaité et l'appareil souhaité voit-il exactement ce qu'il doit voir. Cinq vérifications — par géo, par réseaux mobiles, par fournisseur spécifique, par comportement du CDN/WAF et par fingerprint dans un navigateur anti-détection — comblent cette lacune et montrent une image aussi proche que possible de la réalité.
Si vous lancez des publicités via Facebook Ads, TikTok Ads ou Google Ads, gérez des fiches sur Wildberries et Ozon ou souhaitez simplement voir le site tel que le voient les clients dans différents pays, il vaut la peine d'ajouter aux vérifications classiques via des proxies résidentiels pour des tests géographiques et des proxies mobiles pour contrôler l'accessibilité dans les réseaux mobiles. Cela ne remplace pas le vérificateur d'uptime standard, mais comble sa zone aveugle — et permet de découvrir un blocage avant que les clients n'en parlent.