Prévention de la fraudeGIVT vs SIVT : les 9 catégories de trafic invalide de Google DV360
GIVT vs SIVT, cartographiés : une requête IP voit nettement 2 des neuf catégories de trafic invalide de Google DV360, et la plupart pas du tout. Découvrez lesquelles, avec 5 requêtes IP réelles.
Vous avez vu des clics invalides dans Google Ads, puis la page d'un fournisseur a qualifié une partie de votre trafic de « SIVT ». Ces lettres vous indiquent qui est censé repérer chaque type de mauvais trafic, et si vous pouvez agir vous-même.
Ci-dessous, nous citons mot pour mot les neuf catégories de Google, plaçons chacune à côté de la norme du MRC, indiquons quel champ IP peut la voir et soumettons cinq adresses réelles à notre API. Pour la question plus large de la détection de la fraude au clic par IP sans liste d'exclusion, commencez par notre guide de référence.
Nous avons ouvert chaque page de Google et du MRC citée ici le 21 octobre 2026 à 5 h 38 UTC.
Qu'est-ce que le trafic invalide (IVT) ?
Le trafic invalide est une activité publicitaire qui ne provient pas d'une personne réelle animée d'un intérêt réel. La page Ad Traffic Quality de Google le résume en une ligne :
"Invalid traffic is any activity that doesn't come from a real user with genuine interest." (« Le trafic invalide est toute activité qui ne provient pas d'un utilisateur réel ayant un intérêt sincère. »)
Les clics, les impressions, les interactions et les conversions peuvent tous être invalides, et tout cela n'est pas malveillant. Les exemples de Google vont des clics accidentels au « fraudulent clicking by competing advertisers » (clics frauduleux d'annonceurs concurrents) et aux « advertising botnets » (botnets publicitaires).
L'aide de Google Ads n'emploie pas les termes GIVT et SIVT. Ils viennent du MRC, et Google les utilise dans son aide DV360, là où figurent les neuf catégories.
Ne confondez pas ces neuf catégories avec les exemples propres à la page Ad Traffic Quality. Cette liste comportait onze rubriques lors de notre vérification : Invalid user activity, Accidental Clicks, Ad Hiding, Ad Injection, Ad Stacking, Botnets, Clickjacking, Falsely Represented Inventory, Misrepresentation of in-stream and out-stream video, Malware et Pop-under ad. Google la qualifie de « not an exhaustive list » (liste non exhaustive) et ne la répartit pas en niveaux.
Les éditeurs ont leurs propres règles, sur la page de l'AdSense consacrée au trafic invalide.
GIVT vs SIVT : ce qui sépare les deux niveaux, et qui décide
Les niveaux diffèrent par la manière dont le trafic est repéré, pas par sa gravité. L'Invalid Traffic Detection and Filtration Standards Addendum, June 2020 Update du MRC définit le GIVT, en page 5, comme un trafic « identified through routine means of filtration executed through application of lists or with other standardized parameter checks » (identifié par des moyens de filtrage de routine, au moyen de listes ou d'autres contrôles de paramètres standardisés). Le SIVT, en page 6, couvre les « more difficult to detect situations that require advanced analytics, multi-point corroboration/coordination, significant human intervention, etc., to analyze and identify » (situations plus difficiles à détecter, qui exigent des analyses avancées, une corroboration ou une coordination sur plusieurs points, une intervention humaine importante, etc., pour être analysées et identifiées).
La page DV360 Filtering invalid traffic to ensure quality dit la même chose en termes plus simples : le GIVT « is identified using lists of known spiders and robots, or other routine checks » (est identifié à l'aide de listes de spiders et de robots connus, ou d'autres contrôles de routine), tandis que le SIVT « requires human intervention or more in depth analysis » (exige une intervention humaine ou une analyse plus approfondie).
Le calendrier en découle. DV360 indique que Google supprime le trafic invalide « either before inventory is bid on, or after an event occurs » (soit avant les enchères sur l'inventaire, soit après qu'un événement s'est produit), et le MRC note en page 8 que la détection du SIVT « may take time to execute and may not be feasible to apply to real-time processes » (peut prendre du temps et ne pas être applicable aux processus en temps réel).
Un même clic peut relever de plusieurs catégories. Le MRC indique en page 49 que les catégories « are often not mutually exclusive as invalid traffic is likely to be detected by or result from more than one category » (ne sont souvent pas mutuellement exclusives, car le trafic invalide est susceptible d'être détecté par plus d'une catégorie ou d'en résulter).
Plusieurs acteurs se partagent le travail :
- Le MRC rédige la norme et accrédite les fournisseurs de mesure au regard de celle-ci.
- Les listes du secteur alimentent le GIVT. Le MRC cite l'IAB/ABC International Spiders & Bots List en page 9 et la Data Center IP list du Trustworthy Accountability Group (TAG) en page 10.
- Les plateformes et les fournisseurs l'appliquent. La page Ad Traffic Quality de Google indique que « Google's Sophisticated Invalid Traffic (SIVT) detection processes are accredited by the Media Rating Council » (les processus de détection du trafic invalide sophistiqué (SIVT) de Google sont accrédités par le Media Rating Council).
Les neuf catégories de trafic invalide de Google à côté des listes du MRC
Google classe le trafic invalide en trois catégories GIVT et six catégories SIVT, et la plupart ont un équivalent approximatif dans les listes du MRC. La formulation de Google est reprise de la page DV360 (traduite ici). La colonne MRC correspond à notre propre rapprochement, car DV360 renvoie à la section 1.1.2 du MRC dans son ensemble, et non élément par élément.
| Niveau | Catégorie DV360 et définition de Google | Formulation du MRC la plus proche (notre rapprochement, addendum de 2020) | Champ IP à vérifier | Notre requête, 21 oct. 2026 |
|---|---|---|---|---|
| GIVT | Centre de données : « Trafic publicitaire provenant de serveurs situés dans des datacenters dont les IP sont associées à une activité invalide (généralement du trafic non humain). » | « Trafic de datacenter invalide connu (considéré comme une source constante de trafic invalide ; à l'exclusion des artefacts de routage d'utilisateurs légitimes et de la navigation légitime depuis des machines virtuelles) » (p. 5) | detection.is_hosting, asn.asn_type | 45.33.32.156 : hébergement, score 10, allow |
| GIVT | Robot d'exploration connu : « Trafic publicitaire provenant d'un programme ou d'un script automatisé qui demande du contenu et se déclare comme non humain (par divers mécanismes d'identification). » | « Bots, spiders et autres robots d'exploration » (p. 5) | threat.crawler.verified | 66.249.66.1 : Googlebot vérifié, score 0, allow |
| GIVT | Schéma irrégulier : « Trafic publicitaire qui comporte un ou plusieurs attributs (par exemple, un cookie utilisateur) associés à des schémas irréguliers connus, comme le trafic d'actualisation automatique ou les clics en double. » | « Filtrage fondé sur l'activité, à partir de données au niveau des transactions et de paramètres issus des données de campagne ou d'application » (p. 5) | Aucun dans la requête. Comptez les clics par IP et par préfixe dans votre propre journal | Aucune |
| SIVT | Navigation automatisée : « Un programme ou un script automatisé qui demande du contenu Web (y compris des annonces numériques) sans intervention de l'utilisateur et sans se déclarer comme robot d'exploration, désignant notamment et principalement les botnets. » | « Navigation automatisée depuis un appareil dédié » et « depuis un appareil non dédié : appareils infectés et détournés » (p. 6) ; robots d'exploration « se faisant passer pour des utilisateurs légitimes » (p. 7) | En partie : threat.is_scanner, threat.is_botnet | 162.142.125.10 : scanner, score 0, allow |
| SIVT | Représentation trompeuse : « Une demande d'annonce pour un inventaire différent de l'inventaire réellement fourni, y compris les demandes d'annonces pour lesquelles l'annonce réelle est affichée sur un autre site Web ou une autre application, un autre appareil ou une autre cible (par exemple une zone géographique). » | « Usurpation de domaine et d'application : usurpation d'ID d'application, blanchiment de domaine et falsification du domaine ou de l'emplacement du site » (p. 7) | Aucun au niveau IP | Aucune |
| SIVT | Interface utilisateur trompeuse : « Une page Web, une application ou un autre élément visuel modifié pour inclure de manière trompeuse une ou plusieurs annonces. Cela inclut l'affichage d'annonces non visibles par l'utilisateur, l'injection d'annonces sans le consentement de l'éditeur ou le fait d'inciter par la ruse les utilisateurs à cliquer sur une annonce. » | « Diffusion d'annonces masquées, empilées, recouvertes, transparentes, invisibles ou volontairement dissimulées de toute autre manière » et « Adwares et malwares qui effectuent des actions trompeuses, y compris l'injection d'annonces » (p. 7) | Aucun au niveau IP | Aucune |
| SIVT | Comportement manipulé : « Un navigateur, une application ou un autre programme qui déclenche une interaction avec une annonce sans le consentement de l'utilisateur, comme un clic involontaire, une conversion inattendue ou une fausse attribution de l'installation d'une application mobile. » | « Activité manipulée : ouverture forcée d'une nouvelle fenêtre de navigateur, ouverture forcée d'un onglet, installation forcée d'une application mobile (redirection mobile), comportement de clic forcé » (p. 6) | Aucun au niveau IP | Aucune |
| SIVT | Comportement incité : « Le recours à une incitation explicite pour pousser des utilisateurs à interagir avec une ou plusieurs annonces dans le seul but de recevoir cette incitation, sans que l'annonceur en ait connaissance. » | « Activité invalide humaine incitée » (p. 6) | Aucun au niveau IP | Aucune |
| SIVT | Classification non divulguée : « Trafic invalide qui ne peut être classé dans aucune des autres catégories de la taxonomie, ou trafic invalide sensible qui ne peut pas être divulgué. » | Aucun élément unique du MRC | Aucun | Aucune |
| SIVT (MRC uniquement) | Pas de libellé DV360 propre | « Trafic de proxy invalide (provenant d'un appareil proxy intermédiaire qui existe pour manipuler les décomptes de trafic ou créer ou transmettre du trafic invalide, ou qui ne satisfait pas d'une autre manière à la validation du protocole) » (p. 7) | En partie : detection.is_vpn, is_proxy, is_tor, is_relay | 185.213.155.73 : Mullvad, 100, block. 185.220.101.1 : Tor, 100, block |
Deux lignes appellent une nuance. L'hébergement n'est pas automatiquement invalide : DV360 compte les IP « linked to invalid activity » (associées à une activité invalide), et le MRC exclut le routage d'utilisateurs légitimes et la navigation depuis des machines virtuelles. Tous les proxys ne sont pas invalides non plus : le MRC ne compte que celui « that exists to manipulate traffic counts » (qui existe pour manipuler les décomptes de trafic). Le MRC répertorie aussi des éléments GIVT que DV360 ne nomme pas, comme le trafic de préchargement et les emplacements 0x0 ou 1x1.
Le trafic invalide est-il la même chose que la fraude au clic ?
Non. La fraude au clic est la part délibérée du trafic invalide, et une grande partie de l'IVT n'a aucune intention de tromper. Les robots d'exploration de moteurs de recherche vérifiés, les pages préchargées et les appuis accidentels comptent tous comme invalides, et aucun d'eux n'est de la fraude.
Googlebot illustre cet écart. Dans notre requête, 66.249.66.1 est revenu comme un Googlebot vérifié, score 0, allow. Il relève du GIVT au titre de Known crawler, et vous voulez aussi qu'il visite votre site : excluez-le donc des décomptes publicitaires et analytiques, mais ne le bloquez jamais. Si une requête prétend être Googlebot, vérifiez qu'une requête Googlebot provient réellement de Google avant de vous fier au nom. Google publie les plages qu'il utilise sur sa page de vérification des robots d'exploration.
Êtes-vous remboursé pour le trafic invalide ?
Si Google le repère à temps, il ne vous est jamais facturé. La page About invalid traffic de Google indique que le trafic invalide détecté avant la fin du mois est retiré de la facturation et des rapports. S'il est détecté après la facturation, « you'll receive credits in the form of a billing adjustment for the value of the invalid activity » (vous recevrez des crédits sous la forme d'un ajustement de facturation correspondant à la valeur de l'activité invalide). Vous pouvez demander une enquête pour une activité « within the last 60 days » (datant des 60 derniers jours).
L'Invalid Activity Credit Report détaille ces crédits par campagne, et la même page renvoie vers le Click Quality Form pour les demandes d'enquête.
Quelles catégories de trafic invalide une requête IP peut-elle voir, et lesquelles non ?
Une requête IP voit nettement deux des neuf catégories de Google, et une troisième en partie. Vos propres décomptes de clics en couvrent une quatrième, et la couche IP ne peut pas voir les cinq autres.
Voit nettement :
- Centre de données.
detection.is_hostingetasn.asn_typeindiquent que l'adresse appartient à un réseau d'hébergement. Savoir si ce réseau est associé à une activité invalide, comme l'exige la définition de Google, relève d'un jugement distinct. Nous expliquons ce qui fait d'une adresse une IP de datacenter dans un article séparé. - Robot d'exploration connu.
threat.crawler.verifiedvaut true lorsque l'adresse figure dans l'un des 19 flux de plages officiels de 10 opérateurs.
Voit en partie :
- Trafic de proxy invalide. Les indicateurs VPN, proxy, Tor et relais montrent le chemin. Ils ne peuvent pas montrer si le proxy « exists to manipulate traffic counts » (existe pour manipuler les décomptes de trafic).
- Navigation automatisée.
threat.is_scannersignale les plages connues de scanners qui balaient tout Internet.threat.is_botnetet le groupethreat.botnetproviennent de données sur les serveurs de commande et de contrôle de botnets, qui décrivent les serveurs pilotant les botnets, et non les appareils domestiques détournés qui envoient les clics. Nous n'avons aucune adresse signalée comme botnet que nous puissions montrer sans risque. - Robots d'exploration usurpés. L'API ne voit jamais de User-Agent. Un bot qui prétend être Googlebot n'est repéré que lorsque votre code compare le nom revendiqué avec
crawler.verified. - Schéma irrégulier. Il s'agit de votre propre décompte des clics par IP et par préfixe /24 ou /64, et non d'un champ.
Ne voit pas : le préchargement et le prérendu, les sessions sans rendu, les user agents qui ne sont pas des navigateurs (des données d'en-tête, pas des données IP), les emplacements invalides, les annonces masquées ou empilées, le clickjacking, l'activité manipulée, la mesure falsifiée, l'usurpation de domaine et d'application, les balises détournées, l'injection par adware, le cookie stuffing, le contenu détourné, les humains incités et les fermes à clics, ainsi que le trafic envoyé via des proxys résidentiels. Les fermes à clics et les proxys résidentiels arrivent sur des adresses de FAI ordinaires, et la couche IP ne peut pas les distinguer de vrais clients.
Cinq requêtes réelles
Nous avons interrogé cinq adresses publiques entre 5 h 30 et 5 h 31 UTC le 21 octobre 2026, sans clé, ce que notre API autorise à raison de 30 par minute. Aucune d'elles n'a envoyé de clic publicitaire à qui que ce soit. Elles représentent le type d'adresses que contient un journal de clics.
| IP, de quoi il s'agit | Champs clés | Score, action | detection_methods | Ce que cela montre |
|---|---|---|---|---|
| 45.33.32.156, scanme.nmap.org sur Akamai Connected Cloud (Linode) | asn_type hosting, is_hosting true, crawler.verified false | 10, allow | datacenter_ip | Une IP de datacenter est candidate au GIVT, pas un verdict |
| 66.249.66.1, Googlebot | is_hosting true, crawler.verified true, name Googlebot, category search_engine | 0, allow | datacenter_ip, verified_crawler | Known crawler : du GIVT, et bienvenu |
| 185.213.155.73, serveur Mullvad à Francfort | is_vpn true, vpn_provider Mullvad, is_hosting true, is_anonymous true | 100, block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | Un VPN est un signal de risque, pas un niveau d'IVT |
| 185.220.101.1, nœud de sortie Tor à Hambourg | is_tor true, is_hosting true, is_spammer true, dnsbl_sources zen.spamhaus.org | 100, block | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer | La preuve de proxy la plus forte, mais toujours pas une preuve pour un clic donné |
| 162.142.125.10, scanner Censys à Ann Arbor | is_scanner true, threat_types scanner, is_hosting false, asn_type unknown | 0, allow | (vide) | Une automatisation qui échappe à un filtre d'hébergement |
Une adresse, de bout en bout
La requête place l'IP dans le chemin :
curl https://api.geoiphub.com/v1/lookup/45.33.32.156 \
-H "x-api-key: YOUR_API_KEY"
Voici une copie abrégée de la réponse de 5 h 30 UTC, avec l'imbrication conservée et les valeurs non modifiées :
{
"ip": "45.33.32.156",
"asn": {
"asn": 63949,
"org": "AKAMAI-LINODE-AP - Akamai Connected Cloud",
"asn_type": "hosting"
},
"detection": {
"is_vpn": false,
"is_tor": false,
"is_hosting": true
},
"threat": {
"is_scanner": false,
"crawler": {
"verified": false,
"name": "none"
}
},
"scoring": {
"fraud_score": 10,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip"]
}
}
Le signal datacenter s'est déclenché, et rien d'autre, si bien que le score est resté à 10. Au regard des deux normes, cette adresse est candidate à un examen GIVT, pas invalide par défaut. Googlebot, en 66.249.66.1, se trouve aussi sur un réseau d'hébergement, mais il est vérifié, et il a obtenu 0.
Vous pouvez vérifier gratuitement si une IP appartient à un datacenter, ou consulter la référence des champs de l'API.
Trois enseignements de ces requêtes
Une IP d'hébergement n'est pas automatiquement du GIVT. Un simple serveur cloud sans autre signal reste dans allow.
Notre blocage n'est pas une étiquette d'IVT. Mullvad et Tor ont tous deux obtenu 100 et block, un verdict de risque pour votre propre parcours. Le MRC exclut les « routing artifacts of legitimate users » (artefacts de routage d'utilisateurs légitimes) du GIVT de datacenter, et un utilisateur de VPN peut être un véritable acheteur.
Le scanner échappe à un filtre d'hébergement. Censys a renvoyé is_hosting: false, un score de 0 et des detection_methods vides, et pourtant threat.is_scanner valait true. L'indicateur ne fait pas varier le score ; lisez-le donc directement.
Là où les preuves IP s'affaiblissent
Le MRC lui-même avertit que le filtrage fondé sur l'IP s'affaiblit. Ses 2024 IVT Interim Updates, publiées le 24 avril 2024, indiquent en page 2 que « Limited or no IP address and less granular User Agent (UA) string may impair list-based approaches, particularly current Specific Identification, Data Center GIVT approaches » (une adresse IP limitée ou absente et une chaîne User-Agent (UA) moins granulaire peuvent compromettre les approches fondées sur des listes, en particulier les approches actuelles d'identification spécifique et de GIVT de datacenter), ainsi que les techniques fondées sur l'activité. La page 6 précise que toutes les organisations de mesure « must periodically assess (at least annually) IVT detection capability reliance on IP address, UA and user-level analysis » (doivent évaluer périodiquement, au moins une fois par an, la dépendance de leur capacité de détection de l'IVT à l'adresse IP, à l'UA et à l'analyse au niveau de l'utilisateur).
Nos propres limites sont claires. GeoIPHub ne classe pas l'IVT et ne détient aucune accréditation du MRC. Nous renvoyons des éléments de preuve réseau, et c'est l'annonceur ou la plateforme qui classe. Les requêtes reflètent un instant donné, car les plages et les listes changent chaque jour.
Que faire pour chaque catégorie
Filtrez le trafic de datacenter et de robots d'exploration à l'aide des champs, évaluez les anonymiseurs, et cessez d'attendre d'un contrôle IP qu'il repère un SIVT qu'il ne peut pas voir. Voici la règle pour chaque catégorie.
| Catégorie | Que faire | Champ à lire |
|---|---|---|
| Data center | Évaluez le risque au moment du clic et excluez ce trafic des signaux de conversion. Ne l'excluez pas en bloc, car la limite de 500 exclusions d'IP de Google Ads ne peut pas contenir un réseau d'hébergement | detection.is_hosting, asn.asn_type |
| Known crawler | Autorisez-le, et excluez-le des décomptes publicitaires et analytiques | threat.crawler.verified, threat.crawler.name |
| Trafic de proxy invalide | Évaluez-le et renforcez la vérification des actions à risque. Ne bannissez pas les sorties partagées | detection.is_vpn, is_proxy, is_tor, is_relay |
| Automated browsing | Lisez les indicateurs de scanner et de botnet. Comparez dans votre code le User-Agent revendiqué avec crawler.verified | threat.is_scanner, threat.is_botnet |
| Irregular pattern | Limitez le débit par IP et par préfixe /24 ou /64 dans votre propre journal | Aucun, vos décomptes |
| Tout le reste | Appuyez-vous sur le filtrage de Google, vos rapports sur les emplacements et la procédure de crédit | Aucun |
Pour les robots d'exploration, le choix de ceux que vous laissez entrer vous appartient. Nous traitons le choix des robots d'exploration IA à bloquer et la vérification des robots d'exploration IA par DNS inverse et plages publiées dans des articles séparés. Pour Tor, notre guide explique comment fonctionne la détection des nœuds de sortie Tor. Pour les bots en général, lisez ce qu'une IP peut et ne peut pas vous dire sur un bot.
Une précaution s'applique à chaque ligne. threat.is_cgnat signale les adresses de NAT d'opérateur, où une adresse porte de nombreux utilisateurs : ne bannissez donc jamais une telle adresse sur la base d'un décompte de clics. Lorsqu'un verdict vous surprend, scoring.detection_methods énumère les raisons qui le sous-tendent.
Comment mesurer le trafic invalide sur votre propre compte
Commencez par ce que Google a déjà filtré, puis ajoutez votre propre point de vue. La page d'aide de Google vous indique d'ajouter la colonne « Invalid clicks » (Clics incorrects) au tableau de vos campagnes. Elle affiche les clics que Google a filtrés avant facturation, et Google ne vous les facture pas.
Votre propre point de vue vient de votre serveur. Journalisez l'identifiant de clic et l'IP du client sur votre page de destination, effectuez une requête par IP et comptez les clics par champ : hébergement, robot d'exploration vérifié, VPN, Tor, scanner. Comptez ensuite par préfixe /24 et /64 pour repérer les schémas irréguliers. C'est la partie de votre trafic invalide visible au niveau IP. Le reste relève des filtres de Google et de la procédure de crédit.
Choisissez une journée de clics payants, interrogez chaque adresse et comparez vos résultats avec la colonne « Invalid clicks ».
Questions fréquentes
Quelle est la différence entre le GIVT et le SIVT ?
Le trafic invalide général (GIVT) se repère avec des listes et des contrôles de routine, par exemple les robots d'exploration connus et les IP de datacenter associées à une activité invalide. Le trafic invalide sophistiqué (SIVT) exige des analyses avancées et une vérification humaine, par exemple pour des bots qui se font passer pour des utilisateurs, des appareils détournés et des clics incités.
Quelles sont les catégories de trafic invalide de Google ?
L'aide de Display & Video 360 de Google nomme trois catégories GIVT (data center, known crawler, irregular pattern) et six catégories SIVT (automated browsing, false representation, misleading user interface, manipulated behavior, incentivized behavior, undisclosed classification).
Le trafic VPN relève-t-il du GIVT ou du SIVT ?
Ni de l'un ni de l'autre par défaut. Le MRC exclut du GIVT de datacenter les artefacts de routage d'utilisateurs légitimes, et ne compte un proxy comme SIVT que lorsqu'il existe pour manipuler les décomptes de trafic. Un indicateur VPN vous renseigne sur le chemin, pas sur l'intention.
Tout le trafic de datacenter est-il du trafic invalide ?
Non. La catégorie de Google couvre les IP de datacenter associées à une activité invalide, et le MRC exclut la navigation légitime depuis des machines virtuelles. Dans notre requête, un simple serveur cloud a obtenu un score de 10 et a été autorisé.
Le trafic invalide est-il la même chose que la fraude au clic ?
Non. Le trafic invalide inclut des activités sans aucune intention de tromper, comme les robots d'exploration de moteurs de recherche vérifiés et les requêtes de préchargement. La fraude au clic en est la part délibérée.
Une requête IP peut-elle détecter le trafic invalide sophistiqué ?
Seulement en partie. Une requête IP peut révéler des anonymiseurs, des scanners et des correspondances avec des flux de botnets. Elle ne peut pas voir les fermes à clics, les proxys résidentiels, les annonces masquées ou empilées, le cookie stuffing ni l'usurpation de domaine.
L'équipe derrière l'API GeoIPHub
Rédigé par l'équipe GeoIPHub, les personnes qui développent l'API de renseignement IP GeoIPHub et son scanner. Les brouillons sont préparés avec l'aide de l'IA et relus par l'équipe ; les exemples d'API sont de vraies requêtes sur l'API en production, sauf mention « illustratif ».
