Comment prévenir la fraude au paiement avant l'émission du virement ?

Un groupe français de brasseries a intercepté une tentative de fraude qui aurait viré 28 000€ sur le compte d'un fraudeur. La facture semblait légitime, le fournisseur semblait légitime, l'approbation comptable était passée. La détection a eu lieu dans une fenêtre que la plupart des équipes finance ignorent : les 60 secondes entre "facture approuvée" et "virement émis". C'est précisément dans cette fenêtre que se joue la prévention de la fraude au paiement, et c'est là que la majorité des dispositifs de contrôle s'arrêtent trop tôt.

L'enquête AFP 2025 sur la fraude aux paiements indique que 79% des organisations ont subi une tentative ou un cas avéré de fraude en 2024, avec le BEC (business email compromise) en tête à 63%. Le rapport 2024 de l'Internet Crime Complaint Center (FBI) recense plus de 16 milliards de dollars de pertes liées à la cyber-fraude, en hausse de 33% sur un an, dont 2,77 milliards directement attribuables au BEC. Le pattern est constant : la facture arrive, paraît crédible, est approuvée, et la fraude se déclenche au moment de l'émission du virement, pas au moment de l'approbation.

Cet article cartographie ce qui doit se passer entre l'approbation et l'émission. Six contrôles avant émission, chacun couvrant une surface d'attaque différente : croisement RIB, vérification des changements de coordonnées bancaires, rapprochement paiement-facture au niveau du fichier, double validation par seuil, vérification hors-bande résistante aux deepfakes, et intégrité du fichier de paiement. Faites tourner les six et le playbook BEC cesse de fonctionner. Sautez-en un seul et le virement part avant que quiconque ne s'en aperçoive.

Pourquoi le pré-paiement est la vraie fenêtre d'attaque

Les contrôles AP sont construits autour de la facture : a-t-elle matché le BC, est-elle passée par la matrice de délégation, la bonne personne l'a-t-elle approuvée. Ces contrôles répondent à la question "cette transaction est-elle légitime ?". Ils ne répondent pas à la question "cette transaction part-elle bien sur le bon compte ?".

C'est dans l'écart entre ces deux questions que vit la fraude moderne. Une facture authentique d'un fournisseur authentique peut très bien partir sur un RIB frauduleux si les coordonnées bancaires ont été modifiées entre l'approbation et l'émission. Les changements de RIB fournisseur sont aujourd'hui une cible de premier rang pour les attaquants, qui ont compris qu'exploiter le workflow de paiement va plus vite et rapporte plus que de pénétrer les systèmes IT.

Le déplacement de regard que cet article propose : arrêter de traiter l'approbation comme le dernier garde-fou. L'approbation valide la facture. Le pré-paiement valide le virement. Ce sont deux contrôles différents, et seul le second arrête une attaque par détournement de fonds.

Cela reformule complètement ce qu'on entend par "prévention de la fraude au paiement". On quitte le terrain des conseils génériques (formation des équipes, MFA, rappel téléphonique) pour entrer dans une pile de contrôles spécifiques. Cette pile s'exécute dans la fenêtre last-mile entre approbation et émission, et elle traite quatre vecteurs d'attaque simultanément : BEC, usurpation fournisseur (VEC), fraude au faux RIB, et arnaque à l'urgence boostée par les deepfakes.

Les 6 contrôles avant émission qui arrêtent la fraude au release

1. Croisement RIB contre la base fournisseurs

Le premier contrôle pré-virement confirme que le RIB de destination correspond bien à celui enregistré sur le fournisseur dans le référentiel. Pas "le fournisseur existe dans la base" mais "le RIB de ce fichier de paiement correspond au RIB de ce compte fournisseur". Un écart, ne serait-ce que d'un caractère, bloque le virement.

C'est le contrôle qui attrape le pattern de fraude au virement le plus courant : une facture approuvée avec le RIB légitime voit ses coordonnées bancaires modifiées avant l'émission. L'attaque fonctionne parce que la plupart des pipelines vérifient le RIB au moment de l'approbation et ne le revérifient jamais au moment du release. Une validation des données bancaires robuste s'exécute au moment exact où le fichier de paiement est généré, pas plusieurs jours en amont quand la facture a été approuvée.

