Migration Drupal 10 vers 11

Drupal 10 a rendu un immense service à l'écosystème, mais son horizon se précise : sa fin de vie est attendue pour décembre 2026, au moment de la sortie de Drupal 12. Pour la plupart des sites, c'est une excellente nouvelle. Contrairement aux migrations majeures du passé, le passage de Drupal 10 à Drupal 11 ressemble beaucoup plus à une mise à jour de routine qu'à une refonte. Si votre site est tenu à jour, l'opération peut tenir en quelques heures et se résumer, dans les cas les plus favorables, à un composer update validé par votre pipeline.

Cet article explique la timeline de fin de vie de Drupal 10, ce qui change réellement entre Drupal 10 et Drupal 11, à quoi ressemble l'upgrade path, quels modules contrib vérifier en priorité, quels breaking changes anticiper et pourquoi tout cela est sans commune mesure avec les migrations Drupal 7 vers Drupal 11 qui ont marqué la décennie précédente. Le ton est volontairement positif : il y a peu de raisons de redouter ce passage et beaucoup de raisons de le planifier dès maintenant.

La timeline de fin de vie de Drupal 10

Drupal suit désormais un rythme de sortie majeure prévisible, ce qui simplifie énormément la planification. Drupal 11 est disponible depuis 2024 et constitue la version recommandée pour les nouveaux projets comme pour les sites existants. Drupal 12 est attendu fin 2026, et c'est sa sortie qui marquera la fin de vie de Drupal 10.

Ce que signifie la fin de vie. Une fois Drupal 10 en fin de vie, il ne reçoit plus de correctifs de sécurité. Un site qui y reste devient progressivement exposé, et les modules contrib cessent eux aussi de supporter la version. Ce n'est pas un couperet brutal du jour au lendemain, mais c'est une échéance qui mérite d'être inscrite à la feuille de route bien avant décembre 2026.

Pourquoi anticiper plutôt que subir. Migrer pendant que Drupal 10 est encore supporté, c'est travailler sans pression. Vous choisissez votre fenêtre, vous testez tranquillement et vous gardez un filet de sécurité. Attendre la dernière minute, à l'inverse, c'est risquer de devoir gérer en urgence la migration et la fin de support simultanément. La bonne approche consiste à viser une migration sereine au cours de l'année 2026, idéalement bien avant l'automne.

Le bénéfice immédiat de Drupal 11. Passer à Drupal 11 vous repositionne en début de cycle de support, et non en fin. Vous gagnez plusieurs années de tranquillité avant la prochaine échéance, et vous préparez du même coup le terrain pour Drupal 12, dont l'upgrade path s'annonce tout aussi fluide.

Ce qui change entre Drupal 10 et Drupal 11

Les évolutions entre Drupal 10 et Drupal 11 sont réelles, mais elles touchent surtout le socle technique et l'environnement, pas l'architecture de votre site. Voici les changements structurants.

Des dépendances modernisées. Drupal 11 relève les exigences sur ses dépendances de base : une version récente de PHP, de Symfony et de la base de données. Concrètement, il faut que votre hébergement et votre environnement local soient à jour. C'est souvent l'étape qui demande le plus d'attention, mais elle est entièrement maîtrisable et bénéficie aussi aux performances.

Du code obsolète retiré. Drupal 11 supprime des API et des fonctions qui étaient marquées comme dépréciées depuis Drupal 10. Si votre code custom et vos modules contrib étaient déjà conformes aux recommandations de Drupal 10, ils sont prêts. C'est tout l'intérêt du modèle de dépréciation progressive de Drupal : vous avez eu tout le cycle de Drupal 10 pour vous adapter.

Des modules sortis du core. Certains modules historiquement inclus dans le core ont été déplacés vers contrib ou retirés. Ils restent disponibles, simplement il faut les déclarer explicitement comme dépendances si vous les utilisez. Rien d'irréversible, juste un inventaire à faire.

Des évolutions de l'expérience d'édition. Drupal 11 poursuit les améliorations engagées côté contributeur et éditeur, dans la continuité de Drupal 10. Pour vos équipes de contenu, le changement est progressif et ne nécessite pas de réapprentissage.

L'upgrade path : souvent un simple composer update

C'est ici que Drupal 11 surprend agréablement. Depuis Drupal 8, Drupal a adopté un modèle d'évolution continue : il n'y a plus de réécriture de site entre versions majeures. Vos contenus, votre configuration et votre architecture restent en place. La migration consiste à mettre à jour le code et à résoudre quelques incompatibilités, pas à reconstruire.

Sur un site bien maintenu, le scénario idéal ressemble à ceci :

# Vérifier l'état du site avant migration
composer outdated "drupal/*"

# Mettre à jour le core et les dépendances vers Drupal 11
composer require drupal/core-recommended:^11 \
  drupal/core-composer-scaffold:^11 \
  --update-with-all-dependencies

# Appliquer les mises à jour de base de données
drush updatedb

# Reconstruire le cache
drush cache:rebuild

Avant de lancer la commande, un outil est incontournable : Upgrade Status. Ce module analyse votre site et liste précisément ce qui est prêt et ce qui ne l'est pas (compatibilité des modules, code déprécié, exigences d'environnement). C'est votre tableau de bord de migration.

# Installer et lancer l'analyse de compatibilité
composer require --dev drupal/upgrade_status
drush en upgrade_status

