IA explicable en LBC/FT : SHAP, activation selon le principe des quatre yeux et coupe-circuit

Un modèle qui classe un client à risque élevé sans pouvoir vous dire pourquoi n'est pas un actif pour votre programme de conformité ; c'est un passif qui n'attend qu'un inspecteur. La promesse de l'intelligence artificielle dans la lutte contre le blanchiment de capitaux et le financement du terrorisme (LBC/FT) est réelle : une meilleure priorisation des alertes, moins d'heures perdues sur des faux positifs évidents, une détection plus précoce de schémas qu'une règle manquerait. Mais cette promesse ne tient que si chaque décision à laquelle le modèle prend part peut être expliquée, contestée et infirmée par un humain, et si le modèle lui-même est gouverné comme l'élément d'infrastructure lourd de conséquences qu'il est. L'IA explicable en LBC/FT — les 3 principales raisons SHAP, les scores de confiance, le contrôle par un humain dans la boucle, l'activation selon le principe des quatre yeux, la surveillance de la dérive et un coupe-circuit — est ce qui transforme un modèle ingénieux en un modèle défendable.

Cet article porte sur cette distinction. Il explique pourquoi une notation en boîte noire ne résiste pas à la gouvernance du risque de modèle, ce que l'explicabilité doit concrètement afficher à l'écran devant un analyste, et comment les contrôles qui entourent un modèle — registre, activation, surveillance, retour arrière et journalisation des décisions — maintiennent l'IA dans les limites que tracent les autorités de contrôle et votre propre politique de risque de modèle. Pour la place de l'IA dans le programme au sens large, aux côtés de l'évaluation des risques, du filtrage, de la surveillance et des déclarations, consultez le guide complet de la plateforme LBC/FT. Le présent article se concentre sur le modèle lui-même et sur la gouvernance qui l'entoure.

Pourquoi la notation en boîte noire est incompatible avec la gouvernance LBC/FT

La gestion du risque de modèle repose sur un ensemble d'attentes bien établies, antérieures à la vague actuelle d'apprentissage automatique. Un modèle qui influe sur une décision réglementée doit être compris par ceux qui s'y fient. Ses hypothèses doivent être documentées, ses performances surveillées, ses limites connues, et ses résultats soumis à une remise en question humaine effective. Les autorités de contrôle attendent des établissements qu'ils sachent comment leurs modèles fonctionnent, et pas seulement qu'ils fonctionnent.

Un score en boîte noire enfreint toutes ces attentes à la fois. Lorsqu'un modèle renvoie « 0,87 » et rien d'autre, l'analyste ne peut pas savoir si ce chiffre traduit un véritable signal d'alerte ou un artefact des données d'entraînement. Le responsable LBC/FT ne peut pas expliquer à un régulateur les décisions de l'établissement en matière de risque. La fonction de validation ne peut pas vérifier que le modèle fait ce qu'il prétend faire. Et lorsque quelque chose tourne mal — une catégorie de clients systématiquement signalée à l'excès, un corridor d'activité discrètement manqué —, il n'y a aucun fil à tirer, parce que le raisonnement n'a jamais été exposé au départ.

L'échec n'est pas seulement technique ; il est aussi procédural. Les décisions LBC/FT doivent résister à l'examen longtemps après avoir été prises. Une décision relative à une activité suspecte prise aujourd'hui peut être remise en question lors d'un contrôle dans deux ans. Si la seule trace de la contribution du modèle est un nombre opaque, l'établissement ne peut pas reconstituer pourquoi un client a fait l'objet d'une escalade ou a été mis hors de cause. La décision devient indéfendable non pas parce qu'elle était erronée, mais parce qu'on ne peut pas démontrer qu'elle était raisonnée. Voilà pourquoi l'explicabilité n'est pas une fonctionnalité accessoire greffée sur un modèle LBC/FT. C'est la condition préalable à toute utilisation du modèle.

Ce que l'explicabilité doit afficher à l'écran

