Pourquoi la migration de données diffère du déploiement d'application

Votre pipeline CI/CD tourne parfaitement. Les déploiements d'application sont devenus routiniers. Mises à jour progressives, déploiements blue-green, voire canary releases — votre équipe les gère sans transpirer. Puis quelqu'un dit : « Il faut modifier le schéma de la base de données et déplacer les données de l'ancienne table vers la nouvelle. » Soudain, le silence s'installe. Les questions fusent. Quelqu'un vérifie si les sauvegardes sont récentes. Un autre demande si on peut le faire pendant les heures de maintenance. La confiance qui régnait l'instant d'avant s'évapore.

Ce n'est pas parce que votre équipe manque de compétences. C'est parce que la migration de données est fondamentalement différente du déploiement d'application. Les traiter de la même manière est une recette pour des incidents de production qu'aucun feu vert de pipeline ne peut empêcher.

Le problème de l'état

Les applications sont conçues sans état. Quand vous déployez une nouvelle version, vous remplacez du code qui s'exécute en mémoire ou sur disque. Si la nouvelle version casse, vous revenez à la version précédente. L'ancien code existe toujours dans votre dépôt. Vous le réexécutez. Les utilisateurs peuvent subir quelques minutes d'indisponibilité, mais leurs données restent intactes.

Les bases de données sont l'inverse. Elles conservent l'état — comptes utilisateurs, historiques de transactions, configurations, enregistrements de commandes. Une fois que vous exécutez une migration qui supprime une colonne, les données de cette colonne sont perdues. Une fois que vous modifiez un format de date sur des millions de lignes, ces dates ne reviennent pas toutes seules. Il n'y a pas de bouton « annuler » pour les modifications de données. Vous pouvez restaurer à partir d'une sauvegarde, mais cela signifie perdre toutes les données créées ou modifiées depuis la dernière sauvegarde.

Cette nature irréversible rend la migration de données tendue. Un échec de déploiement d'application est récupérable. Un échec de migration de données est permanent, sauf si vous avez un plan de récupération précis établi avant de commencer.

Le diagramme suivant compare les deux flux côte à côte :

