Drupal 12 : Ce Qui Change Et Quand Migrer

Drupal 12 est prévu pour la semaine du 7 décembre 2026, et Drupal 10 atteint sa fin de vie le 9 décembre 2026. Les deux dates figurent sur la même page du calendrier des versions du cœur de Drupal, à deux lignes d’écart, et la plupart des exploitants de sites Drupal 10 n’en ont remarqué aucune. La première alpha de la nouvelle majeure a été taguée le 2 septembre 2026 : cette sortie relève désormais du fait établi, non de la spéculation.

Cette collision fait toute l’histoire. L’arrivée d’une majeure n’est en principe pas urgente pour un exploitant, puisqu’on peut rester un an ou deux sur la précédente pendant que l’écosystème rattrape. Cette fois, la majeure précédente cesse de recevoir des avis de sécurité la semaine même où la nouvelle sort, ce qui transforme un événement technique en échéance à portée réglementaire.

Voici le calendrier publié par drupal.org, ce qui change réellement dans le code, ce que les nouveaux planchers imposent à votre hébergement, les trois parcours réalistes avec leurs fourchettes de coût, et un plan construit à rebours depuis décembre. La partie rassurante arrive tôt : un saut de version majeure sous Drupal, c’est surtout de la suppression, pas de la réinvention.

Quand sort Drupal 12, et suis-je obligé de migrer ? Drupal 12.0.0 est prévu pour la semaine du 7 décembre 2026, publié en même temps que Drupal 11.5.0. Drupal 10 atteint sa fin de vie deux jours plus tard, le 9 décembre 2026, et plus aucun avis de sécurité n’est émis ensuite. Un site Drupal 11 n’a qu’une petite mise à niveau devant lui. Un site Drupal 10 doit d’abord passer par Drupal 11.4 ou plus récent : le travail se fait en deux sauts, pas en un.

Les deux dates qui décident de vos six prochains mois

Les gestionnaires de version publient tout le cycle à l’avance, et celui-ci est d’une netteté inhabituelle. Drupal 11.4.0 est sorti la semaine du 29 juin 2026, et cette version a mis fin au support de sécurité de Drupal 11.2.x et de Drupal 10.5.x. Le tag 12.0.0-alpha1 est parti le 2 septembre 2026. Les exigences de bêta devaient être satisfaites au 11 septembre 2026, avec 12.0.0-beta1 et 11.5.0-beta1 la semaine du 14 septembre et les versions candidates la semaine du 9 novembre.

La semaine du 7 décembre fait ensuite trois choses à la fois. Drupal 12.0.0 sort, Drupal 11.5.0 sort à ses côtés, et le support de sécurité s’arrête pour Drupal 11.3.x et Drupal 10.6.x. Deux jours plus tard, le 9 décembre 2026, Drupal 10 dans son ensemble atteint sa fin de vie et plus aucune version n’en sera publiée.

Pourquoi Drupal 10 et Drupal 12 arrivent la même semaine

C’est une politique, pas une coïncidence. La présentation du processus de publication indique que les versions majeures arrivent tous les deux ans, les années paires, et que chaque majeure est supportée au minimum quatre ans, jusqu’à ce que deux autres majeures soient parues. Drupal 10.0.0 est sorti le 15 décembre 2022. Drupal 11 est arrivé en août 2024 et Drupal 12 arrive en décembre 2026, soit la deuxième majeure suivante, et quatre ans se sont écoulés. Le compte à rebours s’est achevé exactement comme prévu.

La même politique régit les versions mineures. Chaque mineure est supportée un an, avec correctifs de bogues et de sécurité les six premiers mois, puis correctifs de sécurité seuls les six derniers. Voilà pourquoi seule 10.6.x reçoit encore des avis aujourd’hui, et pourquoi 11.3.x perd sa couverture à l’instant où 11.5.0 sort.

Drupal 11 ne s’arrête pas quand Drupal 12 commence. Publier 11.5.0 la même semaine ouvre ce que la politique appelle la phase de support à long terme : la majeure précédente conserve une mineure alignée sur la même API, passe sur une version LTS de Symfony et reçoit une mineure de maintenance tous les six mois, au périmètre réduit. Drupal.org ne publie pas de date ferme de fin de vie pour Drupal 11, mais sa propre documentation sur les extensions dépréciées annonce un support jusqu’au milieu ou à la fin de 2028.

