Migrer ses données sans perte : la méthode des essais à blanc

Changer de logiciel de gestion, passer d’un serveur à un autre, fusionner deux fichiers clients : une migration se prépare toujours plus longtemps qu’elle ne s’exécute. La règle que nous appliquons sans exception : on ne migre jamais en une fois, et on ne fait jamais confiance à un contrôle vert sur des données de test. Voici la méthode des essais à blanc, illustrée par la reprise d’une base de gestion commerciale.

Pourquoi les migrations se passent mal

Presque jamais à cause de l’outil. Trois causes reviennent. Les données réelles ne ressemblent pas aux données attendues : un champ censé contenir un code postal contient un commentaire, un client apparaît trois fois sous trois orthographes, un article a un prix négatif hérité d’un avoir. Les règles implicites ne sont écrites nulle part : tout le monde sait que les codes commençant par une lettre sont des articles obsolètes, personne ne l’a dit au prestataire. Et la migration se fait en une seule fois, un vendredi soir : quand le problème apparaît le lundi, on ne sait plus ce qui vient de l’ancien système et ce qui vient du nouveau.

Les quatre temps d’une migration

1. Extraire, et regarder

On commence par sortir les données de l’ancien système dans un format neutre, sans rien transformer. Puis on les compte, au sens propre : combien de clients, combien d’articles, combien de factures par exercice, quels totaux. Ces nombres deviennent les témoins : à la fin, le nouveau système doit afficher les mêmes.

On profile ensuite : valeurs manquantes, doublons, formats aberrants, caractères qui passent mal — accents, apostrophes, retours à la ligne dans un libellé. Sur une base de gestion commerciale, ce profilage révèle en général que 5 à 10 % des fiches demandent une décision humaine. C’est cette proportion qui détermine la durée réelle du projet, pas le volume.

2. Décider, et écrire les règles

Chaque anomalie appelle une règle, écrite : que fait-on des clients sans SIREN ? des articles inactifs depuis cinq ans ? des factures antérieures à la période reprise ? des doublons ? Ces décisions appartiennent à l’entreprise, pas au prestataire, et elles se prennent avant l’écriture, pas pendant. Un document d’une page suffit ; il servira aussi de recette.

C’est aussi le moment de décider ce qu’on ne migre pas. Reprendre dix ans d’historique dans un nouvel outil coûte cher et ralentit le système : souvent, deux ou trois exercices suffisent, l’ancien système restant accessible en lecture, ou son export archivé. Les obligations de conservation — dix ans pour les pièces comptables — se satisfont d’un archivage, pas d’une reprise.

3. Rejouer à blanc, sur les données réelles

C’est l’étape qui évite les catastrophes, et celle qu’on saute le plus souvent. On exécute la migration complète sur une copie du système cible, avec les vraies données, sans rien écrire dans le système de production. On produit un rapport : ce qui serait créé, ce qui serait modifié, ce qui serait rejeté et pourquoi. Puis on compare aux témoins de l’étape 1.

Nous avons appris cette règle à nos dépens sur un traitement de masse : un contrôle entièrement vert sur des données de test aurait, appliqué au réel, dupliqué des enregistrements dans trois registres. Depuis, la règle est absolue : un essai à blanc sur les données réelles, un rapport lu ligne à ligne pour les cas rejetés, puis une écriture limitée à un échantillon avant l’exécution complète.

4. Écrire, par lots, avec une marche arrière

Sauvegarde vérifiée avant toute écriture. Puis les référentiels d’abord — clients, fournisseurs, articles —, contrôlés, avant les mouvements. Chaque lot porte un identifiant qui permet de le retrouver et, si besoin, de le supprimer. Entre deux lots, on recompte. Et l’on garde l’ancien système accessible en lecture pendant plusieurs mois : c’est la seule marche arrière qui fonctionne toujours.

Le cas d’une base de gestion commerciale

Sur une reprise de base EBP vers une nouvelle version ou un nouveau serveur, cinq points méritent une attention particulière. Les codes articles et clients, qui sont des clés : les changer casse l’historique, il faut donc les conserver à l’identique ou tenir une table de correspondance. Les familles et sous-familles, qui portent les comptes comptables et les règles d’arrondi : un article changé de famille change de prix, silencieusement. Les numérotations de pièces, qui doivent repartir au bon compteur pour rester chronologiques et continues. Les tarifs et remises par client, souvent accumulés depuis des années. Et l’encodage des caractères, qui transforme un « é » en trois symboles sur toute une colonne si l’on se trompe de format à l’export.

Le contrôle final se fait sur des cas, pas sur des totaux : on rouvre dix pièces connues — une facture ancienne, un avoir, une commande partiellement livrée, un client avec remise — et on compare écran contre écran avec l’ancien système. Un total juste peut cacher deux erreurs qui se compensent ; dix pièces justes ne mentent pas.

Le calendrier et les précautions

• Jamais en période de pointe, ni pendant une clôture. Le meilleur moment est le début d’un exercice ou une période creuse.
• Une date de gel : à partir de laquelle on ne saisit plus dans l’ancien système. Sans elle, on migre une photo qui bouge.
• Une personne référente côté entreprise, qui connaît les données et peut trancher les cas particuliers en deux minutes.
• Une recette écrite : la liste des contrôles à passer avant de déclarer la migration réussie, signée par celui qui l’a passée.
• Les données personnelles : une migration est un traitement. Les copies de travail contiennent des données de clients et de salariés ; elles se suppriment à la fin, et le prestataire est un sous-traitant au sens du règlement européen.

Questions fréquentes

Combien de temps dure une migration ?

L’exécution, quelques heures. La préparation — extraction, profilage, règles, essais à blanc — représente l’essentiel : de quelques jours pour un fichier simple à plusieurs semaines pour une base de gestion avec historique.

Peut-on migrer soi-même ?

Pour un fichier clients, oui, avec méthode. Pour une base comptable ou de gestion commerciale, l’enjeu n’est pas technique mais réglementaire : numérotation, inaltérabilité des factures, piste d’audit. Mieux vaut se faire accompagner que découvrir le problème au contrôle.

Faut-il garder l’ancien logiciel ?

En lecture, oui, le temps de deux clôtures au moins, et de quoi relire les données archivées pendant dix ans. Une licence qui expire le jour de la migration est une mauvaise idée.

Sources

• Code de commerce, article L. 123-22 (conservation) ; livre des procédures fiscales, articles L. 102 B et L. 47 A (fichier des écritures comptables) ; code général des impôts, article 286, I-3° bis (inaltérabilité des logiciels de caisse).
• Règlement (UE) 2016/679 (RGPD), articles 28, 30 et 32 ; ANSSI, guide d’hygiène informatique.
• Retour d’expérience Alyneia sur des reprises de bases de gestion commerciale et de paie.