La suppression d’une colonne commence rarement par du DDL. Elle commence par un incident en production, un ticket de migration resté en suspens ou une alerte de schema drift montrant qu’un service écrit encore dans un champ que tout le monde croyait abandonné.

C’est pourquoi « comment supprimer des colonnes » est en réalité un problème de migration par étapes. L’instruction ALTER TABLE ... DROP COLUMN est la dernière étape, pas la première. Les équipes ont des ennuis lorsqu’elles traitent la suppression d’une colonne comme une tâche de nettoyage plutôt que comme un changement de compatibilité susceptible de casser les lecteurs, les écrivains, les jobs ETL, les modèles BI, les exports et les chemins de rollback.

Un processus de suppression sûr comporte sept étapes :

1. Confirmer que la colonne n’est pas utilisée
   Vérifiez le code applicatif, les modèles ORM, les procédures stockées, les vues, les jobs planifiés, les tableaux de bord, les pipelines CDC et les requêtes ad hoc des analystes. L’usage survit souvent dans un rapport oublié ou un worker en arrière-plan.

2. Vérifier les signaux de schema drift avant de toucher à la production
   Le drift est un signal d’alerte critique. Si les environnements divergent sur la présence de la colonne, sa nullabilité, ses valeurs par défaut ou les attentes en aval, supprimer la colonne creusera cet écart et rendra la panne plus difficile à diagnostiquer.

3. Déprécier avant de supprimer
   Marquez la colonne comme dépréciée dans la documentation du schéma et les notes de migration. Arrêtez d’abord les nouvelles écritures. Dans de nombreux systèmes, conserver les lectures pendant un cycle de release évite des ruptures inutiles.

4. Livrer d’abord les modifications applicatives
   Supprimez les écritures, puis les lectures, puis déployez. Si l’application référence encore la colonne après l’exécution du DDL, la panne est auto-infligée.

5. Sauvegarder et tester le rollback
   Supprimer une colonne est facile. La restaurer avec le bon type, les bonnes contraintes, les bonnes valeurs par défaut et les données historiques, c’est là que la reprise se complique. Testez le chemin de rollback avant d’exécuter le changement.

6. Exécuter la suppression dans une fenêtre contrôlée
   Même un DDL simple peut verrouiller des tables, invalider des plans d’exécution ou provoquer un retard de réplication selon le moteur de base de données et la taille de la table. Le comportement en production compte plus que la syntaxe des manuels.

7. Surveiller le drift et les défaillances de dépendances après le changement
   Surveillez les outils de comparaison de schémas, les journaux d’erreurs, les exécutions ETL et les rafraîchissements de tableaux de bord. Si quelque chose attend encore l’ancienne colonne, le drift post-changement et les erreurs d’exécution le révéleront rapidement.

La syntaxe est la partie facile. La partie difficile consiste à prouver que la suppression de la colonne ne créera pas un décalage silencieux entre le schéma voulu et celui que vos systèmes supposent encore exister.

Détecter le drift avant et après une suppression est plus simple lorsque les changements de schéma sont suivis automatiquement plutôt que comparés à la main. Pour voir comment les ajouts, suppressions et changements de type de colonnes apparaissent dans chaque table surveillée, consultez digna Schema Tracker.

Questions fréquentes

Est-il sûr d’exécuter ALTER TABLE DROP COLUMN directement en production ?

Uniquement une fois le travail préparatoire terminé. L’instruction DROP COLUMN doit être la dernière étape d’une migration par étapes, après avoir confirmé que la colonne n’est pas utilisée, arrêté les écritures, retiré les lectures de l’application et testé un rollback. L’exécuter en premier transforme un nettoyage en panne.

Comment vérifier si une colonne est encore utilisée ?

Cherchez partout où la colonne peut se cacher : code applicatif, modèles ORM, procédures stockées, vues, jobs planifiés, tableaux de bord, pipelines CDC et requêtes ad hoc des analystes. Un rapport oublié ou un worker en arrière-plan est souvent le dernier lecteur, il vaut donc la peine de consulter aussi les journaux de requêtes.

Pourquoi le schema drift compte-t-il avant de supprimer une colonne ?

Si les environnements divergent déjà sur la présence de la colonne, sa nullabilité ou ses valeurs par défaut, une suppression creuse cet écart et rend la panne qui en résulte bien plus difficile à diagnostiquer. Traitez le drift comme un signal d’alerte et alignez les environnements avant de modifier la production, pas après une panne.

Dans quel ordre faut-il effectuer les modifications applicatives et la suppression de la colonne ?

Arrêtez d’abord les nouvelles écritures, retirez ensuite les lectures, déployez ces modifications applicatives et seulement alors exécutez le DDL. Conserver les lectures pendant un cycle de release évite des ruptures inutiles. Si l’application référence encore la colonne au moment où elle disparaît, la panne est entièrement auto-infligée.

Que faut-il surveiller après la suppression d’une colonne ?

Surveillez les outils de comparaison de schémas, les journaux d’erreurs, les exécutions ETL et les rafraîchissements de tableaux de bord. Tout ce qui attend encore l’ancienne colonne échouera vite, sous forme d’erreur d’exécution ou de drift post-changement : une courte fenêtre de surveillance ciblée juste après la suppression révèle donc la plupart des dépendances restantes.