Logiciel AML on-premises

Un logiciel AML on-premises est un screening anti-blanchiment déployé au sein de l'environnement propre ou dédié d'une entreprise, plutôt que consommé comme un service partagé que le fournisseur héberge et exploite. Les contrôles sont les mêmes — sanctions, personnes politiquement exposées (PEP), presse négative (adverse media) et wallets — mais le logiciel et, surtout, les données de screening de l'entreprise s'exécutent dans un environnement qu'elle contrôle, et non dans une plateforme multi-tenant partagée avec d'autres clients.

Pour la plupart des entreprises réglementées, ce modèle de déploiement n'est pas un détail technique. Il détermine où se trouvent physiquement les données clients et les preuves de screening, qui exploite l'environnement qui les héberge, et à quel point cet environnement est isolé des autres tenants. Une plateforme d'échange crypto, un émetteur de monnaie électronique ou une entreprise de paiement soumise à des obligations de résidence des données, à des exigences single-tenant ou à de strictes attentes de supervision interne fait un véritable choix d'architecture lorsqu'elle met en balance un déploiement on-premises ou dédié face à un déploiement hébergé.

Cet article précise ce qu'est un logiciel AML on-premises, pourquoi les entreprises l'envisagent, ce qu'il exige d'elles en retour, comment se comparent les déploiements hébergé, dédié et on-premises, où se situe le choix dans une plateforme réglementée, et où se trouvent les limites.

Ce qu'est un logiciel AML on-premises

Un logiciel AML on-premises désigne un modèle de déploiement, non un autre type de contrôle. La logique de screening — le rapprochement d'une personne, d'une entreprise ou d'une adresse blockchain avec des données de sanctions, de PEP, de presse négative et de risque des wallets — se comporte de la même manière où qu'elle s'exécute. Ce qui change, c'est l'endroit où elle s'exécute et qui contrôle l'environnement et les données qu'il renferme.

Trois configurations méritent d'être distinguées. Un service hébergé multi-tenant est exploité entièrement par le fournisseur, les données de plusieurs clients étant conservées dans une seule plateforme partagée. Un déploiement dédié single-tenant donne à une entreprise sa propre instance isolée et son propre stockage, que le fournisseur ou l'entreprise l'exploite. Un déploiement on-premises place le logiciel et ses données au sein de l'infrastructure propre de l'entreprise, dans un environnement qu'elle exploite directement. La ligne qui compte suit l'isolement et le contrôle : à quel point les données de l'entreprise sont séparées de celles d'autrui, et qui détient les clés de l'environnement qui les stocke.

Une nuance façonne tout ce qui suit. Le screening AML dépend de données de référence externes — désignations de sanctions, fiches PEP et sources de presse négative qui changent d'un jour à l'autre. De ce fait, un déploiement on-premises signifie rarement un déploiement totalement déconnecté ; les données de référence doivent toujours parvenir à l'environnement et rester à jour. On-premises décrit l'endroit où s'exécutent les données propres de l'entreprise et le screening, non la promesse que le contrôle n'a besoin de rien d'extérieur.

Pourquoi les entreprises envisagent un déploiement on-premises

Le moteur le plus clair est la résidence des données. Le screening traite des éléments identifiants sur les clients et produit des preuves qu'une entreprise doit conserver, et certaines entreprises sont tenues — par la réglementation, une politique interne ou un mandat client — de garder ces données dans une juridiction définie ou au sein de leur propre environnement. Un déploiement qui conserve les données en un lieu contrôlé répond directement à cette exigence, là où un service hébergé partagé peut ne pas le faire.

Le contrôle et l'isolement sont les raisons suivantes. Une configuration single-tenant ou on-premises signifie que les données de screening de l'entreprise ne sont pas hébergées aux côtés de celles d'autres clients, et que l'entreprise exerce une supervision directe sur l'environnement qui les renferme. Pour un établissement qui doit démontrer à un superviseur exactement où se trouvent les données réglementées et qui peut y accéder, cette immédiateté est plus facile à prouver qu'une plateforme partagée.

Le risque lié aux tiers et à la technologie est la troisième raison. Les attentes de résilience opérationnelle poussent désormais les entreprises réglementées à encadrer leur dépendance à l'égard des fournisseurs de technologie et à savoir — et consigner — où leurs données sont conservées et comment un fournisseur est supervisé. Choisir un déploiement dédié ou on-premises modifie la forme de cette dépendance : il réduit l'exposition à une plateforme partagée tout en plaçant davantage de l'environnement sous le contrôle propre de l'entreprise et ses propres dispositifs de résilience. Il se trouve aussi plus près des systèmes internes, ce qui peut simplifier l'intégration avec les plateformes aux côtés desquelles le screening AML s'exécute déjà.

Ce qu'un déploiement on-premises exige en retour

Le contrôle a pour prix la responsabilité. Dans un service hébergé, le fournisseur maintient la plateforme à jour de ses correctifs, l'infrastructure en fonctionnement et, surtout, les données de référence à jour. Déplacez le déploiement dans un environnement dédié ou on-premises, et une plus grande part de ce travail opérationnel devient celui de l'entreprise : exploiter et corriger l'environnement, gérer sa disponibilité et sa reprise, et mobiliser les personnes qui le maintiennent en bon état.

