CGNAT et les proxys mobiles : pourquoi le ban par IP ne fonctionne pas

Depuis un an et demi, la protection des sites repose sur une hypothèse : une adresse IP équivaut à une entité unique qui peut être punie. Les ingénieurs de Cloudflare ont mesuré à quel point cette hypothèse est rompue et ont publié des chiffres. Le principal d'entre eux est inattendu : les adresses derrière lesquelles se cachent des centaines de personnes réelles subissent des limitations de vitesse trois fois plus souvent que les autres. Nous allons examiner ce qu'est le CGNAT, pourquoi les proxys mobiles sont plus résilients que les autres — et pourquoi l'effet de foule n'est plus une indulgence.

Pourquoi « simplement bloquer l'IP » n'est plus une solution bon marché

Tout mécanisme de protection contre l'automatisation — liste noire, limitation de débit, détecteur d'anomalies — part du principe qu'il y a un répondant identifiable derrière l'adresse. Si l'adresse est bloquée, le contrevenant est puni. Le coût d'une erreur est considéré comme nul : après tout, un bot n'a pas pu passer.

Cette arithmétique est valable tant qu'il y a réellement un seul utilisateur derrière l'adresse. Pour une IP de centre de données, c'est le cas : une adresse — une entité louée, le bannissement ne coûte rien au site. Pour un fournisseur d'accès domestique, c'est un ménage, presque rien non plus. Mais pour un opérateur mobile, une seule adresse publique peut desservir tout un quartier. Et là, le bannissement devient soudainement une opération coûteuse : en bloquant le scraper, le site déconnecte des centaines de clients réels qui n'ont rien fait de mal.

C'est cette asymétrie de coût — et non pas la « magie des IP mobiles » — qui détermine qui est durement banni et qui est épargné. Et cela a un nom technique précis.

Qu'est-ce que le CGNAT et pourquoi est-il omniprésent chez les opérateurs

CGNAT (Carrier-Grade NAT, aussi appelé LSN — Large Scale NAT) est une traduction d'adresses au niveau de l'opérateur, et non du routeur domestique. Formulée, la base est documentée dans RFC 6598 (avril 2012) : un bloc d'adresses 100.64.0.0/10 a été réservé pour les traducteurs opérateurs — 4 194 304 adresses qui ne sont pas routables sur le réseau mondial et ne doivent pas franchir la frontière du réseau du fournisseur.

La motivation dans le texte de la RFC est formulée clairement : l'espace d'adresses IPv4 est presque épuisé, mais les fournisseurs doivent soutenir la croissance des clients IPv4 jusqu'à ce qu'IPv6 soit entièrement déployé. Le bloc /10 a été choisi comme la taille minimale permettant de déployer le CGN de manière régionale, sans construire des traducteurs imbriqués.

Chez les opérateurs mobiles, la pénurie d'adresses est la plus aiguë : des millions d'abonnés, des dizaines de milliers d'IPv4 publiques. Ainsi, le CGNAT n'est pas une option, mais la norme par défaut. Une seule adresse publique dessert des centaines, et pendant les heures de pointe, des milliers de sessions, et l'adresse de l'abonné change constamment — lors du passage entre les antennes, lors de la reconnexion de la session, lors de la gestion de la bande passante.

C'est de là que provient toute la valeur pratique des proxys mobiles : vous n'obtenez pas une IP « propre », vous obtenez une adresse que le site ne peut pas désactiver sans causer de dommages collatéraux.

Qu'est-ce que Cloudflare a mesuré exactement

Dans l'étude « One IP address, many users: detecting CGNAT to reduce collateral effects » (Vasilis Giotsas et Marwan Fayad, publiée le 29 octobre 2025, mise à jour le 15 juillet 2026), Cloudflare aborde la tâche inverse : apprendre à distinguer les adresses derrière la traduction opérateur, afin d'appliquer des mesures plus douces.

La méthodologie est constituée de plusieurs sources indépendantes :

