Qualité des données CRM : la mesurer avant de la corriger

La scène revient dans beaucoup de comités. Le directeur commercial présente la prévision du trimestre, la finance conteste le chiffre, et quelqu’un finit par dire que « le CRM est faux ». Personne ne sait dire en quoi, et la conclusion tombe d’elle-même : il faut nettoyer la base. Une équipe s’y attelle, les rapports redeviennent crédibles, puis le même doute réapparaît.

Le problème n’est pas le manque d’effort : on a corrigé sans avoir mesuré quelle dimension lâchait, sur quel objet, et pourquoi. Cet article propose une méthode en trois temps : décomposer la qualité en dimensions contrôlables, la mesurer objet par objet, puis confier chaque champ à quelqu’un qui le porte dans la durée.

Ce que « qualité des données CRM » veut dire

La qualité des données CRM, c’est la capacité d’une fiche à servir la décision qu’on attend d’elle : envoyer une campagne au bon interlocuteur, prévoir un chiffre d’affaires, facturer la bonne société. Une base n’est pas « propre » en général : elle est fiable pour un usage précis, ou elle ne l’est pas.

Cinq dimensions, cinq questions à poser à une fiche

Pour sortir du « le CRM est faux », il faut poser à chaque fiche cinq questions distinctes. Est-elle remplie ? Ce qui est rempli est-il juste ? Est-ce encore vrai aujourd’hui ? Est-ce la même chose que dans l’ERP ? Existe-t-elle une seule fois ? Chacune correspond à une dimension, avec ses causes et ses remèdes.

Complétude et exactitude : remplie ne veut pas dire juste

La complétude se mesure facilement : un champ est vide ou il ne l’est pas. On s’en contente souvent, à tort. Un champ « Fonction » rempli par « Directeur » sur une fiche dont l’interlocuteur est en réalité acheteur est complet, et faux.

L’exactitude demande une référence extérieure : le registre des entreprises pour le SIREN, le site de la société pour l’adresse, l’interlocuteur lui-même pour sa fonction. Elle se vérifie par échantillon : quelques fiches tirées au hasard et confrontées à la réalité disent plus que n’importe quel taux de remplissage.

Fraîcheur : une donnée vraie hier, fausse aujourd’hui

Les interlocuteurs changent de poste, les sociétés déménagent, les transactions s’enlisent sans que personne ne les ferme. Une fiche bien saisie il y a deux ans peut être fausse aujourd’hui sans que personne n’ait commis d’erreur. La fraîcheur se contrôle par la date : date de dernière activité, date de dernière vérification, date de la prochaine action prévue. Une transaction ouverte dont la date de clôture est dépassée fausse directement la prévision.

Cohérence entre le CRM et l’ERP : quel outil fait foi pour quel champ

Dès que le CRM échange avec l’ERP, une même information existe deux fois : l’adresse de facturation, le SIRET, les conditions de paiement. Si chacun corrige de son côté, les deux versions divergent et la synchronisation propage l’erreur. La règle est simple à énoncer : pour chaque champ partagé, un seul outil fait foi, et l’autre le reçoit. Ce partage se décide par écrit, avant de faire circuler la donnée entre l’ERP et le CRM.

Unicité : une fiche, une seule fois

La dernière dimension est la plus visible : le même client enregistré deux, trois ou quatre fois, sous des orthographes voisines. Elle se mesure par des règles de rapprochement (même SIREN, même domaine de messagerie, même nom normalisé) ; sa correction est détaillée dans notre article sur les doublons entre le CRM et l’ERP.

Mesurer avant de corriger

Mesurer la qualité des données CRM ne demande pas d’outil spécialisé. Cela demande de choisir ce qu’on mesure, sur quel objet, et de chercher d’où vient l’erreur.

Choisir les champs qui comptent

Mesurer toutes les propriétés d’un CRM noie le signal. Partez des décisions : quels champs servent à segmenter une campagne, à construire la prévision, à émettre une facture, à affecter un compte à un commercial ? Ce sont eux, et eux seuls, qui entrent dans la mesure. Les autres posent la question de leur utilité.

Un score par objet

Calculez ensuite un score séparé pour chaque objet : contacts, sociétés, transactions. Pour chacun, prenez les champs retenus et, pour chaque dimension, la règle qui dit si une fiche passe le contrôle : le champ est rempli, il respecte le format attendu, il a été vérifié dans la période fixée, il est identique à la valeur de l’ERP. Le score d’un objet est la part de fiches qui passent chaque contrôle, lue dimension par dimension.

Un score global de « la base » mélange des réalités sans rapport : des contacts très complets peuvent masquer des transactions figées. Le niveau attendu se fixe par usage, pas par norme : une adresse de facturation fausse bloque une facture, un deuxième téléphone manquant ne bloque rien.

Lire le score : quelle dimension, quel objet, quelle source

Un score bas n’est utile que si l’on sait d’où vient l’erreur. Trois sources reviennent le plus souvent :

• La saisie. Un champ libre là où une liste fermée suffirait, un champ obligatoire que l’outil n’impose pas, une consigne que personne n’a écrite.
• Les imports. Un fichier de salon chargé sans contrôle de format ni rapprochement avec l’existant.
• La synchronisation. Deux outils qui s’écrasent mutuellement parce qu’aucun ne fait foi sur le champ concerné.

Chaque source appelle un remède différent : c’est pourquoi la mesure précède la correction. Pour situer vos propres données, le diagnostic en tête d’article donne un premier profil par dimension pour l’objet qui pèse le plus dans vos décisions.

