4 questions à poser pour vérifier qu’une plateforme de conformité à la lutte contre la criminalité financière est bien native IA

Dans notre enquête 2026 sur l’État de la criminalité financière, 93 % des 600 hauts dirigeants et responsables de la conformité interrogés ont déclaré utiliser, piloter ou évaluer une solution IA de fournisseur pour le filtrage de leurs clients. Cette forte proportion est presque aussi élevée que pour la surveillance des transactions (87 %). De toute évidence, l’IA n’est plus aujourd’hui un atout concurrentiel en matière de conformité : elle est devenue la norme.

Dès lors, il est inutile que les responsables de la conformité se demandent « Ce fournisseur utilise-t-il l’IA ? » puisque tous répondront oui. La question à poser désormais est de savoir, parmi ces arguments en faveur de l’IA, lesquels décrivent une architecture bâtie pour l’IA dès la couche de données pour gérer efficacement les risques de criminalité financière et lesquels décrivent des fonctionnalités IA greffées sur une plateforme basée sur des règles et qui n’avait pas été conçue pour l’IA.

Cette distinction est importante dans deux domaines où il devient de plus en plus difficile de faire illusion, à savoir lorsqu’apparaît une nouvelle typologie criminelle et que le système doit s’adapter sans avoir à attendre le cycle de versions suivant et lorsqu’une autorité réglementaire demande des explications justifiant une décision que le modèle a prise en quelques millisecondes et qu’elle interroge sur l’efficacité de cette décision. L’IA greffée ou rajoutée pose problème dans ces deux cas de figure tandis que l’architecture native IA est résolument conçue pour les prendre en charge.

La pression est bien réelle. Moins des deux tiers des établissements financiers (59 %) ont mis en place un dispositif complet d’assurance de l’IA pour garantir l’efficacité, l’auditabilité et la gouvernance des modèles IA. Les 41 % restants travaillent à se doter d’un tel dispositif. En parallèle, 43 % des responsables de la conformité classent l’explicabilité des fonctionnalités et des résultats de l’IA parmi les trois critères déterminants pour sélectionner un fournisseur IA. Le niveau d’exigences réglementaires augmente sur l’ensemble du marché de la conformité IA, et ce plus vite que la plupart des établissements ne parviennent à mettre en place les dispositifs de gouvernance nécessaires.

Les fournisseurs ayant conçu leurs moteurs de détection autour de règles et qui ont ajouté l’IA après coup ne peuvent pas s’adapter à des exigences réglementaires toujours plus élevées en améliorant la seule couche IA. Le principe architectural sur lequel repose le moteur de règles, dont la logique est écrite par des humains et exécutée par le système, n’a jamais été compatible avec des modèles adaptatifs ou des flux de travail agentiques. L’IA greffée sur un moteur de règles produit un système qui utilise l’IA. Une architecture native IA produit quant à elle un système conçu autour de l’IA à partir de la couche de données.

Quatre questions permettent de démarquer ces deux approches. Posez-les à chaque fournisseur qui revendique une conformité native IA.

1. L’IA est-elle la couche de détection ou bien une couche d’évaluation greffée sur un moteur de règles ?

L’architecture greffée avec de l’IA la plus répandue exécute un moteur traditionnel de règles qui est le détecteur principal et elle applique des modèles IA en arrière-plan pour évaluer, hiérarchiser ou supprimer les alertes générées par ce même moteur. Dans ce type de configuration, le moteur de règles reste la source canonique de vérité en matière de risques, l’IA faisant office de couche de gestion des alertes.

Une architecture native IA inverse le rapport avec les modèles IA qui servent de détecteurs. Ils ingèrent les données clients, transactionnelles et de paiement ainsi que les listes de sanctions et la couverture médiatique négative pour prendre directement une décision concernant le risque. Les règles peuvent continuer à fonctionner parallèlement aux modèles pour des obligations réglementaires spécifiques qui exigent une logique déterministe, mais elles ne constituent pas le signal principal. 

Le test pour l’acquéreur : Demandez au fournisseur ce qui est à l’origine de la première évaluation des risques dans son système. S’il répond que l’alerte est déclenchée par un moteur de règles avant d’être évaluée par l’IA, l’architecture a été enrichie. Si ce même fournisseur répond que la décision est directement prise par des modèles IA à partir d’un graphe de données unifié, l’architecture est native IA.

2. Le modèle s’adapte-t-il à l’évolution des typologies criminelles ou doit-il être réentraîné par des humains ?

Les typologies de criminalité financière n’attendent pas les cycles de versions trimestriels. La fraude aux paiements push autorisés (PPA), les réseaux rapides de comptes de mule et le blanchiment d’argent en tant que service sont tous survenus ou se sont développés dans des délais plus courts que le rythme de rafraîchissement des modèles de la plupart des fournisseurs. Un système qui dépend de règles écrites par l’humain ou d’un réentraînement programmé du modèle sera systématiquement à la traîne par rapport à la menace qu’il est censé détecter.

Une architecture native IA gère l’adaptation du modèle comme un processus continu. Les modèles de détection se perfectionnent à partir des données entrantes, font émerger de nouvelles caractéristiques et actualisent l’évaluation sans attendre une nouvelle version publiée par le fournisseur. L’apprentissage automatique (ML) prédictif et les grands modèles de langage (LLM) sont conçus pour ce type d’adaptation, ce qui n’est pas le cas des moteurs de règles. 

Le test pour l’acquéreur : Demandez combien de temps s’écoule entre la découverte d’une nouvelle typologie au sein des données de production et une amélioration mesurable de la détection. Si la réponse évoque un cycle de versions, l’écriture de règles par un analyste ou un rafraîchissement programmé du modèle pour le trimestre suivant, l’architecture ne s’adapte pas assez vite face au paysage de menaces.