Traceroutes distribués de plus de 9000 nœuds RIPE Atlas — pour capturer les adresses du bloc 100.64.0.0/10 en chemin ;
Enregistrements WHOIS et PTR — recherche de marqueurs cgnat, cgn, lsn dans les noms et descriptions ;
Catalogues publics d'anonymiseurs — pour collecter des adresses VPN et proxy ;
Modèle XGBoost basé sur les signaux clients, le comportement au niveau de transport, le volume de trafic et la diversité des directions, avec agrégation à la fois par IP individuelle et par sous-réseau /24.

Taille de l'échantillon d'apprentissage : 200 000 adresses CGNAT, 180 000 adresses VPN et proxy, 900 000 adresses ordinaires, répartition 70/30, validation croisée dix fois. La qualité déclarée — précision 0,98, F1 pondéré 0,97, perte logarithmique 0,04, macro-AUC 0,9946.

Un détail séparé, dont on parle peu dans l'industrie : le ratio du nombre d'agents utilisateurs par rapport au nombre d'adresses est nettement plus élevé en Afrique que dans d'autres régions. La répartition historique des grands blocs IPv4 a été attribuée à l'Amérique du Nord et à l'Europe il y a des décennies — et aujourd'hui, cela se traduit par le fait que les utilisateurs des régions en développement sont plus souvent soumis à des punitions collectives. Cloudflare appelle cela un biais socio-économique.

Le chiffre clé : limitation de débit trois fois plus fréquente

Le résultat clé de l'étude semble contre-intuitif pour tous ceux qui ont l'habitude de considérer l'IP mobile comme « intouchable » : les utilisateurs derrière le CGNAT rencontrent des limitations de vitesse trois fois plus souvent que les utilisateurs en dehors du CGNAT.

Il n'y a pas de contradiction ici — il s'agit d'une séparation des mesures par coût. Le bannissement strict d'une adresse est coûteux, car il touche des abonnés réels. En revanche, la limitation de débit, les défis et les CAPTCHA sont peu coûteux et réversibles. Ainsi, la protection ne désactive pas une telle adresse, elle la étouffe. De plus, le mécanisme se déclenche plus souvent pour une raison arithmétique : sur une adresse partagée, le trafic de nombreuses personnes indépendantes s'additionne, et les seuils sont atteints plus rapidement.

Une deuxième paire de chiffres explique pourquoi les sites sont prêts à tolérer de telles adresses. La part de bots sur les adresses CGNAT : médiane 4,8 % contre 4,7 % pour les autres — donc, en médiane, il n'y a pratiquement pas de différence. Cependant, en moyenne, la situation se renverse : 7 % pour CGNAT contre 13,1 % pour non-CGNAT. Cela se lit ainsi : parmi les adresses ordinaires, il existe une longue traîne presque entièrement automatisée — un bloc typique de centre de données, où il n'y a pas de personnes réelles, et cela tire la moyenne vers le haut. Derrière la traduction opérateur, une telle traîne ne peut pas exister : il y a toujours des abonnés réels qui diluent toute automatisation.

Pour le praticien, la conclusion est directe : le proxy mobile est acheté non pas pour la vitesse, mais pour la résilience. La bande passante par adresse est généralement moins bonne que celle d'un centre de données — mais l'adresse ne s'épuise pas définitivement après la première erreur.

Mauvaise nouvelle : CGNAT et proxys ont appris à se distinguer

La conclusion séduisante « puisque derrière une adresse commune se trouvent de nombreuses personnes, je vais me faire passer pour une adresse commune » se heurte à la formulation du problème dans l'étude elle-même. Notez la composition de l'échantillon : les adresses CGNAT et les adresses VPN/proxy sont deux classes différentes, et le modèle a été formé pour les distinguer, et non pour les regrouper dans une seule catégorie « de nombreux utilisateurs derrière une IP ».

Elles se distinguent par des caractéristiques que le locataire de l'adresse ne contrôle pas :

Topologie. La traduction opérateur est visible sur le chemin et dans les enregistrements de service — par le bloc 100.64.0.0/10, par PTR et WHOIS.
Variété des directions. Un véritable quartier de la ville interagit avec des milliers de services différents ; un nœud sous scraping — avec des dizaines, souvent avec un seul.
Profil par sous-réseau. L'agrégation par /24 montre si le bloc d'adresses voisin se comporte comme un abonné ou comme un pool loué.
Signaux clients. L'ensemble des appareils derrière une adresse commune doit ressembler à une véritable population, et non à une seule et même pile reproduite cent fois.

