Choisir un CRM pour un établissement financier
Un CRM bancaire ne se choisit pas comme un CRM commercial ordinaire. L’outil devient un prestataire informatique tiers au sens de la réglementation, il reçoit des données financières de clients, et son intégration au système d’information coûte souvent plus que sa licence. Ce guide expose ce qui sépare les solutions en présence, ce que leurs pages tarifaires disent réellement, et ce qu’un établissement doit vérifier lui-même avant de signer.
Comment ce site est rémunéréCe guide contient un lien rémunéré vers GoHighLevel, placé à un seul endroit : dans la section sur les petites structures du secteur financier. GoHighLevel n’est pas un CRM bancaire, et aucun des éditeurs comparés ici ne rémunère ce site. Il n’y a donc ni note, ni classement, ni verdict.
Les problèmes qu’un CRM règle dans une banque
Les difficultés de la relation client bancaire sont rarement d’ordre technique. Elles tiennent à la dispersion : l’information sur un même client vit dans le système central, dans l’agenda d’un conseiller, dans une messagerie et parfois dans un tableur tenu à l’agence. Chacune de ces sources est exacte ; aucune n’est complète.
Une vision client fragmentée
Le conseiller qui reçoit un client ne voit pas l’appel passé la veille au centre de relation, ni la demande de crédit déposée en ligne. Le client, lui, s’attend à ce que la banque sache. L’écart entre les deux est ce qu’un CRM doit combler — non en remplaçant le système central, mais en rassemblant les interactions autour de lui.
Des opportunités qui ne laissent pas de trace
Une demande de rendez-vous non rappelée, un projet immobilier évoqué au détour d’un entretien, un départ en retraite annoncé : ces signaux existent, mais s’ils ne sont consignés nulle part, ils disparaissent avec le conseiller qui les a entendus — ou avec sa mutation. Le coût n’apparaît dans aucun reporting, précisément parce qu’il n’a jamais été enregistré.
Le cloisonnement entre agences et siège
Le siège définit des campagnes et des objectifs ; les agences les exécutent avec leurs propres méthodes et rendent compte avec retard. Sans outil commun, le pilotage se fait sur des remontées déclaratives consolidées à la main, avec une semaine de décalage et des définitions qui varient d’une agence à l’autre.
Un suivi des conseillers difficile à objectiver
Mesurer l’activité commerciale d’un réseau suppose que les rendez-vous, relances et propositions soient saisis de la même façon partout. C’est une question d’organisation avant d’être une question d’outil, et c’est l’écueil sur lequel échouent le plus de projets : un CRM que les conseillers ne renseignent pas produit des tableaux de bord que personne ne croit.
Une personnalisation qui reste théorique
Proposer le bon produit au bon moment suppose de savoir ce que le client détient déjà, ce qu’il a refusé et ce qu’il a demandé. Sans historique commun, les campagnes s’adressent à des segments larges et atteignent des clients déjà équipés — ce qui use leur attention plus qu’il ne génère d’affaires.
Des ventes croisées qui dépendent du hasard
La proposition d’une assurance emprunteur, d’une épargne ou d’un produit de prévoyance dépend souvent de ce que le conseiller pense à évoquer. Un CRM ne crée pas le besoin du client ; il peut rappeler au conseiller qu’un événement — un crédit accordé, une naissance déclarée — rend la question pertinente.
Un reporting lent et discuté
Quand les chiffres d’activité sont consolidés à partir de fichiers remontés par chaque agence, ils arrivent tard et font l’objet de débats sur leurs définitions plutôt que sur leurs enseignements. Le gain d’un outil commun est d’abord là : des définitions partagées, une source unique, des chiffres disponibles sans ressaisie.
Une expérience client qui varie d’un canal à l’autre
Le client qui a commencé une demande en ligne, l’a poursuivie par téléphone et la termine en agence ne devrait pas avoir à la répéter trois fois. Il le doit souvent, parce que chaque canal tient son propre historique. C’est l’incohérence que le client perçoit le plus directement, et celle qu’un outil commun corrige le plus visiblement.
Ce qu’un CRM est — et ce qu’il ne remplace pas
Un établissement financier dispose déjà d’un système central qui tient les comptes, les contrats et les opérations. Le CRM ne s’y substitue pas. Il organise ce qui se passe autour : les contacts, les demandes, les rendez-vous, les campagnes, les opportunités commerciales et leur suivi.
Cette distinction a une conséquence directe sur le coût d’un projet. La valeur d’un CRM bancaire dépend de ce qu’il reçoit du système central — soldes, produits détenus, événements — et de ce qu’il peut lui renvoyer. Une licence bon marché assortie d’une intégration longue n’est pas une solution économique ; c’est un devis incomplet.
À ne pas confondreUn CRM n’est ni un core banking, ni un outil de conformité, ni un logiciel de gestion de portefeuille. Certaines éditions sectorielles proposent des modules proches de ces fonctions ; elles ne dispensent pas l’établissement de ses propres dispositifs de contrôle, et aucune ne se rend conforme par son installation.
Ce que DORA change au choix d’un CRM
Depuis janvier 2025, le choix d’un logiciel hébergé par un établissement financier n’est plus une décision seulement informatique ou commerciale. Le règlement sur la résilience opérationnelle numérique fait du prestataire un risque à gérer, documenter et déclarer.
L’ACPR, autorité compétente en France, présente ainsi le règlement et son périmètre :
« Le règlement européen 2022/2554 du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA) entrera en application le 17 janvier 2025. » « Les exigences de ce règlement sont rendues applicables, sauf exceptions, à l’ensemble des entités du secteur financier. » Parmi ses volets : « la gestion du risque de tiers porté par les prestataires de services informatiques ». Remise des registres d’information : « le 31/03/2026 ».
Pour un projet CRM, trois conséquences pratiques en découlent. L’éditeur retenu devra figurer au registre d’information que l’établissement tient sur ses prestataires informatiques. Le contrat devra permettre de gérer le risque qu’il porte — accès, audit, réversibilité, sous-traitance ultérieure. Et le choix devra pouvoir être justifié au regard de la criticité de la fonction confiée.[1]
Ce que ce guide ne fait pasIl ne qualifie aucun éditeur au regard de DORA et ne dit pas si un CRM donné relève d’une fonction critique ou importante. Cette appréciation appartient à l’établissement, à ses fonctions de conformité et de gestion des risques. Ce guide signale seulement que la question doit être posée avant la signature, et non après.
Le RGPD s’ajoute à ce cadre sans le remplacer. L’éditeur d’un CRM hébergé traite des données pour le compte de l’établissement : il est sous-traitant, et l’établissement demeure responsable du traitement.[2]
La CNIL définit ce rôle et renvoie ses obligations au contrat :
« Le sous-traitant est la personne physique ou morale (entreprise ou organisme public) qui traite des données pour le compte d’un autre organisme (“le responsable de traitement”), dans le cadre d’un service ou d’une prestation. » Ses obligations « doivent être présentes dans le contrat » : transparence et traçabilité, protection dès la conception et par défaut, sécurité des données, assistance, alerte et conseil.
Certifications, réglementations, autorités : trois choses différentes
Les comparatifs de CRM bancaires rangent souvent dans une même colonne « conformité » des éléments qui n’ont rien de commun. La version précédente de ce site le faisait : elle attribuait « MiFID · RGPD · SOC2 » à un éditeur et « RGPD · ISO 27001 » à un autre, et conseillait de « vérifier les certifications RGPD, MiFID II, DSP2, ACPR ». Ce conseil était faux dans sa formulation même.
| Terme | Nature | Ce qu’on peut demander à un éditeur |
|---|---|---|
| ISO 27001 | Norme de système de management de la sécurité, certifiable par un organisme accrédité | Le certificat, son périmètre, sa date de validité et l’organisme qui l’a délivré |
| SOC 2 | Rapport d’audit sur les contrôles d’un prestataire | Le rapport lui-même, la période couverte et les réserves éventuelles |
| RGPD | Règlement européen applicable aux traitements, pas aux produits | Le contrat de sous-traitance et les garanties qu’il contient — pas un « certificat RGPD » |
| MiFID II | Directive applicable aux services d’investissement et à ceux qui les fournissent | Les fonctions qui aident l’établissement à tracer ses obligations — la conformité reste la sienne |
| DSP2 | Directive sur les services de paiement | Rien de directement certifiable pour un CRM |
| ACPR | Autorité de contrôle — elle supervise des établissements, elle ne certifie pas de logiciels | Rien : l’ACPR ne délivre aucune certification à un éditeur de CRM |
La règle pratique qui en découle est simple. Une certification se prouve par un document daté, délivré par un tiers nommé, sur un périmètre précis ; tout le reste relève de l’affirmation commerciale. Et aucune ligne de ce tableau ne rend un établissement conforme par le seul choix de son logiciel.[1][2]
Les fonctions qui comptent pour une équipe commerciale bancaire
Les listes de fonctionnalités des éditeurs se ressemblent. Le tri utile consiste à distinguer ce qu’un CRM fait en standard de ce qui dépend du paramétrage, d’un module optionnel ou d’une intégration à développer — car c’est cette seconde catégorie qui fait le coût réel d’un projet.
| Fonction | Ce qu’elle apporte | Dont elle dépend |
|---|---|---|
| Vue client consolidée | Toutes les interactions autour d’un client en un seul écran | L’intégration au système central : sans elle, la vue reste partielle |
| Historique des échanges | La continuité quand un conseiller change ou s’absente | Une saisie homogène dans tout le réseau |
| Segmentation du portefeuille | Des campagnes ciblées sur des critères réels | La qualité et la fraîcheur des données reçues |
| Suivi des opportunités | Une visibilité sur les projets en cours et leur avancement | Des étapes définies en commun et respectées |
| Prise de rendez-vous | Moins d’échanges pour fixer un créneau | La synchronisation avec les agendas existants |
| Pilotage des conseillers | Des indicateurs d’activité comparables entre agences | Des définitions communes, arrêtées avant la mise en service |
| Parcours d’entrée en relation | Un suivi des pièces et des étapes jusqu’à l’ouverture | Le lien avec les outils de connaissance client existants |
| Traçabilité des accès | Savoir qui a consulté quoi, et quand | Le paramétrage des habilitations et la conservation des journaux |
Aucune de ces fonctions n’est exclusive à une solution. Ce qui varie, c’est ce qui est livré sans développement, ce que coûte le reste, et le temps nécessaire pour qu’un réseau s’en serve réellement. Une démonstration montre la colonne du milieu ; un appel d’offres doit chiffrer la colonne de droite.
Ce que ce guide n’affirme pasAucun gain de chiffre d’affaires, aucun taux de ventes croisées, aucun temps gagné par conseiller. Ces indicateurs dépendent de l’établissement, de son réseau et de son offre ; les avancer sans mesure reviendrait à présenter une promesse comme un résultat.
Les solutions en présence
La version précédente de ce guide classait cinq solutions de 1 à 5 et leur attribuait des notes sur 10, de 9,4 à 7,0, sans méthode publiée. Ce classement a été retiré. Ce qui suit décrit chaque famille par son positionnement et le type d’établissement auquel elle s’adresse, pour vous permettre d’établir votre propre liste restreinte.
Salesforce Financial Services Cloud
Édition sectorielle d’une plateforme CRM très répandue, conçue pour la banque, l’assurance et la gestion de patrimoine. Elle s’adresse aux établissements disposant d’équipes capables de la paramétrer ou de piloter un intégrateur. Son prix d’entrée par utilisateur est élevé, et le coût d’intégration — non publié — pèse généralement davantage encore.[3]
Microsoft Dynamics 365
Suite CRM intégrée à l’environnement Microsoft, souvent envisagée par les établissements déjà équipés de cet écosystème. Les prix publics portent sur Dynamics 365 Sales ; les composantes propres aux services financiers relèvent d’une offre distincte, non tarifée sur la même page — un point à clarifier en priorité lors d’une consultation.[4]
HubSpot
CRM généraliste orienté marketing et vente, à la prise en main rapide. Il convient davantage aux fintechs et aux structures de taille moyenne qu’à un réseau bancaire étendu. Son édition Enterprise n’a pas de prix public : tout montant qui lui est attribué dans un comparatif est une estimation.[5]
Zoho CRM
CRM généraliste à l’entrée de gamme accessible, parfois envisagé par de petites structures financières. Au relevé, sa page tarifaire française affichait des montants en roupies indiennes : aucun prix en euros ne peut donc être cité ici, et la devise réellement facturée doit être vérifiée avant tout engagement.[6]
Le développement sur mesure
Option retenue lorsque les contraintes du système d’information ou des processus rendent les solutions standard inadaptées. Il offre la maîtrise complète et en fait payer le prix : maintenance, évolutions et continuité reposent entièrement sur l’établissement ou son prestataire — ce qui, au regard de DORA, déplace le risque sans le supprimer.
Ce que coûtent réellement les licences
Le tableau ci-dessous reprend les prix affichés sur les pages des éditeurs à la date de relevé. Il distingue systématiquement cinq informations que les comparatifs omettent : le prix affiché, le prix de liste lorsqu’il diffère, la devise, le traitement des taxes et l’engagement exigé.
| Éditeur · édition | Prix affiché | Prix de liste | Devise | Taxes | Engagement | Source |
|---|---|---|---|---|---|---|
| Salesforce · Financial Services Cloud for Sales | à partir de 325 € | non distingué | EUR | non précisé | annuel | [3] |
| Salesforce · FSC for Sales and Services | à partir de 350 € | non distingué | EUR | non précisé | annuel | [3] |
| Salesforce · FSC Agentforce 1 | 750 € | non distingué | EUR | non précisé | annuel | [3] |
| Microsoft · Dynamics 365 Sales Professional | 56,30 € | non distingué | EUR | HT | annuel | [4] |
| Microsoft · Dynamics 365 Sales Enterprise | 91,00 € | non distingué | EUR | HT | annuel | [4] |
| Microsoft · Dynamics 365 Sales Premium | 130,00 € | non distingué | EUR | HT | annuel | [4] |
| HubSpot · Starter | à partir de 7 € | 20 € | EUR | non précisé | mensuel ou annuel | [5] |
| HubSpot · Enterprise | non publié | sur contact | — | — | — | [5] |
| Zoho · Enterprise | ₹2,400 | non distingué | INR | non précisé | mensuel (annuel en option) | [6] |
Aucun coût d’intégration, de paramétrage ni de reprise de données n’est inclus : aucune de ces pages ne les chiffre. Les éditions ne sont pas équivalentes entre elles et ce tableau ne les classe pas.
Des écarts importants avec la version précédenteL’ancienne version de ce guide annonçait Salesforce Financial Services Cloud à 1 500 € par utilisateur et Dynamics 365 à 700 €. Les pages des éditeurs indiquent, pour le premier, un prix d’entrée de 325 € et un maximum de 750 € ; pour le second, de 56,30 € à 130,00 € hors taxes. Ces montants ne correspondaient à aucune source. [3][4]
Dans un projet bancaire, la licence n’est pourtant pas le premier poste. L’intégration au système central, la reprise des données, le paramétrage des habilitations et la formation des conseillers n’apparaissent sur aucune de ces pages. Un appel d’offres qui compare des prix de licence sans demander ces montants compare la partie la moins significative de la dépense.
Quel type d’outil pour quel établissement
Banque régionale ou réseau multi-agences
L’enjeu est la cohérence entre agences et le pilotage consolidé. Les éditions sectorielles des grandes plateformes sont conçues pour ce cas ; leur intégration au système central sera le poste déterminant, et il faut l’évaluer sur un cas réel avant de retenir une solution.
Banque privée et gestion de patrimoine
Le volume de clients est plus faible et la relation plus dense : liens familiaux, mandats, événements de vie. Les modules spécialisés sont utiles, mais la question première est celle des habilitations — qui voit quoi dans un portefeuille de clients fortunés — et de la traçabilité des accès.
Grande institution et groupe bancaire
Plusieurs métiers, plusieurs systèmes, des exigences de sécurité et de gouvernance élevées. Le choix se joue sur la capacité de l’éditeur à s’intégrer dans une architecture existante et à satisfaire des exigences contractuelles strictes — accès, audit, réversibilité — bien davantage que sur l’interface ou le prix unitaire.
Fintech en phase de croissance
Rapidité de mise en place et coût maîtrisé priment souvent, ce qui oriente vers des CRM généralistes. Mais une fintech agréée reste une entité financière : DORA s’applique, et un outil choisi pour sa simplicité doit tout de même pouvoir figurer au registre d’information avec un contrat adapté.[1]
Petites structures financières : quand un CRM bancaire est disproportionné
Tous les acteurs du secteur ne sont pas des banques. Un cabinet de courtage, un conseiller en gestion de patrimoine indépendant ou une jeune fintech de quelques personnes n’ont ni le système central, ni le budget d’intégration, ni les équipes qui justifient une édition sectorielle à plusieurs centaines d’euros par utilisateur. Leur besoin ressemble davantage à celui de toute entreprise de services : suivre les demandes, fixer les rendez-vous, relancer.
Pour ces structures, un outil généraliste facturé au compte plutôt qu’à l’utilisateur peut suffire. GoHighLevel en fait partie : il regroupe contacts, suivi des opportunités, prise de rendez-vous et relances automatisées, pour un prix mensuel qui ne dépend pas du nombre d’utilisateurs.[7]
Ce que GoHighLevel n’est pasCe n’est pas un CRM bancaire. Il ne se connecte à aucun système central, ne propose pas de module propre aux services financiers, affiche ses prix en dollars et ne précise pas sur sa page tarifaire la localisation des données. Une structure soumise à DORA devra, comme pour tout prestataire, obtenir ces informations et un contrat adapté avant de l’utiliser. Il ne convient pas à une banque. [7][1]
Le lien partenaire ci-dessous ouvre une période d’essai de trente jours, avec le HighLevel Bootcamp inclus sans frais ; la page tarifaire publique de l’éditeur affichait quatorze jours au relevé. Le contenu du Bootcamp ne nous a pas été communiqué et n’est pas décrit ici.[7]
Tester GoHighLevel pendant 30 jours lien rémunéré Pour une petite structure financière, non pour une banque. Lien partenaire : 30 jours, HighLevel Bootcamp inclus. Vérifiez les conditions en vigueur à l’inscription.
Quatre situations types, et ce qu’il faut regarder
La version précédente présentait cinq situations chiffrées comme s’il s’agissait de cas avérés, sans source. Celles qui suivent sont explicitement hypothétiques : ils servent à montrer ce qu’un établissement doit examiner selon sa situation, pas à décrire un client existant.
Un réseau régional sans vision consolidée
Plusieurs dizaines d’agences utilisent chacune leurs propres outils de suivi, et le siège consolide l’activité à la main chaque semaine.
Ce qu’il faut regarder : la capacité à imposer une saisie homogène, l’intégration au système central, et le coût de formation d’un réseau entier — avant le prix de la licence.
Une banque privée et ses familles de clients
Un nombre limité de clients, des relations familiales complexes et une forte sensibilité des informations.
Ce qu’il faut regarder : le cloisonnement des accès, la traçabilité de qui consulte quoi, et les garanties contractuelles de l’éditeur sur la sécurité.
Une fintech qui grandit sans CRM structuré
Les demandes arrivent en ligne, en volume croissant, et sont suivies dans une messagerie partagée.
Ce qu’il faut regarder : la rapidité de mise en place, mais aussi l’inscription du prestataire au registre DORA et la réversibilité si l’outil doit changer à la prochaine étape de croissance.
Une direction qui veut mesurer l’activité des conseillers
Les indicateurs d’activité existent, mais reposent sur des déclarations dont la fiabilité est discutée.
Ce qu’il faut regarder : la définition commune des étapes et des saisies attendues. Sans elle, aucun outil ne produira d’indicateurs fiables, et le choix du logiciel est secondaire.
Les critères qui départagent vraiment
- Intégration au système central : ce qui est livré en standard, ce qui doit être développé, et à quel coût.
- Traitement DORA : place de l’éditeur au registre d’information, clauses d’accès, d’audit et de réversibilité.
- Hébergement et sous-traitance : localisation effective des données, sous-traitants ultérieurs, contrat de sous-traitance.
- Certifications réelles : certificats et rapports datés, avec leur périmètre — pas des logos.
- Habilitations : finesse du cloisonnement entre agences, métiers et portefeuilles.
- Adoption par les conseillers : temps de saisie réel, ergonomie mobile, formation nécessaire.
- Coût total : licence, intégration, reprise, formation, maintenance — sur la durée du contrat.
- Réversibilité : format et complétude de l’export le jour où l’établissement changera d’outil.
L’ordre n’est pas indifférent. Les deux premiers critères éliminent davantage de candidats que les six suivants réunis, et ce sont ceux que les démonstrations commerciales abordent le moins volontiers.
Les erreurs qui font échouer un projet
Choisir pour la taille d’aujourd’hui
Un outil retenu pour dix utilisateurs doit être évalué à la taille que l’établissement vise dans trois ans : nombre d’utilisateurs, volume de clients, nombre d’agences ou de métiers. Changer de CRM en cours de croissance coûte une nouvelle intégration, une nouvelle reprise et une nouvelle formation — et, au regard de DORA, une nouvelle évaluation du prestataire.[1]
Comparer les licences au lieu des projets
Le prix par utilisateur est la seule donnée publiée, donc la plus comparée. C’est aussi la moins déterminante. Un appel d’offres qui ne chiffre pas l’intégration et la reprise retient souvent la solution la plus chère à déployer.
Traiter la sécurité comme une case à cocher
Un logo de certification sur une page commerciale ne prouve rien. Ce qui prouve, c’est le certificat lui-même, son périmètre et sa date, puis le contrat qui engage l’éditeur. Les établissements qui s’en tiennent à la première étape découvrent les limites de la seconde lors du premier incident.
Oublier les conseillers
Un CRM que le réseau ne renseigne pas ne vaut rien, quelle que soit sa richesse fonctionnelle. L’adoption se prépare : saisies réduites au nécessaire, bénéfice visible pour le conseiller lui-même, et une personne qui en répond dans chaque agence.
Viser trop large dès le départ
Les projets qui veulent tout couvrir dès la première phase — tous les métiers, toutes les intégrations, toutes les campagnes — dépassent leur budget avant d’avoir produit un résultat. Un périmètre initial restreint, mis en service puis étendu, donne des preuves plus tôt et des arbitrages plus justes.
Négliger la gouvernance de la donnée
Qui peut créer une fiche, qui peut la modifier, qui décide de sa suppression et au bout de combien de temps : ces règles doivent être arrêtées avant la mise en service. Sans elles, les doublons s’accumulent et les indicateurs perdent leur sens en quelques mois.
Démarrer et tester avant de s’engager
Pour un établissement, une démonstration ne suffit pas : elle montre l’outil sur des données de démonstration. La phase utile est une preuve de concept limitée, conduite sur un périmètre réel et mesurée sur des critères écrits à l’avance.
- Définir le périmètre : une agence ou un métier, une liste de parcours à couvrir.
- Écrire les critères de réussite avant de commencer : temps de saisie, complétude, intégration d’un flux réel.
- Obtenir de l’éditeur, par écrit : localisation des données, contrat de sous-traitance, certificats et rapports d’audit, clauses de réversibilité.
- Faire valider par les fonctions conformité et risques la place du prestataire au regard de DORA.
- Tester avec les conseillers eux-mêmes, et mesurer ce qu’ils renseignent spontanément.
- Chiffrer le projet complet — intégration, reprise, formation — avant toute décision.
Cette séquence prend plus de temps qu’une signature sur démonstration. Elle en fait gagner beaucoup plus en évitant de découvrir après coup que l’outil retenu ne s’intègre pas, que le réseau ne l’utilise pas, ou que son contrat ne répond pas aux exigences applicables au prestataire.[1]
Questions fréquentes
Un CRM peut-il disposer d’une certification RGPD ?
Pas au sens où l’entendent certains comparatifs. Le RGPD s’applique à des traitements mis en œuvre par un responsable identifié, pas à des produits. L’éditeur d’un CRM hébergé est sous-traitant ; ce qu’on peut exiger de lui, ce sont des garanties contractuelles et des mesures de sécurité documentées.[2]
Un CRM choisi par une fintech est-il concerné par DORA ?
Selon l’ACPR, les exigences du règlement s’appliquent, sauf exceptions, à l’ensemble des entités du secteur financier. Une fintech agréée en fait partie, et ses prestataires informatiques relèvent de la gestion du risque de tiers qu’il organise.[1]
Pourquoi ce guide ne désigne-t-il pas de gagnant ?
Parce qu’aucun classement ne tient compte de ce qui décide réellement : votre système central, votre réseau, vos métiers et vos obligations. Un classement général serait une opinion déguisée en mesure. Ce guide fournit à la place les prix relevés, les distinctions réglementaires et les critères permettant d’établir votre propre comparaison.
Pourquoi GoHighLevel est-il mentionné dans un guide bancaire ?
Parce que ce site perçoit une commission sur ce lien, et parce que l’outil peut convenir à de petites structures du secteur financier pour lesquelles un CRM bancaire serait disproportionné. Il n’est présenté qu’à cet endroit, et il est dit clairement qu’il ne convient pas à une banque.
Sources
Chaque prix et chaque affirmation réglementaire renvoie à la page dont il provient, avec sa date de relevé, ce qu’elle établit et ce qu’elle n’établit pas.
- Digital Operational Resilience Act (DORA) ACPR — Autorité de contrôle prudentiel et de résolution · acpr.banque-france.fr · relevé le 2026-09-21
« Le règlement européen 2022/2554 du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA) entrera en application le 17 janvier 2025. » « Les exigences de ce règlement sont rendues applicables, sauf exceptions, à l’ensemble des entités du secteur financier. » Parmi ses volets : « la gestion du risque de tiers porté par les prestataires de services informatiques ». Remise des registres d’information : « le 31/03/2026 ».
Établit : Que DORA s’applique depuis le 17 janvier 2025 à l’ensemble des entités du secteur financier sauf exceptions, qu’il couvre le risque porté par les prestataires informatiques tiers, et qu’un registre d’information est remis à l’ACPR. La page établit aussi, par elle-même, ce qu’est l’ACPR : une autorité de contrôle. N’établit pas : La page ne qualifie aucun logiciel, ne dit pas si un CRM donné constitue un prestataire critique, et ne remplace pas la lecture du règlement ni des textes d’application. - Sous-traitant — définition et obligations CNIL · cnil.fr · relevé le 2026-09-21
« Le sous-traitant est la personne physique ou morale (entreprise ou organisme public) qui traite des données pour le compte d’un autre organisme (“le responsable de traitement”), dans le cadre d’un service ou d’une prestation. » Ses obligations « doivent être présentes dans le contrat » : transparence et traçabilité, protection dès la conception et par défaut, sécurité des données, assistance, alerte et conseil.
Établit : Qu’un éditeur de CRM hébergé agit comme sous-traitant, que l’établissement reste responsable de traitement, et que les obligations du sous-traitant passent par le contrat. N’établit pas : La page ne certifie aucun produit. Aucun logiciel ne porte en lui-même la conformité au RGPD : la conformité est celle d’un traitement, mis en œuvre par un responsable. - Financial Services Cloud — Tarifs Salesforce · salesforce.com · relevé le 2026-09-21
Financial Services Cloud for Sales : « À partir de 325 € EUR/Utilisateur/Mois (Facturation annuelle) ». for Service : à partir de 325 €. for Sales and Services : à partir de 350 €. Agentforce 1 for Sales & Service : 750 € EUR/Utilisateur/Mois (Facturation annuelle).
Établit : Les prix d’entrée par utilisateur et par mois, en euros, sur engagement annuel. N’établit pas : La page ne précise pas si les taxes sont incluses et n’inclut aucun coût d’intégration ou de paramétrage — souvent le premier poste d’un projet bancaire. - Dynamics 365 Sales — Tarifs Microsoft · microsoft.com · relevé le 2026-09-21
Dynamics 365 Sales Professional : « 56,30 € HT utilisateur/mois, paiement annuel ». Sales Enterprise Edition : « 91,00 € HT ». Sales Premium : « 130,00 € HT ». Microsoft Relationship Sales : prix variable, minimum 10 utilisateurs.
Établit : Les prix hors taxes de Dynamics 365 Sales, par utilisateur et par mois, sur engagement annuel. N’établit pas : Il s’agit de Dynamics 365 Sales, pas d’une offre spécifique aux services financiers : la couche sectorielle de Microsoft n’est pas tarifée sur cette page. - HubSpot — Tarifs CRM HubSpot · hubspot.fr · relevé le 2026-09-21
Outils gratuits : « 0 €/mois », jusqu’à 2 utilisateurs. Starter : « À partir de 7 €/mois/licence », prix barré « 20 €/mois/licence », avec « Économisez jusqu’à 65 % sur Starter ». Enterprise : aucun prix affiché, contact commercial.
Établit : Le palier gratuit, le prix promotionnel et le prix de liste de Starter, et l’absence de prix public pour Enterprise. N’établit pas : Aucun prix Enterprise n’est publié : tout chiffre attribué à cette édition est une estimation. - Zoho CRM — Éditions et tarifs (page française) Zoho · zoho.com · relevé le 2026-09-21
Standard « ₹800/utilisateur/mois » · Professional « ₹1,400 » · Enterprise « ₹2,400 » · Ultimate « ₹2,600 ». Gratuit : ₹0 pour 3 utilisateurs.
Établit : Que la page tarifaire française affichait, au relevé, des montants en roupies indiennes. N’établit pas : Aucun prix en euros. Une conversion supposerait un taux et une date que personne ne peut garantir ici ; la devise affichée dépend manifestement du lieu de consultation. - HighLevel — Pricing HighLevel · gohighlevel.com · relevé le 2026-09-20
Starter $97/Month · Unlimited $297/Month · Agency Pro $497/Month. « On all plans, you get unlimited contacts and unlimited users. » « Start Your 14 Day Free Trial Today! »
Établit : Les tarifs en dollars, le nombre illimité d’utilisateurs, et la durée d’essai publique. N’établit pas : Aucun prix en euros, aucune indication de localisation des données, aucune mention d’un usage par un établissement financier soumis à DORA.