Sécurité des CRM : ce qu’il faut regarder en 2026

La sécurité d’un CRM, c’est la façon dont il protège les données clients qu’il contient : le chiffrement en transit et au repos, les contrôles de connexion et d’accès, l’isolation entre clients, une piste d’audit, les sauvegardes, le lieu de stockage des données et les tests indépendants qui étayent les affirmations de l’éditeur. Pour l’évaluer, demandez à chaque éditeur des précisions sur chacun de ces points ; la liste de contrôle ci-dessous les reprend.

Votre CRM contient les données les plus sensibles de votre entreprise : noms de clients, adresses e-mail, numéros de téléphone, montants des affaires, historique des échanges et notes internes. La sécurité des données d’un CRM est donc un critère d’achat, pas un détail à régler plus tard. Une faille de sécurité dans votre CRM n’est pas seulement un problème technique. Pour beaucoup de petites entreprises, c’est un événement qui peut mettre fin à l’activité. Ce guide explique comment évaluer la sécurité d’un CRM : ce qu’il faut regarder, et les questions auxquelles chaque éditeur doit pouvoir répondre.

Ce qui fait d’un CRM une cible

Un CRM concentre exactement ce que veulent les attaquants : des coordonnées vérifiées, des montants d’affaires et un seul identifiant de connexion qui donne accès à tout. Les attaques par hameçonnage visent les identifiants des outils SaaS. Les attaques de la chaîne d’approvisionnement compromettent les intégrations tierces. Les groupes de rançongiciels ciblent tout particulièrement les petites entreprises, parce qu’elles n’ont souvent pas d’équipe dédiée à la sécurité.

Votre CRM est une cible de grande valeur pour trois raisons :

1. Des données personnelles concentrées. Les noms, adresses e-mail, numéros de téléphone et adresses postales de chaque client et de chaque prospect que vous avez jamais contacté.
2. Des informations stratégiques. Les montants des affaires, les données du pipeline, le chiffre d’affaires et les notes sur la concurrence. Ces données ont de la valeur pour vos concurrents et pour des acteurs malveillants.
3. L’historique des échanges. Des fils d’e-mails, des notes de réunion et des discussions internes qui peuvent contenir des informations confidentielles sur votre activité.

Si l’éditeur de votre CRM ne prend pas la sécurité au sérieux, les données de vos clients sont en danger.

Les fonctions de sécurité d’un CRM qui comptent

Le chiffrement

Le chiffrement est la base. Tout CRM doit chiffrer les données à deux niveaux :

• En transit : un chiffrement TLS 1.2 ou 1.3 pour toutes les données qui circulent entre votre navigateur et les serveurs du CRM. Ce chiffrement empêche l’interception des données pendant leur trajet sur Internet.
• Au repos : un chiffrement AES-256 pour les données stockées sur disque. Si quelqu’un obtient un accès physique au serveur, les données chiffrées restent illisibles sans la clé de chiffrement.

Ce qu’il faut demander : « Quelles normes de chiffrement utilisez-vous pour les données en transit et au repos ? Qui gère les clés de chiffrement ? »

L’isolation entre clients (architecture multi-tenant)

La plupart des CRM modernes sont multi-tenant : plusieurs clients partagent la même infrastructure. C’est efficace et économique, mais cela crée une exigence essentielle : vos données doivent être complètement isolées de celles des autres clients.

Une bonne isolation entre clients comprend :

• Des règles d’isolation au niveau de la base de données. La base de données elle-même fait respecter les limites entre les données au moment de chaque requête. Les requêtes d’un client ne peuvent matériellement pas renvoyer les données d’un autre client, même en cas de bug dans l’application.
• Une défense en profondeur. La couche applicative ET la couche base de données font toutes deux respecter l’isolation. Si une couche échoue, l’autre prend le relais.
• Des clés d’API limitées à votre organisation. L’accès à l’API est restreint à votre organisation. Une clé d’API ne peut pas accéder aux données des autres clients.

