Par Kristijan Sekereš

Fin de vie de Drupal 10, Umbraco 13 et Kentico Xperience 13 : que faire avant décembre 2026

Code source HTML ouvert dans un éditeur de code

Trois versions de systèmes de gestion de contenu très répandues perdent leur support à environ trois semaines d'intervalle :

  • Drupal 10 : fin de vie le 9 décembre 2026.
  • Umbraco 13 : fin de vie le 14 décembre 2026.
  • Kentico Xperience 13 : tout support, correctifs de sécurité compris, s'arrête à partir du 1er janvier 2027.

Rien ne s'éteint à ces dates. Le 10 décembre, un site Drupal 10 sert ses pages exactement comme le 8 décembre, et les rédacteurs continuent de publier. Ce qui s'arrête, c'est l'approvisionnement en correctifs de sécurité. À partir de là, une vulnérabilité découverte dans votre version reste ouverte, à moins que quelqu'un ne la referme pour vous.

Au moment où nous écrivons ces lignes, le 3 octobre 2026, il reste environ dix semaines avant les deux premières dates. C'est suffisant pour un site Drupal ou Umbraco bien entretenu. Ce n'est pas suffisant pour une reconstruction sous Kentico 13.

À qui cela s'adresse vraiment

Le travail pèse le plus lourd sur les sites qui ont du code spécifique : modules et thèmes Drupal sur mesure, éditeurs de propriétés et tableaux de bord Umbraco sur mesure, widgets et intégrations Kentico, et tout ce qu'a construit une agence qui est depuis passée à autre chose.

Si votre site Drupal est proche d'une installation standard avec des modules contribués populaires, la mise à niveau est surtout mécanique, et votre hébergeur l'a peut-être déjà planifiée. Demandez-lui la date.

Si vous êtes sur Umbraco 13 et achetez le support étendu (voir plus bas), décembre n'est pas une falaise pour vous. C'est un arrêt des correctifs que vous avez payé pour repousser.

Drupal 10 : fin le 9 décembre 2026

Ce qui s'arrête

La déclaration du projet lui-même est brève : « Drupal 10 arrivera en fin de vie le 9 décembre 2026. » Drupal 10.6 est la dernière version mineure, et le calendrier des versions indique qu'aucune nouvelle version de Drupal 10 ne sortira après cette date.

La semaine du 20 septembre 2026, les statistiques d'utilisation de drupal.org recensaient 221 417 sites sur les branches Drupal 10 contre 210 728 sur Drupal 11, sur 524 579 sites remontant leurs données. Environ quatre sites Drupal sur dix parmi ceux qui remontent leurs données ont dix semaines devant eux sur leur version actuelle. Parmi eux, 21 148 sont encore sur Drupal 10.0, 10.1 ou 10.2, ce qui impose une étape supplémentaire au préalable.

Ce qu'implique la mise à niveau

Le guide officiel de mise à niveau de Drupal 10 vers Drupal 11 se décompose en quelques chantiers :

  1. L'hébergement d'abord. Drupal 11 exige PHP 8.3.0 ou supérieur. Drupal 10 tournait sans problème sur PHP 8.1 et 8.2. PHP 8.1 n'est déjà plus supporté, et le support de sécurité de PHP 8.2 prend fin le 31 décembre 2026. Si votre serveur utilise l'une de ces versions, changez d'abord de PHP, comme un chantier à part, testé pour lui-même.
  2. Passer à Drupal 10.3.0 ou supérieur. Les mises à jour du cœur antérieures à la 10.3.0 ont été supprimées dans Drupal 11 : un site en 10.2 ne peut donc pas faire le saut directement.
  3. Traiter les modules du cœur supprimés. Actions UI, Activity Tracker, Book, Forum, Statistics et Tour ont disparu du cœur dans Drupal 11. Si vous utilisez l'un d'eux, cessez de l'utiliser ou passez à sa version contribuée tant que vous êtes encore sur Drupal 10.3 ou supérieur, avant la mise à niveau du code.
  4. Porter le code spécifique. Le module Upgrade Status montre où votre code et vos modules contribués ne sont pas prêts. Drupal Rector réécrit automatiquement de nombreux appels d'API obsolètes ; le reste se fait à la main. Sur un site qui accumule des années de modules sur mesure, c'est là que partent les heures.
  5. Vérifier chaque module contribué. Chacun a besoin d'une version compatible avec Drupal 11. Quand il n'en existe pas, le guide renvoie vers des correctifs dans la file de tickets du module ou vers le point d'accès Lenient Composer. Chaque module embarqué de cette façon devient de la maintenance qui vous incombe.
  6. L'outillage. Il vous faut un accès en ligne de commande avec Composer et Drush, et une trace de tous les fichiers de scaffold personnalisés, pour qu'ils survivent à la mise à niveau.