2. Vérification des changements de RIB fournisseur (hors-bande)

Quand un changement de coordonnées bancaires a été enregistré sur un fournisseur dans les jours qui précèdent un virement, le changement lui-même devient le déclencheur. Le changement a-t-il été vérifié par rappel sur un numéro connu ? La vérification a-t-elle été tracée avec l'identité de la personne qui l'a effectuée, l'horodatage, et la source du nouveau RIB ? Si l'une de ces réponses est non, le virement reste en pause jusqu'à ce qu'elles soient toutes oui.

La vérification doit impérativement être hors-bande, c'est-à-dire passer par un canal de communication différent du canal qui a porté la demande de changement. L'email ne compte pas comme canal de vérification : c'est précisément le canal que l'attaquant a compromis. L'agent Détection des fraudes au faux RIB intercepte spécifiquement les événements de changement bancaire pour faire respecter ce protocole avant tout mouvement de paiement. La Loi Sapin II, dans son volet anti-corruption, ajoute par ailleurs une exigence de traçabilité documentée que cette couche couvre nativement.

3. Rapprochement paiement-facture au niveau du fichier

Le troisième contrôle confronte le fichier de paiement aux factures sous-jacentes. Chaque ligne du batch SEPA correspond-elle à une facture approuvée ? Le montant de la ligne de paiement égale-t-il le montant de la facture ? Y a-t-il dans le batch des factures qui n'ont pas été approuvées, ou des factures approuvées absentes du batch ?

Ce contrôle attrape la falsification de fichier : un fraudeur qui a accès au fichier de paiement (via une credential compromise ou un complice interne) peut ajouter une ligne, modifier un montant, ou substituer un IBAN. Aucune de ces modifications ne touche aux factures, donc les contrôles AP ne les voient pas. Une réconciliation au niveau du fichier entre instructions de paiement et factures sources est la seule chose qui les détecte.

4. Double validation avec escalade par seuil

Le quatrième contrôle reprend le principe classique des quatre yeux, mais appliqué au moment du release du virement, pas au moment de l'approbation comptable. Tout virement déclenchera une seconde paire d'yeux selon une matrice de seuils.

L'escalade par seuil affine le mécanisme : tout virement supérieur à 10 000€ exige un second valideur. Tout virement supérieur à 50 000€ exige un second valideur plus une vérification hors-bande. Tout virement vers un fournisseur dont le RIB a changé dans les 30 derniers jours exige les deux, indépendamment du montant. Les seuils et déclencheurs d'escalade doivent être codés dans le workflow, pas dans la mémoire des opérateurs, parce que la mémoire humaine flanche sous pression de deadline (notamment les vendredis après-midi, fenêtre statistiquement la plus exploitée par les attaquants).

5. Vérification hors-bande résistante aux deepfakes

Une nouvelle surface de menace est apparue dans les données 2024-2026. Le rapport AFP 2026 sur la fraude aux paiements examine pour la première fois l'impact des fraudes activées par l'IA et des technologies de deepfake, avec une inquiétude croissante sur l'usage de la voix et de la vidéo synthétiques pour usurper l'identité de dirigeants, de fournisseurs ou d'autres tiers de confiance.

Cette évolution casse le protocole standard "rappel sur un numéro connu" si l'attaquant peut spoofer ou cloner la voix à l'autre bout de la ligne. La contre-mesure est en couches : les rappels ne se font qu'à des numéros issus de la base fournisseurs (jamais à un numéro tiré de l'email ou de la facture), les vérifications incluent un élément non-vocal (confirmation écrite, accusé de portail, échange de code), et toute demande "urgente" ou présentée comme un "override exécutif" déclenche obligatoirement un délai de carence plutôt qu'une accélération. Les demandes de virement de dernière minute, les changements d'instructions de paiement à la dernière seconde, ou les pressions à l'exécution immédiate doivent être traitées comme des signaux d'alerte et non comme des contraintes opérationnelles.

