Prévention de la fraude

Fraude des agents d'achat IA au checkout : stopper la fraude par bots grâce à l'IP sans bloquer les vraies ventes

Fraude des agents d'achat IA au checkout : lors de nos requêtes, une adresse ChatGPT-User vérifiée a obtenu 0 et un simple serveur cloud 10. Vérifiez l'agent, puis évaluez l'IP.

ParÉquipe GeoIPHubPublié le17 juin 2026Mis à jour le23 oct. 2026Temps de lecture19 min de lecture

Votre trafic de checkout qui convertit le mieux et votre fraude la plus coûteuse arrivent désormais des mêmes types de réseaux. Adobe a constaté que le trafic IA vers les sites de commerce de détail américains « convertissait 42 % mieux » que les visiteurs humains en mars 2026, un an après avoir converti 38 % moins bien (données Adobe via TechCrunch). Dans le même temps, le trafic automatisé a dépassé 53 % de l'ensemble du trafic web en 2025 (Imperva 2026 Bad Bot Report).

HUMAN Security indique que « 2,3 % de l'activité agentique se produit désormais sur les pages de checkout », et que « seul un demi pour cent sépare » le taux d'automatisation bénigne de celui de l'automatisation malveillante (HUMAN, mars 2026). Le comportement seul ne suffira pas à les trier.

Voici quatre requêtes réelles, pourquoi la correspondance du User-Agent est votre affaire, et une table de correspondance score-action qui préserve les vraies ventes réalisées par des agents.

Le card testing arrive des réseaux d'hébergement, pas du salon d'un acheteur.

Pourquoi bloquer les IP de datacenter et de proxy au checkout échoue dans les deux sens

Un blocage général des datacenters échoue parce qu'il est à la fois poreux et coûteux. Poreux, parce que les attaques les plus coûteuses n'ont pas besoin d'une adresse de datacenter. HUMAN affirme que « le volume de carding a bondi de 250 % depuis 2022 » et que « les tentatives de compromission de compte après connexion ont plus que quadruplé d'une année sur l'autre » (HUMAN). GeoIPHub ne détecte pas les proxys résidentiels : la fraude depuis des connexions domestiques doit donc être repérée par vos données de vélocité et de paiement. Notre article sur la fraude par proxy résidentiel explique pourquoi.

Coûteux, parce qu'il touche des personnes à qui vous voulez vendre :

Les vrais agents tournent sur des réseaux cloud. L'adresse ChatGPT-User vérifiée ci-dessous se trouve sur l'AS8075 de Microsoft et porte l'indicateur datacenter_ip.
Les utilisateurs d'Apple iCloud Private Relay partagent des adresses de sortie de relais exploitées sur des réseaux partenaires comme Cloudflare.
Le NAT de niveau opérateur place de nombreux abonnés derrière une seule adresse. La RFC 6598 réserve 100.64.0.0/10 comme espace d'adresses partagé à cet effet. Cloudflare a mesuré que « les IP CGNAT sont soumises à une limitation de débit trois fois plus souvent que les IP non CGNAT », alors que le taux moyen de bots était plus faible pour les adresses CGNAT, 7 % contre 13,1 % (Cloudflare).

Le type de connexion est donc une donnée pondérée, jamais un refus ferme. Notre article de référence sur la détection des bots par IP montre ce que chaque indicateur IP peut et ne peut pas prouver, avec cinq requêtes réelles.

Quatre appelants au checkout, quatre requêtes : ce que nous avons vu le 23 octobre 2026

Une adresse d'agent vérifiée obtient 0 et allow, et presque n'importe quel serveur cloud aussi. Nous avons effectué quatre requêtes sans clé entre 05:03:52 et 05:04:07 UTC le 23 octobre 2026, à 5 secondes d'intervalle :

