Transformer des tableaux au changement de système

Qui change d’ERP ou de CRM prévoit du temps pour la formation, le paramétrage et les processus. Ce qui est régulièrement sous-estimé, c’est la partie intermédiaire : transformer les données de l’ancien système pour qu’elles soient valides dans le nouveau.

Les chiffres sont désagréablement clairs. Selon le Bloor Group, plus de 80 pour cent des migrations de données dépassent le délai ou le budget, en moyenne de 30 pour cent pour les coûts et de 41 pour cent pour la durée. Gartner prévoit que d’ici 2027, plus de 70 pour cent des projets ERP récemment lancés manqueront leurs objectifs initiaux, jusqu’à 25 pour cent de manière grave.

Ce qui est instructif, c’est ce qui n’est pas en cause. Pas le volume. Un fichier clients de 14'000 entrées est une broutille pour n’importe quelle base de données.

La boucle que personne ne planifie

Une migration de données n’est pas un passage unique. Quatre à six essais sont habituels, et pour une bonne raison : l’état des anciennes données n’est pas connu d’avance. Il apparaît lorsque le système cible refuse le fichier.

Le déroulement est presque toujours le même. Export de l’ancien système. Transformation dans Excel. Import dans le système cible. Message d’erreur. Retour à Excel. Et comme l’export est retiré à nouveau au passage suivant, le classeur de formules ne convient plus tout à fait, et quelqu’un le reconstruit à moitié.

Panorama Consulting décrit les causes récurrentes : doublons, codes produits obsolètes, enregistrements de clients et de collaborateurs sans lien actuel, et informations importantes qui ne figurent que dans un fichier Excel et non dans le système de référence. La racine est presque toujours la même : les services tiennent leurs propres versions des mêmes informations, qui divergent sur des détails, par exemple l’orthographe d’une adresse.

Pourquoi Excel est ici le mauvais outil

Excel sait faire tout ce qu’une transformation exige. Ce n’est pas le problème. Le problème tient à deux propriétés utiles au quotidien et dangereuses dans une migration.

La première : Excel n’avertit pas. Une formule appliquée à 12'000 lignes qui inscrit #VALEUR! dans 400 d’entre elles ressemble à l’écran aux 11'600 autres. L’erreur apparaît à l’import, trois étapes plus tard, et on ne sait alors plus quelle règle l’a produite.

La seconde : Excel oublie. Un classeur de formules retient ce qui est calculé, mais pas pourquoi. Après le troisième essai, plus personne ne sait si la colonne No-art a été raccourcie volontairement ou si c’est une bavure du premier passage.

Ensemble, ces deux points rendent la boucle coûteuse. Non pas le passage isolé, mais le fait que chaque passage recommence à moitié.

Ce qui peut être raccourci et ce qui ne le peut pas

Une distinction préalable, parce qu’elle est régulièrement brouillée dans les promesses commerciales. Une migration comporte deux parties : les décisions et l’exécution.

Un exemple tiré du fichier articles. Dans l’ancien système, une colonne s’appelle No-art et contient des valeurs comme A-1024. Dans le système cible, elle s’appelle sku et n’accepte que des chiffres. Savoir si cela devient le nombre 1024 ou si le A reste dans une colonne distincte est une décision. Elle revient à la personne des achats, et aucun outil au monde ne l’en décharge.

Ce qui suit relève de l’exécution : appliquer la règle à 12'000 lignes, vérifier combien passent, lancer le passage suivant. Cette partie est mécanique, et c’est précisément elle qui dévore le temps de projet.

Trois éléments qui font la différence

Premièrement : un aperçu avant l’écriture. Lorsqu’un type de colonne est converti, il faut savoir au préalable combien de lignes passent proprement et lesquelles non. Ce seul chiffre évite l’erreur la plus fréquente, à savoir une conversion qui abîme silencieusement des données.

Deuxièmement : des requêtes plutôt que des formules pour les questions de contrôle. Combien de lignes sans champ obligatoire ? Combien de doublons sur le numéro client ? La somme des postes ouverts correspond-elle ? Ce sont des questions, pas des calculs. Pouvoir les poser en langage courant, au lieu de construire une formule NB.SI.ENS, épargne une heure à chaque essai.

Troisièmement : garder la transformation répétable. Si l’export suivant parcourt automatiquement les mêmes étapes, la partie la plus coûteuse de la boucle disparaît. Non pas la transformation elle-même, mais sa reconstruction.

Chez Vectoryon, un fichier d’export se présente après lecture comme tableau avec schéma de colonnes reconnu. Le changement de type d’une colonne affiche un aperçu et n’écrit qu’après confirmation. Les requêtes se font en langage courant. Les étapes récurrentes peuvent être enregistrées comme automatisation, déclenchée par une modification de ligne. Chaque étape est journalisée, pour qu’au rapprochement il reste traçable quelle règle a produit quelle valeur.

Ce que ce n’est pas

Vectoryon n’est ni un ERP ni un CRM. Il n’existe aucune liaison directe vers Abacus, SAP, Bexio ou Dynamics, et nous ne le prétendons pas. Le chemin passe par le fichier d’export de l’ancien système et l’interface d’import du système cible.

C’est moins pénalisant qu’il n’y paraît. L’export est de toute façon la première étape de tout projet de migration, car il donne le seul regard fiable sur l’état réel des données. Un couplage système épargne un clic et masque en échange ce qui est réellement transféré.

Le rapprochement après chargement appartient lui aussi au système cible. Un outil peut montrer quelles valeurs il a écrites. Ce que l’ERP en a fait à l’import, s’il a arrondi, tronqué ou rejeté, seul l’ERP y répond.

Et l’attribution métier champ par champ reste chez l’entreprise ou son partenaire d’intégration. Un outil exécute une règle. Quelle règle est juste, il ne le sait pas.

Ce que nous ne prétendons volontairement pas

Vous ne trouverez sur cette page aucun facteur d’économie. De tels chiffres circulent en abondance dans le domaine de la migration et sont presque toujours extrapolés d’un cas isolé.

Pour obtenir un chiffre solide dans un cas précis, il faut prendre un export réel de l’ancien système et mesurer un passage. Cela prend un après-midi et en dit plus que toute brochure.

Les bases du déroulement figurent sous Migration de données. Les deux cas les plus fréquents sont traités séparément : Migration de données dans un projet ERP et Migration de données dans un projet CRM.

Sources

• Gartner, « What IT Leaders Must Do to Avoid Disappointing ERP Initiatives », 2024 : d’ici 2027, plus de 70 pour cent des projets ERP récemment lancés manqueront leurs objectifs, jusqu’à 25 pour cent de manière grave.
• Bloor Group, cité dans le livre blanc Oracle « Put Your Data First or Your Migration Will Come Last » : plus de 80 pour cent des migrations de données dépassent le délai ou le budget, coûts en moyenne 30 pour cent, durée 41 pour cent.
• Panorama Consulting Group, « 6 ERP Data Migration Challenges » : doublons, codes produits obsolètes, entrées sans lien actuel, informations uniquement dans des fichiers Excel.