6. Intégrité du fichier de paiement à la soumission

Le dernier contrôle est technique : le fichier de paiement soumis à la banque doit être strictement le même que celui qui a été approuvé. On hashe le fichier au moment de l'approbation. On le hashe à nouveau au moment de la soumission. Si les deux hash diffèrent, c'est qu'une modification est intervenue entre les deux. Le virement est mis en pause jusqu'à ce que la modification soit identifiée et autorisée.

C'est le contrôle qui ferme la dernière surface d'attaque : la falsification en vol entre le système AP et le portail bancaire. Sans intégrité du fichier, tous les contrôles précédents en amont peuvent passer au vert et le virement partir quand même avec un IBAN substitué. Avec ce contrôle, le système peut prouver que ce qui a été approuvé est exactement ce qui a été soumis. Cette traçabilité technique nourrit aussi la cartographie des risques que la Loi Sapin II demande aux entreprises concernées de tenir à jour.

Pourquoi la plupart des dispositifs pré-virement sont incomplets

Tout DAF décrirait son dispositif comme "robuste". Très peu d'équipes finance font tourner les six contrôles pré-virement. Trois raisons structurelles :

Le handover entre comptabilité fournisseurs et trésorerie est l'angle mort. La comptabilité fournisseurs est responsable de l'approbation. La trésorerie est responsable de l'émission du virement. La fenêtre pré-paiement vit entre les deux, et l'ownership est ambigu. Le croisement RIB au moment du release n'est pas le job de la compta (la facture a déjà été approuvée) et n'est pas le job de la trésorerie (la trésorerie exécute ce que la compta a approuvé). C'est le job de personne, donc il ne tourne pas.

La vérification manuelle par rappel ne scale pas avec le volume. Un Trésorier qui vérifie 50 virements par semaine s'en sort. Le même Trésorier à 500 virements par semaine fait des échantillons. Les équipes finance comprennent le risque mais peinent à maintenir, face aux menaces cyber, la même discipline de contrôle qu'elles appliquent aux audits et aux rapprochements. Le problème n'est plus la conscience du risque, c'est la capacité opérationnelle.

Les pistes d'audit pour les contrôles pré-paiement sont anémiques. L'approbation laisse une piste d'audit propre. L'émission du virement laisse un journal de transaction. La vérification qui s'est passée (ou ne s'est pas passée) entre les deux vit le plus souvent dans un fil d'email, un message Teams, ou la mémoire du Trésorier. Quand la fraude ressurgit, la question "le RIB a-t-il été vérifié ?" reste fréquemment sans réponse documentée. Une piste d'audit native sur les contrôles pré-paiement est le correctif structurel.

Comment les agents IA ferment la fenêtre pré-paiement

La détection de fraude à base de règles s'en sortait honnêtement sur les contrôles 3 et 6 : réconciliation au niveau du fichier, escalade par seuil, vérification de hash. Elle calait sur les contrôles 1, 2 et 5 : matching sémantique de RIB quand le référentiel contient des fautes de saisie, détection de changement fournisseur quand le changement vient d'un domaine email légèrement différent, reconnaissance de patterns d'urgence quand le langage est naturel.

Les agents IA ferment ce gap avec le pattern d'architecture que Phacet déploie sur toute la pile :

L'agent Détection des fraudes au faux RIB couvre les contrôles 1 et 2 à chaque émission de virement. Il croise le RIB du paiement contre le référentiel, détecte les changements bancaires sur une fenêtre de lookback paramétrable, fait respecter le protocole de vérification hors-bande, et bloque le virement jusqu'à ce que la vérification soit tracée. Chaque contrôle, chaque blocage, chaque override est horodaté dans la piste d'audit.

L'agent de fiabilisation de la base fournisseurs entretient le référentiel sur lequel le contrôle 1 s'appuie. Il détecte les doublons, remonte les comptes homonymes proches, et conserve l'historique des RIB que la logique de détection de changement vient interroger. Sans une base propre, le croisement RIB renvoie des faux négatifs.

