Un nouvel ERP peut être parfaitement paramétré et démarrer quand même dans la douleur. Il suffit que des clients soient en double, que les stocks ne collent pas ou que des factures en attente manquent à l'appel.
La reprise de données Sage X3, c'est l'opération qui fait passer ces informations de votre ancien système vers le nouvel ERP. Sur le papier, une formalité technique. Dans la vraie vie, c'est souvent elle qui décide si le démarrage se passe bien, ou si les équipes passent leurs premières semaines à corriger. D'où notre conviction : il faut la traiter comme un projet dans le projet.
Dans un projet d'implémentation de Sage X3, l'attention va naturellement à ce qui se voit : les développements spécifiques, les écrans, les états, la formation. La reprise de données arrive en bas de liste, souvent résumée à une ligne du planning, « import des données ». Comme s'il s'agissait d'un copier-coller.
Le problème, c'est que vos données actuelles n'ont pas forcément été pensées pour Sage X3. Elles ont été saisies pendant des années, par des personnes différentes, avec des règles qui ont changé en cours de route. Un même client existe sous deux orthographes. Des articles qui ne se vendent plus sont toujours actifs. Une partie de l'information vit dans des fichiers Excel que seule une personne sait lire.
Tant que l'ancien système tourne, ces défauts restent invisibles : les équipes les contournent par habitude. Au moment de les charger dans un ERP plus structuré, ils deviennent des erreurs d'import, des contrôles bloquants, ou pire, des données fausses qui passent sans bruit.
Les outils changent d'un projet à l'autre. La méthode, beaucoup moins.
Tout commence par un inventaire. L'ancien ERP est la source évidente, mais il faut aussi recenser tout ce qui tourne à côté : fichiers Excel de suivi, logiciels métiers, outil de facturation. On découpe ensuite le périmètre par domaine (articles, ventes, achats, production, finance) et on désigne pour chacun un référent côté entreprise. C'est à lui qu'on pose les questions, et c'est lui qui tranche.
On fixe aussi les dates pivot, c'est-à-dire les dates de référence de la reprise : par exemple la date d'arrêté des soldes comptables, ou celle à partir de laquelle on reprend les commandes. Enfin, on documente la méthode d'extraction de chaque source et la personne qui s'en charge. Le jour où il faut relancer une extraction, on sait comment faire sans dépendre d'un intervenant extérieur.
On sort les données de chaque source dans un format exploitable, puis on les nettoie : suppression des doublons, correction des erreurs (adresses, numéros de TVA, unités de mesure), mise à l'écart des données obsolètes. Un fournisseur inactif depuis des années n'a rien à faire dans un ERP neuf. Ce tri ne peut pas être fait par l'informatique seule : ce sont les référents métiers qui savent ce qui est encore vivant.
Sage X3 a sa propre logique : ses codes, ses tables de référence, ses règles de gestion. Il faut donc construire des tables de transcodage, autrement dit des tables de correspondance entre les codes de l'ancien système et ceux de Sage X3. Telle famille d'articles devient telle catégorie, tel mode de règlement devient tel code, telle condition de paiement se traduit de telle façon.
On développe ensuite dans Sage X3 des modèles d'import adaptés aux fichiers extraits. Un modèle d'import, c'est en quelque sorte le mode d’emploi qui indique à l'ERP comment lire un fichier et où ranger chaque information. Une fois écrit, il se rejoue autant de fois que nécessaire. Ce travail dépend directement du paramétrage retenu pendant le projet : les deux avancent ensemble.
Les données sont chargées dans un environnement de test, jamais directement en production. Et l'ordre compte : il faut ordonnancer les imports, c'est-à-dire les enchaîner dans le bon ordre, parce que certaines données dépendent d'autres. Impossible d'importer des commandes de vente si les articles et les clients qu'elles mentionnent n'existent pas encore dans Sage X3.
Chaque chargement fait remonter des rejets. On corrige là où se trouve le problème : dans les fichiers d'import, dans les modèles d'import, dans les tables de transcodage ou dans le paramétrage de Sage X3. Et on documente chaque correction, sans exception : c'est ce qui permet de rejouer la reprise à l'identique la fois suivante.
On chronomètre aussi chaque import réussi. Ces mesures servent à préparer le démarrage : on sait combien de temps prendra le chargement final, et donc combien de temps les équipes devront patienter avant de travailler dans Sage X3.
Un import qui passe sans erreur technique ne prouve pas que les données sont justes. Seuls les utilisateurs peuvent le dire : la comptabilité vérifie que les soldes concordent, la logistique que les stocks sont les bons, l'administration des ventes que les commandes ouvertes sont complètes. Ces contrôles se préparent à l'avance, avec des listes de points à vérifier et des totaux à rapprocher entre l'ancien et le nouveau système.
Chaque anomalie relevée renvoie à l'étape 5, puis à un nouvel import. On boucle ainsi entre les étapes 4, 5 et 6 jusqu'à la validation par les métiers. Il n'y a pas de nombre magique d'itérations : on recommence tant que les données ne sont pas fiables.
Le jour du démarrage, on refait tout en production, avec les modèles d'import, les tables de transcodage et l'ordre d'import validés en test. Avant l'extraction finale, les utilisateurs arrêtent toute saisie dans l'ancien ERP. Sans ce gel des saisies, une commande ou un mouvement de stock enregistré pendant le chargement manquerait dans Sage X3. On extrait, on charge dans l'ordre établi, les métiers font un dernier contrôle, et on bascule.
La tentation est de tout reprendre, « au cas où ». C'est rarement une bonne idée. Chaque donnée reprise doit être nettoyée, transformée et contrôlée : plus le volume grossit, plus la reprise coûte cher et plus le risque d'erreur augmente.
Ce qui se reprend presque toujours : les données de référence actives (clients, fournisseurs, articles, tarifs en vigueur) et les données ouvertes au moment de la bascule, c'est-à-dire les stocks, les commandes en cours, les factures non soldées et les soldes des comptes comptables à la date de bascule.
L'historique, lui, se décide au cas par cas. Avez-vous besoin de comparer vos ventes d'une année sur l'autre dans le nouvel ERP dès le premier jour ? Pouvez-vous garder l'ancien système en simple consultation, ou archiver des extractions lisibles ? Attention aussi à ne pas confondre reprise et conservation : en Suisse, le Code des obligations impose de conserver les livres et pièces comptables pendant dix ans, mais rien n'oblige à les charger dans le nouvel ERP. Il n'y a pas de réponse universelle. Il faut en revanche une réponse écrite, validée par la direction, avant de commencer.
Commencer trop tard. La reprise démarre souvent une fois le paramétrage terminé, avec l'idée qu'on nettoiera plus tard. C'est trop tard : le nettoyage prend du temps, il dépend de la disponibilité des métiers, et une fois en production plus personne n'a le temps de s'en occuper. Le sujet doit être posé dès le cadrage du projet.
Confondre « import réussi » et « données justes ». Zéro rejet technique ne veut pas dire zéro erreur. Sans contrôle métier, une remise client erronée ou un stock mal valorisé passe sans alerte.
Sous-estimer les temps de chargement. Un import qui passe en quelques minutes sur un échantillon peut prendre des heures sur le volume réel. Si on le découvre le jour du démarrage, c'est toute la fenêtre de bascule qui déborde. D'où l'intérêt de chronométrer chaque import dès les premiers tests.
Sur les projets Sage X3 que nous menons, trois réflexes font la différence.
Tout documenter. Méthodes d'extraction, tables de transcodage, ordre des imports, corrections, contrôles de validation : tout est écrit et partagé. Quand une question revient en fin de projet, la réponse existe déjà, et la reprise finale se rejoue sans improvisation.
Passer les gros imports en tâches batch. Certains fichiers, comme les commandes de vente, peuvent mettre des heures à se charger. Lancés en tâches batch, c'est-à-dire en traitements qui tournent en arrière-plan sur le serveur, ils libèrent l'équipe, qui avance sur autre chose pendant ce temps. Les plus longs peuvent tourner la nuit ou le week-end : on enchaîne ainsi les itérations sans allonger le planning.
Faire une répétition générale. Avant le démarrage, une dernière passe complète en test, avec les mêmes étapes, le même ordre et le même minutage que le jour J, et un plan de retour arrière. Cela suppose un environnement de test disponible et représentatif de la production, un point d'infrastructure qu'on vérifie très tôt.
Cette approche fait partie de notre accompagnement Sage X3, de la préparation jusqu'à la maintenance et aux évolutions après le démarrage.
Un ERP ne vaut que ce que valent les données qu'on y met. La reprise de données n'a rien de spectaculaire, mais c'est elle que vos équipes jugeront le premier matin. La bonne question à se poser dès le lancement n'est pas « quand fait-on l'import ? », mais « qui est responsable de la qualité de nos données, et depuis quand y travaille-t-il ? ».