L'explicabilité est concrète, pas une simple aspiration. Dans la Plateforme LBC/FT de Creodata, le service d'inférence IA est conçu pour que chaque surface d'IA — partout où un modèle contribue à un score ou à une recommandation — comporte les quatre mêmes éléments, visibles par l'analyste au moment de la décision.

• Une étiquette d'identité. Chaque surface d'IA affiche une étiquette « AI · modèle · vversion ». L'analyste voit, sans avoir à chercher, que l'IA est intervenue, quel modèle a produit le résultat et dans quelle version. Aucun jugement automatisé caché ne se fait passer pour un fait du système.
• Les 3 principales raisons SHAP. Chaque score est accompagné des trois facteurs qui l'ont le plus influencé, issus d'une attribution de type SHAP. Au lieu de « 0,87 », l'analyste voit les trois variables qui font monter ou baisser le score — l'exposition pays, le schéma de transactions, le signal de filtrage —, classées selon leur contribution. Le raisonnement est visible en surface, et non enfoui dans un modèle que l'analyste n'ouvrira jamais.
• Un pourcentage de confiance. Le résultat indique le degré de confiance du modèle. Un signalement à forte confiance et un signalement marginal ne se lisent pas de la même façon, et l'analyste peut les pondérer en conséquence au lieu de traiter chaque score comme également certain.
• Une commande humaine Accept / Modify / Reject. Le modèle propose ; l'humain dispose. Chaque surface d'IA donne à l'analyste une commande explicite pour accepter le résultat du modèle, le modifier ou le rejeter purement et simplement. Le modèle n'agit jamais de lui-même. Il alimente une décision humaine, sans jamais s'y substituer.

Voilà ce que signifie concrètement l'humain dans la boucle. On ne demande pas à l'analyste d'entériner les yeux fermés un nombre qu'il ne peut pas interroger. On lui remet une suggestion étiquetée, expliquée et quantifiée, ainsi qu'un moyen clair de passer outre. Ce même raisonnement fondé sur les 3 principales raisons SHAP accompagne aussi l'instruction des dossiers : lorsqu'une alerte donne lieu à un dossier, l'analyste voit déjà pourquoi le modèle y a contribué et peut examiner la notation par l'IA aux côtés de la logique à base de règles qui s'est déclenchée, au lieu de traiter les deux comme des systèmes séparés dont personne ne répond.

L'explicabilité présente un second avantage que les équipes de conformité ressentent immédiatement : elle permet à l'IA de réduire les faux positifs sans devenir une nouvelle source de bruit inexpliqué. Lorsqu'un modèle rétrograde une correspondance, il en montre les raisons, de sorte que l'analyste peut se fier à cette dépriorisation au lieu de la redouter. C'est toute la différence entre un modèle qui supprime discrètement des alertes et un modèle qui aide l'analyste à les clôturer de manière défendable — un thème traité en détail dans comment l'IA réduit les faux positifs d'une manière que vous pouvez défendre devant un inspecteur.

Gouverner le modèle, pas seulement ses résultats

Expliquer un score isolé est nécessaire, mais pas suffisant. Le modèle lui-même est un objet contrôlé doté d'un cycle de vie, et la gouvernance LBC/FT attend autour de ce cycle de vie des contrôles aussi rigoureux que ceux qui encadrent toute autre modification importante d'un système de conformité. Le service d'inférence IA traite un modèle comme le reste de la plateforme traite toute action sensible.

Un registre et une activation selon le principe des quatre yeux

Les modèles n'arrivent pas en production par hasard. Le service gère un registre de modèles propriétaire : un inventaire contrôlé de chaque modèle et de chaque version à la disposition du locataire. Mettre un modèle en production est un acte lourd de conséquences ; il est donc protégé par l'activation selon le principe des quatre yeux : une personne propose l'activation, une seconde personne, indépendante, l'approuve. Aucun individu ne peut, seul, introduire un nouveau modèle, ou une nouvelle version d'un modèle existant, dans des décisions qui touchent des clients. Ce mécanisme reprend le principe des quatre yeux qui protège toutes les autres actions importantes de la plateforme, des dérogations à la notation des risques jusqu'à la transmission des déclarations, et il offre à la fonction de validation un point de contrôle naturel : un modèle ne peut pas être mis en production tant qu'une seconde paire d'yeux autorisée ne l'a pas validé.