Ce qu’il faut demander : « Comment isolez-vous les données entre clients ? Appliquez-vous l’isolation au niveau de la base de données en plus de l’application ? Que se passe-t-il si un bug de l’application contourne le filtrage de votre couche applicative ? »

L’authentification et les contrôles d’accès

Qui peut accéder à quoi dans votre CRM doit être strictement contrôlé.

L’authentification multifacteur (MFA)

La MFA doit être disponible et pouvoir être imposée à tous les utilisateurs. Un mot de passe volé ne doit pas suffire à lui seul pour accéder à votre CRM. Vérifiez la prise en charge des applications d’authentification, des clés d’accès (passkeys : Face ID, Touch ID, Windows Hello ou clés matérielles) et des codes de secours.

Le contrôle d’accès par rôle (RBAC)

Tous les membres de l’équipe n’ont pas besoin d’accéder à tout. Le RBAC vous permet de définir des rôles avec des autorisations précises :

• Administrateur : accès complet aux réglages, aux utilisateurs et à toutes les données
• Responsable commercial : accès aux données de l’équipe, aux rapports et à la gestion du pipeline
• Commercial : accès à ses propres contacts, affaires et activités
• Lecture seule : un accès en consultation pour les parties prenantes qui ont besoin de visibilité mais ne doivent rien modifier

Un bon système RBAC est granulaire. Vous devez pouvoir contrôler l’accès au niveau du module (ce rôle peut-il voir les factures ?), au niveau de l’action (peut-il modifier, ou seulement consulter ?) et au niveau des données (voit-il toutes les affaires, ou seulement les siennes ?).

Ce qu’il faut demander : « Quels rôles sont disponibles ? Puis-je créer des rôles personnalisés ? Quel est le niveau de détail des autorisations ? Puis-je limiter l’accès aux données à “ses propres fiches uniquement” pour certains rôles ? »

La gestion des sessions

Le CRM doit fermer les sessions des utilisateurs inactifs au bout d’un délai, permettre aux administrateurs de révoquer des sessions et donner de la visibilité sur les sessions actives. Si un salarié quitte l’entreprise, vous devez pouvoir couper son accès immédiatement.

La piste d’audit

Chaque action dans le CRM doit être consignée : qui a fait quoi, quand et d’où. Cela comprend :

• la création, la modification et la suppression de fiches ;
• les connexions et les tentatives de connexion échouées ;
• les changements d’autorisations et les attributions de rôles ;
• les exports de données et les opérations en masse ;
• les accès à l’API et l’activité des webhooks.

Une piste d’audit a deux fonctions. D’abord, elle dissuade les menaces internes, parce que les gens se comportent différemment quand ils savent que leurs actions sont enregistrées. Ensuite, elle permet d’enquêter quand quelque chose tourne mal. Vous pouvez retracer exactement ce qui s’est passé et qui en est responsable.

Ce qu’il faut demander : « Proposez-vous une piste d’audit complète ? Jusqu’où remonte-t-elle ? Puis-je filtrer par utilisateur, par type d’action ou par période ? Le journal d’audit lui-même est-il protégé contre la falsification ? »

La sauvegarde et la restauration des données

L’éditeur de votre CRM doit avoir une stratégie de sauvegarde solide :

• Des sauvegardes automatiques à intervalles réguliers (au minimum chaque jour)
• Une restauration à un instant précis, pour remettre les données dans leur état à un moment donné si quelque chose tourne mal
• Une redondance géographique, avec des sauvegardes stockées dans un lieu physique différent de celui des serveurs principaux
• Des restaurations testées et vérifiées régulièrement (une sauvegarde qui n’a jamais été testée n’est pas vraiment une sauvegarde)

Ce qu’il faut demander : « À quelle fréquence les données sont-elles sauvegardées ? Pouvez-vous restaurer les données à un instant précis ? Où les sauvegardes sont-elles stockées ? Quand avez-vous testé une restauration pour la dernière fois ? »

La conformité et les tests indépendants

Selon votre secteur et votre pays, votre CRM peut devoir respecter des exigences de conformité précises. Vous devez aussi savoir quels tests externes étayent les affirmations de l’éditeur en matière de sécurité :

