Reprise de données : les contrôles à prévoir avant la bascule.

La reprise de données ne se résume pas à importer un fichier. Les informations peuvent être réparties entre un ancien logiciel, des tableurs et une base de données. Elles portent parfois des noms différents pour désigner la même chose, ou utilisent les mêmes champs avec des règles différentes.

Faire l’inventaire avant de transformer

Listez les sources, les volumes et les données dont les équipes ont encore besoin. Certaines informations devront être reprises pour travailler dans le nouvel outil ; d’autres peuvent rester dans une archive consultable. Ce choix doit être validé avec les personnes qui utilisent les données, pas seulement avec l’équipe technique.

Repérez les identifiants, les doublons, les champs vides et les valeurs qui ne respectent plus les règles actuelles. Par exemple, une même société peut apparaître sous plusieurs noms. Le nouvel outil ne pourra pas résoudre seul cette ambiguïté.

Écrire les correspondances et les exceptions

Pour chaque champ à migrer, notez sa source, sa destination et la transformation éventuelle. Une date peut changer de format ; un statut ancien peut correspondre à plusieurs statuts du nouvel outil. Les cas sans correspondance doivent être signalés pour décision, plutôt que remplis avec une valeur arbitraire.

Cette table de correspondance sert de référence commune. Elle permet de vérifier le script de reprise et de comprendre plus tard pourquoi une valeur a changé. Les données sensibles demandent aussi une attention particulière : limitez les copies de travail et les accès aux personnes concernées.

Répéter la migration sur un jeu représentatif

Un premier essai doit contenir des enregistrements simples et des cas difficiles : données manquantes, anciennes valeurs, doublons et liens entre objets. Vérifiez le résultat dans le nouvel outil avec les équipes métier. Une ligne importée peut être techniquement valide mais inutilisable dans leur travail quotidien.

Les contrôles utiles comprennent :

• le nombre d’enregistrements lus, importés et rejetés ;
• la comparaison de champs clés sur un échantillon choisi ;
• la présence des liens attendus, par exemple entre clients et commandes ;
• la possibilité de relancer l’import sans créer de doublons.

Préparer la bascule et le contrôle final

Définissez quand l’ancien outil cessera d’être modifié, comment traiter les changements arrivés depuis le dernier essai et qui validera la reprise. Prévoyez une sauvegarde de la source et un moyen de revenir à l’état précédent si le résultat n’est pas exploitable.

Après l’import final, comparez les volumes et faites vérifier les parcours importants par les utilisateurs. Une migration réussie se juge sur les données consultées et utilisées dans le nouvel outil, pas uniquement sur le message « import terminé ».