Un coupe-circuit

Lorsqu'un modèle se comporte mal — dérive, schéma de résultats inattendu, constat de la fonction de validation —, attendre n'est pas une option. Le service fournit un coupe-circuit : un moyen immédiat de mettre un modèle hors service. L'activation est délibérée et lente par conception ; la désactivation est rapide par conception. Cette asymétrie est voulue. Mettre un modèle en service doit exiger du soin et une seconde signature ; l'arrêter lorsque quelque chose semble anormal ne doit exiger ni délai ni débat.

Surveillance de l'équité et de la dérive

Un modèle exact au moment de son activation ne le reste pas de lui-même. Le comportement des clients change, les typologies évoluent, et les données qui alimentent le modèle évoluent sous ses pieds. Le service assure en continu une surveillance de l'équité et de la dérive, à l'affût d'une dégradation des performances du modèle ou de résultats qui se biaiseraient au détriment d'un groupe de clients d'une manière que l'établissement n'a jamais voulue. C'est cette surveillance qui fait du coupe-circuit non plus un bouton de panique, mais un contrôle gouverné : elle vous dit quand l'utiliser, avant qu'un inspecteur ou une déclaration manquée ne vous le dise à votre place.

Retour arrière

L'activation est réversible. L'association d'un registre versionné et du retour arrière (rollback) signifie que si une nouvelle version d'un modèle donne des résultats insuffisants, l'établissement peut revenir proprement à la version précédemment validée, sans avoir à la reconstituer manuellement. Les changements de modèle deviennent des décisions réversibles plutôt que des portes à sens unique — exactement la propriété que recherche une fonction de validation lorsqu'elle approuve la mise en production d'une nouvelle version.

Journaliser la décision pour qu'elle résiste à l'audit

La dernière couche de gouvernance, c'est la trace. Une décision d'IA qui ne peut pas être reconstituée ultérieurement n'est, du point de vue de l'audit, pas une décision du tout. Le service d'inférence IA journalise chaque décision d'IA importante avec trois éléments qui permettent de la reconstituer : la version du modèle qui l'a produite, une empreinte des données d'entrée (inputs hash) qui capture exactement ce que le modèle a vu, et la sortie SHAP qui explique pourquoi il a attribué ce score.

Ce triplet est essentiel, car il répond aux trois questions qu'un inspecteur ou un réviseur interne posera sur toute décision passée. Quel modèle a pris cette décision ? La version. Sur quelle base a-t-il décidé ? L'empreinte des données d'entrée, qui fige les données exactes fournies au modèle, de sorte qu'elles ne puissent pas être discrètement contestées plus tard. Pourquoi a-t-il décidé ainsi ? La sortie SHAP, conservée à côté du score. Ensemble, ces éléments permettent à l'établissement d'assumer une décision prise des mois ou des années plus tôt, non pas en s'en souvenant, mais en la rejouant à partir de la trace.

Comme ces décisions sont inscrites dans le même journal d'audit immuable, en ajout seul, que celui où écrit le reste de la plateforme, elles figurent à côté des actions humaines qui les entourent : qui a accepté ou rejeté le résultat du modèle, qui a activé le modèle, qui a approuvé cette activation. La contribution du modèle n'est pas une couche séparée dont personne ne répond ; elle fait partie d'un seul et même historique probant, continu. Pour savoir comment cette trace est constituée et protégée dans l'ensemble de la plateforme, consultez comment les décisions de l'IA sont consignées dans la piste d'audit sous le contrôle du principe des quatre yeuxEN.

Comment l'affichage et la trace concordent

Les deux moitiés de l'IA explicable — ce que voit l'analyste et ce qu'enregistre le système — sont délibérément la même information, capturée au même moment.