• Des tests de sécurité indépendants : une évaluation externe de l’application de l’éditeur et de ses contrôles de sécurité. Demandez quels tests l’éditeur a passés, quand, et quelles preuves il peut fournir.
• SOC 2 Type II : un rapport d’audit sur les contrôles de sécurité d’un éditeur sur une période donnée. Certains acheteurs, souvent de grandes entreprises et des secteurs réglementés, en demandent un à leurs éditeurs.
• RGPD : si vous stockez des données sur des résidents européens, votre CRM doit permettre l’export des données, leur suppression (droit à l’effacement) et la gestion du consentement.
• HIPAA : si vous traitez des données de santé, le CRM doit respecter les exigences de la HIPAA, notamment un accord de partenaire commercial (BAA) avec l’éditeur. Vérifiez-le avant de stocker la moindre information sur des patients.
• CCPA : les exigences du California Consumer Privacy Act pour les entreprises qui servent des résidents de Californie.

Ce qu’il faut demander : « Quels tests de sécurité indépendants avez-vous passés, et quelles preuves pouvez-vous fournir ? Avez-vous un rapport SOC 2 Type II ? Où en êtes-vous de la conformité au RGPD ? »

Les fonctions de sécurité souvent négligées

La validation et le nettoyage des saisies

Un CRM reçoit en permanence des saisies d’utilisateurs : noms, adresses, notes, corps d’e-mails. Chaque champ de saisie est un point d’attaque possible par script intersite (XSS) ou par injection SQL. Le CRM doit nettoyer toutes les saisies avant de les stocker ou de les afficher.

Ce n’est pas quelque chose que vous pouvez vérifier sur une page marketing. Mais vous pouvez demander : « Comment nettoyez-vous les saisies ? Utilisez-vous des requêtes paramétrées ? Nettoyez-vous le contenu HTML avant de l’afficher ? »

La sécurité de l’API

Si votre CRM a une API (c’est le cas de la plupart), elle doit être sécurisée :

• La gestion des clés d’API : la possibilité de créer, de renouveler et de révoquer des clés d’API
• La limitation du débit : elle empêche les abus et les attaques par force brute
• Des autorisations restreintes : les clés d’API ne doivent avoir que les autorisations minimales nécessaires
• La journalisation des requêtes : tous les appels à l’API doivent être consignés à des fins d’audit

La sécurité des intégrations tierces

Quand votre CRM se connecte à d’autres outils (e-mail, calendrier, comptabilité, marketing), chaque intégration ouvre une surface d’attaque possible. Vérifiez :

• si le CRM utilise OAuth pour les intégrations (plutôt que de stocker les mots de passe d’outils tiers) ;
• si vous pouvez révoquer l’accès d’une intégration sans toucher au reste du CRM ;
• si le CRM vous prévient quand une nouvelle intégration est connectée.

Le contrôle des exports de données

Pouvoir exporter toute votre base de contacts au format CSV est à la fois une fonction et un risque. Recherchez :

• Des exports soumis à autorisation : seuls les utilisateurs qui ont certains rôles peuvent exporter des données
• La journalisation des exports : chaque export est enregistré dans la piste d’audit
• Des limites de débit sur les exports : elles empêchent l’extraction massive de données par des comptes compromis

Les signaux d’alerte

Quand vous évaluez la sécurité d’un CRM, voici les signes qui doivent vous alerter :

• Aucune page claire consacrée à la sécurité sur le site de l’éditeur. Si l’éditeur ne parle pas de sécurité, il n’en fait probablement pas une priorité.
• « Nous sommes dans le cloud, donc c’est sécurisé. » L’hébergement dans le cloud n’est pas une stratégie de sécurité. Posez des questions sur les contrôles précis.
• Aucun test de sécurité indépendant. Un éditeur incapable de dire quels tests externes il a passés vous demande de le croire sur parole quant à sa sécurité.
• L’authentification à deux facteurs réservée à la formule la plus chère. L’authentification à deux facteurs est une fonction de sécurité, pas un luxe. La réserver au niveau le plus cher est un signal d’alerte.
• Aucun contrôle d’accès par rôle. Si tous les utilisateurs ont le même niveau d’accès, un seul compte compromis expose tout.
• Aucune piste d’audit. Sans journaux, vous n’avez aucune visibilité sur ce qui se passe dans votre CRM.

