Reprise de données : méthode, recette et garde-fous

Dans un projet de migration, le code se réécrit ; les données, elles, doivent traverser. Vingt ans de saisies, de corrections manuelles et d'évolutions de schéma ne traversent jamais proprement sans méthode. C'est le chantier le plus sous-estimé des migrations PC SOFT, et celui qui décide de la confiance des utilisateurs au premier jour.

Pourquoi c'est le chantier le plus risqué

Une régression de code se corrige par une mise à jour ; une donnée perdue ou faussée peut être irrécupérable, et une facturation fausse se voit immédiatement. S'ajoute l'effet d'accumulation : les bases anciennes contiennent des états que plus aucune règle actuelle ne produit, des doublons historiques, des valeurs sentinelles qui avaient un sens en 2008. La reprise doit traiter tout cela explicitement, pas le découvrir en production.

Une situation type

Le cas le plus fréquent ressemble à ceci : un référentiel clients contient des doublons créés à des périodes différentes, sous des orthographes légèrement différentes, avec des historiques de commandes répartis entre les deux fiches. Une extraction brute reproduirait ce doublon dans le nouveau système, avec le même problème qu'avant. Le traitement correct exige une règle de fusion validée par le métier, qui choisit la fiche de référence et documente ce qu'il advient de l'historique de l'autre, avant que le rejeu suivant ne l'applique de façon systématique.

Extraction depuis un format propriétaire

HFSQL ne se lit pas avec les outils standards du marché : l'extraction passe par les connecteurs dédiés ou par un programme d'extraction écrit pour votre schéma. Notre choix par défaut : l'extracteur dédié, rejouable et journalisé, qui transforme l'opération en processus répétable. Un rejeu complet doit pouvoir se lancer chaque semaine pendant le projet, pour que la bascule finale ne soit que le dernier rejeu d'une longue série réussie.

Nettoyage et déduplication

Entre l'extraction et le chargement, les données passent par une phase d'assainissement : normalisation des formats (dates, téléphones, codes postaux), traitement des valeurs sentinelles et des champs détournés de leur usage, déduplication des référentiels avec règles de fusion validées par le métier. Chaque règle de nettoyage est écrite, versionnée et rejouable : aucun nettoyage manuel en base, qui serait perdu au rejeu suivant.

Mapping et règles de transformation

Le dictionnaire de mapping est le document central du chantier : pour chaque table et chaque champ source, sa destination, son type cible, sa règle de transformation et ses cas particuliers. Il se construit avec le métier, car la moitié des décisions sont fonctionnelles : que faire des commandes orphelines, des clients inactifs depuis dix ans, des statuts qui n'existent plus ? Ce document sert ensuite de contrat de recette : on vérifie ce qu'il annonce.

Les questions à trancher avec le métier

• Que faire des enregistrements orphelins, sans lien valide vers leur table de référence ?
• Faut-il reprendre l'historique complet ou seulement les exercices encore actifs ?
• Comment traiter les statuts ou codes qui n'existent plus dans le système cible ?
• Quelle fiche fait référence en cas de doublon détecté lors de la déduplication ?

Rejeu et double-run

Le rejeu à blanc, chronométré, valide la mécanique complète et donne la durée réelle de la bascule finale. Quand le métier l'exige (facturation, paie, stocks critiques), on ajoute une période de double-run : l'ancienne base continue d'être alimentée en parallèle pendant que la nouvelle prend le relais, et les écarts sont comparés quotidiennement. C'est le filet de sécurité ultime, à réserver aux flux qui le justifient car il a un coût d'exploitation réel.

Erreurs fréquentes

• Lancer le premier rejeu complet trop tard, une fois le calendrier de bascule déjà fixé.
• Comparer uniquement les volumes entre source et cible, sans vérifier les agrégats métier.
• Négliger le double-run sur un flux critique parce que le rejeu à blanc s'est bien passé une fois.
• Corriger une donnée directement en base cible plutôt que dans la règle de transformation, ce qui efface la correction au rejeu suivant.

Recette d'intégrité : les contrôles obligatoires

• Comptages par table, comparés automatiquement entre source et cible à chaque rejeu.
• Agrégats métier : totaux de facturation par exercice, soldes clients, valeurs de stock, comparés au centime.
• Échantillonnage orienté cas limites : caractères spéciaux, dates extrêmes, enregistrements les plus anciens et les plus récents.
• Contrôles de cohérence référentielle : plus aucun orphelin après chargement, contraintes actives en base.
• Validation métier formelle : les référents signent la recette sur des jeux de données qu'ils ont choisis eux-mêmes.

Une reprise réussie ne se remarque pas : les utilisateurs retrouvent leurs dossiers, leurs totaux et leurs historiques, à l'identique. Tout l'effort de méthode vise cette absence d'événement.

FAQ