Guide
Migration de données CRM et ERP : ce qui dérape vraiment
Une migration est un projet de nettoyage qui se termine par un import. Voici ce qu'il faut déplacer, ce qu'il faut laisser, et les quatre hypothèses qui transforment deux semaines en deux mois.
L'essentiel
La plupart des dépassements ne sont pas techniques. Ils viennent de la découverte, à mi-parcours, que les données source n'ont jamais été aussi propres qu'on le supposait : clients en double, produits aux références incohérentes, et historiques que personne ne sait expliquer. Décidez tôt ce qui doit vraiment être déplacé. Les données de référence et les encours le méritent presque toujours. L'historique complet des transactions presque jamais : il alourdit la migration et n'est presque jamais consulté ensuite. Gardez plutôt l'ancien système consultable.
Au-delà du bouton importer
Ce qu'implique réellement une migration
Un import déplace des lignes. Une migration décide quelles lignes méritent d'exister dans le nouveau système, à quoi elles doivent ressembler une fois arrivées, et qui tranche quand deux enregistrements se contredisent. L'import lui-même occupe généralement le dernier après-midi du projet.
Dans les faits le travail se divise en quatre : cadrer le périmètre, profiler les données source pour savoir à quel point elles sont dégradées, nettoyer et rapprocher, puis charger et vérifier. Les équipes qui ne budgètent que la quatrième partie sont celles qui dépassent.
Trois variables
Ce qui détermine la durée
Pas le nombre de lignes. Ces trois-là.
Combien de systèmes se contredisent
Une source unique, c'est un projet de données. Trois sources qui détiennent chacune une version différente du même client, c'est un projet de rapprochement, et c'est là que partent les semaines.
Si quelqu'un possède les règles
Il faut trancher quel doublon l'emporte et quelle valeur par défaut appliquer à un champ manquant. Sans cette personne, la migration attend des décisions que personne n'est habilité à prendre.
L'historique sur lequel vous insistez
Les données de référence et les soldes ouverts sont bornés. L'historique complet ne l'est pas, et c'est l'endroit le plus simple pour diviser le périmètre par deux sans rien perdre d'utile.
La séquence
Comment se déroule une migration
Cinq phases. Les deux premières décident du résultat.
- 1
Décider ce qui bouge
Convenir par écrit des entités et des périodes reprises. Tout ce qui n'est pas sur cette liste reste dans l'ancien système, qui demeure consultable.
- 2
Profiler la source
Compter doublons, valeurs nulles et références incohérentes avant d'annoncer une date. C'est l'étape qui transforme des hypothèses en un calendrier défendable.
- 3
Nettoyer à la source quand c'est possible
Corriger dans l'ancien système coûte souvent moins cher qu'écrire des règles de transformation, et l'équipe retrouve des données qu'elle reconnaît.
- 4
Charger dans un environnement de répétition
Jamais directement en production. Une répétition donne la durée réelle et fait apparaître les échecs pendant qu'ils coûtent encore peu.
- 5
Vérifier avec le métier, pas avec un compteur
Faire correspondre des totaux n'est pas une vérification. Demandez aux utilisateurs de retrouver leurs propres enregistrements : ils repèrent ce qu'aucune somme de contrôle ne verra.
Quatre pièges
Les quatre hypothèses qui coûtent des semaines
Aucune ne concerne l'outillage.
Supposer que la source est propre
Elle ne l'est jamais. La seule question est le degré, et le profilage y répond en quelques jours au lieu de le découvrir au deuxième mois.
Tout migrer parce que c'est là
Un historique repris par prudence coûte du temps de migration, du stockage et toutes les montées de version futures. Reprenez ce qui sert et gardez le reste consultable ailleurs.
Croire que la mise en production est la fin
Les premières semaines après bascule produisent les corrections qui comptent. Budgétez-les, sinon elles retombent sur celui qui peut le moins refuser.
Personne ne possède les règles
Toute migration rencontre des cas où la bonne réponse relève du jugement. Sans responsable désigné, ces décisions s'empilent et le projet attend.
Côte à côte
Reprise à l'identique ou migration cadrée
Les mêmes données. Une deuxième année très différente.
| Critère | Reprise à l'identique | Migration cadrée |
|---|---|---|
| Ce qui est repris | Tout, parce que décider paraissait risqué. | Données de référence, encours, et l'historique qui le mérite. |
| Doublons | Repris tels quels, puis multipliés. | Résolus avant le chargement, selon une règle écrite. |
| Calendrier | Confiant jusqu'au profilage. | Fixé après profilage, donc il résiste au contact des données. |
| Confiance après bascule | L'équipe continue de vérifier dans l'ancien système. | Le nouveau système fait référence, parce qu'ils l'ont vérifié eux-mêmes. |
Ce qui est repris
- Reprise à l'identique
- Tout, parce que décider paraissait risqué.
- Migration cadrée
- Données de référence, encours, et l'historique qui le mérite.
Doublons
- Reprise à l'identique
- Repris tels quels, puis multipliés.
- Migration cadrée
- Résolus avant le chargement, selon une règle écrite.
Calendrier
- Reprise à l'identique
- Confiant jusqu'au profilage.
- Migration cadrée
- Fixé après profilage, donc il résiste au contact des données.
Confiance après bascule
- Reprise à l'identique
- L'équipe continue de vérifier dans l'ancien système.
- Migration cadrée
- Le nouveau système fait référence, parce qu'ils l'ont vérifié eux-mêmes.
Pour être honnête
Quand il ne faut pas migrer du tout
Si l'ancien système fait toujours son travail et que le nouveau ne le recouvre que partiellement, faire tourner les deux avec un connecteur est souvent la meilleure réponse. Une migration se justifie quand une source unique supprime une friction quotidienne réelle, pas quand elle range joliment un schéma d'architecture.
L'autre cas honnête, c'est une entreprise dont les données sont si dégradées que les migrer reviendrait à emporter le problème. Parfois le bon geste est de repartir proprement avec les seules données de référence, et de traiter l'ancien système comme une archive où plus personne n'écrit.
Les questions qu'on nous pose sur les migrations
Des réponses directes avant d'annoncer une date.
Faut-il nettoyer avant ou après ?
Avant, et dans l'ancien système quand c'est praticable. Nettoyer à la source coûte moins cher qu'écrire des règles de transformation et laisse à l'équipe des enregistrements qu'elle reconnaît.
Faut-il migrer tout notre historique de transactions ?
En général non. Il alourdit la migration, gonfle le nouveau système et n'est presque jamais consulté une fois les données courantes fiables. Les données de référence et les encours sont repris ; l'ancien système reste consultable pour le reste.
Combien de temps prend une migration ?
Pour une source unique et propre, quelques semaines. Plusieurs sources contradictoires, ou des données que personne n'a profilées, allongent le délai, et la réponse honnête est que le calendrier ne peut pas être fixé avant le profilage.
Comment une migration est-elle chiffrée ?
Cela dépend du nombre de sources qui se contredisent, de l'état des données une fois profilées, et de l'historique dans le périmètre. Nous donnons un chiffre précis après les 30 minutes d'audit.
Quelle interruption faut-il prévoir ?
La bascule elle-même se compte en heures, pas en jours, parce que la répétition a déjà établi la durée réelle. Ce qui coûte du temps, c'est la période de corrections après la mise en production.
Et si ça tourne mal ?
L'ancien système reste disponible et consultable jusqu'à ce que le nouveau soit vérifié par ceux qui l'utilisent tous les jours. La bascule est une décision prise sur preuves, pas une date fixée d'avance.
Vous ne savez pas à quoi ressemblent vraiment vos données ?
Dites-nous quels systèmes détiennent aujourd'hui les enregistrements clients et produits. Nous vous dirons à quoi ressemble un périmètre de migration réaliste, et où se cache le travail de rapprochement.