Votre CRM est un outil destiné à générer du chiffre d'affaires. Ce n'est pas un système KYC adapté.

Votre meilleur outil commercial est votre pire infrastructure de conformité

Les établissements réglementés passent des mois à mettre en place onboarding KYC au sein de leur CRM. Ils configurent des objets personnalisés, intègrent des composants de téléchargement de documents, connectent des API de vérification tierces via des intergiciels et consacrent des ressources techniques à la maintenance de l'ensemble. Puis, la politique de conformité change ou un nouveau type d'entité nécessite une séquence de vérification différente. Et toute cette structure commence à se fissurer.

Le problème ne réside pas dans la mise en œuvre. Le problème, c'est l'architecture. Un CRM est un outil de premier ordre pour la gestion des relations commerciales. Il n'a jamais été conçu pour servir de système d'enregistrement des preuves de conformité.

Principaux enseignements

• Un CRM organise des événements commerciaux. La conformité exige un état souhaité. Il ne s'agit pas simplement de modèles de données différents, mais de philosophies architecturales différentes. Un CRM pose la question suivante : « Que s'est-il passé avec ce client ? » La conformité pose la question suivante : « Ce client est-il manifestement en conformité à l'heure actuelle, et quelles preuves le démontrent ? » Les systèmes de workflow sont a priori plus faciles à mettre en place, mais leur complexité s'accroît à chaque modification des exigences.

• Les systèmes basés sur des flux de travail s'effondrent sous la pression de la conformité. Lorsqu'une exigence réglementaire évolue, une solution KYC reposant sur un CRM nécessite un travail de développement pour reconstruire les séquences. Un système fondé sur des données recalcule automatiquement les dossiers concernés, sans intervention des développeurs.
• La présentation d’un CRM à une autorité de régulation comporte un risque réel de sanctions personnelles. Entre octobre 2024 et décembre 2025, l’AMF a rendu 12 décisions en matière de lutte contre le blanchiment et le financement du terrorisme (LCB-FT) pour un montant total de 5,815 millions d’euros. Dans 100 % des décisions de sanction, les dirigeants ont été sanctionnés à titre personnel. Deux d'entre eux ont été frappés d'une interdiction définitive d'exercer dans le secteur. L'AMF ne se contente pas de sanctionner les défaillances de processus ; elle sanctionne l'absence d'un système permettant de démontrer de manière structurelle la conformité (Autorité des marchés financiers, Guide de jurisprudence LCB-FT par Ondorse, 2026).
• Un CRM ne permet pas de gérer les révisions périodiques ni le suivi KYC. Il ne dispose d’aucun mécanisme natif pour déclencher les cycles de mise à jour des documents, appliquer les nouvelles exigences en matière de documentation, procéder à un nouveau filtrage des clients par rapport aux listes PPE, ou signaler les dossiers périmés en fonction du niveau de risque. Il en résulte un portefeuille qui semble à jour dans le CRM, mais qui n’est pas conforme aux exigences des autorités de régulation. C’est la voie directe vers des campagnes de mise en conformité incessantes et des sanctions.En 2023, 63 % des réclamations de l’ACPR concernaient des défaillances en matière de vigilance continue, et non les processus de démarrage.

• Un CRM et Ondorse ne sont pas des systèmes concurrents. Ils remplissent des fonctions différentes au sein d'une même infrastructure. Ce modèle d'intégration a fait ses preuves au sein de nombreuses institutions réglementées : le CRM déclenche l'action, Ondorse prend la décision, puis le CRM reçoit le résultat.
• Le principe est simple : le CRM gère la relation commerciale, tandis qu’Ondorse gère le dossier de conformité. Chaque système remplit la fonction pour laquelle il a été conçu. Aucun des deux ne porte atteinte à l’autre.

Pourquoi les équipes chargées de la conformité finissent-elles par intégrer le processus KYC dans leur CRM ?

Le raisonnement est compréhensible. Les équipes commerciales travaillent déjà dans Salesforce. Les données clients s’y trouvent. Les opportunités et les fiches clients y sont également. Lorsqu’un nouveau client signe un contrat, la prochaine étape qui s’impose semble être la suivante : déclencher le workflow KYC à partir du même système qui a généré la transaction.

Le piège, c'est que « évident » et « correct » ne sont pas synonymes.