ChatGPT-User : 104.208.184.193, le premier hôte de 104.208.184.192/28, le premier préfixe du fichier chatgpt-user.json d'OpenAI. Nous avons récupéré le fichier à 05:03 UTC. Il listait 234 préfixes IPv4, aucun IPv6, avec un creationTime du 20 octobre 2026.
Fetcher déclenché par l'utilisateur de Google : 107.178.192.1, dans 107.178.192.0/27 du fichier user-triggered-fetchers.json de Google.
Simple serveur cloud : 45.33.32.156, scanme.nmap.org, un hôte de test public chez Linode. Ce n'est pas un agent.
iCloud Private Relay : 104.28.46.99, une adresse de sortie de relais Apple sur Cloudflare.

Appelant	`crawler.verified` / `name` / `category`	`fraud_score`	`recommended_action`	Décision au checkout
ChatGPT-User, `104.208.184.193`	true / ChatGPTUser / ai	0	allow	Accepter comme agent de l'acheteur
Fetcher Google, `107.178.192.1`	true / GoogleUserTriggeredFetcher / fetcher	0	allow	Accepter
Serveur cloud, s'il se présentait comme un agent, `45.33.32.156`	false / none / none	10	allow	Vérification renforcée
Private Relay, `104.28.46.99`	false / none / none	9	allow	Accepter

Voici la requête ChatGPT-User, abrégée, avec l'imbrication conservée et les valeurs non modifiées :

GeoIPHub API

{
  "ip": "104.208.184.193",
  "asn": {
    "asn": 8075,
    "org": "MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft Corporation",
    "asn_type": "hosting",
    "connection_type": "datacenter"
  },
  "detection": {
    "is_hosting": true
  },
  "threat": {
    "is_crawler": true,
    "crawler": {
      "verified": true,
      "name": "ChatGPTUser",
      "operator": "OpenAI",
      "category": "ai",
      "verification_method": "ip_range_list"
    }
  },
  "scoring": {
    "fraud_score": 0,
    "recommended_action": "allow",
    "detection_methods": ["datacenter_ip", "no_ptr_datacenter", "verified_crawler"]
  }
}

Deux signaux d'hébergement se sont déclenchés, datacenter_ip et no_ptr_datacenter. Le signal disculpant verified_crawler a ramené le total à 0. Cette adresse n'a pas de DNS inverse, ni en direct ni dans nos données, donc le fichier de plages d'OpenAI est la seule preuve. Le fetcher Google présente le même schéma à 0, sauf que son nom d'hôte se résout : c'est donc rdns_hosting qui se déclenche au lieu de no_ptr_datacenter.

C'est la ligne du serveur cloud qui compte. Son 10 provient uniquement de datacenter_ip, dans la tranche allow (25 ou moins). Si cette requête était arrivée avec un User-Agent ChatGPT-User, le score indiquerait toujours allow. Seuls verified: false et name: "none" montrent que la revendication est fausse. C'est pourquoi la colonne de décision indique une vérification renforcée, et non une acceptation.

L'adresse de relais a obtenu 9, avec relay_ip comme seule méthode. Les relais sont plafonnés à 60, donc un utilisateur de Private Relay ne peut jamais atteindre block. Notre géolocalisation indique Luanda, en Angola, mais le flux de sortie d'Apple indiquait Lusaka, en Zambie, lorsque nous avons vérifié le 12 octobre 2026 : jugez donc les utilisateurs de relais au niveau du pays.

À 05:09 UTC, nous avons aussi interrogé 136.121.16.1, le premier hôte IPv4 du fichier user-triggered-agents.json de Google. Ce fichier couvre Google-Agent, dont Google dit qu'il « est utilisé par des agents hébergés sur l'infrastructure Google pour naviguer sur le web et effectuer des actions à la demande de l'utilisateur » (Google). L'adresse a été vérifiée comme GoogleUserTriggeredAgent, score 0, allow. Elle a aussi déclenché fcrdns_mismatch, alors qu'un dig en direct confirme son nom d'hôte par une recherche directe. C'est un bug de notre côté ; il n'a pas modifié le score, et nous l'avons enregistré.