L'agent de matching 3 points alimente le contrôle 3 en maintenant le lien entre facture approuvée et ligne de paiement. Quand le fichier de paiement est généré, chaque ligne se rattache à une facture dont le BC, le contrat et le bon de livraison ont été vérifiés.

L'agent Contrôler la facturation fournisseur et réduire les surcoûts apporte la protection amont : il attrape les patterns de variance de prix et de surfacturation que les fraudeurs utilisent pour glisser des montants supplémentaires dans des factures par ailleurs légitimes. Le contrôle tourne au niveau AP, mais il réduit le volume que la couche pré-virement doit filtrer.

Chaque agent suit le même pattern à trois temps : il structure l'input (RIB, événement de changement, fichier de paiement), contrôle contre une référence (référentiel, historique, hash), puis expose le résultat avec sa justification complète. Les agents tournent sur 100% des virements, pas sur un échantillon, ce qui est la seule façon de tenir le rythme du volume. Combinez cela avec la couche élargie de contrôles financiers automatisés et la fenêtre pré-paiement cesse d'être un angle mort.

Ce que donne une couverture pré-virement à 100% en production

Trois résultats clients illustrent ce qui change quand les six contrôles pré-virement tournent sur chaque paiement :

La Nouvelle Garde (10 brasseries) a intercepté 28 000€ de tentative de fraude grâce aux contrôles RIB et aux contrôles de changement bancaire qui tournaient dans la fenêtre pré-virement. Théo Richard, le CFO, décrit Phacet comme "un membre de l'équipe qui opère 24h/24", ce qui est exactement le point d'architecture : des contrôles pré-paiement qui tournent à vitesse machine attrapent ce que des contrôles manuels à vitesse humaine vont nécessairement laisser passer. La tentative de fraude correspondait au pattern manuel : facture d'apparence légitime, fournisseur plausible, RIB modifié. Les contrôles de niveau AP l'auraient laissé passer. Les contrôles pré-virement l'ont bloqué.

Astotel (18 hôtels) a récupéré environ 5 000€ par an en faisant remonter des surfacturations fournisseur, ce qui alimente la couche de protection amont. Moins de surface d'attaque en amont signifie moins de volume de paiements légitimes en compétition pour l'attention des opérateurs sur les contrôles pré-virement. Sa Directrice Achats résume : "Je repère des erreurs que je n'aurais jamais vues seule."

Vivason (audioprothésiste, retail multi-sites) a identifié 180 000€ par an de surfacturation fournisseurs avec exactement la même pile de contrôles amont. Le pattern est constant : les contrôles pré-paiement fonctionnent d'autant mieux que les contrôles factures en amont tournent aussi, parce que les deux couches se renforcent l'une l'autre. Sans contrôles au niveau de la facture, la couche pré-virement se noie dans le bruit. Sans contrôles pré-virement, la couche facture laisse ouverte la surface de l'attaque par détournement.

Le fil rouge des trois cas : la variance et la fraude n'étaient pas plus importantes après la mise en place des contrôles, elles sont devenues visibles. Récupérer des fonds une fois la fraude consommée est extrêmement difficile, presque impossible. Le pré-paiement est la dernière chance réaliste d'arrêter un virement frauduleux, parce qu'à la seconde où les fonds ont settle, le processus de récupération juridique a déjà perdu la course.

Foire aux questions

Qu'est-ce que la prévention de la fraude au pré-paiement, exactement ?

La prévention de la fraude au pré-paiement est l'ensemble des contrôles qui s'exécutent entre l'approbation comptable d'une facture et l'émission du virement. Elle traite ces deux événements comme deux portes de contrôle distinctes plutôt que comme un seul instant, et fait tourner des vérifications sur les instructions de paiement elles-mêmes, pas seulement sur la facture sous-jacente. L'objectif est d'attraper les patterns de fraude (BEC, faux RIB, falsification de fichier) que le processus d'approbation ne voit pas. Plus de détail dans notre entrée glossaire sur les contrôles avant paiement.

