Migration Drupal 9/10 vers 11

Drupal 9 est officiellement en fin de vie depuis novembre 2023. Drupal 10 est encore supporté mais sa fenêtre se réduit. Drupal 11, sorti en août 2024, est désormais la version recommandée pour tous les sites en production. Si vous êtes encore sur Drupal 9 ou en début de Drupal 10, l'upgrade vers Drupal 11 est un chantier qu'il vaut mieux anticiper plutôt que subir.

La bonne nouvelle, c'est que cet upgrade n'a rien à voir avec la migration Drupal 7 vers 11, qui est une vraie migration au sens propre. Ici, on parle d'un upgrade in-place : la base de données reste, les contenus restent, le thème se met à jour, les modules s'adaptent. C'est plus rapide, plus prévisible, et techniquement bien encadré par les outils de l'écosystème Drupal.

Différence fondamentale : migration vs upgrade

Le mot "migration" est utilisé à toutes les sauces, mais techniquement deux choses très différentes coexistent.

La migration Drupal 7 vers Drupal 11

C'est une vraie migration au sens propre. Drupal 8 a marqué une rupture architecturale complète (Symfony, services, gestion de configuration moderne). Il n'existe pas de chemin d'upgrade direct depuis Drupal 7. Ce qu'on appelle "migration" consiste à installer un Drupal 11 vierge, puis à migrer les contenus depuis l'ancien site via l'API de migration. Le thème est entièrement réécrit, les modules custom doivent être portés, les configurations sont reconstruites. Comptez plusieurs semaines à plusieurs mois selon la taille. Notre page migration Drupal détaille spécifiquement ce parcours.

L'upgrade Drupal 9 ou 10 vers 11

C'est un upgrade in-place. Le site reste en place, on met à jour le code et les schémas de base de données via drush updatedb. Pas de migration de contenu, pas de réécriture du thème, pas de redirection à mettre en place. Juste un travail rigoureux sur les dépendances, les API dépréciées et les modules contribués. Comptez en jours ou en semaines selon la complexité, pas en mois.

Ce guide se concentre sur le second cas : l'upgrade Drupal 9 ou 10 vers Drupal 11.

Pré-requis techniques pour Drupal 11

Avant de commencer, vérifiez que votre environnement est compatible avec Drupal 11.

Versions minimales requises

• PHP 8.3 au minimum. Drupal 11 ne tourne plus sur PHP 8.2, encore moins sur PHP 8.1. C'est souvent le premier blocage à régler côté serveur.
• MySQL 8.0+ ou MariaDB 10.6+ ou PostgreSQL 16+. Si vous êtes sur des versions plus anciennes, prévoyez la mise à jour côté hébergement avant l'upgrade Drupal.
• Composer 2.5+ pour gérer les dépendances proprement.
• Drush 13+ pour les opérations de ligne de commande.

Compatibilité des modules contribués

C'est le point le plus délicat. Vérifiez sur drupal.org chaque module contribué installé sur votre site, et notez ceux qui ont une version compatible Drupal 11. Pour ceux qui n'en ont pas encore :

• Si le module est essentiel et activement maintenu, attendez la version compatible (ou contribuez au patch si vous êtes équipé pour).
• Si le module est essentiel mais abandonné, cherchez une alternative communautaire.
• Si le module est secondaire, désactivez-le et reportez la décision après l'upgrade.

L'outil Upgrade Status (lui-même un module Drupal) donne en quelques minutes un rapport complet sur l'état de compatibilité de votre site avec Drupal 11. C'est par lui qu'on commence systématiquement.

La méthodologie d'upgrade pas à pas

Étape 1 : Préparer un environnement de staging

Aucun upgrade ne se fait en direct sur la production. Clonez votre site sur un environnement de staging représentatif (même version PHP, même version de base de données, mêmes modules activés, contenu récent). C'est sur cet environnement que vous allez tester l'upgrade complet, mesurer la durée, identifier les blocages, valider la non-régression fonctionnelle.

Étape 2 : Installer Upgrade Status et faire le diagnostic

composer require drupal/upgrade_status --dev
drush en upgrade_status -y

Ouvrez ensuite le module dans l'interface admin Drupal et lancez l'analyse complète. Vous obtenez un rapport détaillé :

• État de chaque module contribué (compatible D11, incompatible, abandonné).
• Liste des appels d'API dépréciés dans le code custom.
• Estimation de la charge de travail à fournir.

Ce rapport est votre feuille de route. Travaillez-la en priorité avant tout composer update.

Étape 3 : Utiliser Rector pour les modules custom

Rector est un outil d'analyse et de réécriture automatique de code PHP. Drupal fournit un set de règles spécifiques (Drupal Rector) qui automatise une grande partie des modifications nécessaires pour passer aux nouvelles API.

composer require palantirnet/drupal-rector --dev
vendor/bin/rector process web/modules/custom

