Reprise de données CRM : plan de bataille pour migrer 15 ans d'historique sans perdre le métier

La reprise de données est souvent traitée comme une tâche technique de dernière minute. C'est une erreur fréquente : dans un projet Salesforce, elle concentre une part importante des retards, des surcoûts et des rejets d'utilisateurs. Quand un CRM porte quinze ans d'historique — comptes, contacts, opportunités, contrats, échanges commerciaux — la migration touche directement la mémoire du métier. Cet article propose un plan de bataille pour cadrer cette opération, en préservant ce qui compte vraiment.

Pourquoi la reprise de données est un projet à part entière

Une base CRM de quinze ans n'est jamais homogène. Elle a connu plusieurs versions d'outil, des changements d'organisation commerciale, des fusions de fichiers, des imports Excel et des règles de saisie qui ont évolué. Le résultat est un patrimoine riche mais hétérogène : doublons, champs libres, statuts obsolètes, contacts sans rattachement clair.

Traiter cette reprise comme un simple transfert de tables mène presque toujours au même point : les utilisateurs ne retrouvent pas leurs repères, contestent la fiabilité du nouvel outil et retournent à leurs anciens fichiers. La réussite technique de la migration ne suffit pas ; c'est la continuité métier qui doit être l'objectif.

Étape 1 : cartographier avant de migrer

Avant toute manipulation, il faut savoir ce que l'on possède. Cette phase de découverte, souvent négligée, conditionne tout le reste.

Inventorier les objets et les volumes

Recensez les entités concernées : comptes, contacts, opportunités, activités, pièces jointes, historiques de statut. Mesurez les volumes réels et non estimés. Un million d'activités anciennes ne se traite pas comme dix mille comptes actifs.

Distinguer données vivantes et données d'archive

Toutes les données n'ont pas la même valeur. Une opportunité perdue il y a douze ans n'a pas le même statut qu'un contrat en cours. Classez le patrimoine en trois catégories :

• Données opérationnelles : utilisées au quotidien, à migrer intégralement.
• Données de référence historique : consultées ponctuellement, à migrer avec un niveau de détail réduit.
• Données obsolètes : à archiver hors CRM ou à ne pas reprendre.

Cette segmentation évite de polluer Salesforce avec un historique que personne ne consultera, tout en préservant l'accès à ce qui a une valeur juridique ou commerciale.

Étape 2 : nettoyer sans trahir le métier

Le nettoyage est le cœur du sujet. Il faut améliorer la qualité sans effacer la réalité opérationnelle.

Dédoublonnage et normalisation

Les doublons sont inévitables sur quinze ans. Leur traitement doit impliquer les équipes métier, seules capables d'arbitrer quel enregistrement conserver. Normalisez les référentiels : pays, secteurs d'activité, civilités, unités commerciales. Ce travail prépare aussi la cohérence des futurs rapports.

Conserver la traçabilité

Un principe simple : ne jamais réécrire l'histoire silencieusement. Conservez les dates de création d'origine, les propriétaires historiques et une trace des transformations appliquées. Un commercial doit pouvoir expliquer pourquoi un compte est rattaché à lui depuis 2014.

Étape 3 : le mapping, traducteur entre deux mondes

Le mapping relie chaque champ source à sa destination dans Salesforce. Sur un historique long, c'est là que se jouent les malentendus.

• Un champ libre de l'ancien outil peut devoir devenir une liste de valeurs contrôlée.
• Des statuts commerciaux anciens n'ont plus d'équivalent : il faut décider comment les représenter.
• Les relations entre objets (contact rattaché à un compte, opportunité liée à un devis) doivent être reconstruites, pas seulement copiées.

Documentez chaque règle de transformation. Ce document de mapping devient la référence partagée entre l'intégrateur, l'équipe technique et les référents métier. Il sert aussi de base aux tests.

Étape 4 : tester en conditions réelles

Une migration ne se valide pas sur un tableau de correspondance mais sur des données concrètes manipulées par les utilisateurs.

Les migrations à blanc

Réalisez plusieurs passages complets sur un environnement de recette. Chaque itération révèle des écarts : volumes qui explosent, champs tronqués, relations perdues. Le nombre de passages n'est pas un aveu d'échec, c'est la mécanique normale d'une reprise maîtrisée.

La recette métier

Faites vérifier les données par ceux qui les utilisent. Sélectionnez des cas représentatifs : un gros client, un dossier complexe, un compte récemment repris. Si les référents retrouvent leurs repères, la migration tient. S'ils ne les retrouvent pas, aucun rapport de contrôle technique ne compensera leur défiance.

Étape 5 : la bascule et l'après

Le jour de la bascule doit être un non-événement, parce que tout a été répété. Prévoyez une fenêtre où l'ancien système reste consultable en lecture seule pendant quelques semaines, le temps que la confiance s'installe.

Après la mise en production, surveillez les indicateurs de qualité : taux de champs renseignés, doublons résiduels, enregistrements orphelins. La reprise ne s'arrête pas au go-live ; elle se prolonge par une phase de stabilisation.

Cadrer le budget et le prestataire

La reprise de données représente souvent une part sous-estimée du budget projet. Elle mobilise des compétences spécifiques : analyse de données, connaissance des outils d'intégration (chargeurs, ETL), et surtout capacité à dialoguer avec le métier. Lors du choix d'un intégrateur, demandez à voir sa méthode de reprise, ses environnements de test et sa gestion des itérations, pas seulement sa maîtrise technique de Salesforce.

Un bon indicateur : un prestataire qui pose des questions sur vos règles de gestion historiques avant de parler outillage prend le sujet au bon niveau.

Migrer quinze ans d'historique n'est pas un exercice de plomberie technique mais un projet de continuité métier. En cartographiant tôt, en associant les référents et en testant plusieurs fois, une ETI transforme une opération à risque en fondation solide pour son nouveau CRM.