Vous avez tout fait correctement. Vous avez extrait les adresses IP suspectes de vos termes de recherche et de vos données d’analytics, les avez ajoutées à votre liste d’exclusion, vous vous êtes peut-être même heurté au plafond de 500 adresses de Google, et les clics sans valeur et les faux leads ont continué d’arriver. Ce n’est pas une erreur de votre part. La raison a un nom : les proxys résidentiels. Ils font passer la fraude au clic par de vraies adresses IP domestiques attribuées par des FAI, identiques à celles de vos meilleurs clients, ce qui signifie qu’une liste de blocage statique ne peut pas les voir. Le blocage d’IP reste nécessaire, mais il ne traite plus qu’environ la moitié du problème. Ce guide explique le mécanisme, pourquoi les listes de blocage sont structurellement dépassées et ce qu’apportent en plus la détection des appareils et la détection comportementale.
La liste de blocage créée le mois dernier est déjà obsolète
Deux faits de 2026 cadrent tout le problème. D’abord, le trafic automatisé représente désormais 53 % de tout le trafic web, contre 47 % pour les humains, selon le Bad Bot Report 2026 d’Imperva. Ensuite, une part importante et croissante de ce trafic malveillant ne vient plus de centres de données que vous pouvez reconnaître et bloquer ; elle vient de connexions résidentielles qui ressemblent exactement à de vrais utilisateurs.
La leçon honnête que la plupart des annonceurs apprennent à leurs dépens : une liste d’IP malveillantes est l’instantané d’une cible qui a déjà bougé. Le temps que vous identifiiez et excluiez une adresse, le fraudeur en utilise déjà une autre. La solution n’est pas une liste plus longue ; c’est une autre couche de détection.
Ce qu’est réellement un proxy résidentiel
Un proxy résidentiel fait passer le trafic par la connexion Internet d’un vrai particulier. L’IP de sortie appartient à un foyer ou à une petite entreprise disposant d’une ligne haut débit ou mobile ordinaire, et non à un hébergeur. Les opérateurs construisent ces réseaux en intégrant des SDK dans des applications mobiles gratuites, des extensions de navigateur et des VPN « gratuits » qui revendent discrètement la bande passante de l’utilisateur, souvent sans consentement réel.
Ce détail change tout. Lorsqu’un clic frauduleux sort d’un proxy résidentiel, il arrive avec la réputation IP de confiance d’une vraie connexion domestique. Il n’apparaît sur aucune liste de blocage de centres de données, puisqu’il ne vient pas d’un centre de données. Et le bloquer purement et simplement est dangereux : derrière cette même plage d’IP se trouvent de vrais clients que vous voulez conserver. Le trafic de centres de données et de VPN est relativement facile à évaluer ; le trafic de proxys résidentiels est conçu précisément pour déjouer les contrôles qui l’attrapent.
La preuve de 2026 : le démantèlement d’IPIDEA par Google
Ce n’est pas théorique. Le 29 janvier 2026, le Threat Intelligence Group de Google a annoncé avoir perturbé IPIDEA, l’un des plus grands réseaux de proxys résidentiels au monde. L’ampleur est le sujet : le réseau était alimenté par des SDK cachés dans plus de 600 applications Android, reposait sur environ 7 400 serveurs et plus de 3 000 empreintes de fichiers Windows uniques, et était commercialisé sous 13 marques de proxy et de VPN présentées comme indépendantes. Sur une seule période de sept jours ce mois-là, Google a observé plus de 550 groupes malveillants distincts utilisant des nœuds de sortie d’IPIDEA.
L’explication de Google lui-même sur la difficulté à stopper ce trafic sonne comme un réquisitoire contre le blocage d’IP : « En faisant transiter le trafic par une multitude d’appareils grand public dans le monde entier, les attaquants peuvent masquer leur activité malveillante en détournant ces adresses IP. » Les chevauchements entre nœuds de sortie rendent l’attribution elle-même difficile.
Et c’est cette part de trafic malveillant issue des FAI résidentiels que les chercheurs indépendants ne cessent de mesurer : Imperva attribuait environ un quart du trafic de bots malveillants à des FAI résidentiels dans son rapport 2024, et a constaté que 21 % des attaques de bots utilisaient des proxys résidentiels en 2025. Même après un démantèlement de la taille d’IPIDEA, le réservoir restant est trop vaste (et trop impossible à distinguer de vrais utilisateurs) pour qu’une liste d’exclusion statique puisse suivre.
Pourquoi les listes de blocage statiques sont structurellement dépassées
Il y a trois raisons concrètes pour lesquelles une liste d’IP ne peut pas gagner ce combat :
- La rotation. Les réseaux de proxys résidentiels font tourner des millions d’IP de sortie distinctes. Une défense qui fonctionne en énumérant les mauvaises adresses joue une partie qu’elle ne peut mathématiquement pas terminer.
- Les plafonds stricts de Google. Google Ads vous permet d’exclure jusqu’à 500 adresses IP par campagne et vous oblige à lister chaque version d’une adresse (IPv4 et IPv6). Cinq cents emplacements face à des millions d’IP en rotation, ce n’est pas un combat.
- Les lacunes de couverture. Selon la même documentation de Google, les exclusions d’IP au niveau de la campagne « ne sont pas disponibles pour les campagnes vidéo, les campagnes d’hôtels, les campagnes App, les campagnes Performance Max et les campagnes Display intelligentes ». Les exclusions au niveau du compte atteignent bien Performance Max, mais elles restent soumises à la même limite par campagne et au même problème de rotation.
Fait notable, le filtrage du trafic non valide de Google cite explicitement le trafic de centres de données comme une catégorie qu’il contrôle. Les proxys résidentiels existent précisément pour que le trafic n’y ressemble pas.
GIVT et SIVT : la norme qui prouve le « seulement la moitié »
Le secteur publicitaire dispose déjà d’un vocabulaire pour cela. L’IAB et le Media Rating Council divisent le trafic non valide en deux niveaux. Le trafic non valide général (GIVT) est celui qui est « identifié par des méthodes de filtrage courantes et fondées sur des listes » : bots connus, robots d’exploration et listes d’IP malveillantes. Le trafic non valide sophistiqué (SIVT) est « plus difficile à détecter » et exige « des analyses avancées, une corroboration multipoint et/ou une intervention humaine importante ».
La fraude au clic par proxy résidentiel et par logiciel malveillant relève par définition du SIVT. Une liste de blocage est, selon les termes mêmes de la norme, une méthode de filtrage fondée sur des listes, un outil GIVT. C’est catégoriquement le mauvais instrument pour la moitié du problème qui compte le plus. Voilà la raison précise, conforme aux normes du secteur, pour laquelle le blocage d’IP n’attrape qu’une partie de votre trafic non valide. Pour situer la taille de cette partie, les références de Pixalate pour le 1er trimestre 2025 établissaient le taux de trafic non valide à 18 % sur le web desktop et mobile, et à 31 % sur les applications mobiles.
L’angle mort des conversions que les listes de blocage ignorent
Il existe un second échec, même lorsqu’un clic est filtré. Google indique que lorsqu’un clic est jugé non valide et supprimé, la conversion attribuée à ce clic n’est pas forcément supprimée. Une action frauduleuse peut donc survivre au filtrage des clics et atterrir quand même dans vos données de conversion, où elle alimente le Smart Bidding et Performance Max, et apprend à l’algorithme à dépenser davantage pour rechercher précisément les audiences et les emplacements qui produisent du trafic sans valeur. Les défenses au niveau des IP n’y changent rien. C’est une couche entièrement distincte.
Ce qu’apportent la détection des appareils et la détection comportementale : l’autre moitié
Si l’IP n’est pas fiable, vous détectez plutôt l’acteur. Trois couches résistent à une IP résidentielle en rotation :
-
L’empreinte d’appareil (device fingerprinting). Une identité dérivée, assemblée à partir d’attributs matériels, logiciels et réseau, sans rien stocker sur l’appareil, qui réidentifie le même visiteur malgré l’effacement des cookies, la navigation privée et des IP toutes neuves. Lorsque la fraude arrive par une IP résidentielle en rotation qui n’apparaîtrait jamais sur une liste de blocage, ClickFortify lui attribue un score à partir de signaux d’appareil et de comportement, en plus de la réputation IP, de sorte que le même acteur est attrapé même après un changement d’IP. Son empreinte construit une identité qui survit à l’effacement des cookies et réidentifie un visiteur frauduleux à travers des centaines d’IP de sortie résidentielles différentes.
-
Les signaux comportementaux. Les vraies personnes bougent la souris, font défiler la page, hésitent et naviguent de façon désordonnée et humaine. Les clients automatisés non, et les outils de navigateur headless comme Selenium, Puppeteer et Playwright laissent des empreintes d’automatisation détectables. En analysant le comportement après le clic (temps passé, profondeur de défilement, parcours de navigation et ces indices d’automatisation), ClickFortify signale les clics qui passent un contrôle de réputation IP mais se comportent comme des bots.
-
La corroboration entre signaux. Les indices les plus forts viennent des contradictions. Une IP résidentielle associée à une empreinte d’appareil typique d’un centre de données ; un fuseau horaire ou une langue du navigateur qui ne correspond pas à la géolocalisation de l’IP ; une latence et des délais qui trahissent un acheminement par proxy via un autre pays. ClickFortify recoupe les signaux de cohérence entre IP et appareil et de cohérence géographique, de sorte qu’une session incohérente est mise en évidence au lieu d’être jugée fiable. La détection des proxys, des centres de données et des VPN reste importante ici : non pas comme un verdict à elle seule, mais comme une donnée pondérée parmi d’autres.
Comment ClickFortify superpose les défenses sur Google, PMax et Meta
Assembler ces couches est le vrai travail, et il doit respecter les contraintes de chaque plateforme :
- Google Search et Display. ClickFortify exclut automatiquement en temps réel les IP frauduleuses confirmées et gère la liste d’exclusion de façon dynamique face au plafond de Google de 500 IP par campagne, afin qu’une liste limitée ne soit pas gaspillée sur des adresses périmées pendant que de nouvelles passent sans être bloquées.
- Performance Max. Comme les exclusions au niveau de la campagne ne peuvent pas toucher PMax, ClickFortify applique des exclusions au niveau du compte associées à une détection comportementale hors plateforme, afin que les dépenses PMax ne restent pas sans défense face au trafic par proxy.
- Conversions et Smart Bidding. Comme un clic filtré peut tout de même laisser derrière lui une conversion polluante, ClickFortify ajoute un filtrage au niveau des conversions et de la CAPI, afin que les conversions générées par la fraude n’apprennent pas au Smart Bidding à rechercher du trafic sans valeur.
- Meta. Là où les IP client brutes ne peuvent pas du tout être exclues, ClickFortify peut désactiver automatiquement l’Audience Network sur les ensembles de publicités où une fraude est détectée (sur option, compte publicitaire par compte publicitaire), transmet les éditeurs que vous bloquez à la liste de blocage de Meta et filtre les conversions qu’il envoie via la CAPI, étendant ainsi la protection comportementale à une plateforme dépourvue de contrôles d’IP natifs.
À retenir
Conservez vos exclusions d’IP ; elles constituent une première couche nécessaire et stoppent le trafic peu sophistiqué, fondé sur des listes, que les normes appellent GIVT. Mais comprenez ce qu’elles ne peuvent pas faire. La moitié coûteuse et persistante de la fraude au clic passe désormais par de vraies connexions résidentielles qui changent plus vite qu’aucune liste ne peut le suivre, échappe aux contrôles de centres de données et pollue vos données de conversion même lorsque le clic est attrapé. Attraper cette moitié exige d’identifier l’acteur (par l’appareil et le comportement), et non l’adresse. Cette approche en couches, appliquée de façon cohérente sur Search, Performance Max et Meta, fait toute la différence entre une liste de blocage obsolète en une semaine et une protection qui suit la fraude, quelle que soit la provenance de sa prochaine IP.
