Mener une décision build-buy-partner sur une capacité IA cœur de métier

Une banque américaine de taille intermédiaire (environ 30 milliards de dollars d'actifs) fait face à une échéance. Son système de transaction monitoring AML (anti-money laundering, le régime réglementaire qui oblige les banques à détecter et signaler les activités financières suspectes) a neuf ans, produit des faux positifs à un rythme que les équipes compliance qualifient d'« ingérable », et un examen réglementaire récent a relevé des lacunes dans la documentation des modèles. Le CIO a trois options sur la table : construire un nouveau système en interne avec l'équipe data science de la banque, acheter une plateforme éditeur, ou co-développer avec un partenaire fintech. Le conseil attend une recommandation sous six semaines. C'est cette décision que cette leçon vous apprend à mener.

Pourquoi cette décision est plus difficile qu'il n'y paraît

Le transaction monitoring AML utilise l'IA/ML (machine learning) pour scorer les transactions au regard des activités suspectes, en remplaçant ou en complétant des règles statiques (« signaler tout virement supérieur à 10 000 $ ») par de la détection de patterns qui s'adapte aux nouvelles techniques de blanchiment.

Les enjeux jouent dans les deux sens. Sous-détectez et vous risquez des sanctions réglementaires au titre du Bank Secrecy Act (BSA, la loi AML américaine de référence) et des mesures d'exécution du FinCEN (Financial Crimes Enforcement Network) ou, en Europe, des régulateurs nationaux appliquant les directives AML de l'UE. Sur-détectez et vous noyez les enquêteurs sous les faux positifs : les estimations du secteur citent couramment des taux de faux positifs supérieurs à 90 % pour les systèmes legacy à base de règles, une approximation à traiter comme indicative, pas exacte.

Ce n'est pas un choix générique d'« adoption de l'IA ». C'est une décision portant sur un système situé au cœur d'une fonction compliance fortement auditée et à forte exposition juridique. Cela change le calcul par rapport, disons, à l'adoption d'un outil d'IA pour la rédaction marketing.

Les trois voies, évaluées honnêtement

Construire en interne

Vous conservez le contrôle total du modèle, du pipeline de donnéespipeline de donnéesSéquence automatisée d'étapes qui déplace les données de la source vers la destination : ingestion, transformation, validation et chargement, pour qu'elles arrivent propres et prêtes à l'emploi.Voir la définition complète → et de la logique, ce qui compte quand les régulateurs demandent « pourquoi le modèle a-t-il signalé cette transaction ? » (une exigence souvent appelée explicabilité du modèle).

Les coûts sont réels et récurrents : data scientists, ML engineers, infrastructure MLOpsMLOpsMachine Learning Operations : combinaison des pratiques ML et DevOps pour industrialiser, déployer, monitorer et réentraîner les modèles de façon fiable en production.Voir la définition complète → et, surtout, les effectifs compliance et validation nécessaires pour documenter le modèle conformément aux orientations prudentielles comme la SR 11-7 de la Réserve fédérale sur le model risk management. La plupart des banques de taille intermédiaire sous-estiment ce second poste de coûts.

Le build a du sens quand vous disposez d'un actif de données différenciant (une base clients ou des patterns de transactions véritablement atypiques) ou quand les modèles standards performent mal sur votre segment. Il est rarement pertinent comme premier mouvement pour une banque de taille intermédiaire avec une équipe data science réduite.

Acheter une plateforme

Des éditeurs comme NICE Actimize, Oracle Financial Services, SAS et Feedzai commercialisent des plateformes AML avec des modèles de détection pré-entraînés, des workflows de case management et (point critique) du reporting réglementaire prêt à l'emploi.

L'avantage, c'est la rapidité de mise en conformité et la charge de validation des modèles partagée, ces éditeurs ayant déjà traversé plusieurs examens bancaires. L'inconvénient, c'est l'adéquation : un modèle éditeur entraîné sur des centaines d'établissements peut ne pas détecter des patterns spécifiques à votre base clients (une banque fortement exposée au trade finance ou au correspondent banking présente des patterns de risque différents d'une banque à dominante retail).

Acheter implique aussi un risque de vendor lock-in et moins de transparence sur les rouages du modèle, ce qui peut compliquer l'explication des décisions aux examinateurs. Vous êtes conforme, mais dépendant.

Nouer un partenariat ou co-développer avec une fintech

Cette voie hybride (la banque apporte les données et l'expertise compliance, la fintech apporte l'ingénierie ML et une plateforme plus légère) est de plus en plus fréquente pour des capacités comme le triage d'alertes et le scoring de transactions, où opèrent des acteurs tels que Hawk AI ou ThetaRay.

Le partenariat peut combiner l'adéquation métier avec une itération plus rapide que le build, et plus de personnalisation que l'achat. Le hic : la gouvernance. Qui détient la documentation du modèle quand le régulateur la demande ? Qui est responsable si le modèle rate une correspondance sanctions ? Ces points doivent être contractuels, pas présumés.

Un framework de scoring réutilisable

Notez chaque option de 1 à 5 sur ces dimensions, pondérées selon ce qui compte le plus pour votre établissement :

Pour le cas AML : si le constat d'examen portait sur des lacunes documentaires, la défendabilité réglementaire et l'explicabilité devraient porter le poids le plus lourd, ce qui oriente souvent vers l'achat ou le partenariat, où les éditeurs apportent une documentation éprouvée en examen, plutôt que vers le build, où la banque hérite de cette charge depuis zéro.

Un mini-calcul chiffré

Supposons que le système actuel de la banque génère 100 000 alertes par an, avec un taux de faux positifs de 90 % (une estimation citée par le secteur, à traiter comme approximative) et que chaque alerte prenne 20 minutes de revue à un analyste.

• Heures analystes actuelles : 100 000 × 20 minutes = 33 333 heures/an
• À un coût complet d'analyste compliance d'environ 60 $/heure (une estimation américaine raisonnable pour 2026, non spécifique à un éditeur), cela représente environ 2 millions de dollars/an de main-d'œuvre de revue à elle seule.

Si un nouveau système enrichi par l'IA (build, buy ou partner) ramène les faux positifs à 70 % tout en détectant les mêmes vrais positifs, le volume d'alertes à revoir baisse proportionnellement : environ 100 000 → environ 70 000 alertes pertinentes, soit près de 10 000 heures d'analystes économisées, ou environ 600 000 $/an.

Mettez cette économie en regard du coût de chaque voie sur un horizon de 3 ans (les frais de licence éditeur se situent généralement entre le haut des six chiffres et le bas des sept chiffres par an pour les banques de taille intermédiaire, les coûts de build se concentrent en amont sur les talents et l'infrastructure, les coûts de partenariat sont en général un mélange des deux). Le business case ROI (return on investment) ne tient que si vous modélisez la traîne des coûts de compliance et de validation, pas seulement le coût de licence ou de développement, une erreur que beaucoup de banques commettent quand le business case paraît bon sur le slide d'un éditeur mais ignore la charge d'implémentation interne.

Ce à quoi les examinateurs s'intéressent vraiment

Quelle que soit la voie retenue, les régulateurs américains et européens convergent vers des attentes similaires : une gouvernance des modèles démontrable, pas nécessairement un choix particulier d'éditeur ou de build.

Le framework SR 11-7 de la Fed (toujours la référence en 2026) exige une validation indépendante, un monitoring continu et une documentation claire des limites du modèle. L'AI Act européen, en cours d'évolution, impose des obligations supplémentaires aux systèmes d'IA « à haut risque », et le transaction monitoring AML tombe plausiblement sous surveillance vu son impact sur l'accès des personnes aux services financiers, même si les banques devraient suivre les orientations définitives de l'Autorité bancaire européenne plutôt que présumer d'une classification.

Concrètement : une décision d'achat n'externalise pas la responsabilité réglementaire. La banque reste redevable même si l'éditeur a construit le modèle. C'est le malentendu le plus courant dans les décisions build-buy-partner en matière d'IA bancaire, pas seulement en AML.

🎬 [VIDEO: "How Banks Use AI to Fight Money Laundering" - youtube.com/results?search_query=how+banks+use+ai+to+fight+money+laundering - cherchez du contenu explicatif récent de chaînes consacrées aux technologies bancaires traitant du transaction monitoring AML et de l'IA, utile pour une démonstration visuelle du scoring d'alertes et des workflows de case management]

Application à la décision de la banque

Puisque le constat d'examen portait sur la documentation, et non sur la précision de détection, le mouvement initial le plus solide est probablement l'achat ou le partenariat, pas le build. Une plateforme éditeur apporte une documentation éprouvée en examen dès la sortie de boîte ; un partenariat fintech peut être ajouté plus tard pour un tuning spécifique à certains segmentssegmentsDécouper un marché en groupes distincts de clients partageant des besoins, des caractéristiques ou des comportements similaires, afin de traiter chaque groupe avec une approche dédiée.Voir la définition complète →, une fois l'écart de conformité de base refermé.

Le build reste l'option de long terme si, après deux ou trois ans d'exploitation d'une solution éditeur ou partenaire, la banque identifie un besoin de détection véritablement différenciant que le marché ne couvre pas, moment où elle disposera à la fois des données et de l'expérience interne pour construire de façon crédible.

Points clés

• Les décisions build-buy-partner en IA bancaire doivent pondérer la défendabilité réglementaire et l'explicabilité aussi fortement que le coût ou la vitesse, en particulier pour les systèmes critiques pour la compliance comme le monitoring AML.
• Acheter une plateforme éditeur ne transfère pas la responsabilité réglementaire ; la banque reste redevable des résultats sous des frameworks comme la SR 11-7.
• Modélisez toujours l'intégralité de la traîne de coûts (validation, documentation, maintenance), pas seulement le prix de la licence ou du développement, quand vous calculez le ROIROIReturn on Investment : le rapport entre le profit net et le coût d'un investissement. Un ROI de 300 % signifie que chaque dollar investi en rapporte 3.Voir la définition complète →.
• Le partenariat fonctionne mieux quand la gouvernance et la responsabilité sont définies contractuellement en amont, pas présumées.
• Utilisez un framework de scoring pondéré (adéquation réglementaire, adéquation des données, délai de mise en conformité, TCOTCOTotal Cost of Ownership, coût total de possession incluant acquisition, implémentation, maintenance, formation et évolution d'un outil sur sa durée de vie., talents, explicabilité) pour garder la décision structurée plutôt que dictée par les pitchs d'éditeurs.