Faut-il attendre Drupal 12 ?

Non. Drupal 12.0.0 est prévu la semaine du 7 décembre 2026, la semaine même où s'arrête le support de sécurité de Drupal 10. Une version .0 la semaine où votre version actuelle expire, ce n'est pas un plan. Drupal 11.4 continue de recevoir des correctifs de sécurité après cette semaine-là, et la 11.5 sort en même temps que la 12.0. Passez à la 11 maintenant et regardez la 12 l'an prochain.

Umbraco 13 : fin le 14 décembre 2026

Ce qui s'arrête

Umbraco 13 est une version à support long terme (LTS). Selon la page du cycle de support d'Umbraco, elle est en phase de sécurité (correctifs de sécurité uniquement) depuis le 14 décembre 2025 et arrive en fin de vie le 14 décembre 2026 ; Umbraco indique qu'ensuite, elle « n'est plus recommandée ».

Une seconde date se cache dessous. Umbraco 13 tourne sur .NET 8, et Microsoft arrête le support de .NET 8 le 10 novembre 2026. L'environnement d'exécution dont dépend votre site perd son support un mois avant le CMS.

Ce qu'implique la mise à niveau

La règle d'Umbraco est de passer à la version LTS la plus proche avant la plus récente. Umbraco 13 étant elle-même une version LTS, la cible est Umbraco 17, la LTS suivante. Elle est sortie le 27 novembre 2025, entre en phase de sécurité le 27 novembre 2027 et arrive en fin de vie le 27 novembre 2028. Elle tourne sur .NET 10.

L'étape difficile se trouve au milieu. Umbraco 14 a entièrement remplacé l'interface d'édition, et les notes de mise à niveau par version le résument en une ligne : « AngularJS supprimé : un nouveau backoffice construit avec les Web Components et Lit, et propulsé par l'Umbraco UI Library. »

En pratique, cela signifie :

  • Chaque personnalisation du backoffice est réécrite. Les éditeurs de propriétés sur mesure, les tableaux de bord, les sections personnalisées et les parties interface des packages étaient en AngularJS dans Umbraco 13. Rien de tout cela n'est repris ; tout est reconstruit sous forme de web components.
  • Les éditeurs de propriétés sont scindés en deux, une partie serveur et une partie client, ce qui change la structure des éditeurs sur mesure.
  • Certains éditeurs disparaissent. Nested Content, la mise en page Grid et l'ancien Media Picker ont été supprimés. Umbraco recommande Block List ou Block Grid à la place. C'est un chantier de contenu autant que de code : les pages construites avec ces éditeurs ont besoin que leur contenu stocké soit converti.
  • Les macros sont supprimées. Umbraco renvoie à la place vers des vues partielles ou des blocs dans l'éditeur de texte riche.
  • XPath est supprimé, Dynamic Roots figurant parmi les solutions de remplacement.
  • Les packages ont besoin d'une version pour Umbraco 17. Un package abandonné, c'est un remplacement ou une réécriture.

La recommandation d'Umbraco est de mettre à niveau hors ligne, de tout tester, puis de lancer la mise à niveau sur chaque environnement. Associez tôt vos rédacteurs aux tests : le backoffice qu'ils utilisent tous les jours aura un autre aspect et un autre comportement.

