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 à lui seul il rate la fraude acheminée par proxy. 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
La plupart des listes d’exclusion se construisent de la même façon : repérer une adresse suspecte dans les rapports, l’ajouter, recommencer. Cela fonctionne contre le trafic des centres de données, qui provient de réseaux d’hébergement que l’on peut reconnaître et bloquer. Cela fonctionne bien moins contre le trafic acheminé par des 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, alors que le trafic de proxys résidentiels est conçu précisément pour déjouer les contrôles qui l’attrapent. Notre guide du trafic de bots dans Google Ads traite le versant automatisé du même problème.
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, reposait sur environ 7 400 serveurs et plus de 3 000 empreintes de fichiers Windows uniques, et était commercialisé sous un ensemble de 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. »
La leçon pour les annonceurs concerne le modèle, pas un réseau en particulier. Google indique que les SDK donnent aux opérateurs « les millions d’appareils dont ils ont besoin », et d’autres réservoirs de proxys résidentiels continuent de fonctionner après le démantèlement de l’un d’eux. Au niveau de l’IP, ils ressemblent à de vrais utilisateurs, et aucune liste d’exclusion statique ne peut suivre un réservoir de cette taille.
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 puisent dans d’immenses réservoirs d’appareils grand public et changent d’IP de sortie en permanence. 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 que vous voulez exclure. Cinq cents emplacements face à un réservoir d’IP domestiques 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 s’appliquent à tout le compte, Performance Max compris, mais ce sont toujours des listes d’adresses, avec le même problème de rotation.
La page de Google sur le trafic non valide décrit des filtres automatiques qui recherchent les interactions ne correspondant pas à un comportement humain normal. Les proxys résidentiels sont conçus pour que le côté réseau d’un clic ressemble à celui d’un utilisateur domestique ordinaire, ce qui laisse à l’appareil et à la session le soin de trahir la fraude.
GIVT et SIVT : la norme qui explique pourquoi les listes ne suffisent pas
Le secteur publicitaire dispose déjà d’un vocabulaire pour cela. La norme du Media Rating Council sur le trafic non valide le divise en deux niveaux. Le trafic non valide général (GIVT) est celui qui est « identifié par des méthodes de filtrage courantes, appliquées au moyen de listes ou d’autres contrôles de paramètres standardisés » : bots connus, robots d’exploration et listes d’IP malveillantes. Le trafic non valide sophistiqué (SIVT) couvre « les situations plus difficiles à détecter, qui exigent des analyses avancées, une corroboration ou une coordination multipoint, une intervention humaine importante, etc. »
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, un filtrage « appliqué au moyen de listes », un outil GIVT. C’est catégoriquement le mauvais instrument pour le SIVT. 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.
L’angle mort des conversions que les listes de blocage ignorent
Il existe un second écart, même lorsqu’un clic est filtré. La page de Google sur le trafic non valide indique que, comme vous collectez les leads sur votre propre site web et dans votre CRM, « des bots ou des utilisateurs peuvent encore soumettre des formulaires même si Google identifie l’interaction publicitaire comme non valide ». La même page précise que Google « supprime certaines conversions non valides si elles proviennent de trafic non valide », ce qui ne veut pas dire toutes. Et la définition des clics non valides de Google note que lorsqu’un clic mène à une conversion puis est filtré, « Google supprime le clic non valide des statistiques de la campagne, mais la conversion valide demeure ». Google compte cette conversion comme valide, mais si le clic qui l’a produite était frauduleux, le formulaire rempli peut lui aussi être sans valeur. Il atterrit dans vos données de conversion et alimente le Smart Bidding et Performance Max. La solution fiable consiste à stopper davantage de clics frauduleux avant qu’ils n’atteignent votre formulaire, et une liste d’IP connues ne le fait que pour les adresses que vous avez déjà attrapées.
Ce qu’apportent la détection des appareils et la détection comportementale en plus des listes d’IP
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, 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 attribue à chaque clic un score fondé sur plus de 100 points de données d’appareil, de réseau et de comportement, et pas seulement sur la réputation de l’IP. Son empreinte réidentifie un visiteur frauduleux même lorsque l’IP de sortie change.
-
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 ; des délais de connexion qui laissent penser que le trafic est relayé par un autre pays. ClickFortify attribue à chaque clic un score fondé sur plus de 100 points de données d’appareil, de réseau et de comportement, de sorte qu’une session dont les signaux se contredisent 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. Pour la protection contre la fraude au clic dans Google Ads, ClickFortify attribue en temps réel à chaque clic un score fondé sur plus de 100 points de données d’appareil, de réseau et de comportement et exclut automatiquement les IP non valides via les listes d’exclusion d’IP de Google Ads, avec une piste de preuves pour chaque blocage. Google plafonne les exclusions d’IP d’une campagne à 500 adresses : c’est pourquoi le blocage par liste seul ne suffit pas et pourquoi le score attribué à chaque clic compte.
- Performance Max. Google indique que les exclusions d’IP au niveau de la campagne ne sont pas disponibles pour Performance Max, tandis que les exclusions d’IP au niveau du compte s’appliquent à tout le compte, Performance Max compris. La protection par IP sur PMax passe donc par les exclusions au niveau du compte.
- Données de conversion. Comme des bots peuvent encore soumettre des formulaires après que Google a signalé l’interaction, l’objectif sur Google Ads est que moins de clics frauduleux atteignent vos formulaires. ClickFortify agit au niveau du clic et de l’IP, de sorte que moins de données sans valeur parviennent à vos données de conversion. Il ne modifie ni ne supprime les conversions dans Google Ads.
- Meta. Meta n’offre aucun blocage d’IP : ClickFortify attribue donc un score à chaque visite de page de destination et agit par les contrôles que Meta propose. Il peut désactiver l’Audience Network sur les ensembles de publicités où une fraude est détectée (sur option, compte publicitaire par compte publicitaire) et transmettre à la liste de blocage de Meta les éditeurs que vous bloquez. Lorsque le proxy CAPI est activé, les conversions sont comparées au score de fraude du visiteur, et les événements signalés sont supprimés ou étiquetés avant que Meta ne les reçoive.
À 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 fraude au clic acheminée par proxy emprunte 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é. L’attraper 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.
