Migrer des données depuis Excel ou un ancien système de gestion : comment contrôler le résultat

Une migration de données ne se juge pas au fait que les données soient entrées. Elle se juge au fait qu’on puisse démontrer qu’elles sont toutes entrées, et correctement. La différence se voit trois mois plus tard, quand quelqu’un cherche un document vieux de deux ans et ne le trouve pas : à ce moment-là, plus personne ne sait s’il n’existait déjà pas avant, s’il a été exclu volontairement ou s’il s’est perdu pendant le transfert.

La partie difficile n’est pas de déplacer les informations. C’est de conserver les liens entre elles — le client relié à ses commandes, la commande reliée à ses documents — et de préserver la possibilité de vérifier. Ce guide sert à préparer le transfert de façon à ce qu’il soit contrôlable, pas seulement réalisable.

Inventaire : ce qui existe et ce qui ne doit pas passer

Avant de regarder les champs, on regarde les sources. Elles sont presque toujours plus nombreuses que celles déclarées : à côté du système de gestion, il y a les feuilles de calcul avec lesquelles quelqu’un a résolu un problème que le système de gestion ne résolvait pas, et ces feuilles contiennent des données que personne d’autre n’a.

• Pour chaque source : qui l’utilise, qui la met à jour, depuis quand elle existe, combien de lignes elle contient et laquelle est la plus récente.
• La qualité, de façon concrète : combien de lignes ont le champ obligatoire vide, combien d’adresses sont incomplètes, combien de dates sont impossibles. Quelques vérifications suffisent pour comprendre à quoi vous avez affaire.
• Ce qui ne doit pas passer : fiches inactives depuis des années, essais, lignes de service, données que vous n’avez plus de raison de conserver. C’est une décision à prendre et à écrire, pas à reporter au moment du transfert.
• Ce qui doit rester consultable mais non actif : les historiques. Souvent, le bon choix est de porter les dernières années dans le nouveau système et de conserver le reste dans une archive lisible, plutôt que de tout traîner.

Le mapping origine-destination

C’est le document central du travail : une ligne par champ, avec la règle écrite à côté. Il se remplit avant d’exécuter quoi que ce soit, et sert aussi de documentation par la suite. Les valeurs sont illustratives.

La dernière ligne est une règle générale utile : ce que l’on ne sait pas interpréter se transfère tel quel, dans un champ de texte. Pire que de perdre une donnée, c’est de la transformer selon une hypothèse erronée, parce que la première erreur se voit et la seconde non.

Identifiants et doublons

Chaque entité transférée a besoin d’une clé stable, et la clé de l’ancien système doit être conservée aussi dans le nouveau, dans un champ dédié. Cela ne coûte rien et permet pendant des années de répondre à la question « d’où vient ce client ? ».

• Les doublons se cherchent avant le transfert, dans la source, là où ils sont encore corrigibles par ceux qui connaissent les données.
• La fusion de deux fiches doit être décidée par une personne, pas par une règle automatique : deux sites de la même société peuvent être deux clients distincts pour des raisons comptables.
• Quand deux lignes se réunissent, on conserve les deux anciennes clés : les documents historiques pointent vers l’une des deux.
• Les doublons qu’on n’arrive pas à résoudre se transfèrent quand même, marqués. Un doublon visible est un problème ; un doublon supprimé par erreur est une perte.

L’essai, et les trois contrôles qui comptent

Le transfert s’exécute d’abord sur un environnement de test, avec un échantillon qui comprend les cas difficiles : le client avec le plus de commandes, celui avec l’adresse étrange, celui dont le nom contient des caractères accentués, la commande la plus ancienne et la plus récente.

1. Comptages : combien de lignes en origine, combien en destination, combien écartées et pour quel motif. La somme doit correspondre exactement, et les rejets doivent être listés nommément, pas simplement comptés.
2. Totaux : la somme des montants par année, en origine et en destination. C’est le contrôle qui découvre d’un seul coup les séparateurs décimaux mal lus et les lignes perdues.
3. Relations : un client donné a-t-il toutes ses commandes ? Une commande donnée a-t-elle toutes ses lignes et ses documents ? C’est le contrôle qui saute le plus souvent, parce que le comptage global correspond même quand les liens se sont rompus.

Le procès-verbal de réconciliation et le jour du basculement

Le procès-verbal est une page que l’on signe et que l’on conserve : date du transfert, version des sources, comptages et totaux comparés, liste des rejets, décisions prises sur les exclusions, nom de la personne qui a vérifié. Il sert à clore la discussion des mois plus tard, quand la mémoire ne suffit plus.

Le basculement définitif se planifie comme on planifie un déménagement. On choisit un moment d’activité à l’arrêt, on informe les personnes à partir de quand l’ancien système ne doit plus être mis à jour, et on établit à l’avance ce qu’il faut faire des informations saisies entre-temps, parce que quelqu’un les saisira quand même.

• Sauvegarde complète de l’origine et de la destination, vérifiée avant de commencer : une sauvegarde que personne n’a essayé de relire n’est pas une sauvegarde.
• L’ancien système reste accessible en lecture seule pendant une période convenue. C’est la vraie voie de retour, plus que la restauration technique.
• Une condition d’abandon écrite à l’avance : si à un certain moment les contrôles ne correspondent pas, on annule et on réessaie une autre fois. Le décider en cours de route est impossible, parce que tout le monde est déjà fatigué.
• Les exceptions connues doivent être attribuées à quelqu’un avec une échéance, pas laissées dans une liste : les adresses à corriger à la main ne se corrigent pas toutes seules.

Ce que ce guide ne couvre pas

Ici, il est question du transfert ponctuel : porter les données d’où elles sont à où elles doivent se trouver, une fois. Maintenir alignés deux systèmes qui continuent à vivre tous les deux est un problème différent, avec ses propres règles sur qui commande quelle donnée et ce qui se passe quand les deux se contredisent, et il est traité à part. La décision en amont, c’est-à-dire remplacer ou non l’outil actuel, est également hors périmètre.