Le cas de Mirakl illustre la troisième source. Les problèmes de synchronisation entre HubSpot et Salesforce entraînaient des incohérences dans les données, et aucune règle claire n’encadrait l’usage des propriétés et des workflows dans HubSpot. Le travail a notamment porté sur deux plans : corriger les paramètres de synchronisation entre les deux outils, et définir des règles d’usage des propriétés et des workflows pour que la base reste fiable dans la durée. Le cas Mirakl est détaillé sur notre site.

Nettoyer sans mesurer, c’est corriger le symptôme et laisser la cause en place.

Qui porte chaque champ

Une donnée se dégrade quand tout le monde peut la modifier et que personne n’en répond. C’est pour cela que tant de bases « redeviennent sales » après un nettoyage.

Le dictionnaire de données CRM

Le dictionnaire de données est un document simple : une ligne par champ utile, et pour chaque ligne une définition, un propriétaire, une règle de saisie, l’outil qui fait foi et le contrôle associé. Il tranche des questions qui paraissent évidentes jusqu’au jour où trois équipes y répondent différemment : qu’appelle-t-on un « client actif », qui a le droit de changer une raison sociale.

Ce dictionnaire n’a pas besoin d’être exhaustif : commencez par les champs retenus pour la mesure, ceux qu’on contrôlera ensuite.

La gouvernance en pratique

La gouvernance des données CRM tient en trois décisions écrites : qui crée un champ, qui le modifie, qui le supprime. Sans elles, chaque équipe ajoute ses propriétés au fil des besoins, avec des noms voisins et des définitions différentes. Une règle suffit souvent : toute création de champ passe par le responsable du CRM, qui vérifie qu’il n’existe pas déjà, l’inscrit au dictionnaire et lui nomme un propriétaire.

Le rôle des commerciaux : saisir moins, mais saisir juste

« C’est le travail des commerciaux » est une réponse fréquente, et incomplète. Les commerciaux saisissent, mais ils ne choisissent ni les champs, ni les règles, ni les listes de valeurs. Leur demander de remplir des dizaines de champs par fiche produit des valeurs par défaut et des saisies faites en fin de mois. Réduire la saisie aux champs utiles, et expliquer à quoi chacun sert, fait davantage qu’un rappel à l’ordre. Le sujet relève aussi de l’adoption, traitée dans notre guide de la conduite du changement.

Garder des données fiables dans la durée

« On a déjà nettoyé, c’est revenu. » L’objection décrit ce qui se passe quand rien ne change en amont. Une base fiable dans la durée repose sur deux mécanismes : bloquer l’erreur à l’entrée, et la repérer tôt quand elle passe malgré tout.

Bloquer l’erreur à l’entrée

• Des champs obligatoires imposés par l’outil. Écrit dans une consigne mais pas paramétré, il reste facultatif.
• Des listes fermées. Secteur, pays, étape, motif de perte : une liste évite les variantes orthographiques d’une même réponse.
• Des formats contrôlés. SIRET, téléphone, e-mail, code postal se vérifient à la saisie, et à l’import.
• Des imports encadrés. Un fichier entrant passe par un modèle, un contrôle de format et un rapprochement avec l’existant avant d’être chargé.

Les flux entre outils obéissent aux mêmes règles : chaque connexion doit dire ce qu’elle fait d’une valeur refusée (voir notre checklist technique pour connecter le CRM au reste du SI).

Les rituels de contrôle

Le contrôle qui maintient la qualité n’est pas un chantier, c’est une habitude : trois rythmes, chacun avec un propriétaire nommé et une liste courte.

• Chaque semaine. Les fiches créées dans la semaine sans un champ obligatoire, revues par le responsable du CRM. L’erreur est récente, son auteur s’en souvient.
• Chaque mois. Les fiches sans activité et les transactions figées, revues par le responsable commercial. Par exemple, la liste des transactions ouvertes sans activité depuis 90 jours, à fermer ou à relancer ; le délai est une règle à fixer chez vous, pas une norme.
• Chaque trimestre. Le rapprochement des champs partagés entre le CRM et l’ERP, et la revue du dictionnaire : champs à ajouter, à archiver, propriétaires à confirmer.

Quant au temps des équipes, ces rituels coûtent peu parce qu’ils portent sur des listes courtes et récentes ; c’est le grand nettoyage, sur des erreurs accumulées, qui coûte cher. Chez OKLIMA, la création d’un catalogue produit a facilité la gestion des transactions avec des données produits standardisées, et un système de vérification intégré aux pipelines commerciaux assure un suivi rigoureux des transactions : le contrôle fait partie du processus (voir le cas OKLIMA).

Une liste courte revue chaque semaine vaut mieux qu’un grand nettoyage chaque année.

Quand faire appel à un regard extérieur

Sur un périmètre simple, tout cela se fait en interne. Un regard extérieur devient utile dans trois situations : plusieurs outils détiennent chacun une version du même client et personne n’a le mandat de trancher lequel fait foi ; un projet ERP va figer pour des années les règles de reprise et de synchronisation, et le dictionnaire doit exister avant, comme nous le montrons à propos du rôle d’un intégrateur ERP ; ou la base a déjà été nettoyée sans que la qualité tienne, signe que la cause est dans le système et non dans la saisie.

Par où commencer

Pas par un nettoyage. Commencez par un état des lieux court : choisir l’objet qui pèse le plus dans vos décisions, lister les champs qui servent ces décisions, mesurer chacun sur les cinq dimensions, et nommer un propriétaire pour chaque champ qui n’en a pas. Ce travail transforme « le CRM est faux » en une liste précise de causes, chacune avec son remède et son responsable.

C’est le métier de turnK : fiabiliser la donnée qui circule entre vos outils, pour que les chiffres présentés en comité soient ceux que tout le monde croit.