Combien de sites restent sur Drupal 10

Les chiffres sont publics et ils ne sont pas confortables. Les statistiques d’usage du cœur de drupal.org, pour la semaine du 23 août 2026, recensent 468 877 sites déclarant une version du cœur. Parmi eux, 205 568 tournent sur une branche de Drupal 10 et 168 857 sur Drupal 11. Environ 44 % de la base installée déclarante utilise la version qui cesse de recevoir des avis en décembre.

Le chiffre le plus tranchant est à l’intérieur de celui-là. Seule 10.6.x conserve une couverture de sécurité, et 10.6.x représente 139 911 de ces sites. Les 65 657 restants sont sur 10.0 à 10.5 : ils exploitent donc déjà aujourd’hui, en septembre, une mineure non supportée, sans attendre décembre.

Ces comptages proviennent de sites qui se déclarent volontairement via le module Update Status, la population réelle est donc plus grande et penche dans le même sens. Concrètement, un très grand nombre d’organisations vont tenter de réserver le même travail au même trimestre, et la capacité des agences en octobre et novembre sera la contrainte, davantage que le code.

Ce que la fin de vie signifie vraiment pour un site Drupal

La fin de vie n’est pas un interrupteur qui casse le site. Votre installation Drupal 10 servira des pages le 10 décembre exactement comme le 8 décembre. Ce qui change, c’est que l’équipe de sécurité de Drupal cesse de publier des avis et des correctifs pour ce code : à partir de cette date, toute vulnérabilité nouvellement découverte dans le cœur de Drupal 10 reste ouverte définitivement.

Le deuxième effet est plus lent et fait davantage de dégâts. La couverture de sécurité d’un module contribué dépend de l’existence d’une version stable sur une branche du cœur supportée. À mesure que les mainteneurs abandonnent la compatibilité Drupal 10, les modules de votre site quittent donc discrètement le processus d’avis eux aussi. Vous n’êtes pas prévenu. Le module cesse simplement d’apparaître dans les publications de sécurité, et le rapport des mises à jour disponibles sur votre propre site continue de s’afficher en vert.

Le troisième effet, c’est que la sortie coûte plus cher à mesure que vous attendez. Un site Drupal 10 mis à niveau en novembre l’est contre une branche du cœur maintenue, avec un chemin de mise à jour fonctionnel. Le même site mis à niveau en juin suivant devient un projet de sauvetage, parce que les modules contribués dont il dépend ont eu six mois de plus pour avancer sans lui.

Cyber Essentials, assurances et clauses contractuelles

C’est ici qu’un CMS non supporté cesse d’être une question d’ingénierie. Les exigences Cyber Essentials pour l’infrastructure informatique v3.3 du NCSC, datées d’avril 2026, indiquent que tout logiciel présent sur les appareils du périmètre doit être sous licence et supporté, et doit être retiré des appareils dès qu’il cesse de l’être, ou sorti du périmètre au moyen d’un sous-ensemble défini qui bloque tout trafic depuis et vers Internet. Le contrôle s’applique aux serveurs, à l’IaaS, au PaaS et au SaaS : une installation Drupal sur un serveur du périmètre est donc pleinement concernée.

Un site Drupal 10 accessible au public ne peut pas être coupé d’Internet. Après le 9 décembre 2026, les deux seules réponses possibles sont de le mettre à niveau ou d’accepter qu’il échoue à ce contrôle. Si votre organisation détient Cyber Essentials ou Cyber Essentials Plus et le renouvelle chaque année, la question vous sera posée par écrit lors de la prochaine évaluation.

Restez prudent sur ce que vous affirmez au-delà. Qu’une police de cyberassurance ou un contrat client précis soit affecté dépend entièrement de sa rédaction, et les clauses qui comptent exigent en général un logiciel supporté ou des versions maintenues par l’éditeur, plutôt que de nommer Drupal. Lisez votre propre police et vos propres contrats-cadres avant décembre plutôt qu’après un incident, car c’est le moment où cela coûte le moins cher.

Ce qui change réellement dans Drupal 12

Très peu de choses, et c’est la réponse honnête et utile. Les notes de version de 12.0.0-alpha1 le disent sans détour : 12.0.x sera presque identique à 11.5.x, à ceci près que le code déprécié est supprimé, modules dépréciés entiers compris, que les dépendances passent à de nouvelles versions majeures et que les prérequis système sont relevés. Pour tout le reste, les notes renvoient à la branche 11.5.x.

