Réussir le passage à Drupal 11 sereinement

Mon verdict est sans ambiguïté : prenez le cap de Drupal 11 dès maintenant. Voici les trois arguments qui le justifient.

1. L'arrêt de Drupal 10 ne bougera pas

Le 9 décembre 2026, le suivi communautaire de Drupal 10 s'achève et les correctifs de sécurité cessent. Cette échéance ne dépend nullement du calendrier réel de Drupal 12 : même si ce dernier était décalé jusqu'en décembre 2026, la fin de Drupal 10 resterait gravée à cette même date. Tout report de la migration au-delà laisse votre site exposé sans filet de sécurité.

2. De Drupal 11 à Drupal 12, la marche sera basse

Les responsables du cœur ont renvoyé à Drupal 13, vers 2028, les suppressions d'API les plus brutales initialement prévues pour Drupal 12. Résultat : franchir le pas de Drupal 11 à Drupal 12 le moment venu se révélera nettement plus léger que le saut depuis Drupal 10. Choisir Drupal 11 aujourd'hui, c'est en quelque sorte régler deux montées de version d'un seul effort.

3. Les modules contrib ont eu le temps de mûrir

Drupal 11 circule depuis août 2024. À l'heure où j'écris, en mai 2026, l'écosystème contrib dispose donc de près de deux années de recul. La grande majorité des modules incontournables — Webform, Paragraphs, Pathauto, Token, Metatag, Views, Search API et compagnie — proposent des versions stables alignées sur Drupal 11. Quant aux quelques traînards, ils sont repérés et leurs équivalents bien documentés.

Les rares cas où viser Drupal 12 directement se défend

Quelques configurations peuvent justifier d'attendre Drupal 12 : un Drupal 10 tout récent disposant d'une marge confortable au-delà de décembre 2026 (de fait inenvisageable, puisque l'arrêt est figé), un site voué de toute manière à une refonte de fond en comble (autant viser directement Drupal 12), ou encore une plateforme presque dépourvue de code custom avec un budget serré. Ces situations restent l'exception.

C'est le scénario que je rencontre le plus souvent. Sur le papier, ce saut s'effectue sur place, sans rebâtir le site, mais il réclame tout de même une série d'ajustements en amont.

Étape 1 : inventorier les dépréciations

Je commence par exécuter le module officiel Upgrade Status sur l'installation Drupal 10. Son rapport recense les API obsolètes mobilisées par votre code maison ainsi que les modules contrib qui ne tournent pas encore sous Drupal 11. C'est la matière première du plan d'action. Selon le volume de code, traiter chaque alerte demande de quelques heures à quelques journées.

Étape 2 : actualiser les modules contrib

Avant de toucher au cœur, je porte l'ensemble des modules contrib à leur dernière version Drupal 10 compatible Drupal 11 — la plupart proposent une mouture qui supporte les deux. Cette précaution fait fondre les conflits au moment du basculement du cœur. Chaque mise à jour est éprouvée sur un environnement de pré-production avant tout déploiement.

Étape 3 : ajuster les modules custom

Pour chaque module maison signalé par Upgrade Status, je substitue les API obsolètes, je corrige les déclarations info.yml (core_version_requirement: ^10 || ^11), puis je teste. Sur les modules les plus tortueux, je mets en place des tests automatisés avant la bascule afin de débusquer toute régression.

Étape 4 : basculer le cœur

Côté Composer : composer require drupal/core-recommended:^11.0 drupal/core-composer-scaffold:^11.0 drupal/core-project-message:^11.0 --update-with-all-dependencies, enchaîné par drush updatedb et drush cache:rebuild. Quand la préparation a été menée proprement, l'opération en production ne dure que quelques minutes.

Étape 5 : recetter et valider

Je déroule alors les tests de non-régression sur les parcours métier sensibles, je contrôle les droits d'accès, j'éprouve les connexions externes (CRM, ERP, services tiers) et je vérifie l'accessibilité RGAA comme les Web Vitals. Le moindre écart est consigné en vue d'un ajustement après la mise en ligne.

Une migration vers Drupal 11 menée proprement s'articule en quatre temps qui s'enchaînent, à moduler selon l'ampleur du site et vos impératifs métier.

Temps 1 - Diagnostic

• Recensement des modules contrib et vérification de leur statut Drupal 11
• Examen des modules custom via Upgrade Status, complété d'une relecture du code
• Étude de la base (volumétrie, schéma, contenus laissés à l'abandon)
• Cartographie des liaisons externes (CRM, ERP, services tiers)
• Feuille de route chiffrée hiérarchisant priorités et risques repérés

Temps 2 - Mise en condition

• Montée des modules contrib vers des versions compatibles D10 et D11 à la fois
• Reprise du code custom (dépréciations Symfony 7, info.yml, hooks périmés)
• Substitution des modules contrib incompatibles par leurs équivalents
• Bascule de l'environnement de pré-production en PHP 8.3
• Tests automatisés couvrant les parcours métier névralgiques

Temps 3 - Bascule du cœur

• Réplication d'une copie de production sur la pré-production
• Montée du cœur vers Drupal 11 pilotée par Composer
• Lancement de drush updatedb puis contrôles post-bascule
• Recette fonctionnelle exhaustive : parcours visiteurs et liaisons tierces
• Essais de montée en charge pour les sites très sollicités

Temps 4 - Mise en ligne et consolidation

• Scénario de bascule précis (créneau, dispositif d'astreinte, retour arrière)
• Mise en production avec ou sans interruption (voir mon guide migration sans coupure)
• Surveillance rapprochée durant les tout premiers jours en ligne
• Corrections appliquées aux écarts relevés une fois en production
• Bilan de l'opération et documentation transmise pour la TMA

Foncer en production sans pré-production

Tenter la bascule directement sur le site en ligne, sans copie d'essai, reste de très loin le premier déclencheur d'incidents que j'observe. Disposer d'un clone calqué sur la production — même version de PHP, même moteur de base, même jeu de modules — ouvre un terrain où l'on rejoue l'opération en toute tranquillité. Les hébergeurs dignes de ce nom proposent ce type d'espace à la demande, voire compris dans la formule.

Oublier de remplacer les modules sans suite

Une poignée de modules contrib très installés sous Drupal 10 n'ont pas de version Drupal 11 : certains ont cédé la place à des successeurs, d'autres ont été absorbés par le cœur. Faire l'impasse sur ce recensement au moment de l'audit, c'est s'exposer à de mauvaises surprises tardives qui font glisser le planning. Le rapport d'Upgrade Status les pointe pourtant sans exception.

Trop de modules contrib empilés

Nombre de sites Drupal ont vu leur liste de modules contrib enfler année après année sans jamais de ménage. Le moment de migrer est idéal pour dresser l'inventaire et débrancher tout ce qui ne sert plus. Un parc allégé, c'est une migration plus rapide, une exposition aux attaques réduite et des temps de réponse meilleurs.

Couverture de tests trop maigre sur le custom

Le code sur-mesure concentre presque toujours les premiers grains de sable d'une migration. Dans l'idéal, je veux des tests automatisés (PHPUnit, Behat) embrassant les parcours sensibles avant de basculer. Quand un module maison n'en possède aucun, écrire ces tests à cette occasion finit toujours par se rentabiliser au fil du temps.

Minimiser le temps de recette

Migrer vers Drupal 11 ne se résume pas à pousser le cœur. La recette fonctionnelle — parcours visiteurs, permissions, contenus, liaisons tierces, accessibilité, performance — réclame fréquemment davantage de temps que l'opération technique elle-même. Je réserve au bas mot 25 à 40 % de l'enveloppe globale à cette étape.