Pourquoi c'est le poste le plus risqué
Un bon paramétrage ne sert à rien sur des données fausses. La reprise concentre les risques d'un projet ERP : volume, qualité, délais. C'est aussi le poste le plus sous-estimé au chiffrage. Il se pilote avec qui pilote la reprise, mais engage fortement vos équipes.
Le périmètre à reprendre
La première décision est de définir ce qu'on reprend. Les données vivantes (tiers, soldes, en-cours) sont indispensables ; les historiques peuvent souvent être archivés plutôt que migrés. Ce périmètre se cadre dès le définir le périmètre à reprendre, pas au dernier moment.
La qualité des données
Une migration est l'occasion de nettoyer : doublons, adresses obsolètes, comptes inactifs. Importer des données sales, c'est transporter ses problèmes dans le nouvel outil. Le cas des le cas des historiques comptables demande une attention particulière, pour la cohérence des soldes.
Jeux de test, bascule et réconciliation
Une reprise sérieuse passe par des jeux de test répétés avant la bascule réelle, puis par une réconciliation : vérifier que les totaux du nouvel ERP correspondent à l'ancien. C'est cette étape, souvent écourtée, qui sécurise le démarrage.
Questions fréquentes
Qu'est-ce que la reprise de données dans un projet ERP ?
La reprise de données consiste à extraire les données de l'ancien système, à les nettoyer, puis à les importer dans le nouvel ERP : tiers, articles, écritures, historiques. C'est souvent la phase la plus longue et la plus risquée d'un projet.
Faut-il tout reprendre dans le nouvel ERP ?
Non. Reprendre l'intégralité de l'historique est rarement utile et coûteux. On distingue les données vivantes indispensables (tiers, soldes, en-cours) des historiques, qu'on peut parfois archiver plutôt que migrer. Le périmètre se décide en amont.
Qui pilote la reprise de données ?
La reprise se pilote conjointement : l'intégrateur pour la technique, l'entreprise pour la connaissance et la validation de ses données. Une reprise réussie suppose une implication forte des équipes métier, pas seulement techniques.
Pourquoi la reprise de données fait-elle échouer des projets ?
Parce qu'elle est sous-estimée : données de mauvaise qualité, périmètre flou, tests insuffisants et bascule mal préparée. Une reprise bâclée se paie au démarrage, quand les erreurs remontent en production.
Mis à jour le 10 août 2026 — Michael DANCHIN, Pôle Conseil ERP — Cap ERP