Les gabarits publics changent généralement moins que le backoffice, sauf là où ils affichent du Nested Content, du Grid ou des macros. Chercher ces trois éléments dans vos vues donne une première mesure rapide du chantier.

Acheter du temps : XLTS

Umbraco vend un support long terme étendu (XLTS) pour les versions LTS à partir d'Umbraco 10, 13 comprise. Vous choisissez 6, 12 ou 24 mois, et la couverture commence le lendemain de la fin de vie. Il ne couvre que les correctifs de sécurité, avec des fonctionnalités figées. Vous l'achetez auprès d'Umbraco (les partenaires passent par leur responsable partenaire), et la page n'affiche aucun prix.

XLTS a du sens quand la réécriture des éditeurs sur mesure ne peut pas être menée correctement d'ici le 14 décembre. Il en a moins comme moyen de repousser la décision, car la réécriture coûtera la même chose l'an prochain. Et il corrige Umbraco, pas l'environnement d'exécution : le support de .NET 8 s'arrête de toute façon.

Kentico Xperience 13 : fin le 1er janvier 2027

Ce qui s'arrête

Kentico 13 est déjà en support réduit. Tout au long de 2026, Kentico ne publie de versions « que sous forme de correctifs de sécurité ». Ensuite, selon le cycle de support de Kentico : « À partir du 1er janvier 2027 : nous cesserons tout support, maintenance, mise à jour, version, correctif, patch, réparation (y compris les réparations de sécurité) et tout autre service lié à Kentico Xperience 13. »

Aucune prolongation n'est mentionnée. Le successeur est Xperience by Kentico, que Kentico propose « selon des conditions convenues d'un commun accord ». C'est une nouvelle discussion de licence, pas un simple changement de version.

Ce qu'implique la migration

Xperience by Kentico est un autre produit, et le Kentico Migration Tool est honnête sur ses limites : « L'outil ne migre que les modèles de données et le contenu. La migration du code n'est pas prise en charge. »

