Migration Drupal 8 vers 11 : le guide

Drupal 8 est en fin de vie depuis novembre 2021. Si votre site tourne encore sur cette version, il ne reçoit plus de correctifs de sécurité officiels depuis plus de quatre ans. Chaque mois qui passe agrandit l'écart technique avec l'écosystème actuel : modules contrib qui ne sont plus testés sur votre version, dépendances PHP obsolètes, compatibilité serveur qui se dégrade. La bonne nouvelle, c'est que le chemin vers Drupal 11 est aujourd'hui bien balisé et que la migration est devenue beaucoup plus prévisible qu'à l'époque du grand saut de Drupal 7 vers Drupal 8.

Ce guide explique pourquoi il faut migrer maintenant, quel chemin emprunter selon votre situation, comment auditer vos modules contrib et custom, à quel effort vous attendre et quels pièges éviter. L'objectif n'est pas de vous faire peur, c'est de vous donner une vision claire pour planifier un investissement qui sécurise votre site et le remet sur les rails de l'évolution continue.

Pourquoi migrer maintenant

Repousser une migration coûte rarement moins cher. Au contraire, l'écart technique s'accumule et chaque report rend la marche suivante plus haute. Voici les raisons concrètes d'agir.

Sécurité. Un site Drupal 8 ne reçoit plus de Security Advisory du core ni de la plupart des modules contrib. Une faille découverte aujourd'hui ne sera pas corrigée sur votre version. Pour un site exposé au public, c'est un risque qui croît avec le temps.

Compatibilité de l'écosystème. Les modules contrib maintenus ciblent désormais Drupal 10 et 11. Les nouvelles fonctionnalités, les correctifs et le support communautaire se concentrent sur les versions actuelles. Rester sur Drupal 8 vous coupe progressivement de cet écosystème vivant.

Dépendances techniques. Drupal 8 repose sur des versions de PHP et de Symfony qui ne sont plus supportées. Vos hébergeurs migrent leurs serveurs, et faire tourner une stack obsolète devient de plus en plus contraignant à mesure que les environnements modernes ne la supportent plus.

Coût croissant de l'immobilisme. Plus on attend, plus le delta entre l'existant et la cible grandit. Une migration anticipée se planifie sereinement. Une migration faite dans l'urgence, après un incident de sécurité, se subit. L'écart de confort entre les deux est considérable.

Investissement, pas dépense. Migrer vers Drupal 11, c'est repartir sur une base supportée jusqu'en 2027 et au-delà, avec un chemin de mise à jour fluide vers les versions suivantes. C'est aussi l'occasion de nettoyer la dette technique accumulée et de moderniser votre stack.

Le chemin de migration

Bonne nouvelle structurante : depuis Drupal 8, les versions majeures s'enchaînent par évolution et non par reconstruction. Le grand chantier de migration de données était celui de Drupal 7 vers Drupal 8. À partir de Drupal 8, le passage d'une version majeure à la suivante consiste essentiellement à mettre à jour le code et à retirer les API dépréciées.

Drupal 8 vers Drupal 9. Drupal 9 est techniquement Drupal 8 débarrassé de son code déprécié, avec Symfony et les autres dépendances mises à niveau. Le travail principal consiste à supprimer l'usage des API dépréciées dans votre code et à mettre à jour vos modules contrib vers leurs versions compatibles. L'outil drupal-rector automatise une grande partie de ces corrections, et upgrade_status dresse l'inventaire de ce qui reste à traiter.

Drupal 9 vers Drupal 10. Même logique. On retire les dépréciations introduites dans la branche 9, on met à jour Symfony et on remplace les composants front retirés du core (CKEditor 4 devient CKEditor 5, le thème Classy disparaît au profit de Starterkit). C'est une étape généralement fluide pour un site dont le code a été tenu propre.

Drupal 10 vers Drupal 11. Encore une fois, le passage se fait par mise à jour du code et nettoyage des dépréciations. Drupal 11 relève les exigences minimales (PHP, base de données) et continue d'élaguer le code legacy.

Deux stratégies s'offrent à vous selon votre situation.

# Vérifier l'état de compatibilité de votre site
composer require drupal/upgrade_status
drush en upgrade_status
# Détecter et corriger automatiquement les API dépréciées
composer require palantirnet/drupal-rector --dev
vendor/bin/rector process web/modules/custom

La première approche, par paliers successifs (8 vers 9, puis 9 vers 10, puis 10 vers 11), est la plus sûre pour un site complexe avec beaucoup de custom. Chaque palier est validé avant de passer au suivant, ce qui isole les problèmes.

La seconde approche, le saut direct vers Drupal 11, est envisageable pour un site relativement standard, avec peu de code custom et des modules contrib tous disponibles en version compatible. On reconstruit alors un environnement Drupal 11 propre vers lequel on importe la configuration et le contenu, plutôt que de faire transiter le site par chaque version intermédiaire. C'est souvent plus rapide quand le site s'y prête. Le bon choix dépend entièrement de votre base de code, et c'est précisément ce qu'un audit Drupal permet de trancher avant de s'engager.

