Migration de CRM : ce qui casse au changement, et ce qui ne se transfère pas

Pourquoi la migration des fiches inquiète, alors que ce n'est pas là que ça casse

Demandez à un directeur commercial ce qui l'inquiète dans une migration de CRM, et la plupart répondent une version de « perdre les données clients ». En pratique, la migration des objets principaux, comptes, contacts, opportunités, est la partie que les outils de migration maîtrisent vraiment bien aujourd'hui. Ce qui casse réellement, et que les équipes sous-estiment systématiquement, se trouve un niveau en dessous : la structure, l'automatisation et le reporting construits autour de ces fiches.

Ce qui ne se mappe pas proprement : champs, objets et automatisations

Les champs personnalisés se traduisent rarement un pour un. Un champ à liste déroulante accumulé sur quinze ans, avec la moitié des valeurs qui ne servent plus, doit soit être remappé manuellement vers l'équivalent du nouveau système, soit finit dans un champ texte générique qui perd toute sa structure. Les objets personnalisés construits pour un workflow précis, un suivi de renouvellement, un objet de recommandation partenaire, n'ont souvent aucun équivalent direct et doivent être reconstruits depuis le schéma.

Les automatisations et déclencheurs posent un problème encore plus grand. Ils ne sont presque jamais importables tels quels, parce que chaque CRM construit sa logique d'automatisation différemment en interne. Une règle qui attribue des leads selon le territoire, ou un déclencheur qui crée une tâche quand une opportunité change d'étape, doit être recréée à la main dans le nouveau système d'automatisation, testée, puis validée face aux cas limites que l'ancien système gérait discrètement depuis des années.

L'activité historique : elle se transfère, mais pas comme on l'imagine

Les notes, journaux d'appels et historiques d'e-mails se migrent en général, mais souvent comme des données brutes plutôt que comme le fil interactif d'origine. Une note qui référençait un champ personnalisé depuis renommé, ou écrite par un utilisateur qui a quitté l'entreprise, peut perdre le contexte qui la rendait utile. Les horodatages posent un problème récurrent : la gestion des fuseaux horaires diffère d'un système à l'autre, et une activité correctement ordonnée dans l'ancien CRM peut apparaître décalée de plusieurs heures dans le nouveau si l'outil de migration ne gère pas la conversion avec soin.

Le coût que la plupart des équipes ne budgétisent pas : tableaux de bord, rapports et intégrations

Les rapports et tableaux de bord enregistrés se migrent presque jamais comme des objets fonctionnels. Même quand un outil de migration annonce prendre en charge les rapports, les filtres, regroupements et champs calculés sous-jacents doivent souvent être reconstruits à la main pour vraiment correspondre à ce que la direction consultait avant. Un tableau de bord de prévisions qu'un directeur regarde chaque lundi matin peut prendre plus de temps à reconstruire correctement que toute la migration des contacts.

Les intégrations sont l'autre coût sous-estimé. Une plateforme d'engagement commercial, un dialer, un outil de signature électronique, une plateforme de marketing automation, chacun a son propre connecteur vers le CRM, et aucun ne se migre automatiquement juste parce que les données du CRM ont bougé. Chacun doit être reconnecté, réauthentifié, et souvent reconfiguré individuellement pour correspondre aux nouveaux noms de champs ou structures d'objets. Les équipes qui planifient « la migration » comme un événement unique découvrent régulièrement qu'il s'agit en fait d'une dizaine de migrations plus petites qui se déroulent en parallèle.

Ce qu'il faut auditer et geler avant le jour de la migration

Avant que la moindre donnée ne bouge, auditez et documentez trois choses : chaque champ personnalisé et son usage actuel (supprimez ceux que personne ne sait expliquer), chaque automatisation active et la règle métier précise qu'elle applique, et une liste complète des intégrations connectées avec un responsable désigné pour chacune. Gelez les changements non essentiels sur l'ancien système une à deux semaines avant la bascule, parce qu'un champ ajouté ou un workflow modifié en pleine migration est une cause fréquente de fiches qui échouent silencieusement à se mapper.

La structure des permissions et des rôles mérite sa propre passe. Les règles d'accès se traduisent rarement proprement, et les rater dans le nouveau système bloque soit des commerciaux hors de fiches dont ils ont besoin, soit, pire, ouvre des données qui auraient dû rester restreintes.

Pourquoi une courte période en parallèle vaut mieux qu'une bascule d'un coup un vendredi

L'envie de migrer tout un week-end et de basculer complètement sur le nouveau système le lundi matin est compréhensible, et c'est généralement une erreur. Une bascule d'un coup compresse la découverte de chaque trou, un mappage de champ manquant, une automatisation cassée, une intégration non reconnectée, en un seul week-end sans filet de sécurité, et tout ce qui remonte le lundi tombe sur une équipe qui a déjà perdu l'accès à l'ancien système.

Faire tourner les deux systèmes en parallèle pendant une courte fenêtre, même quelques jours seulement, donne à l'équipe l'occasion de comparer les fiches côte à côte, de repérer les erreurs de mappage pendant que les anciennes données restent interrogeables, et de laisser les commerciaux signaler ce qui semble faux avant que l'ancien système ne s'éteigne. Ça coûte un peu plus de coordination en amont, et ça évite une semaine bien pire à éteindre des incendies après.

La position à défendre

La migration des fiches principales est la partie d'un changement de CRM qui suscite le plus d'anxiété et qui en mérite le moins : la plupart des outils la gèrent correctement aujourd'hui. Le vrai coût se trouve dans la reconstruction des tableaux de bord et rapports, qui ne se migrent jamais comme des objets fonctionnels, et dans la reconnexion de chaque intégration une par une. Budgétisez du temps et un responsable spécifiquement pour ces deux points, pas seulement pour « déplacer les données », et la migration se passera nettement mieux que ce que racontent les histoires d'horreur.