Expertise - Migration de données : reprendre les données d'un ancien logiciel sans en perdre

De quoi parle-t-on ?

Prenons une application métier qu'on refait de zéro, parce que sa dette technique la rend trop difficile à faire évoluer. La nouvelle application est prête, mais les fiches saisies pendant des années sont dans l'ancienne base. Il faut les retrouver dans la nouvelle, complètes et justes. Une migration de données fait passer les données d'un ancien système à un nouveau sans en perdre et sans les abîmer.

L'exercice est risqué parce qu'une vieille base contient presque toujours des données que la nouvelle application refuserait :

• des dates impossibles, comme un 31 février ou une année 0200 tapée à la place de 2000 ;
• des doublons : la même personne saisie deux fois, avec une orthographe un peu différente ;
• des incohérences : une fiche rattachée à un dossier qui n'existe plus, un champ obligatoire resté vide ;
• un schéma qui ne correspond pas : une information rangée dans une seule colonne d'un côté et répartie dans trois tables de l'autre, ou des valeurs codées autrement.

En plus, l'ancien système sert souvent encore pendant qu'on prépare la migration, et ses données continuent de bouger.

Des migrations que nous avons menées

Cobra : d'un ancien CRF en ASP.NET à PostgreSQL et Django

Cobra suit une cohorte de patients asthmatiques et BPCO. Avant l'application actuelle, les données étaient saisies dans un ancien CRF, une application ASP.NET sur SQL Server, avec deux bases séparées : l'une pour les données médicales, l'autre pour l'identité des patients. En 2022, nous avons repris ces données vers PostgreSQL et Django.

La reprise est une commande de migration. On la lance d'abord en mode « dry-run » : elle fait tout l'import dans une transaction, puis l'annule à la fin. Quand le résultat est bon, on la lance pour de vrai. Tout l'import entre dans une seule révision de l'historique, ce qui permet de savoir quelles données viennent de la reprise.

Chaque fiche reprise garde aussi les données d'origine, telles qu'elles étaient dans l'ancien système, avec le nom et le prénom masqués. Une date invalide ne bloque pas l'import : elle est notée dans un journal, et le reste passe.

L'ancien système a continué à recevoir des données après la mise en service de Cobra. En 2024, une deuxième passe a repris uniquement ces données-là, et on peut la limiter à un centre ou à un patient. Dans Cobra, les visites reprises s'affichent comme anciennes visites.

Simplauto : lire l'ancienne base en place

En 2020, nous avons refait entièrement Simplauto, le site de réservation de contrôle technique. Les données de l'ancien site étaient dans une base PostGIS. Les commandes de migration la lisaient directement, à travers des modèles Django posés en lecture seule sur l'ancien schéma, et remplissaient les nouveaux modèles. Elles avaient, elles aussi, un mode « dry-run ».

De MySQL 5.7 à MySQL 8.0

En 2026, nous avons préparé le passage de MySQL 5.7 à MySQL 8.0 pour la base d'une vieille application Django 1.6 sous Python 2.7, et nous l'avons validé sur une copie de la production. Une pile de test permet d'essayer l'application sur la nouvelle version, et une procédure décrit la bascule.

Notre méthode

Une migration est un programme : on peut la lancer sur une copie des données, regarder le résultat, corriger et recommencer autant de fois qu'il le faut. Le jour de la bascule, on lance la commande qu'on a déjà répétée.

On commence toujours à blanc. En mode dry-run, la migration écrit vraiment dans la base, ce qui fait jouer les contraintes de PostgreSQL, puis annule tout. Elle dit ce qu'elle aurait importé et ce qu'elle aurait rejeté.

L'import tourne dans une seule transaction. Une fiche incomplète ou incohérente est repérée avant d'être écrite : la migration la note dans ses avertissements, la saute et passe à la suivante. Si c'est le lot entier qui est faux, on annule la transaction et la base revient à son état d'avant.

Ce qui n'a pas pu être repris va dans un journal, avec la fiche concernée et la raison du rejet, pour qu'on puisse le corriger à la source ou à la main.

La passe de rattrapage de Cobra contrôle aussi ce qui est déjà dans la nouvelle base. Un patient déjà repris est sauté. Un patient qui ressemble à un patient déjà créé dans Cobra (même centre, mêmes nom et prénom, même mois de naissance) n'est pas importé : il est listé à part, pour qu'on le vérifie à la main.

La bascule se prépare elle aussi : la date, l'ordre des étapes, ce qu'on fait si quelque chose se passe mal, et la passe de rattrapage pour les données saisies entre-temps.

L'outillage

Nous écrivons ces migrations comme des commandes Django, dans le même dépôt que l'application. Elles utilisent les modèles de la nouvelle application, se testent comme le reste du code, et restent sous la main pour une deuxième passe. Nous n'utilisons pas d'outil ETL : sur une application métier, le plus dur est d'écrire les règles de conversion, et elles se lisent mieux en Python, à côté du code qui utilisera les données.

Ce que Naeka peut faire

Reprendre les données d'un ancien logiciel

Vous remplacez une application, la vôtre ou celle d'un autre prestataire. Nous lisons l'ancienne base, nous établissons avec vous la correspondance entre l'ancien modèle et le nouveau, et nous écrivons la migration. Si c'est l'application elle-même qu'il faut reprendre et maintenir, voyez notre offre de TMA.

Changer de base ou monter de version

Passer d'une base à une autre, ou monter une base vers une version encore maintenue. Nous testons l'application sur la nouvelle base avant la bascule, et nous écrivons la procédure du jour J.

Migrer en plusieurs passes

Si l'ancien système continue de recevoir des saisies après la mise en service, une passe de rattrapage les reprend ensuite dans la nouvelle application.

Anonymiser une copie pour les tests

Pour répéter une migration, il faut des données réelles. Nous préparons une copie anonymisée de la base, pour que les développeurs et les testeurs ne voient pas de données personnelles.

Parlons de vos données

Vous avez un logiciel à remplacer ou une base à changer de version ? Contactez-nous. Pour commencer, un extrait de l'ancienne base nous montre quelles données passeront telles quelles et lesquelles demanderont des règles de conversion.