Migration CRM : reprendre ses données sans rien perdre

Deux fiches pour le même client, trois contacts pour la même entreprise : la migration les reproduit à l'identique si on ne les traite pas avant. Dans le nouveau CRM, les doublons faussent les reportings, cassent les automatisations et poussent les équipes à retourner dans Excel. Leur suppression est un préalable, pas une option de nettoyage après coup. Une base commerciale contient toujours des doublons : saisies multiples, fusion de fichiers, homonymes. Les repérer sur le nom seul ne suffit pas. Il faut définir des règles de correspondance sur l'email, le téléphone, le site ou le numéro SIRET, puis choisir quelle fiche conserve l'historique et les pièces jointes. Ce travail s'anticipe parce qu'il change le volume de données à transférer et la manière de construire la structure cible. Migrer des fiches dupliquées dans un outil neuf, c'est reconstruire le problème ailleurs.

Les champs personnalisés sont la première cause de perte de données silencieuse. Un champ « source de prospect » dans l'ancien CRM n'a pas d'équivalent direct dans le nouveau. S'il n'est pas mappé explicitement, les valeurs disparaissent sans message d'erreur. L'audit doit lister chaque champ personnalisé, indiquer son usage, son type et sa volumétrie. Beaucoup ne servent plus : les supprimer avant la migration simplifie la structure. Mais certains contiennent des informations métier essentielles, comme un numéro de dossier ou une date de décision. Il faut alors les rapprocher des champs cibles ou créer de nouveaux champs dans le CRM de destination. Sans cette correspondance, une partie des données part en archive ou reste dans l'ancien logiciel, inaccessible pour les commerciaux. Ce travail paraît ingrat, il est pourtant ce qui évite les mauvaises surprises après la bascule. Une donnée mal mappée est une donnée perdue, même si l'export affiche une ligne complète.

Les échanges avec un client — appels, emails, réunions, notes de rendez-vous — sont l'âme d'un CRM. Ils ne peuvent pas être reconstitués une fois l'ancien outil fermé. La reprise doit donc prévoir leur migration dans le bon ordre temporel et avec les bons auteurs. Si l'export ne contient pas la date et le créateur de chaque action, l'historique devient un mur de données anonymes inexploitables. Tout ne mérite pas d'être repris. Des années d'anciennes tâches ou des notes obsolètes peuvent être archivées plutôt que transférées. Le critère est simple : une information qui aide à gérer la relation client aujourd'hui se migre ; le reste s'archive hors CRM ou se supprime. C'est aussi le moment de vérifier que le nouveau CRM accepte le même type d'activités et de prévoir le mapping des types. Un historique propre vaut mieux qu'un historique complet envahi de bruit.

Les pièces jointes ne voyagent pas dans un simple export CSV. Elles sont souvent stockées hors base, sur un serveur de fichiers, dans un module de messagerie ou chez un hébergeur tiers. Si l'export ne contient qu'un chemin d'accès ou une URL, ces fichiers deviennent inaccessibles dès que l'ancien serveur est coupé. Une migration complète des pièces jointes inclut un recensement des emplacements, une copie des fichiers et une réassociation à la bonne fiche. Il faut aussi vérifier les doublons de fichiers, les noms trop longs ou illisibles, et les formats propriétaires que le nouveau CRM ne pourra pas afficher. Plus le volume est grand, plus cette étape doit être planifiée et testée. Beaucoup d'entreprises découvrent après la bascule que les contrats signés ou les devis PDF sont restés dans l'ancien outil, juste parce que personne n'avait listé les emplacements de stockage.

Un ancien CRM contient des données fiables, des données inutiles et des données fausses. Tout transférer dans le nouvel outil, c'est recréer une base polluée dès le premier jour. La migration est une occasion unique de faire le tri : contacts inactifs, opportunités soldées qui n'ont plus de valeur, doublons, champs vides. Il faut définir en amont les critères de conservation et les appliquer avant l'extraction. Les données non retenues sont archivées hors CRM ou supprimées selon les obligations légales. Sans cette étape, le nouveau CRM coûte plus cher à l'exploitation et les équipes retombent dans leurs vieilles habitudes. Un CRM n'est pas une cave dans laquelle on entasse tout ; c'est un outil de travail qui n'est utile que si on peut lui faire confiance.

La bascule « big bang » concentre tous les risques sur une seule date : si un import échoue, tout le monde est bloqué. Mieux vaut migrer par lots : d'abord une équipe pilote, un périmètre limité, puis on vérifie les données, on corrige les mappings, on étend aux autres équipes. Cette progression sécurise le projet et habitue les utilisateurs au nouvel outil avant la généralisation. La première cause d'échec d'un projet CRM est rarement technique : c'est l'humain, le cadrage et l'appropriation. C'est pourquoi la reprise des données doit être pensée comme un sujet métier, pas comme une opération d'import. Chez CRM sur Mesure, la conception d'un CRM sur mesure commence par cet audit du système existant et par la cartographie des données, avant d'écrire une seule ligne de configuration. On sécurise d'abord ce que l'entreprise veut garder, puis on construit l'outil adapté à son activité.