Drupal 10 approche de sa dernière étape de support. Selon le calendrier officiel de Drupal, la branche 10.6.x est le dernier mineur de Drupal 10 et la fin de vie est fixée au 9 décembre 2026. Après cette date, aucune nouvelle version de Drupal 10 ne sera publiée.
Cette échéance mérite d'être planifiée, mais elle ne justifie pas une mise à niveau précipitée. Le bon objectif est de savoir ce qui bloque aujourd'hui, de réduire ces écarts progressivement, puis de répéter le passage à Drupal 11 dans un environnement sûr avant de toucher à la production.
Que signifie concrètement la fin de support de Drupal 10 ?
Jusqu'à sa fin de vie, Drupal 10.6.x reste dans la fenêtre de support prévue par le projet Drupal. Le 9 décembre 2026 marque la fin de cette branche majeure : il n'y aura ensuite plus de nouvelle version Drupal 10, y compris pour poursuivre sa maintenance courante.
Pour une organisation, le sujet n'est donc pas seulement le numéro de version affiché dans l'administration. Continuer durablement sur une branche arrivée en fin de vie augmente le risque de devoir arbitrer dans l'urgence lorsqu'une dépendance, un module contribué ou l'infrastructure évolue. Une préparation suffisamment tôt permet au contraire de traiter les incompatibilités comme un chantier maîtrisé.
La première étape consiste à établir l'état réel du projet : version exacte du core, versions de PHP et de la base de données, modules contrib et personnalisés, thème, dépendances Composer, intégrations et parcours métier. Un audit Drupal utile part de cet inventaire, pas d'une simple commande de mise à jour.
Faut-il migrer ou simplement mettre à niveau ?
Pour un site Drupal 10 moderne et maintenu, le passage à Drupal 11 est une mise à niveau de version majeure. Les données, la configuration et le code restent dans la continuité du même projet Drupal, à condition que le site respecte le chemin de mise à niveau et que ses extensions soient compatibles.
Le mot « migration » reste souvent utilisé dans les projets et dans les recherches Google, mais il ne faut pas mettre tous les cas dans la même catégorie. Un Drupal 7 ancien, par exemple, demande généralement une évaluation de migration ou de reconstruction : l'architecture du contenu, les modules remplacés, le thème et les intégrations peuvent avoir beaucoup changé. Drupal 7 est lui-même arrivé en fin de vie le 5 janvier 2025.
Drupal 9 demande aussi un traitement séquentiel. Drupal ne permet pas de sauter une version majeure : un projet Drupal 9 doit d'abord rejoindre Drupal 10 avant de passer à Drupal 11. Pour un site ancien ou mal documenté, le bon point de départ est donc de reconstituer un chemin supporté, pas de chercher un raccourci vers la dernière version.
Si votre projet est déjà sur Drupal 10, notre page migration Drupal détaille l'accompagnement possible autour des mises à niveau et modernisations. Si le périmètre est encore incertain, mieux vaut commencer par un audit de compatibilité.
Les prérequis à vérifier avant Drupal 11
Le guide officiel de Drupal pour passer de Drupal 10 à Drupal 11 fixe Drupal 10.3.x comme version source minimale. Cela ne signifie pas qu'un projet ancien en 10.3 doit rester figé là : avant le changement de majeure, il est généralement plus lisible de remettre d'abord le site sur une version Drupal 10 encore supportée, puis de traiter les écarts de compatibilité.
Drupal 11 demande aussi PHP 8.3 au minimum. Les exigences de la base de données et des autres composants de plateforme ont évolué elles aussi. Une mise à niveau Drupal doit donc inclure l'hébergement et l'environnement d'exécution, pas seulement le code applicatif.
Core et plateforme
- Identifier la version exacte de Drupal core et vérifier que le projet peut atteindre un Drupal 10 supporté avant le passage à 11.
- Vérifier PHP, le moteur de base de données, les extensions PHP et les autres exigences système de Drupal 11.
- Contrôler la version de Composer et la cohérence de
composer.jsonetcomposer.lock.
Modules contribués et code personnalisé
Le module Upgrade Status reste l'outil de référence du projet Drupal pour examiner la préparation à une nouvelle version majeure. Il aide à vérifier si la version actuelle du core permet l'upgrade, si la plateforme répond aux exigences suivantes et si des modules ou du code utilisent encore des API incompatibles ou dépréciées.
- Mettre à jour les modules contribués vers des versions compatibles lorsqu'elles existent.
- Identifier les modules abandonnés, remplacés ou dépendants de correctifs non pérennes.
- Analyser les modules personnalisés et le thème pour les API dépréciées.
- Utiliser les outils de compatibilité sur le site Drupal 10 avant l'upgrade, tant que les anciennes API sont encore présentes et détectables.
Données, configuration et intégrations
Une mise à niveau peut être techniquement correcte et pourtant casser un usage important. Il faut donc vérifier le chemin de mise à jour de la base, la configuration exportée, les langues, les champs, les formats de texte et les références d'entités, mais aussi les interactions extérieures au core.
- Formulaires, e-mails transactionnels et traitements associés.
- API entrantes ou sortantes, webhooks et authentifications tierces.
- Cron, files de tâches et traitements différés.
- Recherche, cache, indexation et services externes éventuels.
- Parcours multilingues, aliases, canonical et hreflang lorsque le site les utilise.
Pourquoi composer update n'est pas le vrai sujet
Composer est indispensable pour gérer les dépendances d'un projet Drupal moderne, et le guide officiel recommande notamment de tester la résolution des dépendances avant d'effectuer l'upgrade. Mais une résolution Composer réussie ne démontre pas que le site est prêt à être mis en production.
La complexité se trouve souvent dans les écarts autour du core : un module contribué dont la version compatible modifie un comportement, une API dépréciée utilisée dans du code métier, un thème qui dépend d'un rendu ancien, une configuration qui n'a jamais été rejouée proprement, ou un parcours critique qui n'est testé que manuellement.
Les différences entre environnements comptent aussi. Une mise à niveau qui démarre sur une machine de développement peut échouer ailleurs si PHP, la base de données, les extensions ou les services externes ne sont pas alignés. C'est pour cela qu'un projet sérieux traite l'upgrade comme une chaîne complète : dépendances, code, données, configuration, infrastructure, déploiement et validation.
La maintenance Drupal régulière réduit ce travail en évitant d'accumuler plusieurs générations de mises à jour, de dépréciations et de dépendances en même temps.
Notre méthode pour réduire le risque
Nous abordons une mise à niveau majeure comme une succession de preuves plutôt que comme une seule opération. Le niveau de détail dépend du site, mais la logique reste la même.
- Audit et inventaire. Nous établissons les versions, dépendances, modules, code personnalisé, thème, configuration et intégrations qui comptent réellement.
- Backlog de compatibilité. Les écarts Drupal 11 sont classés afin de distinguer les mises à jour simples, le code à adapter, les modules à remplacer et les décisions fonctionnelles.
- Backup et retour arrière. La stratégie de sauvegarde et de rollback est définie avant la première mutation de production.
- Implémentation isolée. Les changements sont développés et validés hors production, avec des contrôles reproductibles.
- Validation en PREPROD. Le candidat est testé dans un environnement PREPROD réel avant toute bascule.
- Données représentatives lorsque c'est utile. Pour les défauts qui n'apparaissent qu'avec un contenu réaliste, nous pouvons travailler sur un PREPROD dérivé de PROD et sanitizé avant activation. La chaîne est conçue pour que les données PROD brutes ne transitent pas par des runners GitHub-hosted.
- Contrôles automatiques et humains. Les tests techniques sont complétés par les parcours éditoriaux et métier qui comptent pour le site.
- Déploiement contrôlé. La production n'est modifiée qu'après validation du candidat et de la procédure de retour arrière.
- Vérifications après déploiement. Nous contrôlons le fonctionnement du site, les parcours critiques et les signaux techniques utiles après la mise en ligne.
Cette discipline n'élimine pas tout imprévu, mais elle évite de découvrir les problèmes importants au moment où la production doit déjà basculer. C'est aussi la manière dont notre agence Drupal en Belgique sépare la préparation technique de la décision de mise en production.
Quel chantier selon votre Drupal actuel ?
- Drupal 10 récent et correctement maintenu
- Commencer par un audit de préparation Drupal 11 : plateforme, contrib, code personnalisé, dépréciations et dépendances Composer. Le chantier peut rester une mise à niveau majeure bien délimitée si les écarts sont faibles.
- Drupal 10 avec dette technique
- Construire d'abord un backlog de compatibilité. Les modules contrib non maintenus, le code personnalisé ancien, les patches historiques et les contraintes d'hébergement doivent être traités explicitement avant de planifier la bascule.
- Drupal 9
- Reconstituer un chemin séquentiel supporté. Drupal 9 ne se met pas directement à niveau vers Drupal 11 : il faut passer par Drupal 10, puis préparer Drupal 11.
- Drupal 7
- Évaluer une migration ou une reconstruction plutôt que de présenter le projet comme une simple mise à jour en place. Le modèle de contenu, les modules, le thème et les intégrations doivent être reconsidérés selon le site réel.
- Version ou architecture mal documentée
- Faire l'inventaire avant de choisir la solution. Un audit Drupal évite de décider trop tôt entre mise à niveau, migration et refonte.
Lorsque le projet nécessite aussi une remise à plat de l'expérience, de l'architecture ou du thème, une refonte Drupal peut être étudiée séparément. Elle ne doit pas être imposée uniquement parce que la version du core change.
Quand commencer ?
La date à retenir est le 9 décembre 2026. Le meilleur moment pour commencer dépend de votre état de départ, pas d'un compte à rebours générique.
Un site Drupal 10 propre, à jour et peu personnalisé n'a pas le même backlog qu'une plateforme avec plusieurs modules maison, des intégrations critiques ou des dépendances anciennes. Commencer avant l'échéance donne surtout du temps pour découvrir ces écarts, choisir les bonnes corrections, répéter la mise à niveau en PREPROD et réserver une fenêtre de production adaptée à l'activité.
Si vous devez encore déterminer la taille du chantier, faire auditer votre Drupal avant la migration permet de transformer l'incertitude en liste de décisions. Si le périmètre est déjà clair, vous pouvez préparer votre migration vers Drupal 11 avec un plan de mise à niveau et de validation.
Checklist Drupal 10 → Drupal 11
Cette liste peut servir de point de départ pour une revue interne avant de planifier la bascule.
- ☐ Relever la version exacte de Drupal core et confirmer le chemin jusqu'à une version Drupal 10 supportée.
- ☐ Vérifier que la version source respecte le minimum Drupal 10.3.x demandé pour l'upgrade vers Drupal 11.
- ☐ Vérifier PHP 8.3 ou plus et les exigences actuelles de la plateforme Drupal 11.
- ☐ Contrôler les versions et la compatibilité des modules contribués.
- ☐ Scanner les modules personnalisés et le thème pour les API dépréciées ou supprimées.
- ☐ Examiner les contraintes Composer et tester la résolution des dépendances avant la mise à jour réelle.
- ☐ Vérifier le chemin de mise à jour de la base de données et la rejouabilité de la configuration.
- ☐ Définir et tester la sauvegarde ainsi que le scénario de rollback.
- ☐ Préparer un environnement PREPROD représentatif et isolé de la production.
- ☐ Déterminer quelles données représentatives sont réellement nécessaires et comment elles seront sanitizées.
- ☐ Tester les parcours métier critiques, y compris authentification, recherche et fonctions éditoriales.
- ☐ Tester les formulaires, e-mails, API, webhooks et autres intégrations.
- ☐ Vérifier cron, files de tâches et traitements différés.
- ☐ Vérifier les langues, aliases, canonical et hreflang lorsque ces éléments sont utilisés.
- ☐ Exécuter les tests automatisés disponibles et compléter par une validation humaine ciblée.
- ☐ Préparer la procédure de déploiement, les contrôles de santé et les critères de retour arrière.
- ☐ Après déploiement, relire les logs et valider les parcours critiques avant de considérer le chantier terminé.
Le passage à Drupal 11 n'a pas besoin d'être une opération spectaculaire. Bien préparé, il devient un chantier de compatibilité, de validation et de déploiement que l'on peut découper et vérifier.
Vous voulez cadrer le projet avant de toucher à la production ? Parler de votre projet.