Deux équipes demandent une « vue client unique ». La première veut retrouver les devis, les interlocuteurs et les relances. La seconde veut rapprocher les achats, les visites et les réactions aux campagnes pour créer des segments. Elles utilisent la même expression, mais elles ne décrivent pas le même système.
Un CRM organise généralement la relation et les processus associés. Une CDP, ou plateforme de données clients, vise à réunir et à exploiter des données provenant de plusieurs sources pour des usages de connaissance et d’activation.
Les frontières fonctionnelles peuvent se chevaucher selon les produits.
Le bon choix commence donc par les décisions à rendre possibles, pas par un sigle.
Acheter une CDP pour réparer un CRM mal tenu est rarement un bon diagnostic. Ajouter un CRM ne résout pas non plus, à lui seul, une identité client dispersée entre plusieurs systèmes.
Partir d’une action aujourd’hui impossible
Demandez aux équipes de décrire trois actions qu’elles ne peuvent pas réaliser correctement. « Mieux connaître le client » reste trop abstrait. « Ne plus envoyer une relance d’acquisition à une personne qui vient de signer » désigne un problème vérifiable. « Montrer au commercial les achats du compte et le bon contact » en désigne un autre.
Pour chaque action, précisez le déclencheur, les données nécessaires, le délai et le canal de sortie. Un segment recalculé chaque semaine ne demande pas la même architecture qu’une réaction attendue quelques secondes après un événement. Une décision qui engage un devis peut nécessiter une validation humaine plutôt qu’une synchronisation immédiate.
Identifiez ensuite le point de rupture. L’information n’existe-t-elle pas ? Est-elle dans un autre système ? Est-elle mal identifiée ? Arrive-t-elle trop tard ? L’équipe n’a-t-elle simplement pas accès à un champ déjà disponible ? Ces causes appellent des réponses différentes.
Le besoin peut parfois être satisfait par une intégration limitée et une règle métier claire. Il peut aussi révéler une difficulté structurelle de rapprochement et de gouvernance. Le coût d’une plateforme ne se justifie que si elle traite un problème réel avec une responsabilité durable.
Le cahier des charges CRM aide à formaliser la partie relationnelle avant d’étendre l’architecture.
Comparer les responsabilités, pas les listes de fonctionnalités
Le CRM constitue souvent l’environnement de travail des équipes commerciales ou de service : comptes, contacts, opportunités, interactions, tâches et règles de suivi. La qualité dépend alors de l’adoption, des définitions de statut et de la discipline de saisie autant que du logiciel.
Une CDP peut rapprocher des données issues du commerce, du site, des campagnes ou d’applications pour construire des profils et des segments. La documentation de Microsoft Customer Insights décrit notamment des étapes d’unification à partir de sources de données. Cet exemple illustre une capacité de catégorie ; il ne signifie pas que tous les produits exécutent le même rapprochement ou répondent au même besoin.
Un entrepôt de données conserve et organise des données pour des traitements analytiques et d’autres usages. Une plateforme d’automatisation orchestre des scénarios et des communications. Un gestionnaire de consentement traite des préférences et des choix dans un périmètre donné. Plusieurs fonctions peuvent être réunies dans une suite, mais leur responsabilité doit rester identifiable.
| Besoin dominant | Point de départ à examiner | Vérification décisive |
|---|---|---|
| Suivre devis et relances | CRM | Le processus est-il partagé et utilisé ? |
| Rapprocher des identités entre sources | CDP ou couche d’unification | Les règles de correspondance sont-elles maîtrisées ? |
| Analyser des historiques volumineux | Entrepôt et outils de données | Les modèles et la qualité sont-ils entretenus ? |
| Déclencher des communications | Automatisation | Les conditions et exclusions sont-elles fiables ? |
La présence d’un module nommé « Customer 360 » ne prouve pas une unification correcte. Demandez comment les données sont rapprochées, quelles erreurs sont possibles et comment elles se corrigent.
L’identité client est le chantier central
Une personne peut utiliser plusieurs adresses, acheter pour une entreprise, changer d’employeur ou partager un équipement. Un compte B2B peut contenir plusieurs établissements et plusieurs rôles. Ces réalités compliquent une promesse apparemment simple : reconnaître le même client partout.
Distinguez les identifiants techniques et les identités métier. Un identifiant de navigateur n’est pas une preuve certaine de personne. Un domaine email n’identifie pas toujours une entreprise unique. Une adresse partagée ne permet pas forcément de distinguer les utilisateurs.
Les règles de rapprochement doivent préciser ce qui autorise une fusion, ce qui constitue seulement un indice et ce qui interdit le rapprochement. Examinez aussi la réversibilité : si deux profils ont été fusionnés à tort, peut-on les séparer et corriger les activations déjà déclenchées ?
Dans un exemple fictif, un distributeur rapproche deux contacts portant le même nom. L’un achète pour une société, l’autre pour une association. Une fusion approximative peut mélanger les historiques et exposer des informations au mauvais interlocuteur. Le risque dépasse la qualité d’un segment marketing.
Préparez un jeu de contrôle avec doublons attendus, homonymes, changements d’adresse et comptes partagés. Faites vérifier les résultats par une personne qui connaît les cas métier. Un pourcentage global de rapprochement ne montre pas à lui seul si les erreurs sont acceptables.
Fixer une source de référence par donnée
La « source de vérité unique » devient trompeuse lorsqu’elle laisse croire qu’un logiciel doit décider de tous les champs. Le système de facturation peut faire référence pour les factures. Le CRM peut faire référence pour le responsable commercial. Un outil de consentement ou un registre adapté peut faire référence pour certaines préférences.
Écrivez cette répartition champ par champ pour les informations critiques. Qui peut modifier la donnée ? Quelle modification l’emporte ? Quel historique est conservé ? Quel système reçoit la correction ? Les règles de priorité ne doivent pas être cachées dans un connecteur configuré par une personne partie depuis longtemps.
Une synchronisation bidirectionnelle exige une attention particulière. Si deux systèmes modifient le même champ, vous risquez des écrasements ou des boucles. Définissez des responsabilités d’écriture et des mécanismes de résolution des conflits avant la mise en production.
La fraîcheur compte également. Afficher un stock, un statut contractuel ou une opposition avec plusieurs jours de retard peut être inacceptable. Une donnée destinée à une analyse trimestrielle tolère parfois une autre cadence. Le délai attendu doit être lié à une décision, pas à la disponibilité d’un bouton « temps réel ».
Conservez l’horodatage de l’événement et celui de son traitement. Ils permettent de distinguer une information produite tardivement d’un retard d’intégration.
Consentement et finalités : une architecture ne crée pas un droit
Réunir davantage de données ne donne pas automatiquement le droit de les utiliser pour tous les objectifs. Documentez les finalités, les bases légales, les durées et les accès avec les personnes compétentes. Les choix doivent se traduire dans les segments et les canaux réellement activés.
Une préférence de communication ne doit pas rester un champ décoratif dans une vue client. Testez son effet : après opposition dans le système prévu, les prochains scénarios concernés excluent-ils la personne ? Le changement se propage-t-il aux outils connectés ? Que se passe-t-il si un ancien fichier est réimporté ?
Le même travail concerne les demandes de correction ou de suppression. Une donnée effacée dans l’interface peut subsister dans une source, une exportation ou une réimportation programmée. Cartographiez ces chemins et définissez une procédure cohérente plutôt que de promettre une suppression globale non vérifiée.
Appliquez des accès proportionnés. Une équipe chargée d’une campagne n’a pas nécessairement besoin de consulter tout l’historique de service ou les pièces contractuelles. Les droits doivent suivre l’usage et être réexaminés lors des départs ou changements de fonction.
Le risque n’apparaît pas seulement dans les grandes bases. Un petit fichier contenant des informations sensibles ou mal partagées peut déjà poser un problème sérieux.
Calculer le coût d’exploitation, pas seulement la licence
La comparaison commerciale commence souvent par le prix affiché. L’investissement réel inclut les connecteurs, la préparation des données, la migration, le paramétrage, les tests, la formation et la maintenance. Les volumes de profils, d’événements, de destinations ou d’appels peuvent aussi modifier la facture selon le contrat.
Demandez une simulation avec vos usages, vos pointes et vos règles de conservation. Vérifiez les coûts des environnements de test, des journaux et des exports. La possibilité technique d’une fonction ne prouve pas qu’elle est incluse dans l’offre proposée.
Dans un scénario fictif, une licence coûte 12 000 € par an. Le projet mobilise 8 000 € d’intégration, 5 000 € de préparation des données et 6 000 € de temps interne la première année. Le coût initial atteint 31 000 €, avant certains frais récurrents éventuels. Cette addition pédagogique montre pourquoi comparer seulement deux abonnements peut inverser un choix.
Évaluez aussi les dépendances humaines. Une architecture complexe entretenue par une seule personne fragile n’est pas nécessairement moins coûteuse qu’un dispositif plus simple. Le temps de diagnostic d’un incident, la compétence nécessaire et la documentation font partie du coût complet.
Le budget marketing piloté par la marge permet de replacer l’investissement dans sa contribution attendue plutôt que de le justifier par une promesse générale de personnalisation.
Exiger une démonstration avec vos cas limites
Une démonstration standard montre généralement un parcours favorable. Préparez un scénario plus exigeant : doublon, donnée manquante, changement de consentement, retrait d’un accès, panne de connecteur et export de sortie. Utilisez des données fictives ou convenablement protégées pour éviter d’exposer inutilement votre clientèle.
Demandez à suivre un enregistrement du début à la fin. Où entre-t-il ? Comment est-il identifié ? Quelle règle le transforme ? Quel segment l’utilise ? Quelle action part vers un autre outil ? Que conserve le journal ? Cette traçabilité aide à distinguer une capacité réelle d’une promesse de présentation.
La recette doit contenir des critères d’acceptation binaires pour les éléments essentiels. « La donnée remonte bien » est trop vague. « Une opposition créée dans le système de référence exclut le contact des scénarios concernés dans le délai convenu » peut être vérifié.
Ajoutez une sortie du système. Peut-on exporter les données dans un format exploitable avec les identifiants et les relations nécessaires ? Comment récupérer les règles de segmentation et la documentation ? Un export de quelques colonnes ne garantit pas une réversibilité opérationnelle.
Le choix devient plus clair lorsque vous savez aussi comment quitter la solution.
Déployer par usage, puis élargir si les résultats le justifient
Choisissez un premier cas limité mais important. Par exemple, empêcher les messages d’acquisition après signature ou donner une vue cohérente des achats à un service client. Définissez la population, les systèmes concernés et une mesure de qualité.
Ce pilote doit tester la gouvernance autant que les connecteurs. Qui corrige un doublon ? Qui valide une nouvelle source ? Qui décide qu’un champ n’est plus nécessaire ? Qui suspend un scénario lorsqu’un incident apparaît ? L’absence de réponse signale un problème d’organisation que le logiciel ne résoudra pas seul.
Comparez ensuite le fonctionnement obtenu à l’objectif initial. Les équipes utilisent-elles la donnée ? Le délai est-il respecté ? Les erreurs sont-elles détectées et corrigées ? L’usage apporte-t-il un bénéfice supérieur à son entretien ? Ces questions précèdent l’ajout de nouvelles sources.
Une entreprise n’a pas à choisir définitivement entre CRM et CDP comme entre deux camps. Elle doit répartir les responsabilités d’une architecture à la mesure de ses usages. La simplicité reste une qualité lorsqu’elle préserve la fiabilité, les droits et la capacité d’évolution.
Le document de décision à conserver
Avant de signer, rassemblez dans une même note les usages retenus, les usages exclus, les sources de référence, les délais et les responsables. Joignez les résultats du pilote et les écarts qui restent ouverts. Un comité doit pouvoir comprendre pourquoi la solution a été choisie sans revoir plusieurs heures de démonstration.
Précisez ce qui déclenchera une réévaluation. Une multiplication des sources, un besoin de réaction plus rapide ou un changement du modèle commercial peuvent justifier une autre architecture. Une simple nouvelle fonctionnalité annoncée par un fournisseur n’est pas, à elle seule, une raison de recommencer le projet.
Conservez les hypothèses économiques avec leur degré d’incertitude. Un gain de temps estimé doit pouvoir être comparé au temps effectivement économisé. Une amélioration attendue de la qualité doit être traduite en incidents évités, corrections ou décisions mieux informées. N’attribuez pas automatiquement toute hausse commerciale à la nouvelle plateforme : campagnes, prix et organisation évoluent souvent en parallèle.
Demandez enfin un propriétaire pour les données que personne ne veut entretenir. Les champs facultatifs deviennent vite des zones grises : chacun les consulte, personne ne les met à jour. Supprimer une information devenue inutile peut améliorer la confiance dans l’ensemble plus efficacement que l’ajout d’un nouveau tableau de bord. La qualité d’une architecture client se mesure aussi à sa capacité à renoncer aux données qu’elle ne sait pas garder justes.
Examinez également la documentation contractuelle avec les interlocuteurs compétents : localisation et circulation des données, sous-traitants, assistance, exportation et fin de contrat. Ces éléments ne se déduisent pas d’une démonstration fonctionnelle. Une architecture séduisante peut être inadaptée si les engagements de service ou les conditions de sortie ne correspondent pas aux contraintes de l’entreprise.