Votre site tourne encore sur Drupal 9. Le support est terminé depuis novembre 2023. Et vous vous posez la question depuis des mois : par où commencer ? Combien de temps ça prend ? Est-ce qu'on peut se permettre d'attendre encore ?
Ce guide répond à toutes ces questions — étapes par étapes, sans jargon superflu. Il s'adresse aux DSI et responsables IT qui doivent piloter un projet de migration Drupal et doivent convaincre en interne.
Pourquoi migrer vers Drupal 11 maintenant — et pas dans six mois
Drupal 9 a atteint sa fin de vie (EOL) le 1er novembre 2023. Cela signifie que toute faille de sécurité découverte depuis cette date ne sera pas corrigée par la communauté. Votre site est exposé.
Drupal 10 a lui aussi une durée de vie limitée : son support prend fin en décembre 2025. Autrement dit, si vous migrez vers Drupal 10 aujourd'hui, vous entamez une migration incomplète qui vous demandera un nouvel effort dans moins d'un an.
La bonne cible en 2026, c'est Drupal 11.
Drupal 11, sorti en juillet 2024, apporte :
- PHP 8.3+ requis : performances significativement améliorées (jusqu'à 25 % de gain sur certaines workloads)
- Symfony 7 : stack moderne, mieux maintenue, meilleure sécurité par défaut
- Suppression des API dépréciées : base de code plus propre, dette technique réduite
- CKEditor 5 : éditeur enrichi nativement intégré, sans plugin tiers
- Amélioration de l'expérience d'administration : Claro comme thème admin par défaut, navigation contextualisée
Pour les DSI : la migration n'est pas une dépense, c'est une réduction du risque et un investissement dans la longévité de la plateforme.
Ce que migration Drupal 9 → 11 implique techniquement
Contrairement à Drupal 7 → 8 (qui était une réécriture totale), la migration Drupal 9 → 10 → 11 suit un chemin de mise à niveau incrémentale. Vous n'abandonnez pas votre base de code : vous la modernisez.
Le chemin officiel recommandé est :
Drupal 9 → Drupal 10 → Drupal 11Il est techniquement possible de sauter directement de 9 à 11 sur un site peu personnalisé, mais dans la majorité des projets réels (modules contrib, thème sur mesure, intégrations tierces), il est plus sûr de procéder en deux temps.
Ce qui change entre Drupal 9 et Drupal 11
| Élément | Drupal 9 | Drupal 11 |
|---|---|---|
| PHP minimum | 7.4 | 8.3 |
| Symfony | 4/5 | 7 |
| CKEditor | 4 | 5 |
| jQuery UI | Inclus | Supprimé |
| Bootstrap 3 | Utilisé dans certains thèmes | Incompatible sans mise à jour |
| API dépréciées Drupal 9 | Présentes | Supprimées |
Implication : tout module contrib ou code custom qui utilisait des API dépréciées devra être mis à jour ou réécrit. C'est là que se cache l'essentiel de la charge de travail.
Les 6 étapes clés d'une migration Drupal 9 vers 11
Étape 1 — Audit du site existant (1 à 3 jours)
Avant toute chose : faites l'inventaire. Un audit complet couvre :
- Modules contrib installés : sont-ils compatibles Drupal 11 ? Ont-ils une version maintenue ?
- Code custom : thème sur mesure, modules développés en interne, hooks personnalisés
- Intégrations tierces : CRM, ERP, outils marketing, APIs externes
- Contenu : volume de nœuds, taxonomies, types de champs, media
- Performance actuelle : temps de chargement, score Core Web Vitals — base de comparaison post-migration
Outil indispensable : Upgrade Status (drupal/upgrade_status). Ce module analyse votre site et liste tous les éléments incompatibles avec la version cible. Installez-le, lancez l'analyse, exportez le rapport.
Conseil DSI : exigez ce rapport dès le démarrage du projet. Il est la base de chiffrage fiable. Toute estimation de charge sans cet audit est approximative.
Étape 2 — Mise à jour des dépendances et du code custom (variable : 2 jours à 4 semaines)
C'est l'étape la plus variable — et la plus sous-estimée.
Pour les modules contrib :
- Vérifier sur drupal.org que la version Drupal 11 est disponible et stable
- Mettre à jour via Composer :
composer require drupal/[nom_module]:^[version_d11] - Certains modules ont été abandonnés : identifier les alternatives (ex. certains modules jQuery UI ont des successeurs natifs)
Pour le code custom :
- Corriger les usages d'API dépréciées signalés par Upgrade Status
- Mettre à jour le thème (si basé sur Bootstrap 3 ou un thème contrib obsolète)
- Vérifier la compatibilité PHP 8.3 : certaines constructions PHP < 8.0 peuvent causer des erreurs fatales
Estimation de charge indicative selon le profil du site :
| Profil du site | Charge développeur estimée |
|---|---|
| Site vitrine simple (< 5 modules custom, < 20 contrib) | 3–5 jours |
| Site institutionnel moyen (thème custom, 30–50 contrib) | 5–15 jours |
| Portail B2B complexe (modules custom, intégrations API, multilinguisme) | 20–60 jours |
Étape 3 — Migration vers Drupal 10 en environnement de staging (2 à 5 jours)
Avant de viser Drupal 11, stabilisez sur Drupal 10. Cette étape se fait sur un environnement de recette isolé — jamais en production.
Commandes Composer pour monter en version :
# Vérifier les contraintes de version
composer outdated
# Mise à jour du core vers Drupal 10
composer require drupal/core-recommended:^10 drupal/core-composer-scaffold:^10 --update-with-all-dependencies
# Lancer les mises à jour de base de données
drush updatedb
# Vider les caches
drush crAprès cette étape : tests fonctionnels complets. Chaque fonctionnalité critique doit être validée.
Étape 4 — Montée vers Drupal 11 (1 à 3 jours)
Une fois le site stabilisé sur Drupal 10, la montée vers Drupal 11 est généralement plus rapide, surtout si toutes les API dépréciées ont été corrigées à l'étape précédente.
# Mise à jour vers Drupal 11
composer require drupal/core-recommended:^11 drupal/core-composer-scaffold:^11 --update-with-all-dependencies
# Mise à jour de la base de données
drush updatedb
# Vider les caches
drush crPoints d'attention spécifiques à Drupal 11 :
- jQuery UI : si votre thème ou vos modules utilisaient jQuery UI, ces composants ont été retirés du core. Migrez vers les alternatives vanilla JS ou les modules de remplacement
- Claro : nouveau thème admin par défaut — vérifiez que vos personnalisations admin sont toujours fonctionnelles
- CKEditor 5 : si vous utilisez CKEditor 4 via un module contrib, la migration vers CKEditor 5 nécessite une attention particulière sur les formats de texte et les plugins d'éditeur
Étape 5 — Recette complète et tests de non-régression (3 à 10 jours)
C'est l'étape souvent raccourcie à tort. Une migration sans tests rigoureux, c'est un risque de régression en production.
Checklist minimale :
- [ ] Toutes les pages du site se chargent sans erreur (crawl automatisé recommandé)
- [ ] Les formulaires fonctionnent (contact, devis, lead capture)
- [ ] Les médias et fichiers uploadés sont accessibles
- [ ] Les intégrations tierces répondent correctement (CRM, analytics, marketing automation)
- [ ] Les emails transactionnels partent bien
- [ ] Les performances sont équivalentes ou meilleures (Core Web Vitals)
- [ ] L'accès admin fonctionne sur tous les rôles utilisateurs
- [ ] Les règles de cache et de CDN sont toujours opérationnelles
Bonne pratique : impliquer les utilisateurs métier dans la recette, pas seulement l'équipe technique. Ce sont eux qui repèrent les régressions fonctionnelles invisibles aux tests automatiques.
Étape 6 — Mise en production et monitoring post-migration (J+1 à J+30)
Le jour du go-live n'est pas la fin du projet. Les premières semaines post-migration sont critiques.
Plan de mise en production recommandé :
- Maintenance programmée : annoncez une fenêtre de maintenance aux utilisateurs (généralement la nuit ou le week-end)
- Sauvegarde complète (fichiers + base de données) avant tout changement
- Migration en production : appliquer les mêmes commandes drush qu'en staging
- Tests smoke post-déploiement : vérification des parcours critiques en production
- Monitoring renforcé : surveiller les logs d'erreurs, les temps de réponse, les alertes serveur pendant 2 semaines
Les 5 pièges classiques à éviter
1. Sous-estimer le code custom
La plupart des retards et dépassements de budget viennent de code custom non inventorié. Des hooks mal documentés, des thèmes maison avec des surcouches oubliées, des modules internes sans tests — tout cela ressort à la migration. Faites l'audit avant de chiffrer.
2. Migrer sans environnement de staging dédié
Tester en production ou sur un environnement partagé avec d'autres projets, c'est s'exposer à des risques inutiles. Chaque migration sérieuse mérite un environnement ISO-prod : même configuration serveur, même version PHP, même base de données restaurée.
3. Oublier la mise à jour PHP
Drupal 11 requiert PHP 8.3 minimum. Si votre hébergeur ou infrastructure tourne encore sur PHP 7.4 ou 8.0, la migration du CMS doit être coordonnée avec la mise à jour de l'environnement d'exécution. C'est une contrainte d'infrastructure, pas seulement de code.
4. Négliger les modules contrib dépréciés
Certains modules populaires sur Drupal 9 n'ont pas de version Drupal 11. Ne supposez pas que votre module favori est maintenu — vérifiez sur drupal.org. Parfois, la fonctionnalité est désormais dans le core (ex. Layout Builder, Media Library) et le module contrib devient inutile.
5. Sauter la phase de recette métier
Les tests techniques ne suffisent pas. Les utilisateurs métier — marketing, commercial, service client — utilisent le back-office différemment des développeurs. Réservez toujours une phase de validation fonctionnelle avec les équipes qui utilisent Drupal au quotidien.
Estimation de charge et de budget : ordre de grandeur
Les fourchettes ci-dessous sont indicatives. Seul un audit de votre site permettra de produire un chiffrage précis.
| Type de site | Durée estimée | Budget indicatif (régie agence) |
|---|---|---|
| Site vitrine simple | 2–4 semaines | 5 000–12 000 € |
| Site institutionnel moyen | 4–8 semaines | 12 000–35 000 € |
| Portail B2B / Intranet complexe | 8–20 semaines | 35 000–100 000 € |
Facteurs qui font varier le budget :
- Nombre de modules custom à réécrire
- Compatibilité des intégrations tierces
- Volume de contenu à migrer / retravailler
- Nécessité de refonte graphique (theme uplift)
- Niveau d'exigence pour les tests et la recette
- Contraintes d'infrastructure (migration d'hébergeur, passage en containerisation)
À noter : ne pas migrer a aussi un coût. Chaque mois passé sur un Drupal 9 non supporté augmente le risque de faille non patchée. Une intrusion, un defacement ou une fuite de données peut coûter bien plus qu'une migration préventive.
FAQ — Les questions que posent les DSI
Peut-on migrer directement de Drupal 9 à Drupal 11 sans passer par Drupal 10 ?
Techniquement oui, via une mise à jour Composer directe. Mais pour les sites complexes, l'approche en deux temps (9→10 puis 10→11) est plus sûre : elle permet de valider chaque palier et de corriger les problèmes de manière incrémentale.
Notre site a des dizaines de milliers de pages de contenu. La migration du contenu est-elle automatique ?
Oui, dans la grande majorité des cas. Les migrations Drupal 9 → 11 sont des montées de version, pas des migrations de données au sens strict. La base de données est conservée et mise à jour via drush updatedb. Il n'y a pas besoin de réimporter le contenu depuis zéro.
Nos équipes utilisent beaucoup Views et Webform. Ces modules seront-ils disponibles sur Drupal 11 ?
Oui. Views est dans le core Drupal depuis la version 8. Webform et la plupart des modules incontournables ont des versions Drupal 11 stables. Vérifiez toujours sur drupal.org/project/[nom_module] pour confirmer.
Combien de temps durera le support de Drupal 11 ?
La politique Drupal prévoit un support d'au moins 3 ans pour les versions majeures. Drupal 12 est en cours de développement mais n'a pas encore de date de sortie annoncée. Migrer vers Drupal 11 en 2026 vous donne une plateforme supportée pour plusieurs années.
Faut-il profiter de la migration pour refaire le design ?
Ce n'est pas obligatoire. La migration technique peut se faire indépendamment d'une refonte graphique. Cependant, certains projets profitent de la montée de version pour moderniser le thème ou passer à un design system plus récent. C'est une décision à prendre au cas par cas selon votre roadmap produit.
Prochaine étape : auditer votre site avant de chiffrer
Chaque migration est unique. Le seul moyen d'obtenir un chiffrage fiable — en temps et en budget — est de commencer par un audit technique de votre site existant.
Chez DrupaLabs, nous proposons un diagnostic de migration : nous analysons votre site Drupal actuel, identifions les bloquants, et vous remettons un rapport avec une estimation de charge détaillée. Sans engagement.
Demander votre diagnostic de migration →
DrupaLabs — Studio d’ingénierie digitale et d’automatisation métier. Nous accompagnons les DSI et équipes IT dans la migration, la refonte et l'optimisation de plateformes Drupal B2B.