Se préparer à migrer de Drupal 10 à Drupal 11

Pourquoi agir maintenant

Risques sécurité et conformité

Après la fin de vie, les vulnérabilités découvertes sur Drupal 10 ne seront plus corrigées par le projet principal. Elles seront pourtant documentées publiquement dans les bases CVE et exploitées par des outils automatisés qui ne distinguent pas « vieux site sans importance » de « plateforme métier critique ».

Pour les organisations soumises à des obligations réglementaires — RGPD, normes sectorielles, audits de conformité — maintenir une plateforme sur une version non maintenue ouvre une brèche dans leur dossier de conformité. Ce n'est pas théorique : les assureurs cybersécurité et les acheteurs institutionnels posent désormais la question de la version logicielle dans leurs questionnaires de qualification.

Ce que coûte l'inaction

Reporter la migration ne supprime pas le coût : il le déplace et l'amplifie. Un projet de migration Drupal engagé maintenant, avec du temps, peut être conduit de façon méthodique — un module à la fois, avec des tests, un retour arrière planifié. Le même projet engagé en urgence en novembre 2026 sera conduit sous pression, avec moins de marges de test, sur un marché de prestataires surchargés par la même date butoir qui concerne tous leurs autres clients.

L'autre coût invisible de l'inaction : chaque fonctionnalité développée d'ici là sur Drupal 10 devra soit être revalidée sur Drupal 11, soit être refactorisée si elle s'appuie sur des API dépréciées. Plus vous attendez, plus la dette s'accumule.

Auditer avant de migrer

Inventaire des modules et thèmes

Le premier travail d'un projet de migration Drupal 11 est un inventaire exhaustif. Listez chaque module contrib installé sur votre instance Drupal 10, sa version, son statut de maintenance actuel, et l'état de sa compatibilité avec Drupal 11.

La grande majorité des modules activement maintenus ont déjà publié une version compatible Drupal 11. C'est précisément l'un des arguments pour ne pas attendre : la fenêtre pendant laquelle les mainteneurs de modules continuent à supporter les deux versions se referme progressivement. Les modules de niche ou peu maintenus sont ceux qui posent problème — et mieux vaut les identifier aujourd'hui pour avoir le temps de trouver une alternative, migrer le code, ou décider de retirer la fonctionnalité.

Pour les thèmes, la question est similaire : les thèmes personnalisés basés sur des hooks ou des templates dépréciés devront être adaptés. Stark et Olivero, les thèmes de base de Drupal 11, ont évolué, et les thèmes contrib qui n'ont pas suivi la roadmap nécessitent un travail de mise à jour.

Données, contenus et médias

L'upgrade du core ne touche pas directement la structure de votre base de données — c'est l'un des points forts de la mise à jour Drupal 10 vers 11. Mais si votre instance porte des configurations complexes (types de contenu imbriqués, champs de référence en cascade, migrations de contenu issues de versions antérieures), c'est le moment de les documenter et d'identifier les entités qui pourraient se comporter différemment.

La gestion des médias mérite une attention particulière si vous utilisez le module Media avec des fournisseurs tiers ou des bundles personnalisés. Les changements de comportement entre versions mineures s'accumulent ; vérifiez les notes de mise à jour de chaque version intermédiaire.

Performances et dette technique

Un projet de migration est une opportunité d'audit. Avant de migrer, évaluez l'état de la base de code : modules activés mais inutilisés, configurations orphelines, code personnalisé qui contourne des fonctionnalités du core, requêtes lentes, configuration du cache. Ces éléments ne bloquent pas la migration mais alourdissent la plateforme cible.

Feuille de route de migration (30 / 60 / 90 jours)

Phase 1 — Préparation (jours 1 à 30)

L'objectif de cette phase est d'entrer en migration avec une visibilité complète et un environnement sécurisé.

• Mettre en place ou consolider l'environnement de développement et de staging. Toute la migration s'effectuera hors production.
• Geler les nouvelles fonctionnalités sur la branche de production jusqu'à la bascule. Les développements parallèles croisent inévitablement la migration et créent des conflits.
• Compléter l'inventaire modules/thèmes et produire une matrice de compatibilité.
• Identifier les modules sans version Drupal 11 : décision pour chacun (alternative, refactoring, suppression).
• Définir le budget et le calendrier définitifs, avec les jalons de validation.

Phase 2 — Exécution (jours 31 à 60)

