Drupal 11.4 : nouveautés par rapport à 11.3 | Droptica

Quoi de neuf dans Drupal 11.4 : panorama des changements par rapport à 11.3

Drupal
Droptica Team
Droptica Team
05.06.2026

Drupal 11.4 est la prochaine version mineure de la branche 11.x, avec une sortie stable prévue pour la semaine du 22 juin 2026. Elle ne casse pas la compatibilité ascendante des API publiques, mais apporte des améliorations concrètes : routing par attributs PHP, nouveau bootstrap basé sur Symfony Runtime, compression Brotli des assets, changements SEO dans robots.txt et une liste de dépréciations à traiter dans les modules custom.

La version 11.4.0-beta1 est déjà disponible (depuis le 3 juin 2026), vous pouvez donc tester dès maintenant l’ensemble des changements décrits ci-dessous — la bêta n’est toutefois pas recommandée en production. Voici ce qui change réellement par rapport à Drupal 11.3.

Dans cet article :

Quand Drupal 11.4 sort et combien de temps il sera supporté

Drupal 11.4.0-beta1 a été publié le 3 juin 2026, et la version stable 11.4.0 est prévue pour la semaine du 22 juin 2026 (selon le calendrier officiel mis à jour le 4 juin 2026 ; le décalage de beta1 a repoussé l’ensemble du cycle). Il s’agit d’une version mineure : elle ajoute des fonctionnalités et des améliorations sans casser la compatibilité ascendante des API publiques. Les API internes et les modules expérimentaux peuvent toutefois évoluer, ce qui peut nécessiter des mises à jour de modules contrib et custom.

Les dates de support comptent. La branche 11.4.x recevra un support sécurité jusqu’en juin 2027, et la branche 11.3.x jusqu’en décembre 2026. La sortie de 11.4 marque aussi la fin du support sécurité pour 11.2.x et 10.5.x. L’ensemble de la ligne Drupal 11 sera supporté jusqu’à la sortie de Drupal 13.

En pratique : si vous êtes sur 11.3, vous avez jusqu’en décembre 2026, mais passer à 11.4 prolonge la fenêtre de sécurité de six mois et reste relativement peu coûteux, car c’est une version mineure sans rupture BC. Si vous découvrez cette branche, nous avons décrit les fonctionnalités et la direction de Drupal 11 dans un article dédié.

Routing par attributs PHP, la grande nouveauté pour les développeurs

Le changement le plus intéressant pour les développeurs en 11.4 est la possibilité de définir des routes directement en PHP via des attributs, et non plus uniquement dans des fichiers *.routing.yml. Toute classe du namespace Controller d’un module (par ex. Drupal\example\Controller) portant l’attribut Symfony\Component\Routing\Attribute\Route est enregistrée comme définition de route.

L’attribut #[Route] peut être appliqué au niveau de la méthode et de la classe, où il définit des valeurs par défaut partagées. Les clés defaults, requirements et options sont fusionnées (le niveau méthode prime), tandis que name et path sont concaténés — vous pouvez ainsi définir un préfixe au niveau classe et des suffixes sur les méthodes. Les routes basées sur la méthode __invoke sont également prises en charge.

Le mécanisme a aussi été étendu aux formulaires. Les classes implémentant Drupal\Core\Form\FormInterface dans le namespace Form d’un module, annotées avec l’attribut Route au niveau classe, sont détectées comme définitions de routes. L’attribut doit être sur la classe ; les attributs sur les méthodes de formulaire sont ignorés. Les routes de formulaires d’entités doivent toujours être définies via le route provider dans la définition du type d’entité.

Ce mécanisme complète, sans remplacer, les déclarations dans *.routing.yml. Pour les équipes qui écrivent beaucoup de code custom, cela signifie moins d’allers-retours entre fichiers YAML et classes PHP, et des définitions de routes plus proches de la logique du contrôleur.

Symfony Runtime et le nouveau bootstrap

Drupal 11.4 adopte le composant symfony/runtime pour simplifier et séparer le processus de bootstrap. Pour la plupart des sites, ce changement reste invisible, mais si vous avez un front controller custom (index.php ou autre script d’entrée), il vaut la peine de lire le change record dédié, car la façon dont l’application est initialisée évolue.

Bonne nouvelle : les front controllers existants continueront de fonctionner au moins jusqu’à Drupal 12, donc pas de pression pour tout réécrire immédiatement. C’est surtout un signal sur la direction de l’architecture bootstrap.

Par ailleurs, symfony/polyfill-php86 a été ajouté, de sorte que certaines fonctions introduites en PHP 8.6 sont disponibles dans Drupal 11.4, quelle que soit la version PHP sur le serveur.

Performance : Brotli, recipes plus rapides et nouveau cache

