Un CRM n’a pas besoin de devenir la source unique de toutes les données pour être fiable. Il doit surtout offrir une vue de travail cohérente, alimentée par des systèmes dont les responsabilités sont explicites. Voici une méthode pour organiser une base de données clients sans multiplier les copies incontrôlées.
Nommer les objets avant les outils
Une base de données clients devient difficile à maintenir lorsque l’entreprise parle de « client » pour désigner des réalités différentes. Avant de choisir une intégration ou une règle de synchronisation, il faut donc décrire les objets manipulés.
Une personne physique, une entreprise, un compte facturé, un contact commercial, une opportunité, un contrat et une adresse de livraison peuvent être liés, sans être interchangeables. Le CRM peut gérer les contacts et les opportunités, tandis que l’ERP conserve les informations de facturation. Un outil de support peut détenir l’historique des demandes. Une plateforme marketing peut gérer les préférences d’abonnement.
Cette distinction permet de poser une question simple pour chaque champ : quelle décision ce champ doit-il permettre de prendre, et quel système est le mieux placé pour le maintenir ? Une adresse de facturation n’obéit pas aux mêmes règles qu’un numéro de téléphone saisi par un commercial. Une préférence de communication ne doit pas être remplacée par une valeur importée depuis un autre outil sans vérification.
La documentation peut rester concise. Pour chaque objet, indiquez son nom, son identifiant, sa description, ses champs principaux, son propriétaire et les systèmes qui le consultent. Cette cartographie constitue le point de départ du modèle de données.
Attribuer une source de référence
La source de référence n’est pas nécessairement le CRM. Elle dépend de la nature de la donnée et du processus qui la produit. Le système de facturation est souvent le mieux placé pour les informations comptables. Le CRM peut être la référence pour la relation commerciale. Le portail client peut être à l’origine de certaines coordonnées déclarées par la personne elle-même.
Pour éviter les conflits, associez chaque champ sensible à une responsabilité précise. Le système propriétaire crée ou modifie la valeur. Les autres applications la lisent, ou proposent une correction qui revient au propriétaire selon une règle définie.
Il faut également répondre à la question : quel système crée l’identifiant ? Une même entreprise peut posséder plusieurs identifiants techniques, mais leur rôle doit être explicite. Un identifiant interne stable sert à rapprocher les enregistrements. Une adresse électronique ou une raison sociale ne devrait pas être utilisée seule comme clé durable, car elle peut changer, être partagée ou être saisie différemment.
Un identifiant global peut être utile pour les échanges, à condition de prévoir la correspondance avec les identifiants locaux. Sans table de correspondance, chaque intégration risque de recréer ses propres règles de rapprochement et de produire des doublons.
Comme le rappelle France Num dans son guide sur le pilotage par les données , les CRM et les ERP ont leurs propres modèles. L’accès aux données, leur export et l’interopérabilité doivent donc être vérifiés avant de présenter plusieurs outils comme un ensemble unifié.
Dédupliquer avec prudence
La déduplication ne consiste pas à fusionner automatiquement tout ce qui se ressemble. Elle commence par la définition de critères de rapprochement et de règles d’arbitrage.
Une correspondance forte peut combiner un identifiant connu, une information légale ou une adresse validée. Une correspondance plus incertaine peut reposer sur le nom, le domaine de messagerie ou le téléphone. Dans ce cas, mieux vaut signaler une proposition de fusion et demander une validation que supprimer silencieusement une fiche légitime.
Avant toute fusion, conservez l’historique des identifiants, des activités et des relations. Vérifiez aussi les effets sur les commandes, les contrats, les tickets et les campagnes. Une fiche qui semble en double dans le CRM peut correspondre à deux entités juridiques distinctes dans l’ERP.
La règle de correction doit être aussi claire que la règle de fusion. Qui corrige une valeur ? Le propriétaire de l’objet, une équipe dédiée à la qualité, ou l’utilisateur qui constate l’erreur ? Une correction utile doit être répercutée sans écraser une information plus récente ou plus fiable. Il est préférable de définir quelques champs prioritaires et une procédure lisible, plutôt que de promettre une qualité parfaite sur l’ensemble du référentiel.
Utiliser le CRM comme vue de travail
Le CRM peut rassembler les informations utiles à l’action commerciale sans stocker toutes les données de l’entreprise. Cette approche réduit les copies et rend les droits d’accès plus faciles à maîtriser.
La fiche CRM peut afficher une donnée issue d’un autre système, avec son origine et sa date de dernière synchronisation. Elle peut aussi distinguer une valeur locale, modifiable par l’équipe commerciale, d’une valeur de référence, seulement consultable. Cette distinction évite que les utilisateurs modifient directement un champ qu’un flux automatique réécrira ensuite.
Le délai de synchronisation acceptable dépend de l’usage. Une information nécessaire à une décision opérationnelle immédiate doit être plus fraîche qu’un attribut utilisé pour un reporting périodique. Il faut donc définir l’exigence par processus, et non appliquer la même fréquence à toutes les données.
Lorsque la synchronisation échoue, l’absence d’information doit être visible. Un journal d’erreurs, une alerte et une procédure de reprise valent mieux qu’une mise à jour partielle présentée comme réussie. Les équipes doivent savoir si elles peuvent poursuivre leur travail, patienter ou contacter l’administrateur.
Tracer les transformations
Une donnée importée n’a pas toujours la même forme que dans son système d’origine. Les intégrations peuvent normaliser une adresse, convertir une date, raccourcir un texte ou transformer une valeur de statut. Chaque transformation importante doit être documentée.
Conservez au minimum l’origine de la donnée, la date du traitement, la règle appliquée et le résultat de l’opération. Cette traçabilité aide à expliquer une incohérence et à rejouer un traitement après correction. Elle permet aussi de distinguer une erreur de saisie d’une erreur de mapping entre deux systèmes.
Les flux doivent préciser leur comportement face aux valeurs vides, aux suppressions et aux conflits. Une valeur vide signifie-t-elle que l’information a été supprimée, ou qu’elle n’a jamais été renseignée ? Une modification locale est-elle temporaire, ou doit-elle devenir la nouvelle référence ? Ces décisions doivent être écrites avant la mise en production de l’interface.
La qualité des données inclut enfin la conformité. La CNIL rappelle que la gestion de la relation client doit respecter les choix des personnes , limiter les données collectées et prendre en compte les demandes d’opposition. Une suppression ou une opposition ne doit donc pas s’arrêter au CRM si d’autres systèmes utilisent encore la donnée.
Tester restauration et export
Une base fiable est une base dont l’entreprise peut vérifier le fonctionnement. Testez d’abord un parcours complet : création d’une fiche, modification d’un champ, synchronisation, correction, fusion éventuelle, puis suppression. Observez les journaux et vérifiez le résultat dans chaque système concerné.
La question « comment une suppression se propage-t-elle ? » doit recevoir une réponse concrète. La suppression peut être propagée comme une instruction, représentée par un statut d’effacement ou traitée par une file de demandes. Dans tous les cas, il faut identifier les systèmes destinataires, les exceptions légitimes et la preuve de traitement.
Testez aussi la restauration. Une sauvegarde inutilisable, incomplète ou impossible à rapprocher des identifiants actuels ne protège pas réellement l’activité. Vérifiez qu’une restauration ne recrée pas de doublons et que les relations entre contacts, comptes, contrats et opportunités restent compréhensibles.
Enfin, réalisez un export lisible par une autre équipe. Il doit permettre de retrouver les objets, les identifiants, les propriétaires et l’origine des champs. Si personne ne peut expliquer le contenu de l’export, la base n’est pas encore suffisamment documentée pour servir de socle fiable.
Le bon CRM n’est donc pas celui qui absorbe toutes les données. C’est celui qui présente les bonnes informations, au bon endroit, avec une origine connue, une responsabilité attribuée et un comportement prévisible lorsque la donnée change ou disparaît.
Commentaires
Aucun commentaire