Drupal raccourcit le support de ses versions mineures : votre plan de maintenance est-il prêt ?

Ce qui change dans la politique de support Drupal

Dans une annonce publiée le 2 novembre, l'équipe Drupal a indiqué qu'à partir de 2027, les versions mineures ordinaires (par exemple Drupal 11.3 ou 11.4) bénéficieront de huit mois de couverture sécurité, contre douze auparavant. Concrètement, une version mineure recevra six mois de corrections de bugs, suivis de deux mois de correctifs de sécurité uniquement. Seule exception : la dernière version mineure d'une version majeure conserve six mois de chaque, soit douze mois au total.

Les versions majeures (Drupal 10, 11, 12...), elles, continuent de bénéficier d'au moins quatre ans de support. C'est là que réside le piège pour les décideurs : dire « nous sommes sur Drupal 11 » ne suffit plus. C'est le second chiffre qui compte. Un site peut tourner sur Drupal 11 tout en approchant de la fin du support sécurité de sa version mineure. Rester supporté implique de progresser régulièrement entre les versions mineures au sein d'une même version majeure, même après avoir investi dans une montée de version majeure récente.

Autre point de vigilance : ces huit mois représentent la durée de vie de la version, pas un délai pour appliquer les correctifs. Les avis de sécurité urgents exigent toujours une évaluation et une action rapides.

Pourquoi Drupal fait ce choix

L'équipe sécurité de Drupal invoque le volume croissant de signalements de sécurité liés aux outils d'IA, qui met sous pression ses ressources disponibles. Maintenir des correctifs sur des branches anciennes représente une charge importante : Drupal estime que ce changement réduira de 30 % le travail de rétroportage (adaptation des correctifs de sécurité aux versions antérieures) sur le cœur du CMS. La nouvelle politique améliore aussi l'alignement avec le calendrier de publication de Symfony, le framework PHP sur lequel repose Drupal.

La contrepartie est claire : la responsabilité se déplace vers les équipes qui maintiennent les sites. Avec une fenêtre de support plus courte, un blocage de mise à jour non résolu devient beaucoup plus difficile à reporter d'un cycle de planification au suivant.

Les dates à inscrire dans votre planning

La transition affecte différemment les versions en circulation. Voici les échéances à utiliser pour évaluer votre situation :

• Drupal 10 : fin du support sécurité le 9 décembre 2026. Si vous êtes encore sur cette version, confirmez dès maintenant le chemin de montée de version majeure et identifiez qui porte le projet.
• Drupal 11.3 : fin du support en décembre 2026. Il faut organiser le passage vers une version mineure supportée.
• Drupal 11.4 : fin du support le 21 avril 2027. Réservez dès à présent le temps de test et de déploiement en amont de cette date.
• Drupal 12.0 et 11.5 : sorties planifiées pour la semaine du 7 décembre 2026, selon le calendrier officiel des versions au moment de la rédaction.

Drupal 11 reste supporté jusqu'en décembre 2028, à condition que les sites progressent vers les versions mineures supportées. Les sites Drupal 11 existants disposent donc d'une marge pour planifier leur prochaine montée de version majeure en fonction de leurs contraintes de compatibilité et de leurs enjeux métier. Pour les équipes encore sur Drupal 10, en revanche, l'échéance de décembre 2026 mérite une attention immédiate : attendre une future version majeure ajoute de l'incertitude à un calendrier déjà serré.

Ce que cela implique pour votre plan de maintenance

La conversation de maintenance utile démarre avec quelques éléments précis : la version déployée, sa date de fin de support, la version cible visée, et tout ce qui empêche d'y aller. Ces informations méritent de figurer dans un court plan écrit, compréhensible à la fois par le propriétaire du site et par l'équipe de développement.

Le travail de test doit ensuite trouver sa place dans le calendrier. Un environnement de préproduction (staging) n'est utile que si quelqu'un a le temps de s'en servir. Avant chaque mise à jour, listez les parcours qui doivent continuer de fonctionner : connexion, publication et validation de contenu, soumission de formulaire, paiement, échange de données avec un autre système. Adaptez les vérifications à ce que votre site fait réellement : un portail de candidature en ligne et un petit site éditorial n'exigent pas la même attention. Impliquez aussi les utilisateurs de l'interface d'administration, qui repéreront une étape éditoriale cassée qu'une simple revue de la page d'accueil manquerait.

Les recommandations officielles de Drupal pour les mises à jour incluent la lecture des notes de version, la vérification de compatibilité des modules et thèmes, la sauvegarde du site, l'application des mises à jour de base de données et le contrôle du résultat après déploiement. Autant d'étapes qui demandent du temps, en plus de la mise à jour du code elle-même.

Enfin, consignez les blocages dès qu'ils apparaissent. Si un module contribué, une intégration sur mesure ou une contrainte de dépendance empêche d'atteindre la version cible, notez l'action suivante et attribuez-lui un responsable. Détecter le problème tôt vous laisse une chance de le résoudre avant qu'une échéance de support ne décide du calendrier à votre place.

Relire votre contrat de maintenance à la lumière de ce changement

La mention « mises à jour de sécurité incluses » peut laisser des questions importantes sans réponse. Le contrat couvre-t-il la montée de version mineure nécessaire pour continuer à recevoir ces correctifs ? Qui gère un problème de compatibilité de module ? Qui teste le workflow éditorial et autorise le déploiement ? Autant de points à clarifier avant le prochain cycle de versions, dans l'intérêt du client comme du prestataire, pour estimer honnêtement la charge de travail.

Une discussion budgétaire utile distingue trois postes : les correctifs courants, les mises à jour mineures planifiées et les montées de version majeures. Chacun a besoin d'un responsable et d'un circuit de validation convenu à l'avance. Prévoyez aussi une capacité réservée pour les correctifs de sécurité urgents, même quand une mise à jour planifiée est déjà en cours.

Pour les organisations qui exploitent plusieurs sites Drupal, tenez un registre partagé des versions et des échéances, avec le responsable de chaque site et la prochaine date de maintenance prévue. Ce suivi permet de repérer rapidement un site sorti du rythme normal de mise à jour. Et avant de clore le prochain ticket de maintenance, demandez la version déployée et sa prochaine échéance de support : placez cette date là où les personnes qui approuvent les travaux la verront.