Rector ne fait pas tout, mais il remplace mécaniquement la majorité des appels d'API dépréciés par leur équivalent moderne. Le travail manuel restant est plus ciblé et plus rapide.

Étape 4 : Mettre à jour les dépendances Composer

Une fois les modules custom propres et les modules contribués vérifiés, lancez la mise à jour des dépendances.

composer require 'drupal/core-recommended:^11' 'drupal/core-composer-scaffold:^11' 'drupal/core-project-message:^11' --update-with-all-dependencies
composer update

Si Composer hurle sur des conflits, c'est qu'un module contribué n'a pas de version Drupal 11 ou que des dépendances tierces sont incompatibles. Revenez à l'étape 2 pour identifier précisément le module bloquant.

Étape 5 : Lancer les mises à jour de base et le rebuild

drush updatedb -y
drush cache:rebuild
drush config:export -y

Le updatedb exécute les hooks d'update de chaque module qui en a, ce qui peut prendre du temps sur des sites volumineux. Le cache:rebuild reconstruit l'arbre de routes, les services, les définitions de plugins. Le config:export capture l'état de configuration mis à jour, à committer ensuite dans Git.

Étape 6 : Tester systématiquement

Sur staging, parcourez méthodiquement :

• Toutes les pages clés (accueil, types de contenu principaux, formulaires, recherche).
• Le back-office complet (création de contenu, configuration, utilisateurs).
• Les fonctionnalités métier spécifiques.
• Les intégrations externes (CRM, paiement, analytics).
• Les commandes Drush utilisées en routine (cron, exports, imports).
• Les tests automatisés s'ils existent.

Notez tous les écarts, corrigez-les sur staging, validez à nouveau. Ne passez en production que quand staging est stable.

Étape 7 : Mise en production

Sauvegarde complète préalable (fichiers + base), bascule planifiée hors heures de pointe, exécution de la même séquence qu'en staging, monitoring renforcé pendant les premières heures, vérification immédiate des indicateurs critiques (disponibilité, temps de réponse, taux d'erreur).

Pièges courants à éviter

Sauter l'étape Upgrade Status

C'est la meilleure manière de découvrir en plein composer update qu'un module essentiel n'a pas de version Drupal 11 et qu'il bloque tout. Faites le diagnostic avant.

Mélanger upgrade et refonte

Un upgrade technique et une refonte fonctionnelle sont deux projets différents. Mélanger les deux multiplie les variables et complique le diagnostic en cas de problème. Faites l'upgrade d'abord, validez la stabilité, puis attaquez la refonte si elle est nécessaire.

Négliger les modules custom

Les développeurs internes ont parfois écrit des modules custom il y a longtemps, sans les maintenir. Ces modules sont souvent les plus piégeux à l'upgrade parce qu'ils utilisent des API très anciennes ou non documentées. Allouez-leur du temps explicite dans le planning.

Oublier les bibliothèques tierces

Les bibliothèques JavaScript du thème, les CDN, les snippets externes : tout ça peut tomber au moment de l'upgrade pour des raisons indépendantes de Drupal lui-même. Vérifiez les versions de jQuery, Bootstrap, et autres frameworks que vous utilisez.

Ne pas tester les commandes en ligne

Si votre site a des cron jobs Drush ou des scripts d'intégration, testez-les explicitement. Les API changent aussi côté Drush, et un script qui marchait hier peut échouer silencieusement après l'upgrade.

Estimation de charge réaliste

Pour donner des ordres de grandeur sur la base de projets récents :

• Site éditorial standard, 5 à 10 modules contribués, 1 module custom léger : 2 à 4 jours de travail.
• Site institutionnel, 15 à 25 modules contribués, plusieurs modules custom : 5 à 10 jours.
• Site complexe avec multisite, 30+ modules contribués, intégrations externes : 10 à 20 jours, voire plus.

Si vous démarrez tôt (avant que des modules essentiels ne perdent leur support), l'upgrade reste un chantier maîtrisable. Plus vous attendez, plus la situation se complique parce que les modules abandonnés s'accumulent et les solutions de contournement deviennent rares.

Pour aller plus loin, notre page migration Drupal détaille la méthodologie complète, et notre forfait de maintenance Drupal inclut la gestion proactive des upgrades majeurs pour éviter d'accumuler du retard sur les versions du CMS.

En résumé

L'upgrade Drupal 9 ou 10 vers Drupal 11 est techniquement bien encadré par les outils de l'écosystème : Upgrade Status pour le diagnostic, Rector pour la réécriture automatique, Composer et Drush pour le déploiement. La méthodologie est éprouvée et reproductible.

Le principal facteur de risque, c'est le retard accumulé. Un upgrade fait à temps prend quelques jours. Le même upgrade fait deux ans trop tard, sur un site dont la moitié des modules ne sont plus maintenus, devient un projet de plusieurs semaines parfois proche d'une refonte. La règle est simple : ne laissez jamais une version majeure de retard sur un site en production critique.