Ce qu’il faut retenir
- Un rollback applicatif ne restaure pas automatiquement les données ni le schéma précédent.
- Ajouter, migrer et retirer en plusieurs étapes préserve une fenêtre de compatibilité.
- La recette doit faire écrire la nouvelle version, puis vérifier que l’ancienne fonctionne encore dans les limites prévues.
Le nouveau binaire échoue. L’équipe redéploie le précédent, mais celui-ci cherche une colonne qui vient d’être supprimée. Le bouton de retour existe ; le service ne repart pas. La réversibilité doit être conçue dans la relation entre application, données et schéma. Elle se démontre avant la mise en production, avec les écritures que la nouvelle version peut produire.
Trois retours qui ne se confondent pas
Le rollback du code redéploie une ancienne version. Le rollback du schéma inverse certaines transformations. La restauration des données revient à un état historique et peut perdre des modifications légitimes. Ces opérations ont des conséquences différentes. Supprimer la colonne ajoutée ne suffit pas si la nouvelle application a déjà modifié le sens des données existantes.
Une migration dite down peut reconstruire une structure vide sans récupérer son contenu. Elle peut aussi échouer lorsque de nouvelles valeurs ne respectent plus l’ancien format. Il faut nommer les pertes et les conditions, pas affirmer qu’une commande inverse rend tout réversible. Un plan de correction vers l’avant peut être préférable si l’application sait encore lire le schéma étendu.
Les contrats entre API et applications s’appliquent ici aux données persistantes. Les clients, traitements de fond et anciennes instances constituent aussi des consommateurs du schéma. Une migration compatible avec la seule nouvelle route web peut casser une tâche nocturne ou un outil de reporting.
Ajouter avant de remplacer
Le modèle expansion-transition-retrait crée d’abord une structure que les deux versions peuvent tolérer. Il déploie ensuite le code capable de gérer l’ancien et le nouveau format. Les données sont migrées, les lectures basculent et l’ancien chemin est retiré après observation. La dernière étape ferme la fenêtre de retour ; elle mérite une décision distincte.
Exemple hypothétique : un service remplace une chaîne libre adresse par plusieurs champs structurés. Il ajoute les nouvelles colonnes sans supprimer l’ancienne. Une version transitoire sait lire l’ancien format et écrire selon une politique définie. Une migration de données remplit les champs lorsque l’analyse est fiable et conserve les cas ambigus pour traitement. Découper au premier espace ne constitue pas une conversion correcte d’adresse.
La double écriture exige une règle sur la source de vérité. Si deux chemins modifient alternativement des formats différents, ils peuvent diverger. Une transaction peut maintenir les champs ensemble lorsqu’ils sont dans la même base. Les exceptions sont tracées et rapprochées. La stratégie doit indiquer comment l’ancienne application interprète les écritures nouvelles pendant un éventuel retour.
Le DDL est aussi une opération de charge
La documentation PostgreSQL 17 d’ALTER TABLE décrit les actions et leurs contraintes de verrouillage. Certaines opérations demandent un verrou important, même lorsqu’elles semblent petites dans le code de migration. Un schéma correct peut donc causer une indisponibilité par attente. Le volume, les transactions longues et les écritures concurrentes changent le comportement réel.
La création d’index concurrente est une possibilité spécifique dont PostgreSQL documente les limites, notamment son exécution hors bloc transactionnel. Tous les outils de migration ne la traitent pas automatiquement. Une opération qui échoue peut laisser un état à inspecter ; relancer la même ligne sans connaître cet état ne suffit pas.
Les délais d’attente sont bornés afin qu’une opération n’immobilise pas la chaîne pendant une durée indéfinie. Pour une migration de données volumineuse, des lots et des points de reprise limitent la pression, mais nécessitent un contrôle de progression. Les valeurs de taille de lot se mesurent sur un volume représentatif ; les performances d’une base de développement vide ne prouvent rien sur la production.
Le test décisif : nouvelle écriture, ancien lecteur
- Reconstituer un environnement isolé avec une forme et un volume de données représentatifs.
- Appliquer l’expansion en exécutant simultanément les opérations usuelles.
- Déployer la version transitoire et créer des données dans tous les chemins nouveaux.
- Redéployer l’ancienne application autorisée au retour, sans restaurer artificiellement la base.
- Vérifier lectures, écritures, tâches asynchrones et intégrations.
- Mesurer ce qui a été perdu, retardé ou rendu incompatible ; corriger avant de fermer la fenêtre.
Dans le scénario d’adresse, l’ancienne version doit continuer à présenter une valeur valide après l’écriture structurée. Si un nouveau champ autorise un contenu impossible à reconstruire dans l’ancien format, le retour est limité à certains usages ou nécessite une correction. La restriction est écrite. Dire que la migration « passe les tests » sans cette définition ne donne pas une garantie exploitable.
Décider la fenêtre de retour
| Étape | Ancienne application | Condition de passage |
|---|---|---|
| Expansion | Doit rester opérationnelle | Lecture et écriture vérifiées |
| Transition | Retour encore prévu | Données nouvelles interprétables |
| Retrait | Compatibilité éventuellement fermée | Décision explicite et nouvelle procédure de reprise |
Les effets externes survivent au rollback
Une migration peut produire des webhooks, recalculer des factures ou déclencher des notifications. Une restauration locale ne retire pas ces effets chez le destinataire. Les migrations de données neutralisent les déclenchements non voulus ou utilisent une politique métier contrôlée. La reprise conserve les identifiants nécessaires à la réconciliation des opérations déjà réalisées.
Les systèmes d’automatisation marketing illustrent le piège : un changement de segment peut envoyer une campagne irréversible, puis un retour de base remet le segment initial. Les utilisateurs ont néanmoins reçu le message. Le plan traite séparément le schéma, l’état métier et les effets externes.
Donner des critères d’arrêt à l’opérateur
Le runbook décrit les verrous attendus, la durée estimée, les erreurs acceptables et les seuils d’arrêt. Il indique ce que l’opérateur peut annuler sans aggraver l’état, puis la méthode de diagnostic après interruption. Une interruption pendant une migration non transactionnelle demande une lecture de l’état réellement atteint avant une reprise. Le statut du pipeline n’est pas cette lecture.
Le responsable choisit une sauvegarde éprouvée pour les situations où les données doivent être restaurées, et un rollback de code pour celles où la compatibilité permet une reprise sans perte. Le coût de ces options entre dans le budget d’exploitation. Une option rapide mais non testée ne doit pas être comptée comme disponible.
La prochaine action utile consiste à prendre la prochaine migration destructive et à la scinder en deux déploiements. Tester ensuite le retour après de vraies écritures nouvelles, dans un environnement isolé, révèle la fenêtre de compatibilité réellement obtenue.
Sources et références
Mise à jour du 1er octobre 2026 : références vérifiées à cette date. Les mécanismes décrits sont durables ; les options exactes restent à vérifier dans la version du produit utilisée.
- PostgreSQL 17 — ALTER TABLE — transformations du schéma et verrouillages
- PostgreSQL 17 — CREATE INDEX — création concurrente et contraintes transactionnelles
