Détection des fraudes dans les ERP : pourquoi les règles ne suffisent plus

Selon l' enquête de l'AFP sur la fraude et le contrôle des paiements , 79 % des organisations ont signalé des tentatives ou des fraudes avérées aux paiements en 2024, et ce chiffre reste obstinément élevé pour la troisième année consécutive. Ce taux n'a pas connu d'amélioration significative d'une année sur l'autre. Ce qui a changé, c'est la surface d'attaque : les processus de comptabilité fournisseurs, qui nécessitaient autrefois un accès interne, sont désormais ciblés par des acteurs externes utilisant des communications générées par l'IA, des identités de fournisseurs synthétiques et des techniques de substitution de comptes bancaires véhiculées par les canaux de messagerie classiques. La détection de la fraude dans les systèmes ERP, basée sur des règles, a été conçue pour un environnement de menaces différent. Elle montre aujourd'hui ses limites.

Contrôles anti-fraude ERP basés sur des règles : conçus pour hier

Chaque ERP intègre des mécanismes de contrôle de la fraude. La détection des factures en double signale les correspondances exactes au niveau du numéro et du montant. Les seuils d'approbation soumettent toute facture dépassant une valeur définie à un second vérificateur. Les demandes de modification des données fournisseurs déclenchent une notification. Ces contrôles sont opérationnels et fonctionnent dans les scénarios de fraude pour lesquels ils ont été conçus.

Le problème, c'est que la fraude s'est adaptée, et elle s'est adaptée plus vite que la plupart des fournisseurs d'ERP n'ont mis à jour leur logique de détection.

Plusieurs facteurs structurels ont aggravé la situation depuis 2024. L'intelligence artificielle générative a considérablement réduit le coût de création de communications falsifiées convaincantes : une attaque par compromission de messagerie professionnelle (BEC), qui nécessitait autrefois un expert en ingénierie sociale, peut désormais être conçue et personnalisée à grande échelle avec un minimum d'effort. Le nombre moyen de virements bancaires demandés lors d'attaques BEC a atteint 4 586 début 2025, selon une étude de Trustpair. Il ne s'agit pas d'un problème propre aux grandes entreprises, mais bien aux PME. Une facture dupliquée, dont la référence INV-891 a été modifiée en INV-0891, contourne la détection des doublons par correspondance exacte. Une demande de paiement de 24 900 $ provenant d'un fournisseur connu contourne le seuil d'approbation de 25 000 $. Une demande de modification de compte bancaire arrive par un courriel usurpé, dont le domaine est identique à celui du fournisseur. Aucun de ces cas ne déclenche les règles existantes, et tous représentent des scénarios courants dans les services comptables des PME.

C’est dans l’écart entre ce que détectent les contrôles basés sur des règles et ce qui se produit réellement que la détection de fraude ERP par IA crée de la valeur opérationnelle. Non pas en remplaçant les règles, mais en effectuant une seconde analyse parallèle qui examine les comportements plutôt que les seuils.

Quatre schémas de détection de fraude ERP que l'IA repère et que les règles ignorent

Détection des factures quasi-dupliquées. La correspondance approximative compare simultanément les factures selon plusieurs critères : numéro de facture, identifiant du fournisseur, montant, date, description des lignes et conditions de paiement. Un fraudeur qui modifie un seul chiffre du numéro de facture est tout de même repéré, car la combinaison du fournisseur, du montant et de la date correspond à un enregistrement existant dans le système. C’est ainsi que l’escroquerie INV-0891 est détectée. La logique de correspondance exacte, quant à elle, est inefficace.

Détection des anomalies comportementales. Chaque fournisseur possède un profil de paiement : montants habituels des factures, fréquence, catégories de lignes de facturation courantes et conditions de paiement acceptées par le passé. Un modèle d'IA, entraîné sur 18 mois d'historique de vos transactions, identifie le profil normal de chaque fournisseur. Une facture d'un fournisseur facturant habituellement entre 8 000 $ et 12 000 $ par mois, et qui arrive soudainement pour 47 000 $ au titre de « services de conseil », est signalée, non pas parce qu'elle dépasse un seuil, mais parce qu'elle ne correspond à aucune transaction enregistrée dans l'historique de ce fournisseur.

Nettoyage des données fournisseurs. La fraude aux fournisseurs fictifs, où un employé crée un fournisseur imaginaire dans la base de données et approuve des factures pour des services inexistants, est l'une des formes les plus courantes de fraude interne. Selon le rapport 2024 de l'ACFE, la fraude interne représente une part importante des pertes totales liées aux comptes fournisseurs. L'analyse des données fournisseurs par l'IA recherche des signaux structurels : fournisseurs partageant leurs adresses avec les employés, fournisseurs sans historique d'achats mais avec des paiements actifs, coordonnées bancaires apparaissant dans plusieurs fiches fournisseurs et numéros d'identification fiscale invalides. La validation classique par règles ne vérifie pas la cohérence de ces champs.