Salesforce excelle dans ce pour quoi il a été conçu : gérer les relations commerciales, suivre le pipeline et enregistrer les interactions entre une équipe commerciale et ses clients. Le modèle de données en est le reflet. Tout s'articule autour des comptes, des contacts, des opportunités et des dossiers liés aux résultats commerciaux.

La conformité aux principes « Know Your Customer » (KYC) et « Know Your Business » (KYB) repose sur une ontologie totalement différente. L’objet central n’est pas un client, mais une évaluation des risques. Le système doit assurer le suivi des éléments suivants :

• Quels éléments de preuve ont été recueillis, auprès de quelle source et à quel moment ?
• Quels contrôles de vérification ont été effectués, dans quel ordre, et avec quel résultat ?
• Quel score de risque a été calculé, sur la base de quels paramètres, et pour quelle raison cette valeur a-t-elle été modifiée ?
• Quelle décision a été prise, par qui et dans le cadre de quelle version de la police ?
• Quels événements survenus depuis ont nécessité une réévaluation ?

Rien de tout cela ne s'intègre naturellement au modèle de données de Salesforce. Les équipes contournent ce problème à l'aide d'objets personnalisés, de champs personnalisés et de code personnalisé. Il ne s'agit pas d'une simple configuration. Il s'agit d'une application de conformité sur mesure, construite sur une infrastructure CRM qui n'a pas été conçue pour la prendre en charge.

Quels sont les problèmes qui surviennent réellement lorsque l'on intègre le processus KYC dans un CRM ?

Les modes de défaillance suivent une séquence prévisible. Ils se manifestent rarement tous en même temps. Ils s'accumulent au fil du temps.

La cause profonde est d'ordre architectural. Un système CRM enregistre ce qui s'est passé. Il ne dispose d'aucune notion intrinsèque de ce qui doit se passer ensuite. La conformité, en revanche, est une obligation permanente de maintenir un état souhaité : un registre structuré et vérifiable indiquant qui est en conformité, avec quelles preuves, à l'instant présent. C'est dans l'écart entre ces deux modèles que réside le risque réglementaire.

En pratique, cet écart se creuse dans l'ordre suivant :

• Paralysie due aux changements de politique. Lorsqu’une nouvelle politique ou réglementation interne impose une étape de vérification supplémentaire, ou qu’un seuil de risque est modifié, les équipes doivent ouvrir un ticket de développement dans Salesforce. Les changements prennent des semaines. Entre-temps, les dossiers sont traités selon des règles obsolètes et un projet de mise en conformité concernant le retard accumulé dans le traitement des clients est lancé.

• Risques liés à l’audit réglementaire. Les objets Salesforce personnalisés ne constituent pas une piste d’audit immuable et lisible par les autorités de régulation. Lorsqu’un inspecteur de l’AMF ou de l’ACPR demande comment et pourquoi une décision en matière de risque a été prise, répondre « nous disposons d’un objet personnalisé dans Salesforce » ne constitue pas une réponse défendable. L’AMF a établi un principe clair dans l’ensemble de sa jurisprudence pour la période 2024-2025 : la procédure de lutte contre le blanchiment et le financement du terrorisme (LCB-FT) d’un établissement doit être autonome et ne peut se contenter de renvoyer à « l’outil ». L’outil doit venir en appui de la procédure, et non la remplacer.
• Une gestion fragmentée des prestataires. Le filtrage anti-blanchiment (AML), la vérification des pièces d'identité (IDV), l'enrichissement du registre des sociétés, la résolution du graphe des bénéficiaires effectifs finaux (UBO): chacune de ces opérations nécessite une intégration distincte. Salesforce devient ainsi le middleware de services qu’il n’a pas été conçu pour orchestrer. Chaque mise à jour d’API effectuée par un prestataire provoque une rupture quelque part dans la chaîne.
• Les contrôles périodiques passent à la trappe. C’est ce type de défaillance qui ouvre directement la voie à des cycles de correction sans fin. La « vigilance constante » prévue à l’article L. 561-6 du Code monétaire et financier exige un suivi continu, une reclassification périodique des risques et une mise à jour des documents tout au long de la relation client. Un CRM ne dispose d’aucun mécanisme natif permettant de détecter qu’un Kbis client date désormais de plus de trois mois, de signaler qu’un contrôle relatif à une Personne Politiquement Exposée (PPE) est périmé, ou d’imposer une fréquence de mise à jour en fonction du niveau de risque. En l’absence d’une telle infrastructure, il en résulte un portefeuille de dossiers qui semblent à jour dans le CRM mais qui ne sont pas conformes aux yeux de l’autorité de régulation. L’AMF l’a clairement indiqué dans sa décision TRA-2025-05 : un établissement qui s’appuyait sur des questionnaires déclaratifs à l’entrée pour l’identification des PPE, sans mise à jour au cours de la relation, a été sanctionné. Connaître le client depuis longtemps ne constitue pas une diligence raisonnable.
• L'IA repose sur des bases erronées. Les agents d'IA ne produisent des résultats utiles que lorsque le contexte des données sur lesquelles ils opèrent est correctement structuré pour la tâche à accomplir. Une IA de conformité fonctionnant sur des données CRM commerciales génère un raisonnement adapté au contexte commercial. Elle ne peut pas mettre en évidence les bons signaux de risque, car elle analyse un dossier commercial et non un dossier de risque.

