Migrer Drupal 10 sans interrompre votre site en 2026

Le bon scénario dépend du caractère stratégique du site, de sa fréquentation et de votre seuil de tolérance au risque. En pratique, je les combine régulièrement : le blue-green pour la plateforme, le canary pour l'ouverture progressive du trafic, le snapshot pour aligner les données.

1. Blue-Green deployment

Je fais cohabiter deux environnements identiques. Le Blue correspond à votre production actuelle sous Drupal 10. Le Green héberge la nouvelle version en Drupal 11 ou 12, code et contenus déjà transférés. Je passe plusieurs semaines à éprouver le Green sous toutes les coutures. Le jour de la mise en service, je redirige le flux du Blue vers le Green par un simple changement DNS ou une reconfiguration du répartiteur de charge, soit quelques secondes. En cas d'anomalie, le retour arrière est immédiat : il suffit d'inverser la bascule.

Dans quels cas : plateformes très fréquentées, services qui ne supportent aucune fenêtre de maintenance, montées de version lourdes au risque technique marqué. Coût additionnel : une infrastructure doublée pendant 1 à 2 mois.

2. Canary deployment

J'ouvre la nouvelle version au compte-gouttes : 5 %, puis 10 %, puis 50 %, enfin 100 % du trafic sur plusieurs jours. Un répartiteur de charge ou un reverse proxy répartit les visiteurs selon la proportion paramétrée. Je garde l'œil rivé sur les indicateurs en direct (erreurs, temps de réponse, conversions) et, au premier signe de dérive, je referme le robinet à 0 %.

Dans quels cas : sites pour lesquels vous voulez débusquer les régressions sur du trafic authentique avant l'ouverture totale. Il s'articule parfaitement avec le blue-green. Coût additionnel : la brique de supervision et de routage. Durée : 1 à 2 semaines d'ouverture graduelle.

3. Snapshot synchronisé et bascule planifiée

Une option pour les sites moins sensibles ou peu fréquentés. À un horaire arrêté à l'avance (le plus souvent la nuit ou le week-end), je gèle les contenus sous Drupal 10, je prends un instantané de la base, je l'importe sur le Drupal 11/12 déjà préparé, je passe une recette rapide, puis je bascule le DNS. La fenêtre de maintenance annoncée aux internautes oscille entre 15 et 60 minutes, selon le poids de la base.

Dans quels cas : sites dont la fréquentation chute la nuit et le week-end, sans exigence de continuité permanente. C'est le scénario le plus économique, mais il assume une coupure visible. Coût additionnel : négligeable.

4. Réplication bidirectionnelle temporaire

Réservée aux sites qui n'admettent aucune interruption, ce qui reste exceptionnel. Pendant quelques heures, chaque écriture effectuée sur Drupal 10 se recopie en direct sur Drupal 11/12 via un bus de messages ou une couche de synchronisation faite sur mesure. Je bascule le DNS alors que les deux piles fonctionnent encore, et l'ancienne reste consultable en lecture quelques jours. C'est lourd, onéreux, et je ne le recommande que pour des services publics vitaux ou des boutiques en ligne au chiffre d'affaires horaire considérable.

5. Migration progressive par modules ou sous-sites

Cette voie convient aux portails composés de plusieurs sous-sites ou espaces autonomes. Je commence par un sous-domaine témoin (le blog, par exemple), je valide, puis je traite les autres espaces l'un après l'autre sur plusieurs semaines, voire plusieurs mois. Chaque étape étant plus réduite, elle comporte moins de risques et nourrit l'expérience accumulée pour les suivantes.