Les données de référence méritent une attention particulière. Les listes de sanctions et de PEP changent fréquemment, et un contrôle de screening ne vaut que ce que valent les données qui le sous-tendent ; une liste qui n'est plus à jour est une défaillance de contrôle, non un écart mineur. Un déploiement qui isole l'environnement doit malgré tout y acheminer les désignations actualisées de manière fiable et en temps voulu. L'obligation de contrôler face à des données à jour ne s'allège pas parce que le logiciel s'exécute sur l'infrastructure propre de l'entreprise — au contraire, l'entreprise en assume une plus grande part.

Les mises à jour et les évolutions suivent le même schéma. Les nouvelles fonctionnalités, correctifs et changements de sources de données qu'un service hébergé applique de manière centralisée doivent être planifiés et appliqués à un déploiement dédié ou on-premises selon un rythme que l'entreprise gère. Rien de tout cela ne plaide contre le déploiement on-premises ; cela en fixe le prix honnête. Le modèle convient aux entreprises qui ont besoin du contrôle et sont prêtes à porter la responsabilité opérationnelle qui l'accompagne.

Hébergé, dédié et on-premises comparés

Les trois modèles répondent différemment aux mêmes questions. Les placer côte à côte rend le compromis concret : globalement, plus le déploiement est isolé et contrôlé par l'entreprise, plus la responsabilité opérationnelle se déplace du fournisseur vers l'entreprise.

Aucune ligne ne rend un modèle correct à elle seule. Une entreprise lit le tableau au regard de ses propres obligations : où les données réglementées doivent résider, quel degré d'isolement elle doit pouvoir démontrer, et quelle charge opérationnelle elle peut réellement porter.

Où se situe le choix de déploiement

Le déploiement est une décision distincte de la capacité. Les contrôles qu'une plateforme effectue — et la manière dont ils sont appelés, que ce soit via une API sur le chemin critique ou un panneau pour l'examen — sont les mêmes, que le screening s'exécute dans un service hébergé ou au sein de l'environnement propre de l'entreprise. Une entreprise peut intégrer le screening AML dans ses flux d'onboarding et de surveillance, puis décider séparément où ce screening est déployé.

Grumpio propose le screening via Legichain, son produit AML et KYC, qui peut être fourni avec un stockage on-premises ou dédié, de sorte que les dossiers de screening, les résultats et les preuves d'une entreprise résident dans un environnement single-tenant contrôlé plutôt que partagé. Legichain couvre la vérification de personnes et d'entreprises au regard des données de sanctions et de PEP, le screening de presse négative et la vérification du risque des wallets multi-blockchain, restituée sous forme de résultat d'API automatisé, avec score de risque et rapport de preuve PDF, accessible via une API et un panneau web partageant un pool de crédits unique. Les tarifs et le détail du produit sont publiés sur le site Legichain. Vérifier une entreprise de cette manière ne remplace pas une vérification KYB complète, et aucun jeu de données ne couvre chaque partie dans chaque juridiction sans lacunes.

Quelles entreprises optent pour un déploiement dédié ou on-premises est généralement prévisible : celles soumises à des obligations de résidence des données, à des exigences single-tenant ou à des politiques d'hébergement interne qu'un service partagé ne satisfait pas. Pour la plupart des autres, un déploiement hébergé est le choix proportionné. Traiter la question comme une décision d'architecture — et aligner le modèle de déploiement sur les obligations réelles de l'entreprise plutôt que sur un réglage par défaut —, c'est ce qui l'empêche de devenir une hypothèse coûteuse plus tard.

Périmètre et limites

Le modèle de déploiement ne change pas qui répond de la décision de conformité. Où que le logiciel s'exécute, une correspondance est un signal que l'entreprise apprécie, non un verdict que le logiciel prononce ; l'examen de tout signalement et la trace qui l'étaye appartiennent à l'entreprise réglementée. Un déploiement on-premises change où se trouvent les données et qui exploite l'environnement ; il ne déplace pas la décision vers le fournisseur.

Il ne rend pas non plus, à lui seul, une entreprise conforme ou sécurisée. Conserver des données en un lieu donné est un élément d'une posture de protection des données et de résilience, non la conformité en soi ; un environnement contrôlé doit tout de même être bien exploité, tenu à jour et attesté. La manière dont un déploiement est réellement construit et maintenu — la topologie, la façon dont les données de référence sont rafraîchies, les correctifs, la gestion des clés et la reprise — relève de la responsabilité de conception propre de l'entreprise et sort du cadre d'une description générale comme celle-ci. Nous ne fournissons pas d'avis juridiques et ne garantissons aucun agrément. Nous mettons en œuvre les exigences réglementaires et d'audit dans la technologie, l'infrastructure et l'exploitation.

Synthèse et étapes suivantes

Un logiciel AML on-premises est un choix de déploiement, non de ce qui est criblé. Il détermine où résident les données de screening et les preuves d'une entreprise, à quel point l'environnement est isolé, et qui l'exploite — tandis que les contrôles de sanctions, de PEP, de presse négative et de wallets restent, eux, identiques. Son attrait, c'est le contrôle et la résidence des données ; son prix, c'est la responsabilité opérationnelle, y compris l'obligation permanente de tenir à jour les données de référence là où le logiciel s'exécute.

Bien choisir, c'est lire les obligations réelles de l'entreprise — où les données réglementées doivent résider, quel degré d'isolement elle doit démontrer, quelle charge opérationnelle elle peut porter — et aligner le modèle de déploiement sur elles plutôt que sur une habitude. Décider cela délibérément, dans le cadre de la préparation réglementaire plutôt que sous la pression du superviseur plus tard, transforme une question d'hébergement en une position d'architecture défendable.