En quoi la fraude au pré-paiement diffère-t-elle de la fraude à la facture ?

La fraude à la facture manipule le document (fausse facture, doublon, montant gonflé) et est mieux attrapée par les contrôles au niveau de la facture, avant l'approbation. La fraude au pré-paiement manipule les instructions de paiement (RIB modifié, bénéficiaire substitué, falsification en vol) et passe à travers les contrôles factures parce que la facture elle-même est légitime. Les deux exigent des contrôles différents. La couche contrôle avant décision attrape la première ; la couche pré-virement attrape la seconde.

Qu'est-ce que le BEC et pourquoi est-ce le premier vecteur de fraude ?

BEC est l'acronyme de business email compromise (fraude au président, fraude au fournisseur par email compromis). Les fraudeurs utilisent désormais des outils dopés à l'IA pour rédiger des emails crédibles, hijacker des fils d'email légitimes, et usurper l'identité de fournisseurs ou de dirigeants. C'est le premier vecteur parce qu'il contourne entièrement les contrôles techniques : l'email est réel (envoyé depuis une boîte compromise), la demande paraît légitime, et la personne qui exécute agit en bonne foi. La défense est procédurale : vérification hors-bande, double validation, et contrôles RIB pré-virement qui ne font pas confiance au canal email. Plus de détail dans notre entrée glossaire sur la fraude au faux RIB.

Comment les deepfakes changent-ils les contrôles pré-paiement ?

Les outils de voix et de vidéo synthétiques rendent moins fiable le rappel à un numéro connu : un attaquant peut cloner la voix d'un dirigeant ou usurper un fournisseur en visioconférence. La contre-mesure est en couches : rappel à un numéro issu uniquement de la base fournisseurs, complété par un canal non-vocal (confirmation écrite, accusé de portail, échange de code), et délais de carence obligatoires sur toute demande "urgente" ou "override exécutif".

Une PME doit-elle vraiment exécuter les six contrôles pré-virement ?

Oui, par ordre de priorité. Le croisement RIB, la vérification des changements bancaires, et la double validation par seuil (contrôles 1, 2 et 4) sont non négociables à toute taille. Le rapprochement paiement-facture, la vérification résistante aux deepfakes, et l'intégrité de fichier (3, 5 et 6) montent en puissance avec le volume de paiements et l'exposition aux menaces. Dans les équipes réduites où le staffing limite la double validation, des contrôles compensatoires (délai entre approbation et release, revue quotidienne de tous les virements, regard externe sur les montants au-dessus d'un seuil) tiennent le rôle.

Construisez la pile de contrôle last-mile

La question "comment prévenir la fraude au paiement avant l'émission du virement ?" est en réalité une question sur ce qui se passe pendant les 60 secondes que personne ne possède. La compta a signé. La trésorerie est sur le point d'émettre. La fraude vit dans cet écart.

La réponse est une pile en six contrôles qui tourne dans cet écart et qui traite les instructions de paiement comme un objet distinct de la facture. Faites tourner les six contrôles sur chaque virement et le playbook BEC cesse de fonctionner au niveau des instructions bancaires. Sautez-en un seul et l'attaque par détournement reste viable.

Les clients Phacet déploient typiquement l'agent Détection des fraudes au faux RIB en premier (contrôles 1 et 2 en production en moins de deux semaines), puis ajoutent l'agent base fournisseurs et l'agent matching 3 points pour alimenter les contrôles amont (3 et 4), et utilisent la piste d'audit native pour fermer la boucle d'intégrité de fichier (6). Les 40+ agents du catalogue ont été construits sur 100+ déploiements réels, ce qui veut dire que les contrôles reflètent ce dont les équipes finance ont effectivement besoin en production, pas ce qui rend bien sur une page produit.

L'approbation rend la facture honnête. Le pré-paiement rend le virement honnête. Ce sont deux jobs différents, et le virement, lui, ne revient pas.