Ce qu'il migre, selon sa documentation :

  • Les types de pages deviennent des types de contenu. Les pages deviennent des pages de canal web ou des éléments de contenu réutilisables.
  • Les catégories deviennent des taxonomies.
  • Les médiathèques et leurs fichiers, le contenu du Page Builder et les modèles de pages personnalisés (depuis Kentico 13).
  • Les utilisateurs éditeurs et leurs rôles, les contacts et les activités, les consentements.
  • Les classes de modules personnalisés avec leurs données, et les tables personnalisées (sous forme de classes de modules ou d'éléments de contenu).

Ce qu'il ne migre pas :

  • Le code et les personnalisations. Contrôleurs, vues, code des widgets, intégrations, tâches planifiées. Le code qui récupère les pages doit être réécrit pour les éléments de contenu.
  • Les e-mails de réponse automatique et de notification des formulaires. Ils sont recopiés à la main.
  • L'automatisation marketing et les groupes de contacts statiques.
  • Les macros, qui ne fonctionneront plus après la migration, et les autorisations sur les pages.
  • Les médias stockés dans Azure Blob Storage ou Amazon S3. L'outil ne lit les médias que depuis le système de fichiers local.

Deux points pratiques. La source doit être en Kentico 13 Refresh 5 (hotfix 13.0.64) ou supérieur : vérifiez-le d'abord. Et la migration peut être lancée plusieurs fois, avec des transformations de données intégrées ou personnalisées : vous pouvez donc la répéter et affiner le mapping avant la vraie bascule.

Pour dire les choses simplement : le contenu survit, et le site autour est reconstruit. C'est un projet de plusieurs mois, et au 3 octobre, il reste treize semaines avant le 1er janvier. La plupart des sites Kentico 13 tourneront un certain temps sans correctifs. Mieux vaut planifier cette période que la découvrir.

Puisque le code est reconstruit de toute façon, il est légitime de se demander si Xperience by Kentico ou une autre plateforme convient mieux. Rester présente un avantage net : un outil de migration conçu pour votre modèle de contenu. Faites-en une décision, pas un choix par défaut.

Ce que signifie vraiment tourner sans correctifs

Le site continue de fonctionner. Le risque change de forme :

  • La prochaine vulnérabilité reste ouverte. Les correctifs continuent de sortir pour les versions supportées, et leurs avis de sécurité sont publics. Quand une faille corrigée dans une version plus récente existe aussi dans la vôtre, l'avis montre aux attaquants où chercher.
  • La pile vieillit autour du CMS. PHP 8.2 perd son support de sécurité le 31 décembre 2026. .NET 8 perd son support le 10 novembre 2026. Les modules contribués et les packages risquent de cesser d'être testés sur des versions que plus personne ne supporte.
  • La réponse à l'audit change. Si votre politique de sécurité, un questionnaire de cyberassurance ou un marché public demande si votre logiciel est supporté, la réponse honnête devient non.

Si vous devez tourner sans correctifs pendant un temps, réduisez votre exposition : placez l'interface d'administration derrière un VPN ou une liste d'adresses IP autorisées, supprimez les modules inutilisés, ajoutez un pare-feu applicatif web, testez vos sauvegardes et lisez les avis de sécurité de l'éditeur pour la version plus récente. Ces mesures réduisent le risque. Elles ne remplacent pas les correctifs.

Comment décider

  • Drupal 10, surtout des modules contribués : passez à Drupal 11. Dix semaines suffisent si vous commencez ce mois-ci.
  • Drupal 10 avec beaucoup de code spécifique ou un hébergement PHP ancien : réglez d'abord l'hébergement, puis portez le code. Si vous allez déborder, prévoyez une courte période sans correctifs avec le durcissement décrit plus haut.
  • Umbraco 13 avec peu de personnalisations du backoffice : passez à Umbraco 17.
  • Umbraco 13 avec des éditeurs sur mesure, du Nested Content ou du Grid : achetez XLTS pour 6 ou 12 mois et faites la réécriture correctement.
  • Kentico 13 : lancez maintenant le projet de migration, durcissez le site actuel pour janvier, et choisissez la destination sur le fond.
  • Une refonte était prévue de toute façon : laissez la fin de vie servir de déclencheur, et ne portez pas du code que vous êtes sur le point de jeter. Si les gabarits sont reconstruits, c'est aussi le moment le moins coûteux pour corriger l'accessibilité ; notre guide de l'European Accessibility Act explique ce que cela implique pour un site web.

Un calendrier à partir d'aujourd'hui

D'ici la mi-octobre. Faites l'inventaire de chaque site : version exacte du CMS, version de PHP ou de .NET, modules, éditeurs et widgets sur mesure, et compatibilité de chaque module contribué ou package. Sous Drupal, lancez Upgrade Status. Sous Kentico, vérifiez que vous êtes en hotfix 13.0.64 ou supérieur.

D'ici fin octobre. Décidez site par site : mettre à niveau, acheter du temps ou reconstruire. Si vous avez besoin de XLTS, lancez l'achat, puisque la couverture commence le lendemain de la fin de vie.

Novembre. Drupal : passez l'hébergement à PHP 8.3, mettez à niveau en préproduction, testez. Umbraco : passez à .NET 10, mettez à niveau une copie, réécrivez les éditeurs sur mesure, convertissez le contenu Nested Content et Grid. Kentico : appliquez les mesures de durcissement et faites une première répétition de migration.

De fin novembre à début décembre. Mises à niveau en production, avec une marge avant le 9 et le 14 décembre. Si votre organisation gèle les modifications avant les fêtes, planifiez en conséquence.

Janvier 2027. Les sites Kentico tournent durcis pendant que la migration se poursuit.

Où trouver de l'aide

C'est le genre de travail que nous faisons : auditer ce qui est spécifique sur un site hérité, porter des modules Drupal, réécrire des extensions de backoffice Umbraco sous forme de web components, et reconstruire le code qu'un outil de migration laisse de côté. Ce travail relève de notre service de maintenance de systèmes anciens ; si une reconstruction est envisagée, notre service de mise en conformité de l'accessibilité web couvre ce volet.

Si l'une de ces dates est la vôtre et que vous ne savez pas exactement ce qu'il y a sous le capot, écrivez à office@c9group.dev.