Il s'agit de cinq requêtes effectuées un même matin, pas d'un benchmark. Les plages évoluent : relancez-les avant de copier une valeur.

La correspondance du User-Agent est le travail de votre code, pas de l'API

L'API prouve quel bot possède une adresse, et votre code prouve que la requête revendiquait ce même bot. Une requête IP ne voit jamais le User-Agent, donc GeoIPHub ne peut pas signaler seul un agent usurpé. C'est votre gestionnaire de checkout qui détient l'en-tête et qui doit faire la comparaison.

Les noms diffèrent d'un côté à l'autre. Le jeton User-Agent d'OpenAI est ChatGPT-User, et l'API renvoie ChatGPTUser sans le tiret. Le jeton de Google est Google-Agent, et l'API renvoie GoogleUserTriggeredAgent. Une comparaison littérale de chaînes échoue, alors gardez une petite table de correspondance :

GeoIPHub API

// User-Agent token mapped to threat.crawler.name as the API returns it (seen 2026-10-23)
const AGENT_NAMES = {
  "ChatGPT-User": "ChatGPTUser",
  "Google-Agent": "GoogleUserTriggeredAgent",
};

// Returns null when the request makes no agent claim,
// true when the claim matches a verified range, false when it doesn't.
function agentClaimHolds(userAgent, lookup) {
  const token = Object.keys(AGENT_NAMES).find((t) => userAgent.includes(t));
  if (!token) return null;
  const c = lookup.threat.crawler;
  return c.verified === true && c.name === AGENT_NAMES[token];
}

Un résultat false correspond à la ligne du serveur cloud ci-dessus : soumettez-le à une vérification renforcée ou refusez-le, quel que soit le score. La mise en œuvre complète avec nginx et Express, avec un test de GPTBot usurpé, se trouve dans notre guide pour savoir s'il faut bloquer les robots d'exploration IA.

Vérifiez la signature de l'agent avant d'évaluer son IP

Un identifiant ou une signature de protocole valide prime sur tout signal IP. Trois mécanismes répondent à la question « qui a envoyé ceci » plus fermement qu'un fichier de plages.

Agentic Commerce Protocol (ACP). Stripe a annoncé ACP le 29 septembre 2025 comme un standard ouvert « codéveloppé par Stripe et OpenAI » ; le dépôt de la spécification est sous licence Apache-2.0. Sa RFC Agentic Checkout rend obligatoires un jeton bearer Authorization, API-Version et, sur chaque POST, Idempotency-Key, et recommande Signature et Timestamp. Stripe indique que ses Shared Payment Tokens « sont limités à un marchand et à un montant de panier précis », ce qui restreint ce qu'un jeton volé permet d'acheter.

Web Bot Auth. Les agents signent chaque requête selon la RFC 9421 HTTP Message Signatures (Standards Track, février 2024). L'article de Cloudflare sur Web Bot Auth utilise les en-têtes Signature, Signature-Input et Signature-Agent et des clés Ed25519 publiées par le signataire.

Programmes d'agents des réseaux de cartes. Visa a construit son Trusted Agent Protocol « en collaboration avec Cloudflare » sur le standard HTTP Message Signature, afin de distinguer les agents de confiance « de l'automatisation malveillante et des bots malhonnêtes » (Visa, 14 octobre 2025). L'annonce de Cloudflare le même jour précise que « Mastercard intègre Web Bot Auth à Mastercard Agent Pay ».

Lors d'un appel ACP, la RFC indique que c'est ChatGPT qui appelle vos endpoints de checkout : l'IP de connexion appartient donc à la plateforme de l'agent, pas à l'acheteur. Vérifiez l'identifiant sur ce canal et réservez le scoring IP au trafic web direct. Notre guide pour vérifier les robots d'exploration et agents IA par IP, rDNS et Web Bot Auth détaille chaque vérification.