Il existe une poignée de vrais changements de comportement à connaître. L’algorithme de hachage des mots de passe par défaut passe à argon2id, bcrypt restant disponible via les paramètres du kernel là où argon2 manque. Le fichier robots.txt du cœur bloque désormais les pages de résultats de recherche portant des paramètres d’URL, ce qui empêche les moteurs d’explorer des combinaisons à facettes infinies ; les sites ayant un robots.txt personnalisé doivent ajouter ces règles à la main. HTMX, que le cœur embarque déjà, passe de la version 2 à la version 4 pour la bêta 1.

Un dernier point est facile à manquer. Héberger Drupal directement sous Windows en production est déprécié dans Drupal 12, au motif qu’il n’existe pas d’environnement de test Windows automatisé et que peu de développeurs y testent. Windows reste supporté pour le développement local. Si votre production tourne sous Windows, c’est une décision d’hébergement à prendre dans les prochains mois, pas une modification de code.

Les extensions qui quittent le cœur

Drupal sort depuis des années les modules étroits du cœur vers des projets contribués, et Drupal 12 poursuit ce mouvement. Les notes de l’alpha 1 listent Ban, Contact, Field Layout, History, Settings Tray, Shortcut et Telephone comme supprimés, ainsi que le thème Stable 9. Le plugin de champ Text with Summary est lui aussi parti dans son propre module contribué. Ban avait été déprécié dès 11.3, Contact, Field Layout, History et Telephone en 11.4, et Settings Tray, Shortcut et Text with Summary en 11.5.

Deux d’entre eux surprendront. Shortcut et Settings Tray sont des fonctions d’administration qu’un très grand nombre d’équipes éditoriales utilisent au quotidien sans jamais les voir comme optionnelles, et Settings Tray en particulier porte la configuration des blocs en place, sur laquelle les rédacteurs s’appuient.

La mécanique compte plus que la liste. Le bon geste consiste à ajouter la version contribuée à vos dépendances Composer avant de migrer, et non à désinstaller le module. Désinstaller détruit la configuration de l’extension, et la découverte des modules par Drupal regarde le cœur en dernier : dès que le projet contribué est présent, Drupal l’utilise tout simplement. Notez aussi que Drush peut contourner les avertissements d’update.php sur les extensions manquantes, l’échec apparaissant alors après coup sous forme d’erreurs dans le rapport d’état.

La perte de Migrate Drupal est le changement qui fait le plus mal

Les modules Migrate Drupal et Migrate Drupal UI sont supprimés dans Drupal 12 et, contrairement aux autres, ils ne sont pas déplacés vers un projet contribué. Drupal 12 conserve l’API Migrate et les plugins de destination pour Drupal moderne, mais il ne conserve pas les plugins source pour Drupal 6 et Drupal 7.

Relisez cette phrase si vous possédez un site Drupal 7. L’outillage qui lit une base Drupal ancienne et l’écrit dans une base moderne existe dans Drupal 11 et n’existe pas dans Drupal 12. La consigne de drupal.org est explicite : les sites sous Drupal 6 ou Drupal 7 qui comptent utiliser l’API de migration doivent continuer à migrer vers Drupal 11, puis employer le processus de mise à jour ordinaire pour passer de Drupal 11 à Drupal 12.

Une intention vague devient ainsi une contrainte de séquence stricte. Une reconstruction Drupal 7 qui atterrirait après la fin du support de Drupal 11 devrait soit écrire ses propres plugins source, soit restaurer un cœur plus ancien pour lancer la migration dans un environnement jetable, soit exporter et réimporter le contenu autrement. Ces trois options coûtent plus cher que de faire la migration vers Drupal 11 tant que Drupal 11 est une cible courante et maintenue. Notre guide sur les coûts, options et échéances d’une migration Drupal détaille la forme de ce travail.

Les nouveaux planchers de dépendances

Une version majeure est le moment où Drupal a le droit de relever ses prérequis de plateforme, et Drupal 12 en use largement. Ces planchers sont la part de la mise à niveau qui ne se négocie pas, parce qu’ils sont imposés à l’installation.

PHP 8.5, et rien de plus ancien