3. L’IA peut-elle agir sur les alertes ou se contente-t-elle de les signaler ?

Si la détection se cantonne à générer des alertes, alors le coût le plus élevé de l’architecture subsiste, à savoir l’examen de la file d’attente des alertes par des analystes humains. La plupart des coûts opérationnels en matière de conformité ne sont pas liés à la détection des alertes, mais au travail à effectuer ensuite sur des alertes qui seront essentiellement des faux positifs ou des vrais positifs à faible risque. Un système qui se contente de signaler confie à un analyste humain l’examen de l’alerte que le moteur de règles a déclenchée : il ne fait pas évoluer la mission de l’analyste.

Une architecture native IA s’étend de la détection à la remédiation agentique. Les agents IA extraient le contexte des dossiers clients, de l’historique des transactions, des listes de sanctions et de la couverture médiatique négative, ainsi que du graphe de risques de la plateforme. Ils évaluent l’alerte, exécutent le scénario de remédiation et clôturent le cas avec un journal d’audit. Les dossiers soumis au jugement humain sont communiqués avec tout le contexte déjà joint. S’il est bien conçu, ce processus automatise jusqu’à 95 % de la remédiation classique, permettant ainsi aux analystes de se concentrer sur les alertes qui ont un véritable impact réglementaire, plutôt que celles qui monopolisent la journée de travail. 

Le test pour l’acquéreur : Demandez au fournisseur si l’IA produit des alertes que des humains doivent ensuite résoudre ou si elle résout les alertes que les humains examineront uniquement si elles leur sont remontées. La différence est le modèle d’exploitation.

4. L’explicabilité est-elle intégrée à l’architecture ou s’agit-il d’une couche de reporting à part ?

L’explicabilité n’est plus un module optionnel. 43 % des responsables de la conformité la classent parmi leurs trois critères déterminants pour choisir un fournisseur. 41 % des établissements n’ont pas encore pleinement adopté un dispositif d’assurance de l’IA, une lacune qui pourrait entraîner une exécution de l’IA en mode production sans gouvernance au niveau de l’architecture. Une couche IA rajoutée fournira généralement l’explicabilité via un module de reporting distinct qui reconstitue a posteriori le raisonnement ayant conduit à une décision. Cette reconstitution est souvent incomplète et ne résiste jamais bien à une autorité de réglementation qui demande pourquoi un modèle s’est comporté différemment pour deux dossiers semblables.

Une architecture native IA traite l’explicabilité comme une propriété du résultat du modèle plutôt que comme un rapport généré en aval. Chaque décision est accompagnée de ses justifications : les données fournies utilisées, les poids attribués aux différentes fonctionnalités, la logique de la politique appliquée et, le cas échéant, le parcours de l’examen réalisé par l’humain. La traçabilité est produite naturellement par le système et non pas une exportation. 

Le test pour l’acquéreur : Demandez à consulter le dossier d’audit de la décision que le système du fournisseur a prise dans un environnement client, de bout en bout. Si le fournisseur renvoie vers un module de reporting séparé, l’explicabilité est greffée. Si le dossier d’audit correspond aux éléments de fonctionnement du modèle, alors l’architecture est native IA.

Quelles conséquences pour le choix d’un fournisseur ?

Les plus grandes plateformes de paiement posent les 4 questions évoquées plus haut lorsqu’elles évaluent des fournisseurs de solutions de conformité parce que l’écart entre plateforme native IA et IA rajoutée ne se rétrécit pas en mode production : il s’élargit.

C’est sur une architecture native IA que s’appuie Marqeta. Plateforme moderne de paiements pour les acteurs mondiaux de l’innovation, dont Block, Uber et DoorDash, Marqeta a traité en 2025 près de 400 milliards de dollars en volume annuel de paiements. Marqeta déploie la plateforme complète ComplyAdvantage Mesh pour intégrer les renseignements sur les risques, le filtrage et la surveillance des transactions directement à sa couche de décision de paiement. Mesh exécute plus de 80 modèles IA spécialisés dans le filtrage, la surveillance et l’évaluation des risques, l’IA agentique gérant l’examen et la remédiation des alertes courantes, avec une explicabilité intégrée à chaque décision.

« Notre architecture native IA à schéma dynamique pour la prise de décision en matière de risques et nos fonctionnalités agentiques sont conçues pour fonctionner à la pointe en matière de rapidité et de capacité de montée en charge », déclare Vatsa Narasimha, CEO de ComplyAdvantage. « Tout aussi à la pointe, Marqeta est incontestablement une référence incontournable dans l’univers des paiements. Nous la fournissons avec une solution de conformité fiable et qui couvre l’ensemble de la pile technologique pour les fintechs et les plateformes à la demande qu’elle accompagne. »

Le marché ne se pose plus la question de l’avec ou du sans IA. Désormais, la question est de pouvoir différencier les plateformes de conformité architecturées autour de l’IA de celles auxquelles des ressources IA ont été ajoutées. Les premières suivent le développement des établissements qui les utilisent, s’adaptent à l’évolution des typologies criminelles et expliquent chaque décision prise. Les secondes remplissent en partie les mêmes fonctions, mais sous certaines conditions. Lorsque les paiements en temps réel, les modèles opérationnels agentiques et l’augmentation des exigences réglementaires se cumulent, cet écart ne se réduit pas. Les plateformes de conformité bâties dès le départ autour de l’IA résisteront à cette pression, ce que ne pourront pas faire celles qui ont ajouté l’IA a posteriori.