Ce que change Drupal 11 par rapport aux versions précédentes
Drupal 11, sorti en juillet 2024, marque une rupture plus significative que le passage de Drupal 9 à 10. Plusieurs couches techniques ont été profondément remaniées, et les équipes qui l'abordent comme une mise à jour mineure s'exposent à de mauvaises surprises.
Les prérequis techniques à vérifier avant de commencer
Le premier point de blocage est souvent l'environnement serveur. Drupal 11 exige PHP 8.3 minimum, une version que beaucoup d'infrastructures en production n'ont pas encore adoptée. Il s'appuie également sur Symfony 7 et PHPUnit 10, ce qui impacte directement les tests automatisés et l'outillage de développement. Avant même de toucher au code Drupal, il faut donc auditer l'infrastructure : version de PHP, configuration Apache ou Nginx, compatibilité de la base de données (MySQL 8.0+ ou MariaDB 10.6+ sont requis).
Autre vérification critique : la compatibilité de vos modules contributed. La communauté Drupal a globalement bien suivi, mais certains modules de niche, ou des modules fortement personnalisés, n'ont pas encore de version stable pour D11 au moment où vous lancez votre projet. Identifier ces dépendances dès le départ, c'est éviter de découvrir un module bloquant à J-2 de la mise en production.
Ce qui disparaît avec Drupal 11
Drupal 11 achève le nettoyage amorcé avec D10 : toutes les APIs marquées "deprecated" dans les versions précédentes ont été supprimées. Cela concerne notamment des hooks et des fonctions qui existaient depuis Drupal 7 ou 8 et qui avaient été maintenus par compatibilité. Si votre site repose sur du code custom ancien (ce qui est fréquent sur des plateformes de 5 à 10 ans) ces suppressions peuvent générer des erreurs en cascade. Le seul moyen de le savoir à l'avance est un audit de code complet.
Les 5 étapes d'une migration Drupal 11 sans risque
Étape 1 - Auditer l'existant avant de toucher quoi que ce soit
Commencer une migration Drupal 11 par un audit exhaustif de la plateforme actuelle est l’idéal. Cela signifie inventorier tous les modules actifs (contrib et custom), identifier ceux qui n'ont pas de version D11 compatible, cartographier les personnalisations de thème et les hooks custom, et évaluer l'état de la base de code. Cet audit, c'est du temps investi qui évite des semaines de débogage post-migration. Chez nous, cette phase produit un rapport structuré qui devient la feuille de route technique du projet.
Étape 2 - Monter un environnement de staging dédié
Peut-on tester la migration sur un environnement de développement existant ?
Non et c'est l'une des erreurs les plus courantes. Un environnement de staging dédié à la migration doit être une copie exacte de la production : même configuration serveur, même base de données anonymisée, même version de PHP cible. Effectuer les tests sur un environnement "approximatif" fausse les résultats et crée une fausse confiance. Le staging doit également être isolé du reste des développements en cours pour éviter les interférences. On ne migre jamais directement en production, même pour un site "simple".
Étape 3 - Mettre à jour les dépendances dans le bon ordre
Dans quel ordre procéder aux mises à jour ?
L'ordre compte autant que les mises à jour elles-mêmes. La séquence que nous suivons : mise à jour de Drupal core d'abord, puis les modules contrib un par un en vérifiant les logs d'erreur à chaque étape, puis le code custom. Utiliser Composer est indispensable pour gérer les dépendances proprement. Les mises à jour groupées ("tout en une fois") sont à proscrire : elles rendent le débogage impossible en cas d'erreur. Chaque étape doit être suivie d'une passe de tests fonctionnels sur les fonctionnalités critiques du site.
Étape 4 - Gérer les modules contrib non compatibles
Que faire si un module essentiel n'a pas encore de version Drupal 11 ?
Trois options selon les cas. Première option : attendre (si le module est en cours de portage actif par ses mainteneurs, surveiller les releases et décaler la migration si le délai est raisonnable).
Deuxième option : remplacer (certains modules contrib ont des alternatives compatibles D11 qui remplissent la même fonction, parfois mieux).
Troisième option : forker ou réécrire (si le module est critique et sans alternative, il faut intervenir sur le code).
C'est l'option la plus coûteuse, mais parfois inévitable. Dans tous les cas, cette décision doit être prise en amont, dans la phase d'audit, pas pendant la migration.
Étape 5 - Valider, documenter, basculer en production
Comment sécuriser la mise en production finale ?
La mise en production est la dernière étape, pas l'unique moment de vérité. Avant de basculer, nous procédons à une recette complète sur staging avec les équipes métier (pas seulement technique : les utilisateurs finaux détectent des anomalies que les développeurs ne voient pas). Un plan de rollback doit être préparé et testé : si quelque chose se passe mal en production, vous devez pouvoir revenir à l'état précédent en moins d'une heure. La migration en production se fait idéalement en dehors des heures de pointe, avec une supervision active dans les 48 heures qui suivent.
Les erreurs les plus fréquentes et comment les éviter
Nous intervenons régulièrement en mode "pompier" sur des migrations qui ont mal tourné. Les causes sont presque toujours les mêmes.
Sous-estimer le scope du projet
Une migration Drupal 11 sur un site complexe n'est pas une affaire de quelques jours. Sur des plateformes multi-sites ou avec un fort volume de code custom, il faut compter plusieurs semaines de travail. La pression calendaire est souvent ce qui pousse les équipes à sauter des étapes avec les conséquences que l'on imagine.
Négliger les tests de régression
Migrer vers D11 sans suite de tests automatisés, c'est avancer à l'aveugle. Chaque fonctionnalité critique doit être couverte par des tests qui tournent à chaque étape de la migration. Ce n'est pas du luxe : c'est ce qui permet de détecter une régression au moment où elle se produit, pas trois semaines après.
Ignorer la dette technique
Une migration est souvent l'occasion de nettoyer des modules désactivés mais jamais désinstallés, des configurations orphelines, du code mort. Profiter de la migration pour traiter cette dette est un investissement qui facilite les migrations futures et améliore les performances et la sécurité du site à court terme.
Oublier la formation des équipes
Drupal 11 introduit des changements dans l'interface d'administration et dans certains workflows éditoriaux. Les équipes métier doivent être informées, et dans certains cas formées, avant la bascule en production. C'est souvent l'étape oubliée.
Ce que nous faisons fait chez Parker & Parker
Nous accompagnons des organisations publiques et privées dans leurs migrations Drupal depuis très longtemps. Notre approche de la migration vers Drupal 11 repose sur trois convictions.
D'abord, aucune migration ne se ressemble. Un intranet de 500 utilisateurs sur D9, un portail institutionnel multi-sites sous D10 avec une couche headless, ou une plateforme de services avec des intégrations SI complexes : chacun de ces projets demande une analyse spécifique. Nous refusons les "packages migration" standardisés qui ignorent la réalité de votre environnement.
Ensuite, la migration est aussi une opportunité. Nous profitons systématiquement de ces chantiers pour revoir l'architecture des contenus, optimiser les performances, et intégrer des pratiques de sécurité renforcées. Nos clients repartent avec une plateforme plus robuste, pas simplement à jour.
Enfin, nous ne disparaissons pas après la mise en production. Notre accompagnement post-migration couvre la surveillance technique, le traitement des anomalies résiduelles et la montée en compétences des équipes internes. Parce qu'une migration réussie, c'est aussi une équipe capable d'entretenir ce qui a été livré.
Contactez-nous pour un premier échange ou consultez nos réalisations Drupal
FAQ - Migration vers Drupal 11
Faut-il obligatoirement passer par Drupal 10 avant de migrer vers Drupal 11 ?
Oui, si vous êtes encore sur Drupal 9. Il n'existe pas de chemin direct de D9 vers D11 : la migration se fait en deux temps, D9 → D10, puis D10 → D11. Chaque saut de version implique ses propres vérifications. Si vous êtes sur Drupal 10, la migration vers D11 est plus directe, mais nécessite quand même un audit préalable.
Combien de temps prend une migration vers Drupal 11 ?
Cela dépend de la complexité de votre site. Sur un site Drupal 10 relativement standard, avec peu de modules custom, comptez deux à quatre semaines de travail effectif. Sur une plateforme multi-sites avec des intégrations SI et un fort volume de code custom, la migration peut prendre deux à quatre mois. La phase d'audit initial est ce qui permet d'avoir une estimation fiable.
Drupal 11 est-il compatible avec une architecture headless ?
Oui, et Drupal 11 améliore même le support du headless avec des évolutions sur l'API JSON:API et l'outillage autour de Decoupled Drupal. Si vous utilisez déjà une architecture découplée en D10, la migration est généralement fluide sur ce plan-là. Les points d'attention restent les mêmes : modules contrib compatibles et gestion des dépendances frontend.
Quel est l'impact sur le SEO d'une migration Drupal 11 ?
En soi, migrer vers Drupal 11 n'a aucun impact SEO négatif si la migration est bien conduite. Les URLs ne changent pas, la structure de contenu est préservée. En revanche, une migration ratée (temps d'indisponibilité prolongé, erreurs 500, pages cassées) peut avoir un impact réel sur le positionnement. C'est une raison supplémentaire de ne pas précipiter la bascule en production.
Peut-on migrer vers Drupal 11 en maintenant le site en production ?
Techniquement oui, mais c'est une pratique à risque que nous déconseillons sur des sites à fort trafic ou à enjeux critiques. La bonne pratique est de travailler sur un environnement de staging et de basculer lors d'une fenêtre de maintenance planifiée, en informant les utilisateurs et en préparant un plan de rollback. La continuité de service doit être assurée, pas improvisée.
Vous envisagez une migration vers Drupal 11 ?
Avant de lancer le chantier, prenons le temps de cadrer correctement le projet. Nous proposons un audit de compatibilité initial qui dresse un état des lieux précis de votre plateforme et identifie les risques réels de votre migration. C'est la base d'un projet maîtrisé et d'une bascule sereine.