Drupal 12 exige PHP 8.5. Le tableau des prérequis PHP montre Drupal 12.0 supportant PHP 8.5 et refusant tout ce qui est en dessous, tandis que Drupal 11.3 et 11.4 acceptent 8.3, 8.4 et 8.5. Ce recouvrement est votre itinéraire de migration : passez le site à PHP 8.5 pendant qu’il est encore sous Drupal 11.4, vérifiez son comportement, puis changez de version de Drupal.

Le plancher est généreux plutôt que punitif. PHP 8.5 est sorti le 20 novembre 2025, et la page des versions supportées de php.net place son support actif au 31 décembre 2027 et son support de sécurité au 31 décembre 2029. S’y poser achète trois ans avant que cette conversation ne revienne.

Bases de données et Symfony

Les prérequis du serveur de base de données pour Drupal 12 sont MySQL 8.0 ou plus récent, MariaDB 10.11 ou plus récent, PostgreSQL 18 ou plus récent, et SQLite 3.45 avec l’extension json1. Les sites PostgreSQL doivent vérifier ce plancher avec soin, car les notes de version de l’alpha 1 annoncent PostgreSQL 19 alors que la page des prérequis et le code de l’installeur indiquent tous deux 18. Revérifiez à la bêta 1 avant de réserver des travaux sur la base.

En dessous, Symfony passe de 7.4 à 8.1 et Guzzle de 7 à 8. Le support est abandonné pour plusieurs majeures de bibliothèques plus anciennes, dont doctrine/lexer 2, egulias/email-validator 3 et guzzlehttp/psr7 2. Le code sur mesure qui type directement des classes Symfony est l’endroit où cela se voit.

Ce que les planchers imposent à votre hébergement

Le saut de MariaDB est celui qui piège les hébergeurs mutualisés et infogérés. Drupal 11 accepte MariaDB 10.6, dont la maintenance communautaire s’est achevée le 6 juillet 2026 selon la politique de maintenance de MariaDB : un site Drupal 11 peut donc actuellement reposer, en toute légitimité, sur un moteur de base non supporté. Drupal 12 relève le plancher à 10.11, maintenue jusqu’au 16 février 2028. Si votre hébergeur ne propose pas aujourd’hui PHP 8.5 et MariaDB 10.11, le déménagement doit précéder le changement de Drupal, et c’est ce réordonnancement qui transforme un chantier de deux semaines en chantier de deux mois. Notre note sur ce qui fait vraiment tourner Drupal couvre le volet plateforme.

Pourquoi le modèle de dépréciation rend Drupal 12 abordable

Voici le mécanisme que la plupart des exploitants n’ont jamais eu l’occasion de se faire expliquer, et c’est la raison pour laquelle les majeures de Drupal ne font plus peur. La politique de mises à niveau continues engage le cœur sur une promesse simple : la prochaine version majeure a la même API publique que la dernière mineure de la majeure précédente. Les nouvelles API arrivent dans les mineures, les anciennes y sont marquées comme dépréciées, et la suppression n’a lieu qu’à la frontière de majeure.

La conséquence pratique mérite d’être dite clairement. Si votre code sur mesure et vos modules contribués tournent sur Drupal 11.5 sans avertissement de dépréciation, ils tournent sur Drupal 12. La mise à niveau cesse d’être une réécriture pour devenir une montée de dépendances plus une mise à jour de base, parce que tout ce qui aurait cassé vous avait déjà été signalé des mois plus tôt sous forme d’avertissement que vous pouviez traiter à loisir.

C’est aussi pourquoi les notes de version demandent de passer d’abord en 11.4 ou plus récent, et recommandent fortement 11.5. Le chemin de mise à jour de base depuis les versions antérieures à 11.4.0 a été purement et simplement retiré de Drupal 12 : un site en 11.3 ou plus ancien n’a donc aucune route vers la 12 tant qu’il n’est pas remonté dans la branche 11. Ce n’est pas un conseil, c’est un chemin de code absent.

Les outils qui signalent les dépréciations