Auditer vos modules contrib et custom

Le cœur du travail de migration se joue sur vos modules. C'est là que se concentrent à la fois l'effort et l'incertitude, donc c'est par là qu'il faut commencer.

Inventaire des modules contrib. Pour chaque module installé, il faut vérifier qu'une version compatible Drupal 11 existe. Trois cas se présentent : une version stable existe (cas idéal), seule une version de développement ou un patch existe (à évaluer) ou le module est abandonné (il faut alors trouver un remplaçant ou internaliser sa fonctionnalité). L'outil upgrade_status produit cet inventaire automatiquement.

Modules désormais dans le core. Bonne surprise fréquente : certains modules contrib que vous utilisiez ont été intégrés au core au fil des versions (Media, Layout Builder, par exemple). Cela réduit votre surface de dépendances contrib et simplifie la maintenance future.

Code custom. Vos modules et thèmes sur mesure sont le poste le plus variable. drupal-rector corrige automatiquement une bonne partie des appels d'API dépréciés, mais tout ne se règle pas en un clic. Les hooks modifiés, les services dont la signature a changé et les plugins front demandent une revue manuelle.

Thème. Les thèmes front custom méritent une attention particulière. Le passage de Twig à des versions plus récentes, l'évolution des librairies et le remplacement de CKEditor peuvent demander des ajustements de templates et de CSS.

# Exemple : déclarer la compatibilité dans votre .info.yml
name: Mon module custom
type: module
core_version_requirement: ^10 || ^11
package: Custom

Un audit sérieux classe chaque module et chaque composant custom selon son effort estimé. C'est ce qui transforme une migration floue en un plan d'action chiffré et priorisé.

L'effort à prévoir

Donner un chiffre universel serait malhonnête : l'effort dépend du volume de code custom, du nombre de modules contrib, de la complexité du thème et de l'état général de la base. On peut toutefois poser des repères réalistes.

Un site standard, bâti principalement sur du contrib bien maintenu avec peu de custom, représente un effort de quelques jours à quelques semaines. L'essentiel du travail consiste à mettre à jour les dépendances, nettoyer les dépréciations et valider.

Un site moyen, avec du custom significatif, un thème sur mesure et quelques modules contrib à surveiller, se situe plutôt sur une échelle de plusieurs semaines. La revue manuelle du code custom et les tests de non-régression pèsent dans la balance.

Un site complexe, multi-sites ou fortement custom, avec des intégrations tierces et des modules abandonnés à remplacer, demande une planification par phases sur plusieurs mois. Ici, l'approche par paliers et un découpage en lots sont généralement préférables.

Ces fourchettes ne remplacent pas un chiffrage réel. Elles donnent un ordre de grandeur pour cadrer la discussion. Notre service de migration Drupal démarre toujours par un audit qui transforme ces fourchettes en estimation précise pour votre site.

Les pièges courants

Une migration qui dérape vient presque toujours des mêmes causes. Les connaître à l'avance permet de les neutraliser.

Sous-estimer le custom. Le contrib se met à jour avec composer update. Le custom, lui, demande une revue ligne par ligne. C'est le poste qui surprend le plus quand il n'a pas été audité sérieusement en amont.

Oublier la configuration. Drupal gère sa configuration en YAML exportable. Une migration mal préparée peut introduire des écarts de configuration entre environnements. Un workflow propre d'export/import de config et un environnement de staging fidèle à la production évitent ces dérives.

Négliger les tests. Sans tests automatisés, valider qu'un site fonctionne après migration relève de la vérification manuelle fastidieuse et incomplète. Mettre en place un socle de smoke tests avant la migration transforme la validation finale en une opération de quelques minutes plutôt qu'en plusieurs jours d'inspection.

Migrer sans nettoyer. Une migration est l'occasion idéale de retirer les modules inutilisés, le contenu obsolète et le code mort. Tout migrer tel quel, dette technique comprise, c'est rater une opportunité et alourdir inutilement le chantier.

Travailler sans filet. Une migration se mène sur une branche dédiée, avec un environnement de staging, des sauvegardes et un plan de rollback. Improviser directement en production n'est jamais une bonne idée sur un chantier de cette ampleur.

Un investissement qui se rembourse

Migrer de Drupal 8 vers Drupal 11, c'est bien plus que rattraper un retard. C'est remettre votre site sur une trajectoire d'évolution continue, où chaque version majeure suivante (Drupal 12, puis 13) devient une simple mise à jour et non un chantier. C'est récupérer le support de sécurité, l'accès à l'écosystème vivant et les nouvelles fonctionnalités du core. C'est aussi l'occasion d'assainir la dette technique accumulée pendant des années.

Une migration bien préparée, fondée sur un audit honnête et un plan par phases, se déroule sans drame. Le risque ne vient pas de Drupal 11, il vient du report indéfini et de l'improvisation. Plus tôt vous planifiez, plus l'opération est confortable.

Votre site est encore sur Drupal 8 et vous voulez un chemin clair vers Drupal 11? On commence par un audit de votre base de code, puis on bâtit un plan de migration par phases adapté à votre stack. Parlons de votre projet.