Rien de ce sur quoi l'analyste s'appuie au moment de décider n'est perdu ensuite, et rien de ce qui figure dans la trace ne lui a été caché sur le moment. C'est cet alignement qui rend l'IA défendable : l'explication affichée et l'explication conservée ne font qu'une.

À quoi ressemble une bonne pratique

Une capacité d'IA bien gouvernée au sein d'un programme LBC/FT se reconnaît facilement. Chaque résultat d'IA que voit un analyste est étiqueté, expliqué par les 3 principales raisons SHAP, quantifié par un pourcentage de confiance et accompagné d'une commande permettant de l'accepter, de le modifier ou de le rejeter. Aucun modèle n'atteint la production sans que deux personnes autorisées aient accepté de l'activer. Un modèle défaillant peut être arrêté en quelques instants. L'équité et la dérive sont surveillées en continu, et non auditées une fois par an. Les versions peuvent faire l'objet d'un retour arrière, et chaque décision importante est journalisée avec la version du modèle, l'empreinte des données d'entrée et le raisonnement, afin de pouvoir être reconstituée longtemps après les faits.

Le résultat est une IA qui mérite sa place dans le programme au lieu de le fragiliser. Le modèle affine la détection et réduit les efforts inutiles, tandis que la gouvernance maintient chaque décision dans les limites qu'attendent votre politique de risque de modèle et votre autorité de contrôle. C'est la seule forme d'IA qui vaille la peine d'être exploitée dans une fonction LBC/FT réglementée : utile parce qu'explicable, et utilisable parce que gouvernée.

Questions fréquentes

Utiliser l'IA en LBC/FT signifie-t-il que le modèle prend la décision ?

Non. Dans la plateforme de Creodata, le modèle ne décide jamais seul. Chaque surface d'IA présente une suggestion étiquetée, expliquée par SHAP et assortie d'un score de confiance, et c'est l'analyste qui tranche au moyen d'une commande explicite Accept, Modify ou Reject. Le modèle alimente une décision humaine, et l'action humaine est journalisée à côté du résultat du modèle.

Qu'est-ce que SHAP et pourquoi est-ce important pour la conformité ?

SHAP est une méthode d'attribution qui quantifie la contribution de chaque variable d'entrée au score d'un modèle. Pour la conformité, elle compte parce qu'elle remplace un nombre opaque par les 3 principales raisons qui le sous-tendent : un analyste peut ainsi interroger le score, un responsable LBC/FT peut expliquer une décision à un régulateur, et une fonction de validation peut vérifier que le modèle raisonne comme il le devrait.

Comment mettre en production un nouveau modèle LBC/FT en toute sécurité ?

Grâce au registre de modèles et à l'activation selon le principe des quatre yeux. Un modèle et sa version résident dans un registre contrôlé, et leur mise en production exige qu'une personne propose l'activation et qu'une seconde personne, indépendante, l'approuve. Si le modèle se comporte mal par la suite, un coupe-circuit le met immédiatement hors service, et le retour arrière ramène le locataire à la version précédemment validée.

Comment prouver a posteriori une décision assistée par l'IA ?

En la rejouant à partir de la trace. Chaque décision d'IA importante est journalisée avec la version du modèle, une empreinte des données d'entrée qui fige exactement ce que le modèle a évalué, et la sortie SHAP qui explique le score, le tout dans le journal d'audit en ajout seul de la plateforme. L'établissement peut ainsi reconstituer précisément ce qui a été décidé, sur quelles données et pourquoi, des mois ou des années plus tard.

Une IA explicable et gouvernée fait toute la différence entre un modèle qui aide vos analystes et un modèle qui expose votre programme. Pour voir comment les explications SHAP, l'activation selon le principe des quatre yeux, le coupe-circuit, la surveillance de la dérive et la journalisation des décisions fonctionnent ensemble dans un programme LBC/FT en production — et comment les mêmes contrôles s'étendent aux déclarations goAML et à nos services de conseil en conformité en matière de criminalité financière —, réservez une démo de la Plateforme LBC/FT de Creodata.