Deux projets font le travail, et tous deux sont maintenus aujourd’hui. Upgrade Status est le scanner qui couvre tout le site. Vous l’installez sur le site depuis lequel vous migrez, pas sur celui vers lequel vous migrez, car les API dépréciées doivent exister pour qu’il puisse en trouver les appels. Il vérifie si votre environnement satisfait les prérequis système de la majeure suivante, recoupe vos projets contribués avec les mises à jour disponibles, exécute PHPStan pour l’usage d’API PHP dépréciées, et lit les gabarits Twig, les fichiers info.yml, composer.json et les clés de configuration dépréciées. La version 5.0.0-alpha3, du 2 juillet 2026, déclare la compatibilité avec Drupal 10.4, 11 et 12.

Il classe aussi ce qu’il trouve, et c’est la partie qui fait économiser de l’argent. Les problèmes sont triés entre ceux qu’une machine peut corriger et ceux qui réclament une personne, ce qui vous permet de chiffrer la moitié manuelle avant de vous engager sur une date. Il s’exécute sous Drush avec upgrade_status:analyze, et sa sortie JSON au format Code Climate s’intègre à GitLab CI.

Drupal Rector est l’autre moitié. Il réécrit les dépréciations mécaniquement corrigeables dans vos modules et thèmes sur mesure, avec une option --dry-run pour prévisualiser le diff. La version 1.1.2 est sortie le 7 août 2026. À eux deux, ils permettent à un développeur compétent de produire un rapport d’aptitude défendable pour un site de taille moyenne en deux à trois jours.

Parcours un : de Drupal 11 à Drupal 12

Si vous êtes en Drupal 11.4 ou 11.5 avec des modules contribués à jour, c’est un petit chantier. Le guide officiel de mise à niveau tient surtout en commandes Composer : exiger les métapaquets de la version 12 avec --no-update, retirer toute exigence explicite de drupal/core, lancer composer update --dry-run, puis l’exécuter pour de bon et appliquer les mises à jour de base avec drush updatedb.

Le vrai travail se situe de part et d’autre. Avant : lancer Upgrade Status, ajouter les remplaçants contribués de chaque extension du cœur retirée que vous utilisez réellement, et confirmer que votre hébergeur propose PHP 8.5. Après : attendez-vous à ce que chaque fichier d’échafaudage du cœur ait changé, .htaccess compris, donc toute personnalisation qui les touche doit être réappliquée délibérément plutôt que fusionnée à l’aveugle.

Quand une dépendance refuse de se résoudre, composer why-not drupal/core ^12 nomme le bloqueur. Autoriser deux majeures d’un module dans composer.json, par exemple "^6.1 || ^7.0", est la façon habituelle de faire le pont pour un projet en pleine transition. Si vous avez besoin d’un module qui dispose d’un correctif fonctionnel mais d’aucune version taguée, le point d’accès Composer Drupal Lenient existe précisément pour cela et reste maintenu.

Parcours deux : de Drupal 10 à Drupal 12, en deux sauts

Il n’existe aucune mise à niveau directe de Drupal 10 vers Drupal 12. La documentation d’Upgrade Status le dit explicitement, et le retrait du chemin de mise à jour antérieur à 11.4 l’impose. Vous passez de Drupal 10.6 à Drupal 11.4 ou 11.5, vous vérifiez le site, puis vous passez de là à Drupal 12.

Bien planifié, cela ne fait pas le double de travail. Le saut de Drupal 10 vers Drupal 11 porte presque tout le risque, car c’est là que vivent les problèmes de compatibilité des modules contribués et là que le code sur mesure rencontre les API retirées. Le second saut est le petit, décrit plus haut. Les équipes qui tentent de comprimer les deux dans une seule fenêtre de changement finissent en général incapables de dire lequel des deux a cassé quelque chose.

La séquence qui fonctionne consiste à faire le saut vers Drupal 11 maintenant, à laisser tourner le site en 11.4 ou 11.5 plusieurs semaines pour que le comportement réel des rédacteurs et du trafic fasse remonter les anomalies, puis à prendre Drupal 12 en début d’année, une fois que les modules contribués auront tagué des versions stables. Que le premier saut ait lieu avant décembre, voilà ce qui compte, car c’est celui qui vous sort du code non supporté.

Parcours trois : Drupal 7 ou 8, une reconstruction et non une mise à niveau