La performance est l’un des points forts de cette version.

  • Compression Brotli pour CSS et JS. Drupal génère désormais des versions .br (Brotli) des fichiers CSS et JS agrégés si le serveur dispose de l’extension PHP ext-brotli. Cela fonctionne en parallèle du gzip existant, et Brotli offre généralement 15–25 % de compression en plus, donc des fichiers plus légers et un chargement plus rapide. La configuration a aussi été unifiée : les réglages system.performance.css.gzip et js.gzip sont remplacés par css.compress et js.compress, et un hook post-update (system_post_update_migrate_compress_setting()) migre automatiquement les anciens réglages. Sur Apache, cela fonctionne out of the box (le .htaccess mis à jour sert les .br avec repli sur gzip) ; sur Nginx, ajoutez une configuration avec la directive brotli_static (module ngx_brotli requis).
  • Système de recipes plus rapide. Les performances du système de recipes ont été améliorées en installant les extensions par lots. Les développeurs devraient utiliser RecipeRunner::installModules(), qui traite plusieurs modules en une seule passe.
  • Nouveau bin de cache cache.file_parsing. Un bin dédié au cache persistant des résultats d’analyse de fichiers a été ajouté (avec FileParsingCacheCollectorBase et YamlCacheCollector, utilisés notamment pour libraries.yml et routing.yaml). Contrairement au FileCache basé sur APCu, ce cache survit aux vidages de cache et reste cohérent entre CLI et plusieurs serveurs web, ce qui améliore les temps de réponse en local (vidages fréquents via CLI) et en production juste après un déploiement.
  • Preload des polices. Les définitions de bibliothèques (et les overrides dans les composants SDC) prennent en charge une clé fonts pour précharger les polices. Auparavant, il n’y avait pas d’API officielle pour cela et il fallait ajouter les liens manuellement dans l’en-tête HTML.

Ces changements ont l’avantage de fonctionner en grande partie automatiquement après la mise à niveau. C’est un exemple typique de la façon dont maintenir Drupal à jour se traduit concrètement en performance.

Changements pour les site builders et rédacteurs

Tout ne se passe pas dans le code en 11.4. Quelques changements seront aussi ressentis par les personnes qui construisent et éditent les pages.

  • Nouvelle page de vue d’ensemble « Manage display ». Sous /admin/structure/types/manage/{bundle}/display, une nouvelle page est désormais la destination par défaut de l’onglet « Manage display ». Au lieu d’ouvrir directement le formulaire d’édition du mode d’affichage par défaut, elle liste tous les modes avec label, description et statut activé/désactivé, modifiables depuis cette vue. La page est indépendante d’un builder particulier, ce qui facilite l’intégration de Layout Builder, Drupal Canvas et d’autres outils. Si votre module a des tests fonctionnels qui supposent l’ancien comportement de routing, mettez-les à jour.
  • Nouvelle permission pour voir les blocs non publiés. La permission « view unpublished block content » permet d’accorder aux utilisateurs le droit de voir les entités block content non publiées.
  • Recherche de nœuds en sous-module séparé. Le plugin node_search a été déplacé vers le sous-module search_node du module Search. Si vous avez un plugin custom qui étend \Drupal\node\Plugin\Search\NodeSearch, passez à \Drupal\search_node\Plugin\Search\SearchNode.

À lire aussi : si vous planifiez comment l'IA doit aider les rédacteurs après la mise à niveau, consultez notre guide sur la création de contenu de site web avec les modules IA de Drupal.

SEO et sécurité

Drupal 11.4 améliore plusieurs réglages par défaut qui influencent la visibilité dans les moteurs de recherche et la résilience face aux données invalides.

  • robots.txt bloque les pages de résultats de recherche. Le robots.txt par défaut bloque désormais l’indexation des pages de résultats avec paramètres de requête. Les règles Disallow: /search? et Disallow: /index.php/search? ont été ajoutées. Les moteurs indexaient des résultats dynamiques et parcouraient des combinaisons quasi infinies de pages facettées, ce qui surchargeait le serveur et dégradait la qualité SEO. Si vous avez un robots.txt custom modifié, ajoutez ces règles manuellement.
  • Validation UUID. Le type de champ uuid, utilisé automatiquement pour stocker les UUID des entités de contenu, vérifie désormais que la valeur est un UUID valide.
  • Réponses 404 cacheables. Router::matchRequest() lève désormais CacheableResourceNotFoundException au lieu de ResourceNotFoundException, et un nouveau cache context pour le statut d’exception a été ajouté. En pratique, cela améliore la mise en cache des réponses 404 et 403.

Front-end, Twig et CKEditor