Pourquoi les listes d'autorisation d'IP seules sont fragiles, même pour les vrais agents

Une liste d'autorisation tenue à la main finit par casser, car les adresses des agents sont partagées et changent sans cesse. Cloudflare le dit clairement : « la logique selon laquelle des plages d'adresses IP représentent un produit ou un groupe d'utilisateurs est fragile ». L'entreprise ajoute que les connexions « peuvent être partagées par plusieurs utilisateurs, comme dans le cas des proxys de confidentialité et des VPN », et que les plages cloud « changent avec le temps » (Cloudflare).

Le propre fichier d'OpenAI montre cette dérive :

Date de récupération	Préfixes IPv4 dans chatgpt-user.json	`creationTime`
2026-10-06	230	2026-09-25
2026-10-23	234	2026-10-20

Le chiffre du 6 octobre 2026 provient de notre comparaison de GPTBot, OAI-SearchBot et ChatGPT-User. OpenAI précise aussi au sujet de ChatGPT-User que « ces actions étant initiées par un utilisateur, les règles robots.txt peuvent ne pas s'appliquer » (OpenAI).

Notre côté a aussi un décalage. GeoIPHub récupère à nouveau 19 fichiers de plages officiels et reconstruit sa base de recherche chaque jour, donc un nouveau préfixe peut mettre jusqu'à environ deux jours avant d'être vérifié. Traitez une correspondance de plage comme une corroboration forte, et préférez une signature lorsque l'agent en envoie une.

Fraude des agents d'achat IA : les menaces à l'étape du paiement

Trois attaques alimentent la fraude des agents d'achat IA au checkout, et aucune ne ressemble à une commande d'agent légitime, avec un panier pour un acheteur.

Card testing (énumération). Des rafales de tentatives de faible montant ou d'autorisation seule, avec des taux de refus élevés. Visa indique que les attaques par énumération entraînent « 1,1 milliard de dollars de pertes liées à la fraude chaque année », et que « trente-trois pour cent des comptes énumérés ont subi une fraude dans les cinq jours » (Visa, mai 2024).
Prise de contrôle de compte. Des identifiants volés utilisés pour acheter avec des cartes enregistrées. Imperva indique que les services financiers représentaient « 46 % des incidents de prise de contrôle de compte » (Imperva 2026). Notre guide de défense contre la prise de contrôle de compte couvre le volet connexion.
Scalping. Des bots qui accaparent les stocks limités lors des lancements très demandés.

Un card testing réparti sur de nombreuses adresses déjoue un compteur par IP : comptez donc aussi les refus et les cartes distinctes par ASN et par BIN.

Associer le score de 0 à 100 à une action au checkout

Un score de 0 à 100 n'est utile au checkout que si chaque tranche correspond à une action fixe. Le score de risque explicable de GeoIPHub couvre les données côté IP, et scoring.detection_methods nomme chaque signal déclenché. Votre code et vos données de paiement fournissent le reste :

Donnée	Effet sur la décision
Identifiant ACP ou signature Web Bot Auth valide	Canal de confiance, friction faible
`crawler.verified` à true et nom correspondant au User-Agent	Prime sur les signaux d'hébergement
User-Agent d'agent sans correspondance vérifiée	Vérification renforcée ou refus, quel que soit le score
Réseau d'hébergement (`datacenter_ip`)	Légère hausse, 10 à lui seul aujourd'hui
VPN ou sortie Tor	Forte hausse, souvent `block`
Relais (`relay_ip`)	Légère hausse, plafonnée à 60
Vélocité des cartes, des BIN et des refus par IP et par ASN	Forte hausse
Pays de l'IP différent du pays de facturation	Hausse, évaluée au niveau du pays

Associez ensuite les tranches à des actions :

Tranche	Score	Action au checkout
`allow`	0 à 25	Laisser passer, sauf si une revendication d'agent a échoué à la vérification
`review`	26 à 50	3-D Secure
`step_up`	51 à 75	3-D Secure, plus un contrôle de vélocité
`block`	76 à 100	Refuser ou mettre en attente pour examen manuel