Tout ce qui est antérieur à Drupal 9 relève d’un autre exercice. Drupal 7 a atteint sa fin de vie le 5 janvier 2025 et Drupal 6 en février 2016. Ni l’un ni l’autre ne se met à niveau sur place, car ils précèdent entièrement l’architecture moderne. On les migre : un nouveau site est construit sur Drupal courant et le contenu y est déplacé avec l’API Migrate. Un site Drupal 8 dispose techniquement d’une route sur place, mais elle traverse quatre majeures consécutives et chaque module contribué doit survivre à chacune, si bien qu’il est normalement moins coûteux de le traiter aussi comme une reconstruction.

Le coût est dominé par tout ce qui n’est pas du contenu. Le thème est reconstruit, les modules sur mesure sont réécrits contre une API entièrement différente, et les intégrations sont rebranchées. D’après notre expérience, la migration de contenu elle-même est le plus souvent la plus petite moitié du budget, ce qui est l’inverse de ce qu’attendent la plupart des exploitants en demandant un devis, et c’est la raison pour laquelle nous cadrons ces projets comme du développement web plutôt que comme des mises à niveau.

Pour ces sites, l’échéance de décembre agit autrement mais mord tout de même, à cause du retrait de Migrate Drupal. Votre cible doit être Drupal 11, pas Drupal 12, et Drupal 11 est supporté jusqu’au milieu ou à la fin de 2028 selon la documentation de drupal.org. Cela laisse au propriétaire d’un site Drupal 7 une vraie fenêtre, mais une fenêtre à fin ferme, et lancer en 2028 une reconstruction de six mois pour viser une échéance en 2028 n’est pas un plan.

Ce que coûte chaque parcours au Royaume-Uni

Ce sont des estimations maison, pas des tarifs publiés, et l’écart dans chaque fourchette tient presque entièrement à la santé des modules contribués plutôt qu’à la taille du site. Les agences britanniques facturent environ 600 à 900 livres par jour. Une mise à niveau de Drupal 11 vers 12 sur un site entretenu prend trois à huit jours, tests compris, soit environ 2 000 à 6 000 livres. Sur le même site avec des modules contribués vieillissants, comptez deux à quatre semaines et 6 000 à 12 000 livres.

Un site Drupal 10 paie les deux sauts. Bien entretenu, le saut vers Drupal 11 coûte 6 000 à 15 000 livres et celui vers Drupal 12 ajoute 2 000 à 6 000 livres, soit 8 000 à 21 000 livres au total sur quatre à huit semaines. Négligé, le premier saut revient seul à 15 000 à 35 000 livres, et le total se situe entre 17 000 et 41 000 livres. Une reconstruction Drupal 7 prend trois à six mois et coûte couramment 40 000 à 120 000 livres, davantage pour un site volumineux ou très personnalisé.

L’audit des modules contribués qui fixe votre date

Les projets de mise à niveau meurent rarement à cause du cœur. Ils meurent sur le quatorzième module de la liste, celui dont personne ne se rappelle l’installation, qui n’a aucune version compatible avec la majeure suivante et dont le mainteneur s’est exprimé pour la dernière fois en 2023. Faites cet audit avant de vous engager sur une date, car c’est lui qui produit la date.

Lancez Upgrade Status, exportez le rapport, puis triez vos modules en quatre paniers. Le premier réunit les projets ayant une version stable qui supporte la majeure visée, et ceux-là ne coûtent rien. Le deuxième réunit les projets ayant un correctif ou une version de développement dans la file des tickets, qui coûtent un peu d’intégration et portent le risque que le correctif n’aboutisse jamais. Le troisième réunit les projets ayant un ticket ouvert sans correctif, pour lesquels quelqu’un doit en écrire un. Le quatrième réunit les projets sans la moindre activité.

Le quatrième panier fixe votre calendrier, et sa taille est connaissable aujourd’hui plutôt qu’en novembre. Un site comptant trente modules contribués et rien dans le quatrième panier est un chantier simple. Le même site avec quatre modules dans le quatrième panier est un tout autre engagement, avec un tout autre budget, et l’écart entre ces deux devis se joue sur une journée d’analyse.

Que faire d’un module abandonné

Il existe quatre options honnêtes et la bonne dépend de ce que fait le module. Le retirer, si la fonction qu’il apporte n’est plus utilisée, ce qui est vrai plus souvent que les équipes ne le pensent après plusieurs années de dérive éditoriale. Le remplacer par un projet maintenu qui rend le même service, en acceptant la migration de configuration qui va avec.

