Une migration de base de données sans interruption se justifie lorsque le coût d’une coupure dépasse celui de la compatibilité temporaire à maintenir. Pour un SaaS B2B utilisé en continu, privilégiez une évolution progressive du schéma. Pour un outil interne disposant d’une fenêtre de maintenance acceptable, une migration avec arrêt maîtrisé peut rester le meilleur choix.
Le périmètre de cet article est précis : ajouter une contrainte, remplacer une colonne, découper une table ou transformer des données pendant que l’application fonctionne. Changer de moteur ou de fournisseur cloud constitue un autre chantier. Voici comment arbitrer entre maintenance planifiée et migration progressive, estimer l’effort et organiser une bascule sans transformer une évolution fonctionnelle en incident de production.
Faut-il vraiment une migration sans interruption ?
Pas systématiquement. Une migration sans interruption est pertinente si les utilisateurs ne peuvent pas s’arrêter, si les traitements doivent continuer ou si aucune fenêtre commune n’existe entre vos clients. Sinon, une maintenance annoncée, répétée et réversible peut être plus rationnelle.
Commencez par définir ce que signifie « disponible ». Consulter un dossier sans pouvoir le modifier n’offre pas le même service qu’un fonctionnement complet. Un logiciel de préparation de commandes peut tolérer l’arrêt du reporting, mais pas nécessairement celui de la validation des expéditions.
Avant de choisir une méthode, faites valider quatre éléments par le responsable métier :
- Les opérations indispensables : consultation, saisie, paiement, import, synchronisation avec un partenaire.
- La dégradation acceptable : lecture seule, traitement différé ou indisponibilité d’une fonction secondaire.
- La durée maximale admissible : fixée selon l’activité, pas selon une préférence technique.
- Les engagements à vérifier : contrats clients, horaires d’exploitation et dépendances externes.
Ne promettez pas une absence absolue d’impact. Formulez plutôt un objectif mesurable : aucune maintenance visible sur les parcours critiques, avec des limites de latence et d’erreur convenues.
Trois stratégies pour faire évoluer une base en production
Les options suivantes constituent une grille d’arbitrage. Le choix dépend autant de votre capacité d’exploitation que de la transformation SQL envisagée.
| Stratégie | Contexte favorable | Coût principal | Risque à maîtriser |
|---|---|---|---|
| Maintenance avec arrêt des écritures | Outil interne, utilisateurs coordonnables, interruption acceptable | Répétition, communication et immobilisation métier | Dépassement de fenêtre ou reprise des écritures mal contrôlée |
| Lecture maintenue, écritures différées | Consultation prioritaire, opérations pouvant attendre | File d’attente, suivi des demandes et reprise | Doublons, ordre des opérations et incompréhension utilisateur |
| Migration progressive avec coexistence | SaaS utilisé en continu, déploiements échelonnés, fonctions critiques | Compatibilité applicative, reprise des données et contrôles | Divergence entre anciennes et nouvelles représentations |
La lecture seule n’est pas un compromis gratuit. Si vous acceptez des demandes pour les exécuter plus tard, prévoyez leur persistance, leur statut et leur reprise. Sinon, refusez explicitement l’opération plutôt que d’afficher une réussite trompeuse.
Pour un produit SaaS conçu pour plusieurs entreprises clientes, documentez aussi les besoins par segment. Un client international ou un traitement nocturne peut invalider une fenêtre de maintenance qui semblait évidente à l’équipe produit.
Le principe central : séparer expansion, bascule et suppression
La migration progressive repose sur une coexistence temporaire des structures. Le modèle « expand and contract », présenté dans le guide de Prisma sur les évolutions de schéma, consiste à introduire la nouvelle structure, migrer les usages et les données, puis retirer l’ancienne.
Considérons un exemple fictif : un SaaS possède un champ indiquant qu’une intervention est terminée. Le produit doit désormais distinguer une intervention réalisée, contrôlée puis clôturée. Renommer simplement le champ ne résout pas le changement de sens.
Étendre sans casser les usages existants
Ajoutez la représentation cible sans supprimer l’ancienne. Définissez ensuite comment les nouvelles modifications alimentent les deux structures, et laquelle fait autorité pendant la transition.
La question décisive est métier : que signifie une ancienne intervention « terminée » dans le nouveau modèle ? Si l’information historique ne permet pas de distinguer les étapes, utilisez un état de reprise explicite. N’inventez pas une précision absente des données.
Basculer après avoir prouvé la cohérence
Reprenez les données historiques, comparez les résultats, puis activez les nouvelles lectures sur un périmètre limité. Conservez une possibilité de revenir à l’ancienne lecture tant que les nouvelles opérations restent représentables dans l’ancien modèle.
Une nouvelle fonctionnalité peut rendre cette marche arrière impossible avant même la suppression des colonnes. Par exemple, plusieurs états détaillés ne se reconvertissent pas toujours dans un booléen sans perte d’information.
Supprimer lors d’une livraison distincte
Fixez un responsable et des critères de suppression : aucun lecteur ancien identifié, aucun traitement oublié et fin de la période de retour arrière. La documentation de GitLab sur les migrations sans indisponibilité illustre notamment pourquoi certaines suppressions doivent être séparées des changements applicatifs.
Un schéma transitoire sans échéance devient une dette permanente. Inscrivez donc le nettoyage dans le chantier initial, avec son budget et sa validation.
Quels changements peuvent bloquer PostgreSQL ?
La dangerosité d’une migration dépend de l’opération exacte, des verrous requis et de l’activité concurrente. Un changement apparemment mineur dans le modèle applicatif ne garantit pas une opération légère dans PostgreSQL.
La documentation officielle de ALTER TABLE précise les niveaux de verrouillage et les opérations susceptibles de réécrire ou de parcourir une table. Vérifiez toujours ces comportements dans la documentation correspondant à votre version.
| Évolution envisagée | Point à vérifier | Décision recommandée |
|---|---|---|
| Renommer ou supprimer une colonne utilisée | Compatibilité des applications et traitements encore actifs | Introduire une transition plutôt qu’imposer un changement simultané |
| Changer un type de colonne | Réécriture éventuelle, conversion et verrous | Comparer transformation directe et nouvelle colonne avec reprise progressive |
| Ajouter une contrainte | Validité de l’historique et coût de sa vérification | Nettoyer les anomalies et examiner une validation séparée lorsque disponible |
| Créer un index | Blocage des écritures, ressources et durée | Évaluer la construction concurrente et ses contraintes d’exploitation |
Pour certaines contraintes, notamment CHECK et les clés étrangères, PostgreSQL permet de dissocier l’ajout avec NOT VALID de la validation des lignes existantes. Cette possibilité ne s’applique pas indistinctement à toutes les contraintes.
La documentation de CREATE INDEX indique que CONCURRENTLY permet de construire un index sans bloquer les écritures comme une construction standard. En contrepartie, le travail est plus important, l’opération ne peut pas être exécutée dans un bloc transactionnel et un échec peut laisser un index invalide.
Une migration générée par votre ORM reste une proposition à relire. Exigez une revue du SQL et de son mode d’exécution. Un outil qui enveloppe automatiquement chaque migration dans une transaction doit notamment être configuré en conséquence pour ces opérations.
La reprise des données est un traitement de production
Le remplissage de la nouvelle structure, souvent appelé backfill, mérite ses propres règles d’exploitation. GitLab recommande des migrations de données en arrière-plan par lots pour les volumes dépassant ses limites de migration habituelles, avec des mécanismes de régulation de charge.
Pour votre application, exigez au minimum :
- Des lots bornés : une progression identifiable, plutôt qu’une transaction géante.
- Une reprise contrôlée : relancer un lot ne doit ni dupliquer les données ni dégrader leur cohérence.
- Un point de reprise : savoir ce qui est traité, en échec ou encore en attente.
- Une pause possible : arrêter le travail supplémentaire sans arrêter le service métier.
- Une liste d’exceptions : isoler les enregistrements ambigus au lieu de les convertir arbitrairement.
Définissez aussi le traitement des modifications concurrentes. Si un utilisateur modifie une intervention pendant sa reprise, quelle valeur doit gagner ? Prévoyez une vérification de version, une synchronisation transactionnelle ou une autre stratégie explicitement testée. Une copie effectuée à partir d’une lecture ancienne ne doit pas écraser une modification récente.
Dans une même base, envisagez une transaction commune pour les écritures liées. Entre plusieurs systèmes, ne supposez pas une atomicité implicite : prévoyez une livraison fiable des changements et une réconciliation.
Enfin, contrôlez la validité métier, pas seulement le nombre de lignes. Pour notre exemple, vérifiez les transitions d’état, la conservation des historiques et les totaux par entreprise cliente.
Comment tester et autoriser la bascule ?
Une bascule doit être autorisée sur des preuves de compatibilité, de performance et de cohérence. Un test fonctionnel réussi sur une base vide ne couvre pas ces trois dimensions.
Préparez un environnement représentatif : volumétrie, distribution des données, index et scénarios concurrents. Utilisez des données synthétiques ou une copie préparée selon vos exigences de confidentialité. Ne cherchez pas seulement à reproduire la taille totale : une table très sollicitée ou des dossiers particulièrement volumineux peuvent déterminer le risque.
Tester la coexistence des versions
Construisez une matrice explicite :
- ancienne application avec schéma étendu ;
- nouvelle application avant la fin du backfill ;
- anciennes et nouvelles instances actives simultanément ;
- anciens messages consommés par les nouveaux traitements ;
- retour à la version précédente après les premières écritures nouvelles.
Inventoriez les lecteurs moins visibles : exports, outils décisionnels, scripts d’administration, connecteurs et tâches planifiées. Le passage de toute l’interface web à la nouvelle version ne prouve pas que l’ancien schéma est inutilisé.
Fixer les seuils avant l’exécution
Préparez un tableau de bord couvrant latence des parcours critiques, erreurs, attentes de verrous, charge, stockage disponible, retard éventuel des réplicas et progression du backfill. Choisissez les seuils selon votre fonctionnement normal et les engagements du produit.
Pour les commandes sensibles, examinez les paramètres PostgreSQL lock_timeout et statement_timeout, décrits dans la documentation des délais d’exécution. Le premier borne l’attente d’acquisition des verrous, le second la durée d’une instruction. Configurez-les pour la session concernée plutôt que d’imposer une valeur générale sans analyse.
Précisez enfin qui peut interrompre la migration. Une alerte sans décisionnaire ni procédure d’arrêt ne constitue pas une protection opérationnelle.
Retour arrière : distinguer code, données et restauration
Redéployer l’ancienne application n’annule pas les données déjà transformées. Prévoyez trois réponses différentes, selon l’étape atteinte :
- Revenir au code précédent : possible si le schéma et les nouvelles données restent compatibles.
- Corriger en avançant : suspendre la bascule, réparer la transformation et reprendre les lots concernés.
- Restaurer : reconstruire un état antérieur, puis traiter les opérations métier survenues depuis cet état.
PostgreSQL documente la restauration à un instant donné à partir d’une sauvegarde adaptée et des journaux WAL archivés. Cette capacité ne remplace pas une stratégie de retour arrière applicatif.
Pour un SaaS partageant une base entre plusieurs clients, ne supposez pas que restaurer toute la base soit acceptable pour corriger un seul compte. Étudiez une restauration isolée permettant d’extraire puis de réconcilier les données nécessaires.
Le choix du niveau de reprise d’activité d’un SaaS doit donc précéder les transformations irréversibles. Une sauvegarde dont la restauration n’a pas été répétée ne suffit pas à autoriser la bascule.
Quel budget prévoir pour une migration progressive ?
Le budget dépend surtout du nombre d’usages à maintenir compatibles, de la complexité des transformations et des preuves nécessaires avant bascule. La taille de la base compte, mais ne permet pas à elle seule de chiffrer le chantier.
Décomposez l’estimation en livrables plutôt qu’en « script de migration » :
| Poste | Livrable attendu | Facteurs de surcoût |
|---|---|---|
| Diagnostic | Inventaire des dépendances et stratégie retenue | Accès directs non documentés, traitements sans propriétaire |
| Compatibilité | Versions intermédiaires et mécanisme de bascule | Multiples applications, transformations non réversibles |
| Reprise des données | Lots, suivi, réconciliation et gestion des exceptions | Données ambiguës, règles métier complexes |
| Validation et exploitation | Répétition, surveillance, arrêt et retour arrière testés | Environnement peu représentatif, criticité élevée |
| Nettoyage | Suppression des structures et chemins temporaires | Anciens lecteurs difficiles à retirer |
Pour illustrer le calcul, et non donner un tarif de marché : une hypothèse de 15 à 25 jours-personnes, valorisés entre 800 et 1 000 € HT, produit une enveloppe de 12 000 à 25 000 € HT. Ces valeurs sont des hypothèses budgétaires à remplacer par votre estimation et votre coût journalier réels. Elles n’incluent pas automatiquement l’infrastructure temporaire, les interventions hors horaires ou une marge pour les inconnues.
Comparez ensuite le surcoût du scénario progressif au coût complet d’une maintenance : activité suspendue, mobilisation du support, coordination des clients et risque de dépassement. Ne retenez pas le zéro interruption uniquement parce qu’il paraît plus professionnel.
Qui doit porter la migration dans une petite équipe ?
Le responsable technique doit conserver la maîtrise des règles métier, des critères de bascule et du risque accepté. Un renfort externe peut prendre en charge la revue SQL, le backfill ou la préparation opérationnelle, mais pas décider seul de la signification des données.
Désignez un pilote unique, un relecteur technique et un interlocuteur métier. Pendant l’exécution, séparez autant que possible la conduite de la migration de la surveillance du service.
Un renfort ponctuel de l’équipe technique est pertinent si une compétence précise ou de la disponibilité manque. Avant l’intervention, exigez des livrables transférables : procédure, contrôles, critères d’arrêt et consignes de reprise.
Notre recommandation : avec une petite équipe et une coupure acceptable, privilégiez la maintenance répétée. Pour un SaaS critique utilisé en continu, financez la coexistence et la réconciliation. Si la disponibilité est exigée mais que personne ne peut surveiller l’opération, réduisez le périmètre ou renforcez l’équipe avant de lancer.
Questions fréquentes
Faut-il lancer les migrations au démarrage de chaque instance ?
Pour une opération sensible, préférez un processus dédié, exécuté une seule fois et observable indépendamment du déploiement applicatif. Évitez qu’une relance automatique d’instance puisse déclencher sans contrôle une transformation longue.
Un hébergement de base de données managé suffit-il à sécuriser le chantier ?
Ne le considérez pas comme une validation de votre migration. Vérifiez les services réellement inclus au contrat, puis conservez des tests spécifiques pour la compatibilité du code, les transformations métier et les critères de bascule.
Peut-on migrer un seul client à la fois ?
Vous pouvez organiser la reprise des données et l’activation fonctionnelle par client. En revanche, si plusieurs clients partagent les mêmes tables, une modification structurelle de ces tables ne devient pas isolée simplement parce qu’un seul client utilise la nouvelle fonction.
Décider sur la réversibilité, pas sur la promesse
Une migration de base de données sans interruption est un choix d’organisation autant qu’un choix SQL. Retenez-la si la continuité le justifie et si vous pouvez financer la compatibilité temporaire, les contrôles et la surveillance. Sinon, une maintenance maîtrisée vaut mieux qu’une coexistence improvisée.
Pour arbitrer sur votre application, préparez le changement envisagé, les usages critiques, la volumétrie et la coupure acceptable. La séance de consulting IT offerte par Novane permet de confronter ces contraintes à une stratégie de migration et d’identifier les points à vérifier avant de chiffrer le chantier.