Il en résulte un cercle vicieux que la plupart des établissements ne reconnaissent qu’une fois qu’ils s’y trouvent déjà pris : un investissement ponctuel dans onboarding , suivi de campagnes de mise en conformité répétées pour ramener le portefeuille dans les règles, qui se répètent indéfiniment car la cause profonde n’a jamais été corrigée. L’AMF s’est prononcée spécifiquement sur ce scénario : les documents constitués ou sollicités après le contrôle de l’autorité de régulation sont considérés comme la preuve du manquement initial, et non comme une mesure de mise en conformité. Le manquement est établi ; la mise en conformité ne l’efface pas. Un système qui n’a pas été conçu pour assurer un suivi ne peut pas générer les déclencheurs qui empêcheraient la mise en conformité de devenir permanente.

S'agit-il d'un problème lié à Salesforce ou d'un problème d'architecture ?

C'est un problème d'architecture. Salesforce fonctionne exactement comme prévu.

L'erreur consiste à lui demander d'assumer deux rôles à la fois : gérer la relation commerciale et tenir à jour le dossier de conformité. Ces fonctions ont des exigences différentes en matière de données, d'audit, de fréquence de mise à jour et d'obligations réglementaires.

Une architecture bien conçue permet de les séparer clairement.

Dans cette architecture, Salesforce ne disparaît pas. Il remplit mieux son rôle, car il n'est plus chargé de la gestion de la conformité. Il reçoit d'Ondorse des résultats clairs et structurés, qu'il présente ensuite aux équipes commerciales dans le contexte dont elles ont besoin.

Est-ce que cela signifie qu'il faut supprimer Salesforce ?

Non. Et cette distinction est importante.

Le modèle d'intégration qu'Ondorse a mis en place auprès de plusieurs établissements réglementés fonctionne comme suit :

1. Une nouvelle fiche client est créée dans Salesforce (Compte + Opportunité).
2. Salesforce déclenche la création d'un dossier KYC dans Ondorse via l'API REST, en transmettant les données commerciales pertinentes.
3. Ondorse gère l'ensemble du cycle de vie de la conformité : collecte des données via un portail en marque blanche ou une API « headless », vérifications auprès des registres officiels et des prestataires de services de lutte contre le blanchiment d'argent, évaluation des risques, examen par des analystes et prise de décision.
4. Ondorse envoie un webhook à Salesforce indiquant le résultat de la vérification de conformité : approuvé, en attente, rejeté ou nécessitant une diligence raisonnable renforcée (EDD).
5. Les équipes commerciales voient s'afficher dans Salesforce un champ indiquant le statut de conformité, mis à jour en temps réel, sans jamais avoir à intervenir sur l'infrastructure de conformité sous-jacente.

Il s'agit d'une intégration bidirectionnelle, pilotée par les événements, via une API REST et des webhooks. Elle est documentée, versionnée et reproductible. Elle ne nécessite aucune personnalisation de Salesforce au-delà d'une connexion API standard.

L'équipe Salesforce conserve son système. L'équipe chargée de la conformité dispose d'une plateforme spécialement conçue à cet effet. Aucune des deux ne fait de concessions à l'autre.

Quel est, concrètement, le coût d'une architecture inadaptée ?

Les chiffres parlent d'eux-mêmes.

