Comment migrer Drupal 10 sans couper le site en 2026
Oui, on peut migrer Drupal 10 vers 11 ou 12 sans couper le site. La technique principale s'appelle blue-green deployment : deux environnements identiques tournent en parallèle, on bascule le trafic instantanément une fois la nouvelle version validée. La coupure réelle se limite à quelques minutes (synchronisation finale), souvent planifiée de nuit. Pour des sites très critiques, on peut descendre à zéro minute de coupure avec une couche de réplication bidirectionnelle.
Ce guide détaille les cinq approches techniques disponibles, leurs prérequis, le budget supplémentaire associé, et un retour d'expérience terrain sur vie-publique.fr (portail DILA, 2 millions de visites mensuelles). Pour le contexte calendaire de l'échéance fin de vie Drupal 10 au 9 décembre 2026, voir notre roadmap dédiée.
Les cinq approches pour migrer Drupal sans interruption
Selon la criticité du site, le volume de trafic et la tolérance au risque, plusieurs approches sont possibles. Elles se combinent souvent : blue-green pour l'infrastructure, canary pour l'exposition, snapshot pour la synchronisation des données.
1. Blue-Green deployment
Deux environnements identiques tournent en parallèle. Blue = production actuelle en Drupal 10. Green = nouvelle version en Drupal 11 ou 12, avec code et données migrées. Tests exhaustifs sur Green pendant plusieurs semaines. Le jour J, on bascule le trafic du Blue au Green via changement DNS ou reconfiguration du load balancer (quelques secondes). Rollback immédiat possible en inversant la bascule si problème détecté.
Quand l'utiliser : sites à fort trafic, services qui ne peuvent pas tolérer de fenêtre de maintenance, migrations majeures avec risque technique élevé. Surcoût : doublement temporaire de l'infrastructure pendant 1 à 2 mois.
2. Canary deployment
Exposition progressive du trafic à la nouvelle version : 5% puis 10% puis 50% puis 100% sur plusieurs jours. Un load balancer ou un reverse proxy distribue le trafic selon le pourcentage configuré. Les métriques sont surveillées en temps réel (erreurs, latence, conversions) ; au moindre signal de dégradation, on revient à 0%.
Quand l'utiliser : sites où on veut détecter des régressions sur du trafic réel avant l'exposition complète. Se combine très bien avec blue-green. Surcoût : infrastructure de monitoring et de routing. Durée : 1 à 2 semaines d'exposition progressive.
3. Snapshot synchronisé et bascule planifiée
Pour les sites moins critiques ou à faible trafic. À une date convenue (typiquement nuit ou week-end), freeze des contenus sur Drupal 10, snapshot de la base de données, import sur Drupal 11/12 déjà prêt, tests rapides, bascule DNS. Fenêtre de maintenance annoncée aux utilisateurs : 15 à 60 minutes selon la taille de la base.
Quand l'utiliser : sites avec trafic faible la nuit et le week-end, pas d'enjeu de continuité 24/7. C'est le scénario le moins cher mais il introduit une coupure visible. Surcoût : minimal.
4. Réplication bidirectionnelle temporaire
Pour les sites avec zéro tolérance à la coupure (exceptionnel). Pendant quelques heures, les écritures sur Drupal 10 sont répliquées en temps réel sur Drupal 11/12 via un bus de messages ou une couche de synchronisation custom. La bascule DNS se fait pendant que les deux systèmes sont actifs ; le système décommissionné reste disponible en lecture pendant quelques jours. Complexe, coûteux, justifié seulement pour des services publics critiques ou des e-commerces à très fort CA horaire.
5. Migration progressive par modules ou sous-sites
Approche adaptée aux portails avec plusieurs sous-sites ou espaces distincts. On migre d'abord un sous-domaine pilote (par exemple le blog), on valide, puis on migre les autres espaces progressivement sur plusieurs semaines ou mois. Chaque sous-migration est plus petite, moins risquée, et permet d'accumuler de l'expérience pour les suivantes.
Les prérequis techniques pour migrer sans coupure
Infrastructure
- Infrastructure as Code (Terraform, Ansible) pour reproduire à l'identique l'environnement de production en Green.
- Load balancer ou reverse proxy (Nginx, HAProxy, AWS ALB, Cloudflare) permettant la bascule de trafic.
- DNS avec TTL réduit avant la bascule (passer de 3600s à 60s plusieurs jours avant) pour propagation rapide.
- CDN (Cloudflare, CloudFront) permettant le purge rapide des caches après bascule.
Base de données
- Base compatible (MariaDB 10.6+ pour Drupal 11, PostgreSQL 16+ ou MariaDB 10.11+ pour Drupal 12).
- Stratégie de snapshot éprouvée (mysqldump, pg_dump, LVM snapshot selon la stack).
- Plan de synchronisation des contenus créés pendant la phase de test parallèle.
- Validation de la migration de schéma en préproduction avant le jour J (pas juste un dry-run sur un dataset réduit).
Code et modules
- Upgrade Status passé sur le site actuel pour identifier les blockers.
- Drupal Rector pour automatiser les corrections de code déprécié.
- Modules contribués validés en version compatible cible.
- Patches composer-patches revus (obsolètes, mergés upstream, à re-porter).
- Suite de tests automatisés qui couvre les parcours critiques, pour valider la non-régression.
Opérationnel
- Dry-run complet de la procédure de bascule effectué au moins deux fois avant le jour J.
- Monitoring en temps réel sur les deux environnements (erreurs, latence, transactions).
- Plan de rollback documenté avec seuils déclenchant le retour sur Blue.
- Équipe d'astreinte renforcée pendant 24 à 48h post-bascule.
- Communication client préparée : statut page, messages d'information, canaux de support.
Retour d'expérience : vie-publique.fr
Sur vie-publique.fr (portail DILA du gouvernement français), nous avons mené la migration Drupal 9 vers Drupal 11 sur un site à 2 millions de visites mensuelles et 200 000 contenus, sans coupure visible pour les visiteurs. Quelques éléments du chantier.
Paramètres du projet
- Taille : 200 000 contenus, 2M visites/mois, audience grand public jour et nuit.
- Stack : Drupal 9 vers Drupal 11, ElasticSearch pour la recherche, CDN Cloudflare, hébergement souverain européen.
- Contrainte : impossibilité d'annoncer une fenêtre de maintenance visible sur un service public gouvernemental.
- Durée totale : 9 mois entre cadrage et bascule effective.
Approche retenue
- Blue-Green avec infrastructure complète doublée pendant 6 semaines.
- Réindexation ElasticSearch en amont sur Green, pas pendant la bascule.
- Trois dry-runs complets de la procédure de bascule, dont un à J-7.
- Freeze éditorial de 4 heures juste avant la bascule pour permettre la synchronisation finale des contenus.
- Bascule DNS programmée à 3h du matin un dimanche, TTL ramené à 60s une semaine avant.
- Équipe d'astreinte : 4 personnes pendant 48h post-bascule.
Résultats
- Coupure perçue : zéro (le freeze éditorial n'étant pas perçu par les visiteurs, les contenus publics restent accessibles).
- Temps de bascule technique : 4 minutes entre l'instant T0 (bascule DNS) et la confirmation du routing complet sur Green.
- Rollback non utilisé : préparé et testé mais pas déclenché.
- Incidents post-bascule : 3 bugs mineurs détectés et corrigés sous 24h, aucun impact utilisateur final.
Pour plus de détails sur ce chantier, voir l'étude de cas migration Drupal pour le secteur public.
Questions fréquentes
Pour aller plus loin
Fin de vie Drupal 10 : plan de migration 2026
Calendrier EOL 9 décembre 2026, options de migration (D11 maintenant ou attendre D12), matrice de décision, checklist complète.
Drupal 12 en 2026 : sortie, nouveautés, migration
Calendrier Drupal 12 (cible août 2026), prérequis plateforme (PHP 8.5, PostgreSQL 18), modules retirés du cœur, matrice de décision.
Étude de cas : migration vie-publique.fr
Détail du chantier Drupal 9 vers 11 sur un portail gouvernemental à 2M visites/mois. Approche, outils, résultats.
Notre offre Drupal
Migrations Drupal 7 à 12, modules custom, architecture découplée, accompagnement migration sans coupure. Pour le local, Drupal Metz et Drupal Luxembourg.
Une migration Drupal sans coupure à planifier ?
Parlons-en directement.