Les plafonds maintiennent les adresses partagées hors de block. Une adresse de relais est plafonnée à 60, donc elle ne peut pas être refusée sur le seul score, et un plafond de 50 s'applique aux adresses que l'API identifie comme du NAT de niveau opérateur. ACP transporte aussi son propre signal de card testing : la RFC delegate-payment envoie des risk_signals de type card_testing avec une action blocked, manual_review ou authorized. C'est la plateforme de l'agent qui les renseigne ; votre score reste un contrôle distinct. Notre article sur les seuils de score de fraude IP pour la connexion, l'inscription et le checkout teste ces tranches sur cinq autres adresses.

Renforcer plutôt que bloquer : 3-D Secure transfère la responsabilité

Envoyez les tranches intermédiaires vers 3-D Secure au lieu de les refuser, car une vérification renforcée préserve la vente et transfère généralement le risque de rétrofacturation. Le guide de Trust Payments sur la responsabilité 3-D Secure v2 indique qu'après une authentification réussie, « l'émetteur de la carte sera responsable en cas de rétrofacturation frauduleuse dans la majorité des cas ». Il prévient aussi que « l'authentification réussie d'une transaction ne garantit pas le transfert de responsabilité ni l'autorisation de la transaction ».

Une vérification renforcée offre à un vrai acheteur un moyen de passer et oblige un testeur de cartes à prouver qu'il détient la carte. Notre guide sur les faux positifs de la détection VPN explique qui d'autre se retrouve dans cette tranche intermédiaire.

La question de l'agent autorisé est juridique, pas technique

La question la plus difficile est de savoir si l'agent a même le droit d'acheter chez vous. Le 9 mars 2026, le tribunal fédéral du district nord de Californie a accordé à Amazon une injonction préliminaire contre Perplexity. The Register rapporte que le juge a écrit que l'agent Comet de Perplexity « accède avec la permission de l'utilisateur d'Amazon mais sans l'autorisation d'Amazon » (The Register). Perplexity a fait appel et, le 4 août 2026, la cour d'appel du neuvième circuit a annulé l'injonction et renvoyé l'affaire devant le tribunal de district, où elle est toujours en cours.

Cette décision n'a pas tranché la question. Les vérifications IP vous disent qui a envoyé la requête. Vos conditions d'utilisation disent si cet expéditeur a le droit d'acheter.

Là où les vérifications IP échouent au checkout

Les signaux IP ne couvrent qu'une partie du tableau au checkout, et voici les lacunes connues :

Pas de détection des proxys résidentiels. La fraude depuis des connexions domestiques nécessite vos données de vélocité et de paiement.
Pas de visibilité sur le User-Agent. L'API ne signale jamais un agent usurpé ; c'est la correspondance de nom dans votre code qui le fait.
Décalage des plages et lacunes DNS. Un nouveau préfixe peut mettre environ deux jours avant d'être vérifié, et nous avons vu un faux fcrdns_mismatch ce matin.
Le NAT de niveau opérateur n'est pas signalé par plage aujourd'hui. Lorsque nous avons interrogé 100.64.0.1 le 22 octobre 2026, l'adresse n'a pas été marquée comme CGNAT. Ne construisez pas encore de règle sur cet indicateur.

Après toute modification de règle, suivez les faux positifs par segment, par exemple iOS Safari, opérateurs mobiles et Private Relay. Notre article sur la précision réelle de la géolocalisation IP explique pourquoi le pays l'emporte sur la ville.

L'intégrer dans votre gestionnaire de checkout

Intégrez cela côté serveur, sur l'endpoint de checkout, en quatre étapes :

