Migration de données : migrer est facile, prouver qu'on n'a rien perdu est le travail

Personne ne change de base de données par plaisir. On le fait parce que l'ancienne coûte trop cher, parce qu'elle ne tient plus la charge, ou parce que plus personne ne sait la maintenir. Et au moment de lancer la reprise, la question qui empêche de dormir n'est jamais « est-ce que ça va marcher » : c'est « comment saurai-je que tout est bien arrivé ? »

Écrire le programme qui déplace les données est la partie facile du travail. Établir, chiffre en main, ce qui a été transféré, ce qui ne l'a pas été et pourquoi : c'est là que se trouve la valeur, et c'est ce que nous facturons.

Ce que vous achetez n'est pas l'outillage

Autant le dire tout de suite, parce que c'est vrai et que vous le découvririez de toute façon : l'outillage de reprise est jetable. Il s'écrit en dur pour votre modèle de données, une fonction par entité, sans mappage déclaratif, sans configuration, sans interface en ligne de commande. Il ne se revend pas et ne se réutilise pas d'un projet à l'autre.

Ce qui se transpose, en revanche, et ce qui vaut d'être payé, c'est le harnais de contrôle : le programme qui relit la source et la cible après coup et décide, sans intervention humaine, si les deux racontent la même histoire. C'est cette pièce-là qui transforme « on a migré » en « on a prouvé qu'on a migré ».

Huit familles de contrôles, et ce que chacune attrape

Un rapport de réconciliation qui se contente de comparer deux totaux ne prouve rien : deux erreurs opposées s'annulent, et le compte tombe juste sur des données fausses. Notre harnais exécute huit familles de vérifications distinctes, chacune conçue pour attraper une classe de défaut que les autres laissent passer.

• Comptages source et cible, entité par entité et non en total général.
• Tables de jointure : les relations multiples sont ce qui disparaît le plus discrètement, car aucune ligne visible ne manque.
• Intégrité référentielle : aucune clé étrangère ne doit désigner un enregistrement inexistant.
• Existence réelle de chaque fichier, vérifiée une par une côté stockage objet — une référence valide en base ne prouve pas qu'un objet se trouve derrière.
• Cohérence des références de stockage : l'emplacement enregistré et l'emplacement réel désignent la même chose.
• Valeurs hors énumération : les champs à liste fermée de l'ancien système contiennent presque toujours des valeurs que personne n'avait prévues.
• Couverture des clés héritées : chaque enregistrement d'origine reste retrouvable dans la cible par son identifiant historique.
• Doublons de clés héritées : un même enregistrement d'origine ne doit pas être arrivé deux fois.

Le rapport qui en sort est le livrable. Il liste les contrôles au vert, les avertissements, et surtout chaque anomalie avec sa justification. Un écart n'est acceptable que s'il a été décidé, écrit et expliqué ; c'est exactement ce qui le distingue d'une perte silencieuse.

Ce que nous avons mesuré sur un cas réel

La méthode décrite ici n'est pas théorique. Elle vient de la reprise d'une plateforme documentaire scientifique sortie d'une base héritée vers une base relationnelle. Le volume relu à la source : 5 035 898 documents. Le volume chargé dans la cible : environ 3 475 272 lignes. Le verdict du harnais de vérification : zéro échec.

L'écart entre ces deux volumes n'est pas une perte : ce sont des périmètres écartés par décision explicite, et c'est précisément ce que le rapport sert à établir. Une réserve doit accompagner ces chiffres, et nous la portons : la cible de cette reprise était un environnement de préproduction, pas une production. C'est ce qui a été mesuré, et nous n'en tirons rien de plus.

Le détail qui coûte cher, et que nous avons appris

Pour vérifier la couverture et les doublons, chaque enregistrement repris porte la clé de son ancien identifiant. Elle est nécessaire pendant la reprise, et c'est un champ purement technique : il n'a aucune raison de sortir de la base. Nous avons pourtant vu un tel champ apparaître sur des réponses d'authentification avant d'être retiré du périmètre exposé. Depuis, vérifier que la clé de correspondance ne fuit sur aucune réponse d'API fait partie des contrôles de fin de reprise. Nous préférons vous raconter ce genre de chose plutôt que de vous laisser la découvrir.

Ce que nous ne promettons pas

Nous ne garantissons pas le « zéro perte ». Personne ne le peut honnêtement : une base héritée de dix ans contient des enregistrements incohérents, orphelins ou dupliqués qui n'ont pas d'équivalent propre dans un modèle relationnel, et une partie du travail consiste justement à décider ce qu'on en fait. Ce sur quoi nous nous engageons est différent et vérifiable : prouver, pièce par pièce, ce qui a été transféré, et documenter le reste au lieu de le taire.

Nous ne publions pas non plus de délai type. La durée d'une reprise dépend du nombre d'entités, de l'état de la source et du nombre d'allers-retours nécessaires pour que le rapport devienne stable — trois choses qu'on ne connaît qu'après avoir lu votre schéma.

Comment se déroule une reprise

Nous commençons par lire la source telle qu'elle est, et non telle que sa documentation la décrit. Vient ensuite l'écriture du programme de reprise et, en parallèle, celle du harnais de contrôle. Les deux se rejouent autant de fois que nécessaire sur un environnement de préproduction, jusqu'à ce que chaque écart restant soit expliqué. Le basculement, lui, est une décision distincte, prise au vu du rapport.

Si la migration s'accompagne d'un nouveau socle applicatif — API, logique métier, hébergement — c'est la fiche backend sur-mesure qui décrit ce volet. L'ensemble de nos prestations est présenté sur la page services, et la lecture de votre schéma se demande depuis la page contact.