flowchart TD subgraph AppDeploy["Déploiement d'application"] A1[Code] --> A2[Build] A2 --> A3[Test] A3 --> A4[Déploiement] A4 --> A5{Succès ?} A5 -- Oui --> A6[Terminé] A5 -- Non --> A7[Retour à l'ancienne version] A7 --> A6 end subgraph DataMigrate["Migration de données"] B1[Changement de schéma] --> B2[Déplacement de données] B2 --> B3{Succès ?} B3 -- Oui --> B4[Vérification & Réconciliation] B3 -- Non --> B5[Restauration depuis sauvegarde] B5 --> B6[Perte de données possible] end AppDeploy -.->|Réversible| DataMigrate

Impact direct sur les utilisateurs

Quand une application plante, les utilisateurs voient une page d'erreur. Ils peuvent rafraîchir, réessayer plus tard ou contacter le support. C'est agaçant, mais leurs données sont en sécurité.

Quand une migration de données échoue, les dégâts sont invisibles jusqu'à ce que quelqu'un les remarque. Une migration qui calcule mal les soldes de comptes, écrase les adresses de livraison ou supprime l'historique des commandes ne se manifeste pas par une erreur 500. Elle se manifeste quand un utilisateur consulte son compte et trouve des informations incorrectes. À ce moment-là, la migration a déjà eu lieu et les données ont déjà été modifiées. L'utilisateur subit un préjudice réel, pas seulement une gêne.

Cet impact direct sur les données utilisateur exige un niveau de prudence différent. Vous ne pouvez pas traiter une migration de données comme un déploiement de code que vous testez en staging puis promouvez en production. Les enjeux sont plus élevés et les modes de défaillance plus difficiles à détecter.

Durée et contraintes

Les déploiements d'application se terminent généralement en quelques secondes ou minutes. Les mises à jour progressives peuvent remplacer les instances une par une sans indisponibilité notable. Les utilisateurs peuvent même ne pas savoir qu'un déploiement a eu lieu.

Les migrations de données peuvent prendre des heures. Une migration qui met à jour chaque ligne d'une table contenant des millions d'enregistrements va verrouiller des tables, consommer des ressources base de données et ralentir les requêtes. Pendant ce temps, votre application pourrait devoir fonctionner en mode dégradé. Certaines fonctionnalités pourraient être désactivées. Certains endpoints pourraient renvoyer des erreurs. Vous pourriez même devoir mettre l'application hors ligne complètement.

Cette nature longue introduit des problèmes de coordination. Qui surveille la migration ? Que se passe-t-il si elle échoue à mi-parcours ? Comment communiquer l'état au reste de l'équipe ? Ce ne sont pas des questions que vous vous posez habituellement lors d'un déploiement de code.

Ce qui rend une migration de données sûre

Parce que les migrations de données comportent un risque plus élevé, elles nécessitent un ensemble différent de garde-fous. Ce ne sont pas des options supplémentaires. Ce sont les exigences minimales pour traiter les modifications de données avec le sérieux qu'elles méritent.

Idempotence. Votre script de migration doit pouvoir être exécuté plusieurs fois sans danger. S'il échoue à mi-parcours, vous devez pouvoir corriger le problème et le relancer sans provoquer de données en double ou d'état incohérent. Cela implique d'utiliser des vérifications IF NOT EXISTS, des opérations UPSERT, ou une logique conditionnelle qui détecte si une modification a déjà été appliquée.

Capacité de simulation à blanc. Avant de toucher aux données de production, vous devez exécuter la migration dans un environnement sûr qui reflète la production aussi fidèlement que possible. Ce n'est pas la même chose que de tester en staging. Une simulation à blanc doit vous montrer exactement ce qui va changer, combien de temps cela prendra et si des contraintes seront violées.

Stratégie de backfill. Certaines migrations de données impliquent de remplir des données manquantes à partir d'enregistrements historiques. Ce n'est pas une opération unique. Le backfill doit être incrémental, surveillé et réversible. Vous devez pouvoir le mettre en pause, vérifier les résultats et reprendre si tout semble correct.

Réconciliation. Une fois la migration terminée, vous devez prouver que les données sont correctes. Cela implique d'exécuter des requêtes qui comparent l'ancien état avec le nouveau, de vérifier les comptages de lignes, de valider les sommes et de rechercher des anomalies. La réconciliation n'est pas un luxe. C'est le seul moyen de confirmer que la migration a fait ce qu'elle était censée faire.

Une checklist pratique avant toute migration de données

Avant d'exécuter une migration de données en production, parcourez cette liste :

  • Le script de migration est-il idempotent ? Peut-il être exécuté deux fois sans causer de problèmes ?
  • Avez-vous effectué une simulation à blanc sur une copie des données de production ?
  • Savez-vous combien de temps la migration va prendre ? Avez-vous prévu cette fenêtre ?
  • Existe-t-il un plan de rollback qui ne repose pas uniquement sur « restaurer depuis la sauvegarde » ?
  • Avez-vous écrit des requêtes de réconciliation pour vérifier le résultat ?
  • L'équipe sait-elle qui surveille la migration et qui appeler en cas de problème ?

Ce qu'il faut retenir

La migration de données n'est pas un déploiement d'application avec un script différent. C'est une catégorie de travail distincte qui nécessite son propre processus, ses propres garde-fous et sa propre définition de la complétude. La prochaine fois que votre équipe planifie un changement de schéma ou un déplacement de données, arrêtez-vous et demandez : avons-nous couvert l'idempotence, la simulation à blanc, le backfill et la réconciliation ? Si la réponse est non, vous n'êtes pas prêts à exécuter cette migration.