• Mettre à jour le core vers Drupal 11 sur l'environnement de staging.
• Mettre à jour les modules et thèmes dans l'ordre de dépendance. Commencer par les dépendances de base (core, token, pathauto, ctools…) avant les modules métier.
• Traiter les modules sans version compatible : développer les alternatives ou retirer les fonctionnalités abandonnées.
• Exécuter les tests fonctionnels sur les parcours critiques : formulaires, workflows, authentification, API exposées.
• Valider les aspects SEO : redirections, balises, sitemap, comportement des URL. Une migration proprement exécutée ne doit pas créer de régression SEO.

Phase 3 — Bascule et plan de retour arrière (jours 61 à 90)

• Documenter le plan de bascule : séquence des actions, rôles, durée estimée de l'indisponibilité.
• Prévoir le plan de retour arrière : snapshot de la base de données et des fichiers avant bascule, procédure de rollback testée.
• Effectuer la bascule sur une fenêtre de faible trafic.
• Surveiller les logs applicatifs, les alertes de performance et les remontées utilisateurs pendant les 72 heures suivant la mise en production.

Points de vigilance spécifiques à Drupal 11

Changements API, dépréciations, PHP et bases de données

Drupal 11 requiert PHP 8.3 minimum. Si votre hébergeur tourne encore sur une version antérieure, la mise à jour de PHP est un prérequis non négociable — et elle peut avoir des effets sur d'autres applications hébergées sur le même serveur.

Côté code personnalisé, les hooks dépréciés depuis Drupal 9 ou 10 doivent être remplacés par leurs équivalents modernes. Drupal 11 a supprimé les compatibilités qui avaient été maintenues pour faciliter les migrations depuis D8/D9. Utiliser le Upgrade Status module et le PHP deprecation analyzer permet d'identifier les lignes de code à modifier avant la migration.

Les bases de données MySQL 8.0+ et PostgreSQL 16+ sont supportées ; SQLite est désormais une option viable pour les environnements de développement. Vérifiez la version de votre base de données de production et anticipez une éventuelle mise à jour.

Compatibilité hébergeur et CI/CD

Vérifiez que votre hébergeur supporte les prérequis de Drupal 11. Les environnements cloud gérés (Platform.sh, Pantheon, Acquia) ont en général publié leur roadmap de support ; les hébergements mutualisés anciens peuvent bloquer sur la version PHP ou les extensions requises.

Si vous utilisez une pipeline CI/CD, mettez à jour les images de build pour refléter les nouveaux prérequis (PHP 8.3, Composer 2.x, version des dépendances de testing comme PHPUnit).

Budget et délais : ce qui conditionne l'enveloppe

La taille d'un plan de migration Drupal dépend de trois facteurs : le nombre et la complexité des modules contrib utilisés, la quantité de code personnalisé, et l'état de l'environnement de développement existant.

Un site standard avec peu de personnalisation et des modules bien maintenus peut migrer rapidement. Une plateforme métier avec des modules sur mesure, des intégrations API et une base de code développée sur plusieurs années est un projet à part entière, qui mérite un audit préalable avant tout chiffrage.

Ce qui est certain : le coût d'une migration préparée est inférieur au coût d'une migration précipitée, et les deux sont inférieurs au coût d'une maintenance prolongée sur une version non supportée.

Après la migration : TMA et amélioration continue

La migration n'est pas la fin d'un projet, c'est le début d'un cycle d'exploitation sain. Drupal 11 publie des mises à jour de sécurité et de fonctionnalités régulièrement. Les gérer de façon réactive, sans processus, c'est reproduire la situation actuelle — jusqu'à la prochaine fin de vie.

Une TMA Drupal structurée prend en charge ces mises à jour de façon planifiée : correctifs de sécurité dans les délais, montées de version mineures testées, surveillance applicative, et backlog d'améliorations continues. C'est ce qui transforme la migration en actif durable plutôt qu'en dette différée.

FAQ

Mon site est encore sur Drupal 8 ou 9 — puis-je migrer directement vers Drupal 11 ? Oui. La migration directe D8/D9 → D11 est possible et souvent recommandée plutôt qu'un passage intermédiaire par D10. L'outillage (Migrate API, Upgrade Status) supporte ce parcours. La complexité dépend de l'écart de versions de vos modules.

J'ai un multisite. La migration est-elle plus complexe ? Par nature, oui : vous avez plusieurs instances à synchroniser et potentiellement des modules partagés dans un profil d'installation. L'audit préalable est encore plus important. L'avantage : si vos sites partagent la même base de code, vous traitez les problèmes de compatibilité une seule fois.

Et pour Drupal Commerce ? Drupal Commerce 3.x est compatible Drupal 11. Vérifiez la version exacte de votre installation et les modules de paiement associés — certains connecteurs de passerelles moins répandus peuvent nécessiter un développement de compatibilité.