En reprendre la maintenance, une option bien réelle sous Drupal et moins intimidante qu’il n’y paraît. Drupal.org documente une procédure pour devenir mainteneur d’un projet non supporté, et pour un petit module dont votre activité dépend, l’adopter peut revenir moins cher que le remplacer. Le coût est récurrent plutôt que ponctuel, alors budgétez-le honnêtement.

Ou réimplémenter le comportement dans un module sur mesure limité à ce que vous utilisez vraiment. Un module contribué résout le cas général pour tout le monde, alors qu’il vous en faut d’ordinaire une tranche étroite. Réimplémenter cette tranche contre les API actuelles représente souvent deux jours de travail contre deux semaines de portage, et cela supprime la dépendance définitivement. Nos conseils pour recruter un développeur Drupal expliquent comment évaluer quelqu’un sur exactement ce genre de jugement.

Un calendrier à rebours depuis le 9 décembre 2026

Partez de la date de fin et le plan s’écrit tout seul. D’ici fin septembre, lancez Upgrade Status contre Drupal 12 sur une copie de la production et posez les quatre paniers sur le papier. C’est un exercice de deux à trois jours, et c’est le seul artefact qui permette de chiffrer honnêtement tout le reste.

D’ici mi-octobre, confirmez que votre hébergement peut fournir PHP 8.5 et les planchers de base de données, et lancez le déménagement dans le cas contraire. Tranchez aussi les questions de modules contribués, car chacune porte un délai. D’ici début novembre, la mise à niveau vers Drupal 11.4 ou 11.5 doit être terminée sur un site Drupal 10, le site tournant en production sur la nouvelle branche.

D’ici début décembre, vous regardez sortir la 12.0.0 au lieu d’y réagir. Si vous êtes alors sur Drupal 11, prenez Drupal 12 en janvier ou février 2027, une fois que les projets contribués auront tagué des versions stables. Aucun prix n’est décerné pour une mise à niveau la semaine de la sortie, et Drupal 11.5 restera supportée. Le prix est décerné pour ne plus être sur Drupal 10 quand les avis s’arrêtent.

Ce que coûte l’inaction

Le coût direct, c’est que toute vulnérabilité du cœur de Drupal divulguée après le 9 décembre 2026 reste ouverte indéfiniment sur votre site. L’historique des avis de Drupal comporte des exécutions de code à distance assez graves pour avoir été exploitées dans les heures suivant leur publication, et un CMS non corrigé sur une adresse publique est trouvé par des scans automatisés, pas par un attaquant ciblé qui vous aurait choisi.

Les coûts indirects arrivent plus tôt et sont d’habitude plus lourds. Échouer au contrôle sur les logiciels supportés lors d’une évaluation Cyber Essentials peut affecter l’éligibilité à des marchés qui exigent la certification, ce qui est courant dans la commande publique britannique. Les modules contribués cessent de livrer des correctifs pour votre branche. Et la mise à niveau elle-même se renchérit chaque mois, parce que l’écart entre votre base de code et l’écosystème maintenu se creuse sans que personne ne touche à rien.

Il existe un coût plus discret. Un site que personne n’a le droit de mettre à niveau devient en général un site que personne n’a le droit de modifier, et le travail fonctionnel s’arrête, parce que chaque changement devrait s’écrire contre une API en voie de disparition. C’est ainsi qu’un site Drupal de cinq ans devient une reconstruction plutôt qu’une mise à niveau. Si vous pesez cette décision, notre guide du développement web Drupal est un meilleur point de départ qu’un devis.

Deux raisons légitimes d’attendre

Attendre se défend dans deux situations, et seulement si l’attente est délibérée. La première, c’est que vous êtes déjà en Drupal 11.4 ou 11.5. Ces branches sont supportées, ce sont les rampes de lancement prévues pour Drupal 12, et il n’y a aucun avantage à prendre une majeure toute neuve dans ses premières semaines pendant que les projets contribués taguent encore leurs versions. Attendre le premier trimestre 2027 est le choix professionnel, pas le choix paresseux.

La seconde, c’est un site Drupal 7 dont la reconstruction est déjà financée et planifiée. Migrer Drupal 7 vers Drupal 11 puis immédiatement vers Drupal 12 est un mouvement gaspillé. Posez-vous sur Drupal 11, exploitez-le, et prenez Drupal 12 plus tard comme une maintenance ordinaire.