Et ce n'est pas exclusif à Cloudflare : les fournisseurs de renseignement IP ont longtemps cessé de donner un simple drapeau binaire « proxy ou non », mais fournissent une évaluation numérique — et la distinction entre « adresse abonnée commune » et « pool loué » y est déjà intégrée.

Trois conclusions pratiques

Réduisez la charge sur l'adresse, au lieu d'augmenter la parallélisation. Puisqu'une adresse commune est par définition plus proche du seuil de limitation de débit, la stratégie « tirer le maximum de RPS d'une seule IP » échoue plus rapidement. Étalez la tâche dans le temps et répartissez-la entre les adresses, plutôt que de la diviser en flux au sein d'une seule.
Préservez la session. La résilience d'une adresse est une ressource que vous perdez en changeant agressivement d'IP : chaque nouvelle adresse doit passer à nouveau par une vérification de confiance. Pour les tâches nécessitant une authentification et un panier, une session collante est presque toujours plus avantageuse que la rotation — où se situe la limite, a été discuté dans le guide sur les sessions collantes.
Comptez non pas les adresses, mais les réponses réussies. Le pool de centres de données est moins cher par adresse et presque toujours plus cher par requête réussie là où une protection sérieuse est en place. Comparer les types n'a de sens qu'en fonction du coût du résultat : les adresses résidentielles et mobiles sont rentables là où les adresses de centres de données n'atteignent pas la réponse.

Où l'effet de foule ne sauve pas du tout

Il est important de ne pas étendre la logique au-delà de ses limites. La protection contre les punitions collectives n'agit qu'au niveau de l'adresse réseau. Dès que la plateforme passe à d'autres identifiants, l'avantage disparaît :

Blocage de compte. Si l'action est liée à un compte, la qualité de l'IP n'a aucune incidence sur la décision.
Empreinte de l'appareil et du navigateur. La cohérence de la pile est vérifiée indépendamment de l'adresse — et elle se dégrade généralement avant que le filtre IP ne s'active.
Liaison des comptes. Les plateformes recherchent des intersections par sous-réseaux et des correspondances comportementales, et pas seulement par adresse exacte.

Un facteur distinct de l'année 2026 — l'offre. En un mois, le marché a subi deux coups sur les sources d'adresses résidentielles : en juillet, LG a annoncé l'interdiction des SDK de proxy, découvrant qu'environ 42 % des applications de son magasin entraînaient les téléviseurs dans un réseau proxy, et le 3 août 2026, Samsung a mis en place une interdiction de plateforme sur les SDK de proxy résidentiels et a déjà restreint l'enregistrement de nouvelles applications avec cette fonctionnalité. La découverte a été rapportée par Harrison Sand de la société norvégienne Mnemonic ; certaines applications ont déclaré avoir été installées sur des centaines de millions de téléviseurs. Une analyse détaillée de la première vague se trouve dans l'article sur l'interdiction des SDK de proxy sur les téléviseurs LG. Moins de sources d'IP résidentielles — prix plus élevé, et plus la différence entre une adresse bon marché et une adresse qui atteint réellement la réponse est marquée.

Conclusion

Le CGNAT a brisé l'hypothèse la plus basique de la protection web — « une adresse équivaut à un répondant » — et la protection l'a reconnu et quantifié. Mais cette reconnaissance ne s'est pas traduite par une amnistie, mais par une restructuration des mesures : les adresses derrière la traduction opérateur sont moins souvent désactivées définitivement et sont trois fois plus souvent étouffées par des limites, et leur distinction par rapport aux pools de proxy a été intégrée dans une tâche de classification distincte.

Le sens pratique pour ceux qui travaillent avec des proxys est simple : le type d'adresse ne détermine pas si vous allez passer ou non, mais à quel prix le site peut vous arrêter. Adaptez votre travail aux mesures douces — rythme modéré, longues sessions, calcul honnête du coût d'une requête réussie — et choisissez le type d'IP en fonction du coût de l'erreur, et non du coût du gigaoctet.