tely
Blogue
Gestion13 mai 2026

La reprise de données : la phase que tous les devis ERP sous-estiment

0

Elle représente souvent la plus grosse part de la charge d'un projet ERP et n'apparaît presque jamais correctement au devis. Pourquoi, et comment l'aborder.

Un fournisseur te promet un ERP en six semaines. Il est sincère : la configuration prend effectivement six semaines. Ce qu'il n'a pas chiffré, c'est le déplacement de tes données existantes vers le nouveau système.

C'est régulièrement la phase la plus longue du projet, et c'est celle qui décide de son succès. Un ERP parfaitement configuré, alimenté de données douteuses, produit exactement ce que tu avais avant : deux personnes, deux chiffres.

Pourquoi c'est toujours plus long que prévu.

Tes données sont plus sales que tu ne le penses. Le même client existe en quatre exemplaires — « Constructions ABC », « Constructions A.B.C. », « ABC Const. », « Abc constructions inc ». Trois adresses différentes, deux numéros de taxes. Personne ne le savait, parce que personne n'avait jamais regardé les quinze mille lignes d'un coup.

Les règles n'ont jamais été écrites. Le code produit commençant par un X désigne un article discontinué : c'est dans la tête d'une personne, depuis onze ans, et elle est en vacances au moment de la migration.

L'historique n'a pas de structure : sept ans de factures avec des numérotations qui ont changé trois fois, des taux de taxe qui ont évolué, un plan comptable refondu en cours de route.

Et il faut arbitrer, pas seulement transférer. Reprend-on sept ans d'historique ou deux ? Les soldes seulement, ou les écritures détaillées ? Les clients inactifs depuis cinq ans ? Chaque réponse a un coût, et ce sont des décisions d'affaires — elles t'appartiennent, pas au prestataire.

La règle des trois passages.

Une migration réussie se fait au moins trois fois avant la vraie. Passage 1, la découverte : on migre tout, sans nettoyer, pour voir ce qui casse. Le rapport d'erreurs est le livrable — il révèle les doublons, les champs vides obligatoires, les formats incohérents.

Passage 2, la validation : on migre les données nettoyées et on rapproche les totaux. Le solde client global correspond-il au centime près ? La valeur du stock ? Le grand livre ? Si un écart apparaît, on ne le documente pas : on le comprend.

Passage 3, la répétition générale : migration complète en conditions réelles, chronométrée. Elle donne la durée de la fenêtre de bascule et prouve que la procédure fonctionne. C'est aussi ce passage qui rend le plan de retour arrière crédible. Un projet qui n'en prévoit qu'un seul découvre ses problèmes le jour de la bascule, avec l'entreprise à l'arrêt.

Ce que toi seul peux faire.

Le prestataire déplace les données. Il ne peut pas décider laquelle des quatre fiches « Constructions ABC » est la bonne. Cette partie du travail te revient, et elle est incompressible. Prévois une personne de ton équipe, disponible sérieusement — pas « quand elle aura le temps ». C'est la variable qui détermine la durée du projet, plus que la compétence du prestataire.

Un chiffre migré doit être rapprochable. Sinon, on ne bascule pas.

On ne « documente pas l'écart » — un écart accepté au démarrage devient un écart permanent, et il détruit la confiance dans le système en quelques semaines.

Ce qu'on ne fait pas.

On ne bascule pas toute l'entreprise d'un coup. Un service pilote en double saisie pendant quatre à six semaines coûte du temps et supprime le risque. Une bascule complète en une nuit paraît courageuse jusqu'au premier lundi matin.