Chaque boucle de demande manuelle répétée, due à un workflow Salesforce mal configuré ou rigide, allonge directement le temps d'attente pour le client. Sur les marchés B2B concurrentiels, onboarding lente onboarding avant tout un problème de conversion, bien plus qu'un problème de conformité.

Dans le secteur bancaire, le délai moyen d'intégration d'un client professionnel est de 28 jours. Une part importante de ce retard est due à des frictions administratives causées par des systèmes isolés les uns des autres, la ressaisie manuelle des données et la recherche de documents par e-mail. Aucun de ces éléments n'est inhérent à la mise en conformité. Ils sont le résultat de l'utilisation d'un outil inadapté.

Le corpus jurisprudentiel 2024-2025 de l'AMF en matière de lutte contre le blanchiment et le financement du terrorisme (LCB-FT) quantifie précisément les conséquences d'une infrastructure de conformité insuffisante. Entre octobre 2024 et décembre 2025, l'AMF a rendu ou clôturé 12 décisions concernant des sociétés de gestion de portefeuille et des conseillers en investissement financier. Montant total des sanctions financières : 5,815 millions d’euros (2,71 millions d’euros à l’encontre des personnes morales, 3,1 millions d’euros à l’encontre des dirigeants à titre personnel). Dans 100 % des décisions de sanction, les dirigeants ont été sanctionnés à titre individuel. Deux d’entre eux ont fait l’objet d’une interdiction définitive d’exercer dans le secteur (AMF, Guide de jurisprudence LCB-FT, 2025).

Les taux de lacunes constatés dans les dossiers clients échantillonnés ne constituent pas des anomalies. Dans une décision (SAN-2025-09), 94 % des dossiers échantillonnés présentaient des lacunes en matière d’identification KYC et PPE. Dans une autre (SAN-2025-13), 84 % des dossiers échantillonnés ne comportaient pas de justificatif de domicile valide. Dans la décision SAN-2025-11, 73 % des dossiers examinés ne comportaient aucune trace de vérification des personnes politiquement exposées (PPE), aucune vérification par rapport aux listes de sanctions et aucune recherche relative au gel des avoirs.

Le schéma se répète dans tous les cas : la procédure existait. L'outil avait été mis en place. Les dossiers étaient vides. Les autorités de régulation ne se contentent pas de sanctionner les erreurs commises par les équipes. Elles sanctionnent l'absence d'un système garantissant structurellement le respect des règles.

Un système fondé sur des données factuelles peut-il s'adapter aux changements de politique sans nécessiter de travaux de développement ?

C'est là la différence architecturale fondamentale, et il convient d'être précis à ce sujet.

Un système basé sur des workflows — ce que devient tout CRM lorsqu’il est adapté aux exigences de conformité — est optimisé pour des enchaînements d’étapes. L’étape A doit précéder l’étape B. Si la politique de conformité évolue et que l’étape B n’est plus requise, ou si une nouvelle étape C doit être insérée entre A et B, quelqu’un doit modifier le workflow. Cela nécessite un travail de développement. Cela prend du temps. Et tant que la modification n’est pas déployée, les dossiers continuent d’être traités selon les anciennes règles.

Un système fondé sur les preuves fonctionne différemment. Au lieu de codifier la conformité sous la forme d’une séquence fixe d’étapes, il la modélise comme un ensemble d’exigences qui doivent être satisfaites. Chaque dossier dispose d’un graphe de dépendances en temps réel : une cartographie structurée des preuves requises, de celles qui ont été collectées et des lacunes qui subsistent. Lorsqu’une politique change, seule la définition des exigences est mise à jour. Le système réévalue ensuite chaque dossier en cours à la lumière des nouvelles exigences et met en évidence les écarts : les tâches spécifiques, par dossier, qui doivent être menées à bien, abandonnées ou réexécutées. Cette réévaluation a lieu au moment de la requête, et non lors de la création du dossier. Aucun workflow n’a besoin d’être reconstruit. Aucun dossier n’a besoin d’être examiné manuellement pour identifier ceux qui sont concernés. Le système s’en charge.

Ondorse repose sur ce modèle. Si cette fonctionnalité est rare, c’est parce qu’elle nécessite de séparer la couche des règles de conformité de la couche des preuves et de la couche d’exécution (trois modèles de données distincts que la plupart des outils de conformité, et tous les CRM, regroupent en un seul flux de travail). Lorsque ces couches sont distinctes, les équipes chargées de la conformité peuvent mettre à jour les règles, les seuils et les exigences en matière de documentation directement sur la plateforme, sans intervention des développeurs, et la modification est immédiatement répercutée sur tous les dossiers en cours.

