FlowKit

Détecter la fraude aux commandes e-commerce avec l'IA dans n8n

Publié le 3 septembre 2026 · 7 min de lecture

Un pic de commandes un vendredi soir devrait être une bonne nouvelle. Il l'est nettement moins quand la moitié provient de comptes créés dans l'heure, avec une adresse de livraison différente de l'adresse de facturation et un moyen de paiement testé sur plusieurs commandes à la suite — le scénario classique de la fraude à la carte volée ou du testing de cartes en amont d'un usage frauduleux ailleurs. Un examen manuel de chaque commande ne tient pas la charge dès que le volume dépasse quelques dizaines par jour, et un filtrage trop strict rejette des clients légitimes aussi vite qu'il bloque les fraudeurs. n8n permet de construire un scoring de risque qui tourne à chaque commande, avant expédition, sans dépendre d'un unique outil boîte noire.

Les signaux à combiner avant tout scoring

Un système fiable ne repose jamais sur un seul indicateur : il combine plusieurs signaux faibles, chacun anodin isolément mais révélateur une fois cumulé.

  • Écart adresse de facturation / livraison et pays de livraison différent du pays de la carte ou de l'IP de connexion.
  • Vélocité : plusieurs commandes en quelques minutes depuis la même IP, le même appareil ou des variantes du même email, avec des moyens de paiement différents (signature typique du card testing).
  • Incohérence panier : commande de valeur inhabituellement élevée pour un compte sans historique, ou panier composé uniquement d'articles à forte revente (électronique, cartes cadeaux) — un profil très différent d'un panier ordinaire.
  • Compte tout juste créé associé à une commande urgente en livraison express, combinaison qui laisse peu de temps à une vérification a posteriori.
  • Email jetable ou domaine générique couplé à un montant de commande élevé, alors que la majorité de votre base utilise des emails professionnels ou personnels stables.

Aucun de ces signaux ne suffit seul à qualifier une fraude — un client légitime peut très bien commander en urgence vers une adresse de livraison différente de la sienne (cadeau, déménagement). C'est la combinaison et la pondération qui font la différence, exactement le principe déjà détaillé dans notre guide de scoring du risque de churn par IA : plusieurs signaux faibles, une note composite, un seuil d'action plutôt qu'une règle binaire.

Construire le pipeline dans n8n

Le workflow démarre au moment le plus utile : juste après la création de la commande, avant l'expédition, jamais après.

  1. Trigger sur le webhook « nouvelle commande » de votre plateforme (Shopify, WooCommerce, ou Stripe pour un paiement direct) — voir notre guide de sécurisation des webhooks n8n pour valider la signature de la requête avant tout traitement, condition indispensable dès qu'un workflow peut déclencher une mise en attente automatique.
  2. Node HTTP Request vers un service de géolocalisation d'IP (gratuit jusqu'à un certain volume chez la plupart des fournisseurs) pour comparer pays de l'IP, pays de livraison et pays associé à la carte.
  3. Node Code qui calcule les signaux de vélocité en interrogeant les commandes récentes du même client, de la même IP ou du même appareil — stockées dans une table Supabase dédiée, sur le modèle de notre guide de connexion n8n + Supabase.
  4. Un node LLM avec un Structured Output Parser qui reçoit l'ensemble des signaux bruts (écarts géographiques, vélocité, ancienneté du compte, composition du panier) et renvoie un JSON structuré : un score de risque de 0 à 100, une explication courte en langage naturel, et une recommandation (« laisser passer », « mettre en attente », « examen manuel prioritaire »). Le raisonnement en langage naturel a un avantage concret sur un score opaque : la personne qui traite la file d'attente comprend immédiatement pourquoi une commande est remontée, sans devoir décoder des règles internes.
  5. Node IF/Switch qui route selon la recommandation, en suivant les principes de notre guide du routage conditionnel.

Sur la fiabilité de ce type de scoring, une revue systématique de la littérature publiée en 2025 dans la revue Computers par Baisholan, Dietz, Gnatyuk, Turdalyuly, Matson et Baisholanova, « A Systematic Review of Machine Learning in Credit Card Fraud Detection Under Original Class Imbalance » (voir sur Google Scholar), rappelle un point souvent oublié : la fraude reste, par nature, un événement rare comparé au volume total de commandes, et une bonne partie des études publiées rééquilibrent artificiellement leur jeu de données avant d'évaluer leur modèle — ce qui gonfle les taux de précision annoncés par rapport à des conditions réelles de production. Une étude antérieure de Isangediok et Gajamannage, présentée à l'IEEE International Conference on Big Data 2022 (« Fraud Detection Using Optimized Machine Learning Tools Under Imbalance Classes », voir sur Google Scholar), va dans le même sens en comparant régression logistique, arbres de décision, random forest et XGBoost précisément sous cette contrainte de classes déséquilibrées. Conséquence pratique pour ce workflow : ne fixez jamais un seuil de blocage automatique sur la seule confiance affichée par le LLM ou un score composite — calibrez-le sur quelques semaines de vos propres commandes, avec un humain qui valide les faux positifs et les faux négatifs avant d'augmenter l'automatisation.

Mettre en attente plutôt que rejeter