Pour le code custom, Drupal Rector automatise une grande partie des corrections en réécrivant les usages d'API dépréciées vers leurs équivalents Drupal 11. Ce qui aurait demandé des heures de relecture manuelle se règle souvent en quelques passes automatisées suivies d'une vérification.

L'enjeu réel n'est donc pas la commande de mise à jour, qui est triviale, mais le travail préparatoire : s'assurer que tous les modules sont compatibles, que le code custom est nettoyé de ses dépréciations et que l'environnement répond aux nouvelles exigences. Une fois ces conditions réunies, la bascule est rapide.

Les modules contrib à vérifier

Dans la quasi-totalité des projets, ce sont les modules contrib qui dictent le calendrier. Un site ne peut migrer que lorsque tous ses modules disposent d'une version compatible Drupal 11. Voici la méthode.

Faire l'inventaire complet. Listez tous les modules contrib installés et leur version. Upgrade Status le fait automatiquement et indique pour chacun le statut de compatibilité Drupal 11.

Mettre à jour avant de migrer. La plupart des modules populaires proposent des versions qui supportent à la fois Drupal 10 et Drupal 11. Les mettre à jour pendant que vous êtes encore sous Drupal 10 lisse l'effort et réduit le saut le jour J.

Traiter les cas particuliers. Pour les rares modules sans version compatible, plusieurs options existent : trouver un module équivalent maintenu, appliquer un patch communautaire en attendant la version stable ou contribuer soi-même le correctif en amont. Les modules abandonnés représentent l'essentiel du travail réel d'une migration, d'où l'intérêt de les identifier tôt.

Réduire la dette. Une migration est l'occasion idéale de retirer les modules devenus inutiles. Moins de dépendances, c'est moins de risques et un upgrade path plus court pour Drupal 12. Notre offre de migration Drupal inclut précisément cet audit de modules et la stratégie de remplacement ou de patch quand c'est nécessaire.

Les breaking changes à anticiper

Le terme breaking changes peut inquiéter, mais dans le contexte Drupal 10 vers 11 il recouvre des éléments bien circonscrits et documentés.

Les exigences d'environnement. C'est le breaking change le plus courant en pratique. Si votre serveur tourne sur une version de PHP ou de base de données trop ancienne, la mise à jour échouera tant que l'environnement n'est pas relevé. À vérifier en tout premier.

Les API dépréciées supprimées. Tout code qui s'appuyait sur des fonctions dépréciées en Drupal 10 doit être ajusté. Drupal Rector et Upgrade Status couvrent l'essentiel de la détection et d'une bonne partie de la correction.

Les dépendances tierces. Certaines bibliothèques externes embarquées via Composer ont changé de version majeure. Si votre code custom les utilise directement, une adaptation peut être nécessaire. Ce cas reste minoritaire sur un site standard.

La configuration des modules sortis du core. Si vous utilisiez un module désormais en contrib, il faut le déclarer explicitement pour conserver le comportement attendu. Sans cela, certaines fonctionnalités peuvent disparaître silencieusement après la bascule.

La règle générale : ces changements sont prévisibles et outillés. Un site testé en pré-production révèle ses points de friction avant la production, et une suite de tests automatisés transforme la validation en quelques minutes de pipeline plutôt qu'en heures de clics manuels.

Pourquoi c'est bien plus simple qu'une migration Drupal 7 vers Drupal 11

Si vous gardez le souvenir d'une migration Drupal 7 vers Drupal 8 ou 9, oubliez-le pour ce passage. Ce sont deux mondes différents.

Une migration depuis Drupal 7 implique une reconstruction complète : nouveau modèle de données, réécriture des modules custom, migration de chaque contenu via l'API de migration, refonte du thème. C'est un projet à part entière qui se compte en semaines ou en mois.

Le passage de Drupal 10 à Drupal 11, lui, repose sur la continuité architecturale introduite depuis Drupal 8. Votre base de données reste la même structure, votre configuration est conservée, vos contenus ne bougent pas et votre thème continue de fonctionner moyennant quelques ajustements mineurs. Vous ne migrez pas un site, vous le mettez à niveau. C'est la différence entre déménager dans une nouvelle maison et repeindre une pièce.

Cette simplicité n'est cependant pas automatique : elle se mérite par une bonne hygiène technique. Un site dont le core et les modules sont restés à jour, dont le code custom suit les recommandations et qui dispose de tests, migre vers Drupal 11 presque sans friction. Un site laissé plusieurs années sans entretien demandera d'abord un rattrapage. C'est tout l'intérêt d'une maintenance Drupal régulière : elle garde le site en permanence à un saut de la version suivante et transforme les migrations majeures en formalités.

Planifier la migration sereinement

La bonne nouvelle d'ensemble est que vous avez le temps et les outils. La fin de vie de Drupal 10 en décembre 2026 laisse une fenêtre confortable pour préparer le terrain, mettre les modules à jour et programmer la bascule au moment qui vous convient. Plus vous anticipez, plus l'opération est simple.

Une démarche réaliste tient en quatre temps : auditer la compatibilité avec Upgrade Status, mettre à jour les modules contrib pendant que Drupal 10 est encore supporté, nettoyer le code custom avec Drupal Rector et valider l'ensemble en pré-production avant de basculer. Avec des tests automatisés en place, chaque étape se vérifie en quelques minutes.

Vous voulez évaluer l'effort réel de votre passage à Drupal 11 et planifier la bascule sans stress ? Parlons de votre projet : un audit de compatibilité et un plan adapté à votre site valent mieux que l'attente de la dernière minute.