La couche présentation et les projets decoupled bénéficient aussi de quelques améliorations.

  • Fonctions de twig/html-extra. Le paquet twig/html-extra expose les fonctions html_cva, html_attr et html_classes, désormais disponibles dans les templates Twig pour simplifier la construction d’attributs et de classes CSS.
  • CKEditor 5 mis à jour en 47.6.2. L’éditeur a reçu une mise à jour de version ainsi que de nombreuses mises à jour de dépendances front-end.
  • #url dans responsive image devient un objet Url. Dans l’élément de thème responsive_image_formatter, la propriété #url est désormais un objet Drupal\Core\Url et non plus une chaîne, ce qui permet de manipuler les options d’URL.
  • Nouvelle propriété resolvable_uri sur le champ link. Le champ link expose resolvable_uri, qui renvoie un lien prêt pour un attribut href. C’est important pour le decoupled et JSON:API : au lieu d’un internal:/ brut avec fragment séparé, l’API renvoie directement un /#main-content utilisable. Un token [entity:field_link:resolvable_uri] a été ajouté, et définir resolvable_uri initialise les autres propriétés du lien (uri, query, fragment).

Ce qu’il faut savoir avant la mise à niveau

Quelques points à vérifier avant de mettre la production à niveau.

À lire aussi : mise à niveau Drupal étape par étape, préparation et défis courants.

  • Le template drupal/legacy-project est marqué abandoned. Si votre projet repose encore sur drupal/legacy-project, il est temps de passer à drupal/recommended-project.
  • Chemin vers Drupal 12. Les sites doivent être au minimum en 11.3.0 avant une montée vers 12.x, car Drupal 12 a supprimé les update hooks antérieurs à 11.3. Passer à 11.4 vous place dans une bonne position pour cette migration.
  • Validation HTML5. Un réglage enable_html5_validation a été ajouté dans settings.php. Dans Drupal 12, la validation HTML5 sera désactivée par défaut ; définissez cette valeur consciemment pour vos formulaires dès maintenant.
  • Nginx et Brotli. Si vous hébergez sur Nginx et souhaitez la précompression Brotli, ajoutez une configuration serveur avec brotli_static (Apache ne nécessite pas de changement). Vérifiez aussi le code qui définit css.gzip/js.gzip et passez à css.compress/js.compress.
  • Plugins de recherche custom. Si vous avez un plugin basé sur NodeSearch, mettez-le à jour pour le sous-module search_node.

Les principales dépréciations en 11.4

Dans cette version, de nombreux éléments d’API ont été marqués deprecated. Si vous maintenez vos propres modules, planifiez une revue. Les plus importantes :

  • check_markup() est deprecated, sans remplaçant direct. Recommandation : renvoyer un render array plutôt qu’un markup aplati, pour conserver les métadonnées de cacheability.
  • Les fonctions render hide() et show() sont deprecated. Utilisez le flag #printed dans le render array.
  • file_get_file_references() est remplacé par le service FileReferenceResolver.
  • node_access_rebuild() et node_access_grants sont remplacés par des services (dont NodeGrantsHelper).
  • \Drupal\node\Controller\NodeViewController est remplacé par EntityViewController.
  • Les routes user.pass.http, user.login.http, user.login_status.http et user.logout.http ont été déplacées vers le module rest.
  • L’accès à la variable globale autoload est deprecated ; incluez vendor/autoload.php à la place.
  • Plusieurs fonctions locale (locale.batch.inc, locale.bulk.inc, locale.compare.inc) sont remplacées par de nouveaux services, dont LocaleSource, LocaleFileManager et LocaleFetch.

Toutes les dépréciations ont des remplaçants décrits dans les change records sur drupal.org, et le code continue de fonctionner en 11.4. La suppression n’interviendra qu’au prochain major.

Faut-il passer à Drupal 11.4 ?

Sur 11.3, la montée vers 11.4 est un move à faible risque : version mineure, pas de rupture BC sur les API publiques, et en retour un support sécurité plus long (jusqu’en juin 2027), de vrais gains de performance (Brotli, recipes plus rapides, nouveau cache), un meilleur SEO par défaut et un routing plus pratique pour les développeurs.

L’attention la plus forte concerne le code custom : revoir les dépréciations, vérifier un éventuel front controller custom face à Symfony Runtime, et ajouter les règles dans un robots.txt modifié. Pour un site typique basé sur des modules standard, la mise à niveau devrait être rapide et les bénéfices visibles dès le déploiement. Nous avons décrit à quoi ressemble une mise à niveau Drupal bien préparée dans un guide séparé.

Besoin d’aide pour la mise à niveau ou la maintenance Drupal ?

Chez Droptica, nous travaillons avec Drupal depuis plus de dix ans : nous mettons à niveau, maintenons et développons des plateformes enterprise, des intranets et des applications web complexes. Nous savons mener une montée mineure sans interruption et traiter les dépréciations dans le code custom pour que votre projet soit prêt aussi pour Drupal 12.

Si vous planifiez une mise à niveau vers Drupal 11.4 ou souhaitez vous assurer que votre projet est sécurisé et performant, consultez nos services de développement Drupal ou contactez-nous directement pour en discuter.

Check related blog posts