Comment détecter la fraude au clic par adresse IP (sans liste d'exclusion)

Tous les annonceurs découvrent la fraude au clic de la même façon. La courbe des dépenses paraît normale, celle des clics paraît excellente, et celle des conversions est plate. Vous ouvrez les logs bruts, vous triez par IP, et la voilà : la même adresse, quarante fois, aucune conversion, le tout en un seul après-midi.

Alors vous faites ce qui paraît évident. Vous collez cette adresse dans la liste d'exclusion d'IP.

Ça marche, brièvement. Puis les clics reviennent depuis une autre adresse, puis une autre, puis encore une autre, et vers la trentième entrée de votre liste d'exclusion, vous commencez à soupçonner que vous jouez à un jeu impossible à gagner. C'est le cas. La liste d'exclusion n'est pas une version affaiblie du bon outil. C'est le mauvais outil, et il vaut la peine de comprendre exactement pourquoi avant de voir ce qui la remplace : un score de fraude pour le réseau derrière chaque clic.

Ce que font réellement les plateformes publicitaires contre les clics invalides

Commençons par ce que la plupart des annonceurs supposent déjà réglé.

Google filtre bien le trafic invalide, et il le dit clairement. Sa documentation sur le trafic invalide le définit comme un « trafic qui ne représente pas un intérêt réel pour votre entreprise », et précise que « si Google identifie une interaction comme invalide avant la fin du cycle de facturation, vous ne la payez pas ». Nous avons relu cette page le 13 octobre 2026 et elle a été réécrite : les citations de cette section reprennent donc sa formulation actuelle.

C'est réel, et ce n'est pas rien. Mais regardez ce que cela protège. Cela protège la facture. Le trafic invalide détecté avant la fin du mois « est automatiquement retiré de votre facturation et de vos rapports de campagne, donc aucun remboursement n'est nécessaire ». Si Google le découvre après votre facturation, « vous recevrez des crédits, sous la forme d'un ajustement de facturation, correspondant à la valeur de l'activité invalide ». Rien de tout cela ne vous dit quel mot clé, quel emplacement ou quelle audience attire la fraude. Cela n'empêche pas le trafic de polluer vos analyses, et cela n'empêche pas une fausse conversion d'atteindre votre modèle d'enchères.

Vous pouvez demander à Google d'enquêter sur du trafic qu'il a manqué, dans certaines limites. Google « limite les investigations aux 60 derniers jours », et la même page avertit qu'« une investigation ne pourra pas confirmer si des clics précis ont été marqués comme valides ou invalides ». La raison avancée par Google est que partager ces détails aiderait les acteurs malveillants à contourner ses défenses. C'est une raison légitime, et elle vous laisse tout de même sans réponse au niveau du clic.

Ce qui se rapproche le plus d'une ventilation, c'est l'Invalid Activity Credit Report. Il « ventile ces crédits par campagne et par réseau » et ajoute les clics et interactions derrière chaque crédit. Il n'est disponible que pour les campagnes Search et Performance Max, et il couvre les crédits, qui sont émis pour une activité invalide découverte après une facture. Le trafic que Google a filtré avant facturation ne devient jamais un crédit : il ne figure donc pas dans ce rapport.

L'information équivalente de Meta est plus mince encore. Sa page sur les clics invalides indique que Meta « prend plusieurs mesures pour réduire le risque d'abus liés aux clics invalides », effectue un examen manuel lorsqu'une activité suspecte est détectée ou signalée, et ne vous facturera pas les clics jugés invalides. C'est là tout son engagement.

Les deux plateformes corrigent leur propre copie, sur le seul indicateur où leurs intérêts et les vôtres divergent. Tout ce qui reste après leur filtre est votre problème, et votre problème se mesure en stratégie, pas seulement en euros ou en dollars.

Pourquoi une liste d'exclusion d'IP échoue

• Elle manque de place, et elle ne peut pas nommer un réseau. Google Ads plafonne les exclusions d'IP à 500 par campagne et 500 par compte, l'interface ne documente qu'un caractère générique sur le dernier octet, et Performance Max n'accepte les exclusions qu'au niveau du compte. Nous détaillons les limites exactes, les entrées CIDR via l'API et les adresses qui méritent une place dans le guide sur la limite d'exclusion d'IP de Google Ads.
• Elle n'existe pas sur Meta. Meta Ads Manager n'a aucune fonction d'exclusion d'IP. Tous les outils tiers de lutte contre la fraude au clic sur Meta contournent ce manque en plaçant les utilisateurs suspects dans une exclusion d'audience personnalisée, un mécanisme fondamentalement différent et plus grossier.

Ce sont les limites mécaniques. La limite stratégique est pire.

Les adresses tournent plus vite que vous ne pouvez les taper

La fraude publicitaire professionnelle n'opère pas depuis une adresse fixe. Elle loue des IP résidentielles par millions.

En 2025, Google a poursuivi en justice les opérateurs du botnet BADBOX 2.0, qui avait compromis plus de 10 millions d'appareils Android non certifiés. Regardez à quoi servait un seul de ces appareils infectés : création de nœuds de proxy résidentiel, fraude publicitaire programmatique, publicités cachées et fraude au clic. Tout cela provenait d'un seul boîtier TV compromis dans le salon de quelqu'un. Les recherches de HUMAN Security sur PROXYLIB ont mis au jour la chaîne d'approvisionnement qui l'alimentait : des applications Android, publiées sur Google Play, qui inscrivaient discrètement les téléphones de leurs utilisateurs comme nœuds de sortie de proxy.

C'est la même infrastructure que celle dont nous avons parlé dans pourquoi il y a autant de proxies résidentiels dans votre trafic. Pour un annonceur, cela signifie que le clic frauduleux qui vient de vous coûter 14 $ est arrivé depuis une vraie connexion haut débit domestique dans votre ville cible, appartenant à une vraie personne qui ignore que son routeur est à louer. Il n'y a pas d'adresse à bannir. Il y en a dix millions, et demain ce seront dix millions d'autres.

Et les bannir touche de vrais clients

Voici la partie qui coûte discrètement plus cher que la fraude elle-même.

Une adresse IP publique ne signifie plus une personne. Le NAT de niveau opérateur place des centaines ou des milliers d'abonnés mobiles derrière une seule adresse publique, et la RFC 6269, l'évaluation par l'IETF de ce que casse le partage d'adresses, en a énoncé la conséquence il y a des années : lorsqu'un serveur pénalise une adresse partagée, « un utilisateur qui échoue à plusieurs tentatives de connexion peut bloquer d'autres utilisateurs qui n'ont fait aucune tentative auparavant ».

Remplacez « tentatives de connexion » par « clics frauduleux » et vous obtenez votre liste d'exclusion. Excluez définitivement l'IP de l'opérateur mobile derrière laquelle se trouvait par hasard un fraudeur, et vous avez supprimé un nombre inconnu de vrais acheteurs mobiles de toutes les campagnes du compte : silencieusement, sans aucun rapport, pour toujours. C'est la version dépenses publicitaires du problème des faux refus que nous avons traité dans détecter le trafic anonymisé sans bloquer de vrais clients.

Une liste d'exclusion n'a pas de notion de « probablement mauvais ». Elle ne connaît que « banni ». C'est le défaut de conception fatal, et c'est pourquoi la réponse n'est pas une liste plus longue.

Changer de cadre : l'IP est une preuve, pas un verdict

Arrêtez de vous demander « cette adresse est-elle sur ma liste noire ? » et commencez à vous demander « de quel type de réseau provient ce clic, et quelle confiance puis-je lui accorder ? »

Cette question a une réponse riche, car une adresse IP porte beaucoup de contexte qui n'a rien à voir avec son historique de réputation. Ce contexte est difficile à falsifier pour un fraudeur, car c'est une propriété de l'infrastructure qu'il emprunte plutôt que de la requête qu'il envoie.

Le secteur a déjà formalisé cela, et c'est la partie que la plupart des conseils PPC ratent.

Ce que les normes exigent déjà

Les normes IVT Detection and Filtration du Media Rating Council divisent le trafic invalide en deux niveaux, et cette division correspond presque parfaitement à la difficulté de lecture de l'IP. Le General Invalid Traffic (GIVT) est détecté « par l'application de listes ou d'autres contrôles de paramètres standardisés », et la première catégorie que le MRC y range est le trafic de datacenter connu comme invalide. Le Sophisticated Invalid Traffic (SIVT) est le niveau plus difficile qui exige « des analyses avancées, une corroboration/coordination multipoint, une intervention humaine importante », et le trafic de proxy invalide s'y trouve. Nous passons en revue chaque catégorie des deux niveaux, à côté des neuf catégories de Google, et indiquons lesquelles une requête IP peut voir, dans GIVT et SIVT : les catégories de trafic invalide de Google.

Les lignes directrices Certified Against Fraud de TAG rendent la moitié datacenter obligatoire : une entreprise certifiée « doit mettre en œuvre un filtrage des menaces liées aux IP de datacenter sur toutes les transactions monétisables (y compris les impressions, les clics, les conversions, etc.) », et la section 4.8.a ajoute que l'utilisation de la seule TAG Data Center IP List ne suffit pas. Deux conséquences pour un annonceur. Si les organismes de normalisation traitent le filtrage des IP de datacenter comme un plancher de conformité, un annonceur qui ne le fait pas est sous le plancher. Et les normes disent ce que dit cet article : les listes gèrent le niveau facile, et le niveau difficile exige de l'analyse.

Les signaux d'adresse IP qui détectent la fraude au clic

Voici ce qu'il faut lire dans l'IP, à peu près par ordre de rapport signal/bruit pour le trafic payant. Pour les mêmes indicateurs appliqués aux bots au-delà des clics publicitaires, et pour savoir où chacun devient aveugle, voyez quels signaux IP identifient les bots.

Notez le sens de la dernière ligne. Un bon modèle de scoring ne fait pas qu'ajouter des points. Il en retire aussi. Un FAI résidentiel et un robot d'exploration vérifié sont des raisons d'être plus indulgent, une plage de NAT de niveau opérateur voit son score plafonné, et un système qui en est dépourvu transformera votre vraie audience mobile en faux positifs. Ce principe est détaillé raison par raison dans les raisons disculpantes derrière un score de fraude, et il compte davantage dans la publicité que presque partout ailleurs, car sur le trafic payant, un faux positif n'est pas une connexion bloquée. C'est un client que vous avez payé pour acquérir, puis jeté.

Tout lire en un seul appel

Concrètement, il s'agit d'une seule requête sur l'IP qui a déclenché le clic, avant de décider ce qu'il valait. Vous pouvez faire le même contrôle à la main avec le vérificateur gratuit de score de fraude IP.

Les champs qui comptent pour un clic payant se répartissent dans quatre groupes de la réponse :

Un clic depuis un hébergeur obtient un score bas, un clic Tor obtient 100

Le score à lui seul ne déclassera pas pour vous un clic de datacenter, et deux vraies requêtes montrent pourquoi il faut quand même lire les champs. Nous avons recherché les deux adresses le 13 octobre 2026 et les avons relancées le 14 octobre 2026 avec les mêmes valeurs ; le premier bloc est la réponse du 14 octobre 2026. Les résultats changent à mesure que les plages évoluent. La première est l'IP d'hébergement de la requête ci-dessus : scanme.nmap.org, l'hôte de test public que Nmap exploite sur Akamai Connected Cloud à Fremont, en Californie. Elle n'a cliqué sur la publicité de personne. Elle représente n'importe quel serveur cloud ordinaire :

La seconde est une sortie Tor à Hambourg :

Le serveur cloud obtient 10 et allow, avec datacenter_ip comme seule méthode. C'est voulu : le score général est conçu pour tous les types de trafic, y compris les appels API et les sorties réseau d'entreprise, où une adresse d'hébergement seule n'est pas de la fraude. Un clic payant est différent, car un acheteur ne clique pas sur votre publicité depuis un serveur : pour le trafic publicitaire, appliquez donc votre propre règle sur asn.connection_type ou detection.is_hosting au lieu d'attendre que le score indique block. La sortie Tor n'a besoin d'aucune règle supplémentaire : elle obtient 100 et block, et detection_methods nomme quatre raisons indépendantes (sortie Tor, une plage de datacenter sur une liste de blocage, un DNS inverse de type Tor, un spammeur connu).

Un VPN se situe entre les deux. Jusqu'à cette mise à jour, cet article utilisait 45.83.220.7 comme exemple d'hébergement ordinaire. Le 13 octobre 2026, l'API l'identifie comme un serveur Mullvad et lui attribue 46, review, avec known_vpn_server et datacenter_ip. C'est la pondération que demande le tableau des signaux : un clic VPN est une raison de regarder de plus près, pas de bannir, et c'est aussi un rappel de relancer toute requête avant de vous fier à un ancien résultat.

C'est ce champ qui fait passer l'ensemble d'une boîte noire à quelque chose que vous pouvez défendre lors d'une revue de qualité média. Quand un clic est déclassé, vous pouvez dire précisément pourquoi : connexion de datacenter sur un clic payant, ou sortie Tor plus une inscription pour spam. « Le score l'a dit » n'est une réponse que personne ne devrait accepter, surtout pas de la part de ses propres outils antifraude.

Protéger le signal d'enchère, pas seulement le clic

C'est la partie qui change l'économie du problème, et c'est là que les annonceurs sous-investissent systématiquement.

Bloquer un clic frauduleux vous épargne le coût de ce clic. Empêcher une conversion frauduleuse vous épargne quelque chose de bien plus coûteux : apprendre à votre algorithme d'enchères à acheter davantage de fraude.

Les enchères intelligentes (Smart Bidding) et l'optimisation de Meta fonctionnent toutes deux en apprenant quels groupes de signaux produisent des conversions et en enchérissant plus fort vers eux. Injectez une fausse conversion dans cette boucle et vous n'avez pas perdu un clic. Vous avez payé pour entraîner le modèle à aller chercher davantage de trafic ressemblant exactement à celui qui vient de vous escroquer. Le système le poursuivra avec enthousiasme et affichera d'excellents résultats, car selon ses propres critères, il réussit.

Pour être précis sur ce qui est documenté ou non : Google ne publie aucune déclaration selon laquelle les conversions frauduleuses empoisonnent les enchères automatisées. Ce que dit la documentation Smart Bidding de Google, c'est que « si les données de suivi des conversions sont inexactes, vous pouvez constater des fluctuations de votre volume, de votre CPA ou de votre ROAS », tout en notant que Smart Bidding peut réagir et s'ajuster à des données inexactes. L'affirmation plus forte ci-dessus est un raisonnement tiré du fonctionnement de l'optimisation, pas une citation de Google, et vous devez la traiter comme telle. C'est toutefois un raisonnement simple : un optimiseur maximise ce qu'on lui demande de compter.

Le contrôle pratique se fait côté serveur, et c'est le seul endroit où Meta vous donne plus de contrôle que Google, et non moins. Comme l'API Conversions est un canal de serveur à serveur, c'est votre serveur qui décide quels événements sont envoyés à Meta. Une requête IP au moment de la conversion (et non au moment du clic) vous permet de retenir entièrement l'événement lorsque le « client » est une adresse de datacenter. Meta n'apprend jamais à en vouloir davantage. Il en va de même pour les importations de conversions hors ligne de Google.

Scorez le clic pour protéger le budget. Filtrez la conversion pour protéger le modèle.

La liste d'exclusion garde un petit rôle

Rien de tout cela ne signifie que vous devez vider la liste. Cela signifie que vous devez cesser d'en faire la stratégie.

Une liste d'exclusion est le bon outil pour une seule situation : un petit nombre de récidivistes stables, identifiés avec une grande confiance : la plage du bureau d'un concurrent, un scraper sur un hôte fixe, une IP interne qui brûle votre propre budget. Cela fait une poignée d'entrées, elles ne tournent pas, et elles n'approcheront jamais les 500.

Tout le reste (tout ce qui tourne, tout ce qui est partagé, tout ce dont vous n'êtes pas certain) a sa place dans le score, où cela peut être pondéré, atténué avec le temps, corroboré par d'autres signaux et révisé demain quand les preuves changent. Les bannissements sont permanents et binaires. La fraude n'est ni l'un ni l'autre.

Où cela tourne en production

Je construis cela des deux côtés de la chaîne, et il vaut la peine de le dire ouvertement. GeoIPHub est la couche de renseignement IP décrite plus haut. ClickFortify est notre produit de lutte contre la fraude au clic construit par-dessus. Il score les clics publicitaires en direct sur Google et Meta, synchronise le petit ensemble de récidivistes réellement identifiés avec une grande confiance dans les exclusions d'IP de Google Ads, et filtre les conversions suspectes avant qu'elles n'atteignent la CAPI de Meta et le Smart Bidding de Google.

L'architecture est l'argument de cet article, rendu concret : le renseignement IP fait le scoring, et la liste d'exclusion ne sert que pour l'étroite part des cas où un bannissement permanent est réellement la bonne réponse. Si vous préférez construire cette logique vous-même, l'API ci-dessus est celle qu'il appelle.

Six changements à faire avant votre prochaine campagne

• Journalisez l'IP de chaque clic publicitaire. Vous ne pouvez pas scorer ce que vous n'avez pas enregistré. Capturez l'adresse lors de l'arrivée sur la page de destination, avec le gclid/fbclid.
• Scorez, ne bannissez pas. Passez chaque IP de clic dans une requête et stockez le score avec la session, afin de pouvoir segmenter vos rapports par tranche de risque a posteriori.
• Commencez par le plancher datacenter. Le trafic des ASN d'hébergement est la base GIVT du MRC et le signal le plus fiable, avec le moins de faux positifs, dont vous disposez. C'est le gain le moins coûteux à votre portée.
• Filtrez les conversions côté serveur. Retenez les événements de conversion envoyés à CAPI et aux importations hors ligne lorsque l'IP présente un risque élevé. Cela protège le modèle d'enchères, qui vaut plus que le clic.
• Plafonnez le risque sur les IP partagées. Assurez-vous que les plages CGNAT et des opérateurs mobiles sont traitées comme partagées, pas comme mauvaises. C'est le garde-fou qui empêche la prévention de la fraude de devenir une prévention du chiffre d'affaires.
• Gardez la liste d'exclusion courte. Réservez-la aux récidivistes stables et certains, et définissez-la au niveau du compte pour qu'elle couvre aussi Performance Max.

Le clic vous a déjà dit d'où il venait. La seule question est de savoir si vous écoutiez assez attentivement pour entendre plus qu'une adresse.

Questions fréquentes

Comment détecter la fraude au clic par adresse IP ?

Pas en comparant l'adresse à une liste de bannissement, mais en scorant le réseau d'où vient le clic. Les champs à fort signal sont le type de connexion (un clic depuis un ASN d'hébergement ou de datacenter ne vient pas d'un acheteur), les indicateurs d'anonymiseur (VPN, proxy public, Tor), les preuves issues de flux de menaces (botnet, scanner, spammeur) avec un horodatage de récence, et la vérification des robots d'exploration (une requête qui prétend être Googlebot depuis une IP hors des plages publiées par Google échoue à la vérification ; votre code compare cette prétention avec le champ vérifié de l'API). Chacun de ces éléments est une entrée pondérée d'un score de risque, et c'est sur le score, pas sur l'IP brute, que vous agissez.

Peut-on bloquer la fraude au clic sur Meta Ads par IP ?

Non. Meta Ads Manager ne propose aucune fonction d'exclusion d'IP, et c'est pourquoi tous les outils tiers de lutte contre la fraude au clic sur Meta fonctionnent en plaçant les utilisateurs suspects dans une exclusion d'audience personnalisée (Custom Audience) au lieu de bloquer une adresse. Sur Meta, le levier n'est pas le clic, c'est l'API Conversions : comme CAPI fonctionne côté serveur, c'est votre serveur qui décide quels événements de conversion sont envoyés à Meta, de sorte qu'une conversion depuis une IP de datacenter peut tout simplement être retenue.

Google ne filtre-t-il pas déjà les clics invalides pour moi ?

Google en filtre une partie, et il est explicite sur la manière. L'aide Google Ads indique que le trafic invalide détecté avant la fin du mois « est automatiquement retiré de votre facturation et de vos rapports de campagne, donc aucun remboursement n'est nécessaire », et que le trafic invalide découvert après facturation est restitué sous forme de « crédits, sous la forme d'un ajustement de facturation ». Cela protège votre facture, pas votre stratégie de campagne. Les investigations ne couvrent que les 60 derniers jours, et Google indique qu'une investigation « ne pourra pas confirmer si des clics précis ont été marqués comme valides ou invalides » : vous ne pouvez donc pas remonter de la fraude jusqu'aux mots clés, emplacements ou audiences qui l'attirent.

Pourquoi bloquer une adresse IP frauduleuse est-il dangereux ?

Parce que sur l'internet moderne, une seule adresse publique est couramment partagée par de nombreuses personnes sans lien entre elles. La RFC 6269 a documenté cette conséquence il y a des années : lorsqu'un serveur pénalise une adresse partagée, un seul utilisateur abusif peut bloquer d'autres utilisateurs qui n'ont rien fait de mal. Le NAT de niveau opérateur place des centaines ou des milliers d'abonnés mobiles derrière une seule IP publique : une exclusion permanente visant un fraudeur peut donc supprimer discrètement une partie de votre vraie audience mobile de toutes vos campagnes.

Le trafic de datacenter est-il officiellement considéré comme du trafic invalide ?

Le trafic de datacenter connu comme invalide l'est, mais pas tout le trafic de datacenter. Les normes IVT Detection and Filtration du Media Rating Council placent le « trafic de datacenter connu comme invalide » en première catégorie du General Invalid Traffic, tout en excluant la navigation légitime depuis des machines virtuelles et les artefacts de routage d'utilisateurs réels, et le MRC exige au minimum le filtrage du trafic de datacenter provenant des trois plus grands hébergeurs (Amazon AWS, Google et Microsoft). Les lignes directrices Certified Against Fraud de TAG vont plus loin et exigent des entreprises certifiées qu'elles mettent en œuvre un filtrage des menaces liées aux IP de datacenter sur toutes les transactions monétisables.