La tentation, une fois le scoring en place, est d'annuler automatiquement toute commande au-dessus d'un seuil. C'est presque toujours une erreur : un rejet automatique sur un client légitime coûte une vente immédiate et souvent la relation client durablement, alors qu'une commande mise en attente avec notification Slack ou email à l'équipe ne retarde l'expédition que de quelques heures.

  • Risque faible : la commande part directement en préparation, sans intervention.
  • Risque moyen : la commande est retenue, une notification part vers le canal de revue avec le score, l'explication du LLM et un lien vers la fiche client — sur le modèle de notre guide de tri des alertes de sécurité par IA, qui applique le même principe de priorisation à un autre type d'événement.
  • Risque élevé et récidive confirmée (même moyen de paiement déjà associé à une fraude avérée) : blocage automatique, seul cas où l'automatisation complète se justifie, car le signal n'est plus probabiliste mais un fait déjà constaté.

Boucler avec les litiges et impayés

Un score de risque qui n'apprend jamais de ses erreurs perd de sa valeur avec le temps. Chaque chargeback confirmé reçu via Stripe doit remonter automatiquement dans la table de commandes à risque, en réutilisant la logique détaillée dans notre guide de gestion des litiges et chargebacks Stripe par IA : le moyen de paiement, l'adresse IP et l'email associés à ce chargeback deviennent des entrées de la liste de vigilance consultée à l'étape 3 du pipeline, sans attendre une réévaluation manuelle du modèle. C'est un renforcement simple, fondé sur des faits confirmés plutôt que sur des prédictions, qui améliore le scoring bien plus vite qu'un réentraînement complet.

Fiabiliser en production

  • Déduplication : un client qui modifie son panier avant paiement final peut déclencher plusieurs webhooks de commande. Une clé de déduplication par identifiant de commande, sur le principe de notre guide sur les webhooks reçus en double, évite de scorer — et donc de mettre en attente — la même commande deux fois.
  • Panne du service de géolocalisation ou du LLM : le workflow ne doit jamais bloquer silencieusement une commande faute de réponse d'un service tiers. Un Error Workflow dédié route la commande vers l'examen manuel par défaut dès qu'une étape échoue, plutôt que de la laisser en attente indéfiniment.
  • Piste d'audit : chaque décision automatique (score, recommandation, action prise) doit être journalisée avec horodatage, sur le modèle de notre guide de piste d'audit RGPD avec Supabase — utile en cas de contestation d'un client bloqué à tort, et pour ajuster les seuils a posteriori sur des données réelles plutôt que sur une impression.

Pour resituer ce workflow dans une automatisation e-commerce plus large — synchronisation des stocks, gestion des commandes, retours — notre guide complet n8n pour l'e-commerce couvre l'ensemble de la chaîne autour de ce point de contrôle anti-fraude.

Pour aller plus loin

Ce même mécanisme — combiner plusieurs signaux faibles, les faire évaluer par un LLM en sortie structurée, puis router vers une action calibrée par niveau de risque — est au cœur du Pack Inbox IA (79 €), qui applique le même principe de tri et de scoring à une boîte mail. Pour la partie traçabilité et journalisation des décisions automatiques, indispensable dès qu'une commande client est mise en attente sur la base d'un score, le Pack Conformité & Audit (149 €) fournit la piste d'audit horodatée prête à l'emploi. Les trois packs réunis dans le Bundle FlowKit Complet (269 € au lieu de 347 € pris séparément) couvrent la chaîne complète, du tri des commandes entrantes jusqu'à la documentation de chaque décision.

FAQ

Questions fréquentes

Le scoring de fraude par IA remplace-t-il un vrai outil anti-fraude comme Stripe Radar ?

Non, il le complète. Stripe Radar ou l'équivalent de votre PSP analyse le paiement lui-même (empreinte de carte, historique réseau). Le workflow n8n décrit ici travaille en aval, sur des signaux propres à la commande — écart adresse/IP, vélocité, incohérence panier — et sert surtout à trier automatiquement les commandes à examiner manuellement, sans dépendre uniquement d'un seuil de risque unique.

Un modèle de machine learning est-il fiable pour détecter la fraude sur un petit volume de commandes ?

Avec prudence. Une revue systématique publiée en 2025 dans la revue Computers (Baisholan, Dietz, Gnatyuk, Turdalyuly, Matson et Baisholanova) souligne que la fraude reste un événement rare face au volume total de commandes, et que beaucoup d'études rééquilibrent artificiellement leurs données avant d'évaluer leur modèle — ce qui gonfle les scores de précision annoncés par rapport à des conditions réelles. Pour une PME avec peu d'historique de fraude confirmée, un système hybride règles + IA, calibré sur vos propres commandes, est plus robuste qu'un modèle entraîné ailleurs et importé tel quel.

Faut-il bloquer automatiquement une commande jugée à haut risque ?

Non, sauf risque extrême et récurrent déjà confirmé. La bonne pratique est de mettre la commande en attente (hold) et de notifier une personne pour validation manuelle sous quelques heures, plutôt que d'annuler automatiquement : un blocage automatique sur un client légitime coûte une vente et, potentiellement, la relation client, alors qu'une revue humaine rapide ne retarde l'expédition que de peu.

Bundle FlowKit Complet

269 €