Développement Web

Les douze extensions qui quittent le cœur de Drupal 12

La publication de Drupal 12.0.0-beta1, le 30 septembre 2026, fixe la liste définitive. Neuf modules sortent du cœur :

• Ban, Contact, Field Layout, History, Search, Settings Tray, Shortcut, Telephone et Toolbar.

Trois thèmes suivent le même chemin :

• Claro, le thème d'administration historique, Olivero, le thème public par défaut, et Stable 9, le thème de compatibilité des gabarits.

Aucune de ces extensions ne disparaît : chacune devient un projet contribué, publié sur drupal.org et couvert par la politique d'avis de sécurité. Le module Search est par exemple disponible en version 1.0.0 depuis le 17 septembre 2026, compatible ^11.5 || ^12, et Claro en version 3.0.0 depuis le 19 septembre, présentée comme le clone du thème retiré du cœur.

La conséquence est mécanique : ce que le cœur fournissait gratuitement devient une dépendance à déclarer. Pour un site qui utilise la recherche interne et le formulaire de contact, par exemple :

# A executer AVANT la montee, sur un site encore en Drupal 11
composer require drupal/search:^1.0 drupal/contact drupal/claro:^3.0

Le script d'inventaire

Inutile de parcourir la liste des modules à la main. Ce script, à enregistrer dans un fichier puis à exécuter avec Drush, répond en une fois :

<?php
// Extensions retirees du coeur en Drupal 12.
$modules = ['ban', 'contact', 'field_layout', 'history', 'search', 'settings_tray', 'shortcut', 'telephone', 'toolbar'];
$themes = ['claro', 'olivero', 'stable9'];

foreach ($modules as $name) {
  if (\Drupal::moduleHandler()->moduleExists($name)) {
    echo "module actif : $name\n";
  }
}
foreach (\Drupal::service('theme_handler')->listInfo() as $name => $theme) {
  $base = $theme->info['base theme'] ?? NULL;
  if (in_array($name, $themes, TRUE)) {
    echo "theme installe : $name\n";
  }
  if ($base !== NULL && in_array($base, $themes, TRUE)) {
    echo "theme $name herite de $base\n";
  }
}

vendor/bin/drush php:script inventaire-drupal12.php

Une limite à connaître : listInfo() ne renvoie que les thèmes installés. Un sous-thème présent dans le dépôt mais non installé n'apparaîtra pas, d'où l'intérêt de compléter par une recherche dans les fichiers de déclaration :

grep -rn "base theme: \(claro\|olivero\|stable9\)" web/themes

Pourquoi un oubli coûte des données, pas seulement une erreur

C'est le point le plus important des notes de version, et le plus mal compris. Face à un module retiré du cœur, deux gestes semblent équivalents. Ils ne le sont pas du tout.

• Si la fonctionnalité est encore utilisée : il faut ajouter la version contribuée aux dépendances Composer avant la montée, et surtout ne pas désinstaller le module. Les notes sont explicites sur ce point : désinstaller détruirait la configuration et les données de l'extension.
• Si la fonctionnalité n'est plus utilisée : il faut la désinstaller proprement avant la montée, en acceptant la perte de ses données, qui est alors une décision et non un accident.

Le cas de Contact illustre bien l'enjeu. Désinstaller le module supprime les formulaires de contact configurés et les messages stockés. Monter en Drupal 12 sans avoir déclaré drupal/contact laisse le site avec une configuration qui référence un module absent : au mieux une erreur bloquante, au pire une désinstallation en cascade lors des mises à jour de base.

La même logique vaut pour History, qui alimente les marqueurs « nouveau » et « mis à jour » sur les contenus, ou pour Telephone, dont le type de champ est stocké dans la configuration des entités. Un type de champ dont le module n'est plus là, ce sont des données qui deviennent illisibles.

L'ordre des opérations

Il n'y a qu'une séquence correcte, et elle se déroule entièrement en Drupal 11 :

• Inventorier les extensions concernées, modules et thèmes.
• Décider, extension par extension, entre conserver et désinstaller.
• Déclarer dans composer.json les versions contribuées de celles qu'on conserve, et désinstaller les autres.
• Vérifier que le site fonctionne toujours, toujours en Drupal 11.
• Seulement ensuite, monter le cœur en Drupal 12.

La check-list d'inventaire à faire en octobre

Le travail décrit ici se mène sur un site en production, sans rien casser, et peut être fait dès aujourd'hui. Il ne demande pas d'attendre la version finale de Drupal 12.

• Lancer le script d'inventaire sur chaque environnement et noter les extensions concernées.
• Rechercher les sous-thèmes qui héritent de Claro, Olivero ou Stable 9, y compris ceux qui ne sont pas installés.
• Pour chaque extension conservée, vérifier qu'une version contribuée stable et compatible existe, puis l'ajouter aux dépendances.
• Vérifier la version du cœur : une montée depuis Drupal 11.2 ou antérieur est refusée, il faut donc d'abord atteindre 11.4 ou 11.5.
• Demander à l'hébergeur la disponibilité de PHP 8.5, et la date à laquelle il la proposera.
• Vérifier l'état de compatibilité des autres modules contribués avec le module Upgrade Status, qui dispose d'une version alpha couvrant Drupal 12.
• Prévoir le point sur le hachage des mots de passe : Drupal 12 utilise argon2id par défaut, ce qui suppose un PHP compilé avec le support correspondant.

Cet inventaire produit un chiffrage, et c'est tout son intérêt. Un site qui n'utilise aucune des douze extensions et qui est déjà en 11.4 a une montée triviale. Un site avec Search, Contact, un thème d'administration personnalisé et quinze modules contribués à vérifier est un projet à planifier, pas une tâche de maintenance.

Le calendrier qui compte : 7 et 9 décembre 2026

Deux dates se suivent à deux jours d'intervalle, et elles ne concernent pas les mêmes sites.

• Semaine du 7 décembre 2026 : sortie prévue de Drupal 12.0.0 et de Drupal 11.5.0. Drupal 11 reste supporté jusqu'à mi ou fin 2028, au moins jusqu'à la sortie de Drupal 13 : rester en Drupal 11 en décembre est un choix parfaitement défendable.
• 9 décembre 2026 : fin de vie de Drupal 10. Là, il n'y a pas de choix. Un site resté en Drupal 10 ne recevra plus de correctifs de sécurité pour son cœur.

La trajectoire raisonnable se lit donc en deux temps. Les sites en Drupal 10 ont une échéance ferme et doivent viser Drupal 11 avant décembre. Les sites déjà en Drupal 11 n'ont aucune urgence à passer en 12 dès sa sortie, mais tout intérêt à faire leur inventaire maintenant, tant que le sujet est documenté et que les versions contribuées des extensions retirées se stabilisent.

Un dernier point d'organisation : attendre février pour découvrir que le thème d'administration dépend d'un projet contribué sans version compatible, c'est transformer un inventaire d'une heure en projet imprévu. Le coût de cette anticipation est faible, celui de l'improvisation ne l'est pas.

Besoin d'un état des lieux chiffré sur votre site ? Découvrir notre offre de migration Drupal, ou notre contrat de maintenance et TMA Drupal pour que cette veille soit prise en charge.