La reprise de données : le projet au sein du projet

Dans une transformation SI, beaucoup de choses peuvent encore évoluer après la mise en production : une règle de gestion peut être ajustée, un processus revu, un paramétrage modifié. En revanche, corriger les données migrées devient beaucoup plus complexe dès lors qu’elles sont utilisées pour créer de nouvelles transactions.

C’est un constat récurrent dans les projets que j’accompagne : alors que la reprise conditionne directement la qualité du démarrage, son cadrage intervient trop tardivement dans les plannings projets.

On conçoit les processus, on paramètre la solution, on construit les interfaces… puis arrive la question : « Au fait, qu’est-ce qu’on reprend et comment ? » Derrière cette question se cachent plusieurs mois de travail.

Définir rapidement ce que l’on reprend

Quels référentiels doivent être migrés ? Les tiers ? Les articles ? Les axes analytiques ? Les contrats ? Pour les transactions, quelle profondeur d’historique conserver ? Avec quel niveau de détail ? Que laisser dans l’ancien système ?

Ces choix paraissent simples tant qu’on reste à un niveau macro. Dans la pratique, c’est en descendant dans le détail que les arbitrages apparaissent.

Les différents périmètres sont interdépendants. Une décision prise sur un référentiel peut avoir des conséquences sur les flux associés, les interfaces ou les contrôles attendus.

J’ai vu plusieurs fois des sujets que l’on pensait cadrés revenir sur la table faute d’avoir atteint suffisamment tôt le niveau de précision nécessaire. Chaque nouvel arbitrage peut alors entraîner des transformations, développements ou tests supplémentaires et peser directement sur le planning.

Reprendre ne veut pas dire recopier

C’est un point de vigilance absolu : le passage entre la structure existante et celle attendue par le nouvel ERP représente un travail colossal.

Sur l’une de mes missions, les fiches tiers étaient gérées à la maille du SIRET dans l’ancien système, contre le SIREN dans le nouveau. Retrouver cette unicité dans les différentes bases a nécessité un travail considérable. Mais l’enjeu ne s’arrêtait pas au référentiel : il fallait ensuite rattacher correctement à cette nouvelle structure les commandes, réceptions et factures associées. Une modification sur un objet aura des impacts en cascade sur tout ce qui lui est rattaché. Il est nécessaire d’avoir cette vision globale dès le départ.

Les structures évoluent, certaines informations doivent être enrichies, rapprochées ou recalculées. Il faut identifier rapidement ces écarts et documenter les règles permettant de passer de l’existant à la cible.

Profiter du chantier pour nettoyer

Tiers inactifs, articles obsolètes, doublons, valeurs analytiques inutilisées, informations incomplètes… tout transférer revient souvent à transporter dans la nouvelle solution les problèmes de l’ancienne.

Sur le terrain, l’équipe projet ne peut pas résoudre seule ces sujets. Les métiers connaissent les bases et savent arbitrer les cas particuliers. Il faut donc identifier les contributeurs, organiser leurs interventions et piloter leur avancement.

Le cleaning ne peut pas être distribué quelques semaines avant le go-live en espérant que chacun trouvera le temps de traiter des centaines ou des milliers de lignes en parallèle de son activité quotidienne.

Plus ces travaux commencent tôt, plus ils peuvent être absorbés dans la durée plutôt que réalisés dans l’urgence.

Charger ne suffit pas, il faut contrôler

Un fichier intégré sans erreur ne garantit pas la qualité du résultat.

Il faut être capable de réconcilier source et cible : les volumes correspondent-ils ? Les soldes sont-ils cohérents ? Les éléments attendus sont-ils présents ? Les transformations ont-elles fonctionné ? Les rejets sont-ils identifiés et expliqués ?

Un taux de chargement de 98 % ne signifie rien si personne ne sait ce que représentent les 2 % restants, surtout sur un outil dédié à la gestion financière de l’entreprise. Je reviens toujours à une question simple : sommes-nous capables d’expliquer et de justifier le passage entre ce que nous avions avant et ce que nous retrouvons après ?

« Un problème de migration devient très vite un problème d’adoption. »

Répéter avant le jour J

Les bascules à blanc servent à valider les mécanismes de migration, mais pas seulement. Elles permettent aussi d’éprouver l’enchaînement complet : ordre des extractions et des chargements, temps de traitement, responsabilités, dépendances, vérifications…

Entre le planning Excel et son exécution réelle, il y a toujours des écarts. À chaque répétition, je vois émerger des points qui n’avaient pas été anticipés : un traitement plus long que prévu, une dépendance oubliée, une vérification impossible dans le délai prévu…

Sur une autre de mes missions, le nouvel ERP introduisait un objet « contrat » qui n’avait pas d’équivalent dans l’existant. Nous avons dû tenter de le reconstruire à partir de plusieurs sources. Malgré les bascules à blanc successives, nous n’étions pas parvenus à fiabiliser complètement le mécanisme et le choix a été fait de poursuivre le travail en production. Six mois après le go-live, la migration n’était toujours pas terminée et certains utilisateurs refusaient de travailler dans le nouvel outil tant qu’ils ne « retrouvaient pas leurs petits ». Non seulement la reprise a été chaotique, mais les impacts en termes d’adoption ont été terribles.

C’est précisément le rôle des répétitions : faire émerger les difficultés suffisamment tôt pour pouvoir les traiter avant qu’elles ne deviennent des problèmes de production.

Un projet à part entière

Je considère le chantier de la reprise de données comme un projet à part entière dans la transformation. Pour assurer son bon déroulé, il doit avoir son périmètre, ses responsables, ses travaux métier, ses arbitrages, ses tests et son propre planning.

L’enjeu dépasse largement la migration technique. Je l’ai vécu : lorsque les équipes ne retrouvent pas leurs contrats, leurs fournisseurs ou leurs transactions, peu importe que l’ERP fonctionne techniquement, pour elles, « le nouvel outil ne fonctionne pas ». Un problème de migration devient très vite un problème d’adoption.

Chez Solypse, nous avons développé un outil permettant de structurer et de piloter les actions de nettoyage. Nous accompagnons également nos clients dans le cadrage, la préparation et le pilotage de ces phases critiques de leurs transformations.