Fin de vie de Drupal 10 : le plan à lancer avant décembre 2026
Commençons par les faits, parce que l’échéance, elle, ne se négocie pas :
| Fait | Valeur |
|---|---|
| Fin de vie de Drupal 10 | 9 décembre 2026 (à la sortie de Drupal 12) |
| Ce qui s’arrête | Les correctifs de sécurité et de bugs du core 10.x |
| Cible de migration | Drupal 11 (sorti en août 2024 — mûr et stable) |
| Prérequis Drupal 11 | PHP 8.3+, MySQL 8.0+ / MariaDB 10.6+ |
| Chemin de montée | Depuis la dernière mineure de Drupal 10, via Composer — une mise à jour, pas une refonte |
| Temps à prévoir | De quelques jours (site propre) à plusieurs semaines (beaucoup de custom/contrib) |
À cinq mois de l’échéance, c’est exactement le bon moment pour démarrer — non pas parce que la montée est énorme (elle ne l’est pas, comparée à l’époque Drupal 7), mais à cause de ce qui va arriver au calendrier de tout le monde au quatrième trimestre.
Ce que la fin de vie veut vraiment dire
Votre site ne s’éteint pas le 10 décembre. Ce qui s’éteint, c’est le filet de sécurité :
- Plus aucune alerte de sécurité pour le core 10.x. Chaque faille découverte après la fin de vie reste sans correctif — pendant que l’alerte publiée pour Drupal 11 indique aux attaquants exactement où chercher. J’ai détaillé ce mécanisme dans mon manuel des mises à jour de sécurité ; faire tourner une majeure en fin de vie en est le pire scénario.
- La contrib suit le core. Les mainteneurs abandonnent vite le support 10.x une fois que le core l’abandonne — je le fais moi-même sur les 24 modules que je maintiens. Votre arbre de dépendances se fossilise.
- Exposition conformité et assurance. Pour un site public, média ou finance, « CMS non supporté » est un constat d’audit, pas un détail technique.
Pourquoi « on fera ça en novembre » est l’option chère
Toutes les équipes Drupal d’Europe ont la même échéance. La capacité des agences et des freelances d’octobre à décembre 2026 sera réservée — et facturée — en conséquence. Et les migrations pressées, c’est là que naissent les régressions et les accidents SEO. Les équipes qui migrent en août paient le tarif normal et dorment en décembre.
Le plan sur six mois
Juillet — connaître son site. Lancez Upgrade Status, inventoriez modules custom et contrib, obtenez une estimation honnête. Une journée d’audit transforme « ça devrait aller » en liste de tâches chiffrée.
Août — préparer le terrain. Montez les environnements en PHP 8.3 (local, CI, préprod, prod) et les versions de base de données avant de toucher à Drupal. Désinstallez ce qui ne sert plus — chaque module retiré, c’est du travail de migration supprimé.
Septembre — corriger le code. Drupal Rector automatise l’essentiel des corrections de dépréciation dans le custom ; triez la contrib (version compatible / patch dans la file d’issues / remplacement / abandon). C’est la seule phase dont la durée varie fortement d’un site à l’autre — d’où l’audit de juillet.
Octobre — monter et tester. Montée Composer sur une copie de préproduction, drush updb, puis une vraie recette
avec les personnes qui utilisent le site au quotidien. La production reste sous Drupal 10 pendant ce temps.
Novembre — livrer. Bascule en production avec plan de retour arrière, vérification des redirections et métadonnées, suivi Search Console. Mon guide technique pas à pas donne les commandes exactes et la checklist SEO.
Décembre — un tampon, pas un planning. Si votre planning se termine le 8 décembre, vous n’avez pas de planning. Le mois tampon sert à absorber la surprise que tout vrai projet rencontre.
Encore sous Drupal 7 ou 9 ?
Alors cette échéance n’est pas votre premier problème — ces versions sont déjà en fin de vie (Drupal 7 depuis janvier 2025), et le saut est une vraie migration, pas une mise à jour. Même conclusion, urgence en plus : commencez par un audit, aujourd’hui.
Je mène ces migrations toute l’année, de l’audit d’une journée à la livraison complète. Parlons-en avant la ruée du T4 — votre futur vous remerciera en décembre.