Le choix d’une solution de conformité ne repose pas seulement sur les performances de son moteur. Il dépend aussi de la manière dont la solution s’intègre au système d’information existant, de la localisation des données, de la charge d’exploitation et de la capacité à faire évoluer l’architecture dans le temps.
Trois termes reviennent souvent lors de l’étude d’un projet d’intégration d’une solution de conformité par API : SaaS, API et on-premise. Ils ne désignent pourtant pas exactement la même chose.
Le SaaS, pour Software as a Service, correspond à un logiciel hébergé et exploité par l’éditeur, accessible à distance. L’on-premise désigne au contraire une solution installée dans l’infrastructure de l’organisation. Une API, pour Application Programming Interface, est un mode d’intégration permettant à une application existante d’appeler automatiquement les fonctionnalités d’un service.
Une solution SaaS peut donc parfaitement être utilisée via un portail web, via une API ou en combinant les deux.
C’est cette architecture ouverte que nous avons retenue chez AP Solutions IO. Nos solutions sont disponibles en mode SaaS, via une interface Web et des API natives afin de permettre aux organisations d’adapter l’intégration à leurs processus plutôt que d’adapter tous leurs processus à l’outil.
Quelle différence entre un déploiement SaaS et une intégration par API ?
Le SaaS décrit principalement la manière dont la solution est hébergée et exploitée. L’API décrit la manière dont un autre système communique avec elle.
Les deux sont donc complémentaires.
Le SaaS avec portail web
Avec un portail SaaS, les utilisateurs accèdent à une interface fournie par l’éditeur, généralement depuis un navigateur.
L’entreprise n’a pas à déployer la solution sur ses propres serveurs ni à gérer directement son infrastructure applicative. Cela peut réduire sensiblement la charge technique par rapport à une installation on-premise.
Il reste néanmoins plusieurs étapes :
- création des accès ;
- paramétrage ;
- définition des profils utilisateurs ;
- configuration des règles ;
- éventuels imports de données ;
- organisation des processus de traitement des alertes.
Le portail constitue ainsi une option pertinente lorsque les équipes conformité ont besoin d’un environnement dédié pour réaliser ou superviser leurs contrôles.
Chez AP Solutions IO, nous proposons une interface Web qui permet aux équipes d’utiliser directement les fonctions de nos solutions, sans rendre obligatoire une intégration préalable dans le système d’information.
L’intégration par API
Une API permet à une application métier d’interroger directement la solution de conformité.
Un contrôle peut par exemple être déclenché lors de la création d’un client dans un CRM, au cours d’un parcours KYC ou depuis une application bancaire. Le résultat est ensuite renvoyé au système qui a initié la requête.
L’utilisateur peut ainsi rester dans son environnement habituel si le parcours a été conçu de cette manière. L’API ne garantit donc pas à elle seule une expérience totalement invisible : celle-ci dépend de l’intégration réalisée côté client.
Notre technologie fonctionne précisément selon ce principe. Les API natives d’AP Solutions IO peuvent être appelées depuis un SI, un CRM, un outil KYC/KYS, un SIRH ou d’autres applications. Notre page consacrée aux fonctionnalités à examiner dans une solution de conformité permet de replacer cette question d’intégration parmi les autres critères de choix.
Le mode on-premise
Le mode on-premise consiste à déployer la solution dans l’environnement informatique de l’organisation.
Cette architecture peut répondre à certaines politiques internes ou à des contraintes spécifiques d’infrastructure. Elle implique toutefois de prendre en charge davantage d’éléments en interne : déploiement, supervision, sécurité, maintenance, montées de version et gestion de l’infrastructure.
La question ne se réduit donc pas à opposer « contrôle » et « simplicité ». Il faut déterminer quelle responsabilité technique l’organisation souhaite conserver et quelles ressources elle peut mobiliser sur la durée.
Quel mode choisir selon le besoin ?
Il est plus utile de comparer les architectures à partir de leurs conséquences opérationnelles que de chercher un modèle universel.
| Critère | SaaS avec portail | SaaS + API | Hybride : portail + API | On-premise |
| Infrastructure applicative | Gérée par l’éditeur | Gérée par l’éditeur | Gérée par l’éditeur | Gérée en interne |
| Intégration au SI | Limitée ou facultative | Nécessaire | Selon les processus | Dépend du projet |
| Expérience utilisateur | Interface dédiée | Peut rester dans l’outil métier | Adaptée selon les profils | Dépend de l’application |
| Mises à jour applicatives | Gérées par l’éditeur | Gérées par l’éditeur | Gérées par l’éditeur | À organiser en interne |
| Charge d’exploitation | Généralement limitée | Limitée côté hébergement, projet SI côté client | Variable selon l’intégration | Plus importante |
| Usage pertinent | Équipe conformité autonome | Processus automatisés et volumes importants | Besoins mixtes | Contraintes d’infrastructure spécifiques |
L’effort d’intégration dépend du parcours retenu
Un portail SaaS peut éviter le développement d’une interface applicative complète, mais il ne signifie pas zéro travail de déploiement.
À l’inverse, une API nécessite une intégration technique :
- définition des données transmises ;
- authentification ;
- gestion des réponses ;
- règles de traitement des erreurs ;
- parcours des alertes.
AP Solutions IO utilise des API REST/JSON sécurisées par OAuth2, conçues pour faciliter l’interfaçage avec les systèmes existants. Notre configuration no-code permet parallèlement de paramétrer les règles métier sans transformer chaque ajustement en projet de développement.
La charge se déplace, elle ne disparaît pas
Avec une API, une partie de l’effort est déplacée de l’utilisation quotidienne vers le projet d’intégration.
C’est souvent pertinent lorsque le volume des contrôles est important ou lorsque l’organisation souhaite déclencher automatiquement un criblage dans un parcours métier.
Avec un portail, l’effort d’intégration est réduit, mais les utilisateurs doivent travailler dans une interface dédiée.
Le choix dépend donc davantage des processus, des volumes et de l’organisation des équipes que d’une hiérarchie théorique entre les deux modèles.
Faut-il choisir entre portail et API ?
Pas nécessairement. Un mode hybride permet de combiner les deux.
L’API peut automatiser les contrôles intégrés aux parcours métier tandis que le portail fournit aux équipes conformité un espace consacré à la qualification, au traitement et à la traçabilité des alertes.
Des interfaces différentes pour des besoins différents
Un opérationnel qui crée un client dans une application métier n’a pas nécessairement besoin d’accéder à toute l’interface du moteur de conformité.
À l’inverse, un analyste doit pouvoir examiner une alerte, consulter les informations pertinentes, prendre une décision et la documenter.
Avec AP Solutions IO, nous permettons aux mêmes fonctions d’être utilisées depuis l’interface Web ou appelées directement par un système tiers via nos Web Services. Cette organisation permet de choisir le point d’accès selon le profil de l’utilisateur.
L’architecture et la technologie d’AP Solutions IO reposent précisément sur cette logique d’ouverture.
Un déploiement progressif reste possible
Une organisation peut aussi commencer par utiliser un portail puis automatiser progressivement certains parcours par API.
Cette approche permet notamment de tester les règles, observer les volumes d’alertes et stabiliser le paramétrage avant d’engager une intégration plus poussée.
Elle n’est cependant pas obligatoire. Lorsqu’un SI et des processus sont déjà clairement définis, une intégration API peut être prévue dès le départ.
L’essentiel consiste à choisir une séquence cohérente avec les contraintes du projet, et non à appliquer systématiquement le même schéma de déploiement.
Comment intégrer une solution de criblage à un core banking existant ?
Une architecture ouverte permet d’appeler un moteur de criblage depuis un core banking, un CRM ou une autre application métier.
Le projet commence par l’identification des moments auxquels le contrôle doit être réalisé.
Identifier les bons points d’intégration
Selon le dispositif, un appel peut intervenir lors :
- d’une entrée en relation ;
- de l’actualisation d’un dossier ;
- d’un contrôle du portefeuille existant ;
- d’un événement nécessitant une nouvelle vérification ;
- du traitement d’un flux lorsqu’un outil de filtrage est concerné.
Le choix doit résulter du dispositif de conformité et de la cartographie des risques, et non de la seule capacité technique de l’API.
Vérifier les données réellement disponibles
Une intégration efficace dépend aussi de la qualité des données transmises.
Un moteur qui reçoit uniquement un nom dispose de moins de critères pour distinguer un homonyme qu’un moteur recevant également une date de naissance, un pays ou d’autres informations pertinentes.
La réflexion sur l’API doit donc inclure le mapping des données : quelles informations sont présentes dans le système source ? Sous quel format ? À quel moment sont-elles suffisamment fiables pour lancer le contrôle ?
Définir ce qui se passe lorsqu’une alerte apparaît
L’intégration doit également prévoir la gestion du résultat.
Selon le contexte, une correspondance peut conduire à une mise en attente, à une demande d’analyse, à une notification ou à un autre traitement déterminé par les procédures de l’organisation.
L’API déclenche et restitue le contrôle ; elle ne décide pas à elle seule de la procédure métier à appliquer.
Cette distinction correspond à l’approche d’AP Solutions IO : nos outils automatisent la détection et mettent à disposition des résultats traçables, mais le traitement et la gouvernance doivent rester cohérents avec les règles de l’organisation.
S’appuyer sur des partenaires d’intégration lorsque nécessaire
Une intégration peut être réalisée par les équipes internes ou avec un partenaire technologique.
AP Solutions IO travaille notamment avec Elcimaï, qui intègre AP Scan et AP Filter à ses environnements de core banking. D’autres intégrations permettent également d’insérer nos API directement dans des plateformes métier.
Notre page consacrée à l’écosystème de partenaires d’AP Solutions IO présente plusieurs exemples de ces connexions.
Le mode on-premise est-il encore pertinent ?
Oui, dans certaines architectures.
Une organisation peut souhaiter conserver l’exploitation de certains composants dans son infrastructure en raison de sa politique interne, de contraintes techniques ou d’une architecture historique.
Mais cette maîtrise entraîne une responsabilité opérationnelle supplémentaire : ressources techniques, sécurité, sauvegardes, mises à jour et maintien de la disponibilité.
Comparer la maîtrise réelle, pas seulement le lieu d’hébergement
Une infrastructure interne ne garantit pas automatiquement une meilleure maîtrise. Celle-ci dépend aussi des procédures, des compétences disponibles, de la supervision et de la capacité à appliquer régulièrement les mises à jour nécessaires.
À l’inverse, un SaaS externalise une partie de l’exploitation mais nécessite d’évaluer précisément l’hébergement, la sécurité, la disponibilité, la sous-traitance, les conditions contractuelles et la réversibilité.
Pour AP Solutions IO, nous avons fait le choix d’une architecture Web, SaaS et full API, avec des données hébergées en France. Nous ne fondons donc pas notre proposition sur un modèle on-premise, mais sur une architecture hébergée conçue pour rester intégrable aux SI existants.
Quelles questions poser avant de choisir son architecture ?
Avant d’arrêter un mode d’utilisation, plusieurs questions doivent être traitées ensemble :
- Quel volume doit être contrôlé et à quelle fréquence ?
- Quels événements métier doivent déclencher les contrôles ?
- Dans quelles applications les données sont-elles disponibles ?
- Où les équipes conformité souhaitent-elles traiter les alertes ?
- Quel niveau d’automatisation est recherché ?
- Quelles contraintes de sécurité et d’hébergement doivent être respectées ?
- Quelles ressources SI peuvent être consacrées à l’intégration ?
- Quelle réversibilité est attendue en fin de contrat ?
Un volume important n’impose pas automatiquement une API, mais il peut rendre l’automatisation particulièrement pertinente. De même, un portail peut convenir à une équipe conformité autonome sans empêcher une intégration ultérieure.
Comment AP Solutions IO aborde le déploiement d’une solution de conformité par API
AP Solutions IO est une RegTech française spécialisée dans les technologies de conformité LCB-FT, KYC, anticorruption et Export Control.
Notre suite regroupe AP Scan pour le criblage, AP Scoring pour la cotation du risque, AP Monitoring pour la surveillance des opérations et AP Filter pour le filtrage des sanctions et des embargos.
Nos solutions disposent d’interfaces Web, SaaS et d’API natives, avec une architecture ouverte et un paramétrage no-code. Les données sont hébergées en France.
Ce choix permet d’intégrer la conformité de différentes manières :
- utilisation directe par les équipes ;
- appels depuis un CRM ou un système de gestion ;
- intégration dans un core banking ;
- combinaison de plusieurs modes selon les processus.
L’objectif n’est donc pas de choisir abstraitement entre SaaS et API, mais de déterminer comment les différents modes d’accès et d’intégration doivent s’articuler. Avec AP Solutions IO, nous cherchons à déterminer comment la technologie doit s’insérer dans le SI pour automatiser les contrôles sans dégrader les parcours métier ni réduire la capacité des équipes à comprendre et à tracer les résultats.
Pour identifier les points d’appel pertinents, les données disponibles et le niveau d’intégration adapté à votre architecture, vous pouvez échanger avec notre équipe sur votre projet d’intégration.