Ce qui ne se défend pas, c’est de rester sur Drupal 10 sans plan réservé. Si c’est votre cas, la position minimale acceptable d’ici fin septembre est un rapport d’analyse, une branche cible nommée et une date dans un agenda. Tout le reste peut bouger. Si vous voulez faire réaliser cette évaluation par quelqu’un qui l’a déjà menée, notre équipe de développement logiciel traite les audits de version comme une prestation à périmètre fixe.

Par où commencer

Faites l’analyse d’abord. Presque tous les mauvais devis de mise à niveau Drupal qui existent ont été produits sans elle, et c’est pourquoi tant d’entre eux se trompent dans les deux sens. Deux à trois jours de résultats d’Upgrade Status et de Drupal Rector vous disent dans laquelle des cinq fourchettes ci-dessus vous vous trouvez réellement, et ce seul chiffre change la conversation avec votre conseil d’administration plus que n’importe quel discours général sur les versions majeures.

Mecanik réalise ces audits et les mises à niveau qui suivent, sur des sites Drupal 10 face à décembre comme sur des sites Drupal 11 qui préparent un passage plus tranquille en 2027. Le travail sur les modules sur mesure, les intégrations et le nettoyage des dépréciations relève de notre pratique de développement logiciel, tandis qu’une reconstruction ou un déménagement d’hébergement relève du développement web. Si c’est la posture de sécurité qui a mis ce sujet sur votre bureau, commencez par notre note sur les avis de sécurité Drupal et le risque réel, et si le trafic organique vous inquiète pendant un changement de version, l’article sur la configuration technique du SEO Drupal explique ce qu’il faut protéger.

Questions fréquentes

Quand sort Drupal 12 et quand Drupal 10 atteint-il sa fin de vie ? Drupal 12.0.0 est prévu pour la semaine du 7 décembre 2026, publié en même temps que Drupal 11.5.0, et Drupal 10 atteint sa fin de vie le 9 décembre 2026. Les deux dates figurent dans le calendrier des versions du cœur de Drupal. La même semaine, le support de sécurité s’arrête pour les branches mineures 11.3.x et 10.6.x. Drupal 12.0.0-alpha1 a été tagué le 2 septembre 2026.

Puis-je passer directement de Drupal 10 à Drupal 12 ? Non. Le chemin de mise à jour de base depuis les versions antérieures à Drupal 11.4.0 a été retiré de Drupal 12, un site Drupal 10 doit donc passer d’abord en Drupal 11.4 ou plus récent, puis en Drupal 12. Drupal.org recommande 11.5.0 ou supérieur avant le changement de majeure. Prévoyez deux sauts, celui de Drupal 10 vers 11 portant presque tout le risque et tout le coût.

Quels sont les prérequis système de Drupal 12 ? Drupal 12 exige PHP 8.5 et abandonne le support de PHP 8.4 et des versions antérieures. Les planchers de base de données sont MySQL 8.0, MariaDB 10.11, PostgreSQL 18 et SQLite 3.45 avec l’extension json1. Symfony passe à 8.1 et Guzzle à 8.0. Héberger Drupal directement sous Windows en production est déprécié, même si Windows reste supporté pour le développement local.

Qu’y a-t-il vraiment de nouveau dans Drupal 12 par rapport à Drupal 11.5 ? Presque rien, et c’est voulu. Les notes de version de l’alpha 1 indiquent que 12.0.x est presque identique à 11.5.x, hormis le code déprécié supprimé, les majeures de dépendances relevées et les prérequis système rehaussés. Les changements de comportement à retenir sont argon2id comme algorithme de hachage des mots de passe par défaut, HTMX qui passe en version 4, et un robots.txt du cœur qui bloque les pages de résultats de recherche portant des paramètres d’URL.

Combien coûte une mise à niveau vers Drupal 12 au Royaume-Uni ? Sur un site Drupal 11 entretenu, trois à huit jours de travail aux tarifs habituels des agences britanniques, de 600 à 900 livres par jour, soit environ 2 000 à 6 000 livres. Un site Drupal 10 paie les deux sauts et se situe entre 8 000 et 21 000 livres s’il est bien entretenu, et entre 17 000 et 41 000 livres s’il est négligé. Une reconstruction Drupal 7 prend trois à six mois et coûte couramment 40 000 à 120 000 livres. Ce sont des estimations maison, pas des tarifs publiés.