Si la conversion du trafic mobile a soudainement chuté et que le formulaire d'inscription ou de paiement renvoie une erreur 403 pour de vrais clients, ce n'est probablement pas un hacker, mais votre propre WAF qui est en cause. Le pare-feu voit des milliers de requêtes provenant d'une seule adresse IP d'un opérateur mobile et interprète cela comme une attaque DDoS ou un bruteforce. En réalité, derrière cette IP se cachent des centaines ou des milliers de personnes ordinaires — c'est la technologie CGNAT. Nous allons voir comment détecter et corriger ce problème sans ouvrir de brèche pour de véritables attaques.
Qu'est-ce que CGNAT et pourquoi cela pose problème
CGNAT (Carrier-Grade NAT) est une technologie utilisée par les opérateurs mobiles en raison de la pénurie d'adresses IPv4. Au lieu d'attribuer une adresse IP publique unique à chaque abonné, l'opérateur "cache" des milliers d'utilisateurs derrière une ou plusieurs adresses communes. Pour un site, cela se traduit par un trafic provenant d'une seule IP, mais de centaines de personnes différentes en même temps — différents appareils, différents navigateurs, différents comportements, mais la même adresse externe.
Pour un serveur web ordinaire, ce n'est pas un problème — il traite simplement les requêtes. Mais pour les systèmes de protection qui comptent les requêtes par unité de temps à partir d'une seule IP, cela apparaît comme une anomalie. Imaginez : en une minute, 200 requêtes pour la page de connexion proviennent d'une seule adresse. Pour le WAF, c'est un modèle classique de bruteforce ou de scraping. En réalité, cela pourrait être 150 clients réels d'un opérateur mobile dans votre région qui ont simplement ouvert le site en même temps après une campagne publicitaire ou une publication sur les réseaux sociaux.
Le problème est particulièrement aigu dans les pays avec une forte densité d'internet mobile — les opérateurs regroupent un grand nombre d'abonnés derrière un nombre minimal d'adresses IP externes. C'est pourquoi il est nécessaire de tester le comportement du site non pas avec une IP de centre de données ordinaire, mais précisément avec des proxies mobiles, qui passent réellement par l'infrastructure CGNAT de l'opérateur — c'est le seul moyen de reproduire la même image que voit le WAF chez les utilisateurs réels.
Pourquoi le WAF considère CGNAT comme une menace
La plupart des solutions WAF — Cloudflare, AWS WAF, Imperva, modules intégrés Nginx/ModSecurity — utilisent la limitation de débit par adresse IP comme mécanisme de base pour se protéger contre les bots et les DDoS. La logique est simple : si plus de N requêtes proviennent d'une seule IP en T secondes — nous bloquons ou affichons un captcha. Cette règle fonctionne parfaitement pour les attaques classiques d'un seul appareil, mais échoue complètement avec le trafic CGNAT.
Il existe plusieurs scénarios typiques où cela se produit :
- Limitation de débit par IP. La limite "100 requêtes par minute à partir d'une IP" est normale pour le trafic de centre de données, mais catastrophique pour une région mobile avec un million d'abonnés derrière une seule adresse.
- Scoring comportemental. Si le système accumule une "réputation" d'IP sur la base de l'historique des requêtes, un seul utilisateur "malveillant" derrière CGNAT peut ruiner la réputation de l'adresse pour des milliers de clients honnêtes suivants.
- Heuristique géographique. Le WAF marque parfois une IP comme suspecte s'il observe des pics d'activité inhabituels pour un "utilisateur normal" — et le comportement d'une adresse CGNAT est exactement cela : des charges de pointe aux heures d'activité du public.
- Blocage par ASN de l'opérateur. Certaines règles WAF bloquent des plages entières d'ASN d'opérateurs mobiles si des attaques ont précédemment eu lieu à partir de ces plages — tous les clients de l'opérateur dans le pays sont alors touchés.
En résumé : plus le WAF est configuré strictement "par défaut", plus il y a de chances qu'il bloque non pas des bots, mais votre véritable audience mobile — surtout si votre entreprise est orientée vers des pays avec un internet mobile développé et une forte part de trafic CGNAT.
Quelles en sont les conséquences pour les entreprises : clients et revenus perdus
Le problème des blocages CGNAT est rarement visible dans l'analyse standard. Google Analytics et Yandex.Metrica ne détectent tout simplement pas ceux qui reçoivent une erreur 403 au niveau du WAF — ces visites n'atteignent souvent même pas le compteur. En conséquence, le marketeur voit une chute de la conversion, mais ne comprend pas la raison et commence à optimiser les créatifs et les pages d'atterrissage, alors que le problème réside dans l'infrastructure.
Les conséquences réelles pour différents segments d'activité :
- E-commerce. Un acheteur sur mobile ne peut pas finaliser sa commande — le formulaire de paiement renvoie une erreur, le panier est perdu. Pertes directes de revenus, particulièrement visibles après le lancement de publicités sur TikTok Ads ou Facebook Ads, où le trafic principal est mobile.
- SaaS et inscriptions. L'utilisateur essaie de s'inscrire ou de se connecter à son compte, reçoit un captcha à chaque étape ou est bloqué — il part chez un concurrent.
- Contenu et publicité. Le trafic publicitaire provenant des appareils mobiles "s'effondre" massivement sur la page d'atterrissage, le budget publicitaire est dépensé, mais il n'y a pas de conversions — les algorithmes des plateformes publicitaires interprètent cela comme une faible qualité d'audience et augmentent le coût par clic.
- Service client. Le nombre de demandes "votre site ne s'ouvre pas", "je ne peux pas m'inscrire" augmente — et le support technique ne voit pas le problème, car il accède lui-même au site depuis un bureau via le Wi-Fi sans CGNAT.
Le plus désagréable est que ces blocages sont difficiles à diagnostiquer a posteriori, car le journal du WAF montre une seule IP "suspecte" avec un nombre énorme de requêtes, et l'administrateur voit cela comme une confirmation de la validité du blocage, et non comme un faux positif.
6 vérifications avec des IP mobiles pour identifier le problème
Pour comprendre si votre WAF bloque des clients mobiles honnêtes, il est nécessaire de reproduire les conditions réelles de CGNAT — c'est-à-dire de tester le site avec de vraies IP mobiles de différents opérateurs et régions. Voici une liste de contrôle pratique de 6 vérifications.
Vérification 1 : Accès massif depuis une seule IP mobile
Configurez plusieurs sessions parallèles via la même IP mobile (ce qui est naturel pour les proxies avec CGNAT de l'opérateur) et effectuez 50 à 100 actions ordinaires — ouverture de pages, ajout au panier, navigation entre les sections. Si après un certain seuil un captcha ou une erreur 403 apparaît — c'est le premier signal d'un problème.
Vérification 2 : Changement de User-Agent avec une seule IP
Une adresse CGNAT dessert différents appareils — iPhone, Android, différents navigateurs. Lancez des requêtes avec différentes chaînes User-Agent via une seule IP et vérifiez si la règle WAF "variabilité suspecte des appareils à partir d'une adresse" s'active.
Vérification 3 : Test sur des formulaires critiques
Parcourez le parcours complet du client — inscription, authentification, finalisation de commande, paiement — précisément via l'IP mobile de l'opérateur. Souvent, le WAF est configuré de manière plus agressive sur les formulaires de saisie de données (identifiant, paiement), où le risque de bruteforce est plus élevé, et c'est le premier endroit où de vrais clients se perdent.
Vérification 4 : Test avec différents opérateurs et régions
Le comportement de CGNAT varie selon les opérateurs et les pays — parfois, 50 abonnés se cachent derrière une seule IP, parfois 5000. Testez le site avec des IP mobiles de plusieurs opérateurs dans des zones géographiques clés pour votre entreprise afin de comprendre s'il existe des spécificités régionales de blocage.
Vérification 5 : Analyse de la réponse du serveur par codes et en-têtes
Enregistrez non seulement le fait du blocage, mais aussi le code HTTP exact et les en-têtes de réponse (par exemple, cf-mitigated: challenge chez Cloudflare). Cela aidera à comprendre quel mécanisme de protection a été déclenché — limitation de débit, détection de bot ou règle géographique.
Vérification 6 : Surveillance à long terme de la réputation de l'IP
Répétez le test avec la même IP mobile pendant plusieurs jours. Si l'accès se dégrade avec le temps sans raisons visibles de votre part — cela signifie que le système de scoring cumulatif "ruine" la réputation de l'adresse en raison de l'activité d'autres abonnés derrière le même CGNAT, et c'est un problème systémique, pas ponctuel.
Il est important de comprendre :
Pour de tels tests, il faut des IP mobiles réelles, et non des adresses de centres de données ou résidentielles ordinaires — seul le trafic ayant traversé l'infrastructure de l'opérateur reproduit fidèlement le modèle CGNAT que votre WAF voit chez les utilisateurs réels.
Comment configurer le WAF pour ne pas bloquer les clients honnêtes
Après le diagnostic, il est nécessaire d'ajuster les règles de protection afin de ne pas perdre le niveau de sécurité, mais de cesser de bloquer les utilisateurs mobiles réels. Voici les principales approches.
| Problème | Solution dans le WAF |
|---|---|
| Limitation stricte de débit par IP | Augmenter la limite pour les ASN connus des opérateurs mobiles ou passer à une limitation par session/cookie au lieu d'une simple IP |
| Scoring cumulatif de la réputation de l'IP | Réduire le temps de "mémoire" de la réputation pour les plages CGNAT, ajouter une liste blanche pour les ASN connus des opérateurs |
| Blocage par géo/ASN dans son ensemble | Remplacer le blocage total par un challenge doux (vérification JS) au lieu d'un 403 |
| Captcha stricte sur les formulaires de connexion | Activer le captcha de manière adaptative — uniquement en cas de signes réels de bruteforce (multiples tentatives infructueuses à partir d'un même compte), et non en raison de l'IP CGNAT |
Une bonne pratique consiste à tenir une liste de plages connues des opérateurs mobiles dans vos zones géographiques clés et à leur appliquer des règles distinctes, plus douces par rapport au trafic internet ordinaire. Cela nécessite du temps pour la configuration, mais réduit radicalement le nombre de faux blocages.
Outils pour tester avec des proxies mobiles
Pour un audit régulier de la protection du site, il est pratique d'utiliser une combinaison d'un navigateur anti-détection et de proxies mobiles. Les navigateurs anti-détection (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) permettent de créer des profils isolés avec différentes empreintes d'appareil, tandis que les proxies mobiles fournissent un véritable trafic CGNAT des opérateurs.
Voici une approche étape par étape pour le test :
- Créez plusieurs profils dans le navigateur anti-détection avec différents paramètres d'appareil (User-Agent différent, résolution d'écran, fuseau horaire).
- Connectez à chaque profil des proxies mobiles de la région et de l'opérateur souhaités — cela donnera un comportement réel de CGNAT.
- Parcourez les scénarios utilisateurs clés : inscription, connexion, ajout au panier, paiement.
- Enregistrez tous les cas de captcha, 403 et autres blocages, et comparez-les avec les réglages du WAF.
- Répétez le test avec des proxies résidentiels pour comparaison — cela aidera à comprendre si le problème est spécifique au trafic mobile.
Pour des tests parallèles dans différentes zones géographiques, des proxies résidentiels sont également utiles — ils aident à évaluer à quel point le WAF est agressif pour le trafic internet domestique ordinaire et le CGNAT mobile. Si vous prévoyez des tests de charge à partir d'une infrastructure serveur sans lien avec un opérateur, pour des vérifications de contrôle sans effet CGNAT, vous pouvez connecter des proxies de centres de données — ils fourniront une ligne de base propre sans distorsions propres aux réseaux mobiles.
Cette approche complète — IP mobiles, résidentiels et de centres de données dans un même test — donne une image complète : vous voyez exactement où la protection s'active et pour quel type de trafic, au lieu de deviner à partir d'indices indirects dans les journaux.
Questions fréquentes
Peut-on complètement exclure les plages CGNAT des règles WAF ?
Ce n'est pas recommandé — cela réduira la protection contre de réelles attaques, qui peuvent également passer par des réseaux mobiles. Il est préférable d'assouplir les seuils et de passer à un challenge doux au lieu d'un blocage strict.
À quelle fréquence faut-il effectuer de telles vérifications ?
Au minimum une fois par mois et impérativement après toute modification des règles WAF ou le lancement d'une nouvelle campagne publicitaire ciblant le public mobile.
Est-ce que cela affecte le SEO ?
Oui — si des bots de recherche ou de vrais utilisateurs sur des appareils mobiles reçoivent un 403, cela augmente le taux de rebond et peut avoir un impact négatif sur les métriques comportementales de classement.
Conclusion
CGNAT n'est pas une menace, mais une caractéristique de l'internet mobile à laquelle presque toute entreprise avec une audience mobile est confrontée. Le problème ne réside pas dans la technologie elle-même, mais dans le fait que les réglages standards du WAF ne tiennent pas compte de sa spécificité et punissent les utilisateurs honnêtes pour un comportement qui est propre aux réseaux mobiles ordinaires. Les six vérifications de cet article aideront à diagnostiquer rapidement si vous perdez des clients à cause de faux blocages, et un réglage ciblé des règles WAF permettra de restaurer la conversion sans diminuer le niveau de protection.
Si vous prévoyez de tester régulièrement le comportement du site et des entonnoirs publicitaires comme le voient de vrais clients mobiles, nous vous recommandons d'utiliser des proxies mobiles — ils fournissent un véritable trafic CGNAT des opérateurs et permettent de détecter les faux blocages avant que vos clients ne les rencontrent.