Cela n'est pas seulement important pour des raisons d'efficacité. C'est également essentiel pour garantir la validité juridique face aux autorités de régulation. Lorsqu'un régulateur demande si un dossier traité après une mise à jour de la politique a été géré conformément aux nouvelles règles, la réponse doit être vérifiable, et non approximative.

Concrètement, comment Ondorse s'intègre-t-il à SalesForce, le leader des logiciels CRM ?

Cette intégration suit un modèle CRM standard. Elle ne nécessite aucune refonte de la part de l'une ou l'autre des parties.

La documentation relative à l'intégration d'Ondorse distingue cinq types d'intégration, allant du « zéro code » au « headless » complet, la durée de l'intégration au CRM étant estimée entre une et trois semaines de bout en bout.

Le fonctionnement repose sur trois points clés :

Le modèle de données de Salesforce n'est pas modifié, à l'exception d'un petit nombre de champs d'état. Le dossier de conformité, la piste d'audit complète, les paramètres d'évaluation des risques, le journal d'audit et toutes les données issues des prestataires sont exclusivement stockés dans Ondorse. Salesforce reçoit un résultat structuré, et non un simple transfert de données brutes.

Pour les établissements qui exploitent également une plateforme propriétaire de back-office ou de front-office parallèlement à Salesforce, l’intégration s’étend naturellement. Dans l’architecture d’un établissement financier transfrontalier bien établi utilisant Ondorse, Salesforce gère l’intégration CRM classique (déclenchement de la création de dossiers, retour d’information sur le statut), tandis que le back-office de notre client se connecte indépendamment à Ondorse via une intégration distincte au sein de l’application afin d’enregistrer les événements du cycle de vie et de déclencher des contrôles de diligence raisonnable continus. Les deux intégrations fonctionnent en parallèle sans conflit, car chaque système lit et écrit dans Ondorse via sa propre interface API.

Concrètement, cela se traduit ainsi : les équipes commerciales continuent de travailler dans Salesforce sans aucune interruption de leurs processus. Les équipes chargées de la conformité disposent désormais d’une plateforme dédiée où chaque dossier est structuré, horodaté et vérifiable. Les établissements qui ont mis en œuvre ce modèle font état d’une réduction d’environ 50 % onboarding et sont désormais en mesure de faire face à une forte augmentation des volumes sans avoir à renforcer leurs effectifs en matière de conformité.

Pourquoi la bonne question n'est pas « un CRM peut-il assurer le KYC ? », mais « devrait-il le faire ? »

Salesforce et d'autres CRM offrent de nombreuses fonctionnalités. Sa plateforme est extensible, son écosystème AppExchange est vaste et sa communauté de développeurs est importante. Avec suffisamment de code personnalisé, il est possible de reproduire un workflow de conformité au sein de Salesforce.

La question n'est pas de savoir si c'est possible. La question est de savoir quel sera le coût total de ce choix, à long terme.

Chaque mise à jour de la politique de conformité nécessite la création d'un ticket de développement. Chaque nouveau prestataire de services de vérification nécessite une intégration sur mesure. Chaque visite d'un organisme de réglementation nécessite d'expliquer pourquoi le système de référence est un CRM commercial. Chaque fonctionnalité d'IA développée à partir de ce système hérite d'un contexte de données erroné.

La complexité liée à la conformité ne diminue pas avec le temps. Elle augmente. Une architecture qui répond aux exigences initiales mais qui accumule de la dette technique à chaque changement réglementaire n'est pas une architecture de conformité. C'est un fardeau qui ne cesse de s'alourdir.

La répartition des rôles est simple : Salesforce gère la relation commerciale. Ondorse gère le dossier de conformité. Les deux systèmes communiquent entre eux via une API bien structurée. Aucun des deux systèmes n'a à supporter la charge de l'autre.

Ondorse s'intègre à Salesforce dès son installation, grâce à un modèle d'intégration validé par diverses institutions réglementées, notamment des établissements de paiement, des banques, des établissements de monnaie électronique (EMI) et des gestionnaires d'actifs (AM). Pour découvrir comment cette architecture s'adapte à votre infrastructure, consultez le guide d'intégration d'Ondorse ou contactez l'équipe.