Surveillance des modifications de compte bancaire. La fraude à la messagerie fournisseur cible spécifiquement le processus de modification des coordonnées bancaires, car il est souvent peu contrôlé. Un attaquant compromet la messagerie d'un fournisseur, envoie une demande de mise à jour des coordonnées bancaires et attend le prochain cycle de paiement. La surveillance par IA signale les modifications de compte bancaire qui ne correspondent pas aux schémas de communication habituels du fournisseur, qui proviennent de domaines de messagerie différant d'un seul caractère du domaine légitime, ou qui surviennent dans les 30 jours suivant la création d'un nouveau fournisseur. Selon l'analyse de la fraude de Trustpair de 2026, 70 % des organisations s'appuient encore sur des rappels manuels pour valider les modifications de compte bancaire des fournisseurs. Un rappel manuel n'est pas un contrôle du système ; il s'agit d'un comportement humain qui peut être contourné.

Il convient de préciser un point concernant le suivi des comptes bancaires. Le chiffre de 70 % pour les organisations utilisant des rappels manuels concerne l'ensemble du secteur. Parmi les entreprises disposant d'un ERP standard et ne possédant pas de contrôles antifraude personnalisés, ce pourcentage est presque certainement plus élevé. Le processus de rappel fonctionne jusqu'à un certain point : un attaquant ayant compromis la messagerie d'un fournisseur peut intercepter la demande de rappel, y répondre de manière convaincante, et la modification du compte est effectuée. Il ne s'agit pas d'une vulnérabilité théorique, mais d'un vecteur d'attaque documenté dans de nombreux cas de fraude survenus entre 2024 et 2025.

Détection de fraude intégrée à l'ERP, et non ajoutée après coup

Il existe des outils de détection de fraude autonomes, dont plusieurs sont efficaces. Le défi architectural est le même qu'avec toute couche d'IA externe : les données de l'outil et celles de l'ERP sont toujours partiellement désynchronisées. Une modification des données de base des fournisseurs dans l'ERP n'est pas instantanément répercutée dans l'outil de détection de fraude. Une transaction approuvée dans l'ERP peut ne pas être visible pour l'analyse de l'outil de détection de fraude avant le prochain cycle de synchronisation. Ces décalages ne sont pas théoriques : ce sont les failles par lesquelles la fraude passe inaperçue.

L'intégration de la détection de fraude par IA dans un ERP personnalisé signifie que les modèles comportementaux s'exécutent sur les mêmes données transactionnelles, le même référentiel fournisseur et les mêmes journaux d'approbation que ceux utilisés pour tous les autres flux de travail. Aucune synchronisation n'est nécessaire. Une modification du référentiel fournisseur signalée par le modèle de détection d'anomalies peut entraîner le blocage immédiat des paiements en cours, sans attendre de transfert de données.

Chez Baseball Town , le système ERP Witify traite plus de deux millions de transactions de jetons d'adhésion et surveille en temps réel les habitudes d'utilisation de 50 000 comptes membres. La logique de détection des fraudes identifie les anomalies comportementales au niveau de la session, et non seulement au niveau de la transaction, car le système de détection a accès à l'intégralité du contexte d'activité au sein de la même base de données. Ce type de détection inter-contexte est architecturalement impossible lorsque l'outil de détection de fraude et le système opérationnel sont distincts.

Les limites réelles de la détection de fraude par IA

L'IA de détection de fraude réduit les risques, sans toutefois les éliminer. Les modèles entraînés sur des schémas historiques peuvent être surpris par des fraudes véritablement inédites. Les faux positifs représentent un coût réel : un paiement légitime signalé par le modèle de détection d'anomalies nécessite toujours une vérification humaine, et les alertes excessives incitent les équipes de comptabilité fournisseurs à ignorer les avertissements. Le réglage des seuils, la surveillance du modèle et l'examen périodique des éléments détectés et non détectés par le système constituent des tâches opérationnelles continues, et non une configuration ponctuelle.

Contrairement à ce que laissent entendre de nombreux fournisseurs de solutions de sécurité, la détection de fraude par IA dans un ERP n'est pas un système que l'on configure une fois pour toutes. Les modèles entraînés sur des schémas historiques peuvent être surpris par des fraudes véritablement inédites. Les faux positifs représentent un coût réel : un paiement légitime signalé par le modèle de détection d'anomalies nécessite toujours une vérification humaine, et un excès d'alertes incite les équipes de comptabilité fournisseurs à ignorer les avertissements. L'ajustement des seuils, la surveillance des modèles et l'analyse périodique des éléments détectés et non détectés par le système constituent des tâches opérationnelles continues.

Après avoir constaté ce phénomène sur plusieurs systèmes ERP, je suis d'avis que la détection de fraude par IA ne remplace pas les contrôles de processus, la séparation des tâches et les audits périodiques, mais les complète. L'association d'une conception de processus rigoureuse et de la détection d'anomalies par IA permet de détecter davantage d'anomalies que chaque élément pris séparément, tout en réduisant la charge de travail liée à un audit manuel. Ce n'est pas l'absence de ces deux éléments qui permet à une organisation de se maintenir sous le seuil des 79 % année après année.

L'environnement des menaces a évolué. La détection doit s'adapter, et pour cela, il faut un système capable d'apprendre de vos données plutôt que d'appliquer des règles que les fraudeurs ont appris à contourner depuis des années. C'est pourquoi il est essentiel d'intégrer la détection d'anomalies basée sur l'IA à un ERP personnalisé, plutôt que de se fier aux contrôles statiques fournis avec un système standard.