Votre liste de contrôle pour la sécurité d’un CRM

Utilisez cette liste de contrôle pour évaluer un CRM, quel qu’il soit :

• Chiffrement : TLS 1.3 en transit, AES-256 au repos
• Isolation entre clients : sécurité au niveau des lignes, appliquée par la base de données
• Authentification : MFA disponible et pouvant être imposée
• RBAC : autorisations granulaires par rôle, avec un périmètre au niveau des données
• Piste d’audit : journalisation complète de l’activité, avec recherche et filtres
• Sauvegardes : sauvegardes quotidiennes automatiques, avec des restaurations testées
• Conformité et tests : prise en charge du RGPD si vous détenez des données sur des résidents européens. L’éditeur a-t-il passé des tests de sécurité indépendants, et dispose-t-il du rapport SOC 2 ou des conditions HIPAA que vos clients ou votre secteur exigent ?
• Sécurité de l’API : gestion des clés, limitation du débit, autorisations restreintes
• Gestion des sessions : expiration imposée, révocation des sessions
• Contrôle des exports : soumis à autorisation, journalisés, limités en débit

La confidentialité à l’ère de l’IA

L’arrivée de l’IA dans les CRM a ajouté trois questions de confidentialité à la liste des vérifications de sécurité :

1. L’éditeur entraîne-t-il des modèles d’IA sur vos données ? La bonne réponse est non, par défaut, quelle que soit la formule. Certains grands CRM entraînent leurs modèles par défaut : le réglage d’entraînement des modèles d’IA de HubSpot est activé par défaut, et les conditions de Freshworks lui accordent une licence sur les données client (Customer Data) pour l’entraînement de l’IA (AI Training), sauf si le client s’y oppose. Vérifiez le réglage par défaut, pas seulement la politique.
2. Combien de temps les données des appels à l’IA sont-elles conservées ? La bonne réponse est : pas du tout. Le modèle traite la requête, renvoie la réponse et ne garde rien. Demandez combien de temps l’éditeur conserve les données des appels à l’IA et s’il les utilise pour améliorer son produit. C’est utile à savoir avant de signer l’accord de traitement des données (DPA).
3. Pouvez-vous supprimer ou exporter les données liées à l’IA à la demande ? La bonne réponse est : en libre-service, depuis vos propres réglages, sans ticket de support. Les profils de style d’écriture, le contenu des e-mails mis en cache et l’historique d’activité de l’IA doivent tous pouvoir être supprimés sans passer par une procédure de demande d’exercice des droits qui prend 30 jours.

Avec les contrôles de sécurité classiques (chiffrement, MFA, RBAC, journaux d’audit qui rendent toute falsification visible), ces trois questions de l’ère de l’IA forment le périmètre des vérifications pour un CRM moderne. Les réponses de Laureo : l’IA ne s’entraîne jamais sur vos données. Chaque requête IA est envoyée uniquement à des fournisseurs qui n’en conservent rien, et Laureo conserve lui-même l’activité de l’IA que vous voyez dans l’application, comme les conversations et l’historique des exécutions des agents, pour que vous puissiez vérifier ce que l’IA a fait. Vous pouvez demander l’export et la suppression de vos données depuis les réglages de votre compte. La sécurité de Laureo est aussi testée et vérifiée de manière indépendante.

La sécurité n’est pas une fonction. C’est une fondation.

Un CRM aux fonctions excellentes mais à la sécurité faible est un risque. Quand vous choisissez un CRM, vous choisissez un partenaire à qui confier les données les plus sensibles de votre entreprise. Assurez-vous qu’il mérite cette confiance. Posez les questions difficiles, examinez les certifications, vérifiez les réglages de confidentialité par défaut à l’ère de l’IA et choisissez une plateforme qui traite la sécurité comme une fondation, pas comme un détail à régler plus tard.