Une migration de base de données, c'est quoi (et pourquoi c'est risqué) ?

Une migration est une modification de la structure d'une base de données : ajouter une colonne, renommer un champ, séparer une table en deux. Elle est risquée parce que la base contient déjà les données de vraies personnes, et qu'on ne peut pas simplement « repartir de zéro ».

L'analogie : réaménager une bibliothèque ouverte au public

Imaginez une bibliothèque pleine de livres. Vous décidez de changer le classement : ajouter un rayon « jeunesse », ranger par auteur plutôt que par titre. Si vous le faites mal, des livres se perdent, d'autres se retrouvent au mauvais endroit. Et si les lecteurs continuent d'entrer pendant les travaux, ils cherchent des livres qui ne sont plus là.

Une base de données, c'est cela : des tables (les rayons) remplies de lignes (les livres). La migration réorganise les rayons sans perdre aucun livre.

À quoi ressemble une migration

C'est un petit fichier, écrit dans le code et gardé avec lui, qui décrit un changement précis et daté. Par exemple : « ajouter une colonne telephone à la table des clients ». Chaque environnement (votre ordinateur, l'environnement de test, la production) rejoue ces fichiers dans l'ordre, et se retrouve ainsi avec la même structure.

C'est un gros progrès par rapport aux modifications faites à la main dans un outil : une migration se relit, se teste, et se rejoue.

Pourquoi c'est risqué

• Les données existent déjà. Ajouter une colonne vide est simple. Transformer un champ en deux, ou changer un type, oblige à convertir ce qui est déjà stocké. Une conversion mal pensée peut tronquer ou effacer des valeurs.
• Le code et la base doivent rester d'accord. Si la nouvelle version du code attend une colonne que la base n'a pas encore (ou inversement), l'application plante pendant la transition.
• Certains changements sont lents. Sur une grande table, une modification peut verrouiller la base un moment, et les utilisateurs attendent.
• Revenir en arrière est parfois impossible. Supprimer une colonne efface son contenu pour de bon.

Les précautions qui comptent

1. Une sauvegarde récente, et vérifiée, avant toute migration. Une sauvegarde qu'on n'a jamais essayé de restaurer reste un espoir, pas une garantie.
2. Essayer d'abord ailleurs, sur une copie de la base : c'est le rôle de l'environnement de test, voir Staging et production : pourquoi on teste ailleurs.
3. Avancer par petites étapes. Ajouter la nouvelle colonne, faire écrire le code dans les deux, copier les anciennes données, puis seulement plus tard retirer l'ancienne. Chaque étape est sûre seule.
4. Prévoir le retour en arrière quand c'est possible, et savoir à l'avance ce qu'on fait si ce n'est pas possible.
5. Ne jamais modifier la base de production à la main, hors du code : plus personne ne sait ce qui a été fait.

Pourquoi on y pense tard

Dans un projet monté vite, la base évolue souvent par petites retouches faites au fil de l'eau, sans fichiers de migration. Tout va bien jusqu'au jour où il faut recréer un environnement, ou changer quelque chose sur des données réelles : on découvre alors que personne ne sait comment la base en est arrivée là. Voir aussi Idempotence : appuyer deux fois, payer une fois, un réflexe utile pour des opérations qu'on peut être amené à relancer.

À retenir

Une migration réorganise une base déjà remplie : on la prépare, on l'essaie sur une copie, on la fait par petites étapes, et on a une sauvegarde vérifiée avant de commencer.

Et pour votre produit ?

Si vous reprenez un projet dont la base a évolué sans méthode, la première chose à faire est de comprendre son état réel avant de la toucher. C'est une étape habituelle d'une reprise de projet : lire la structure, vérifier les sauvegardes, mettre les changements sous contrôle. Si vous voulez en parler, nous pouvons échanger 30 minutes.