Vérifiez d'abord tout identifiant ACP ou toute signature Web Bot Auth, et accordez le canal de confiance à ceux qui sont valides.
Interrogez l'IP de connexion, comme dans notre guide pour ajouter la détection de fraude IP à votre application avec l'API gratuite.
Appliquez la table de correspondance des User-Agents à threat.crawler.name. Une revendication d'agent qui échoue déclenche une vérification renforcée ou un refus.
Associez scoring.recommended_action au tableau des tranches, et ajoutez par-dessus votre vélocité par carte et par ASN.

Lorsqu'une décision semble erronée, suivez les étapes de comment enquêter sur une adresse IP pour comprendre pourquoi. Commencez par une adresse de vos propres logs de checkout qui s'est présentée comme ChatGPT-User cette semaine. Interrogez-la et comparez crawler.name à la revendication.

Faut-il bloquer les robots d'exploration IA ? Décider par bot, appliquer par IP Comment vérifier les robots d'exploration et agents IA par IP : DNS inverse, plages CIDR et Web Bot Auth GPTBot, OAI-SearchBot ou ChatGPT-User : lequel bloquer À partir de quel score de fraude IP faut-il bloquer ?Comment enquêter sur une adresse IP : 3 vraies IP, 3 verdicts

FAQ

Dois-je bloquer toutes les IP de datacenter ou de proxy au checkout pour stopper les bots ?

Non. Les vrais agents tournent sur des réseaux cloud : le 23 octobre 2026, une adresse ChatGPT-User vérifiée sur l'AS8075 de Microsoft a obtenu 0, allow. Les blocages généraux rejettent aussi les utilisateurs de Private Relay et du NAT de niveau opérateur (CGNAT). Pondérez l'hébergement dans le score et envoyez les tranches intermédiaires vers 3-D Secure.

Comment distinguer un agent d'achat IA légitime d'un bot frauduleux à l'étape du paiement ?

Vérifiez d'abord l'identité : un identifiant ACP ou une signature Web Bot Auth conforme à la RFC 9421. À défaut, interrogez l'IP, qui renvoie threat.crawler.verified et le nom du bot, et faites vérifier par votre code que ce nom correspond au User-Agent revendiqué par la requête.

Pourquoi une liste d'autorisation d'IP seule est-elle fragile pour les agents IA ?

Cloudflare souligne que les connexions d'un service d'exploration peuvent être partagées, comme avec les proxys de confidentialité et les VPN, et que les plages cloud évoluent dans le temps. Le fichier chatgpt-user.json d'OpenAI est passé de 230 à 234 préfixes IPv4 entre nos récupérations du 6 et du 23 octobre 2026.

Comment un score de risque IP de 0 à 100 doit-il se traduire en décision au checkout ?

Laissez passer allow (25 ou moins), envoyez review (50 ou moins) et step_up (75 ou moins) vers 3-D Secure, et refusez ou mettez en attente block (au-dessus de 75). Une revendication d'agent qui échoue à la vérification déclenche une vérification renforcée, quel que soit le score.

Passer par 3-D Secure nuit-il davantage à la conversion qu'un blocage ?

Un blocage fait perdre la vente à coup sûr ; une vérification renforcée offre à un vrai acheteur un moyen de passer. Trust Payments indique qu'après une authentification réussie, l'émetteur est responsable d'une rétrofacturation frauduleuse dans la majorité des cas, sans que ce soit garanti.

Est-il légal d'empêcher des agents IA d'acheter sur ma boutique ?

Cela dépend de l'autorisation, et ceci n'est pas un conseil juridique. En mars 2026, un tribunal fédéral a accordé à Amazon une injonction préliminaire contre Perplexity, dont l'agent Comet, selon le juge, accédait à Amazon avec la permission de l'utilisateur mais sans l'autorisation d'Amazon. La cour d'appel du neuvième circuit a annulé cette injonction en août 2026, et l'affaire est toujours en cours.

Rédigé par

Équipe GeoIPHub

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 ».

Suivez-nous sur LinkedIn

Partager cet article

Plus d'articles