Drupal CMS 2.0 en 2026 : Canvas et IA dans le cœur

Drupal CMS 2.0 a été publié le 28 janvier 2026 sur la base de Drupal Core 11.3, le bond de performance le plus marquant que Drupal ait connu en dix ans, avec un gain de capacité serveur estimé entre 26 et 33 % sans changer de matériel. Cette distribution bouscule trois habitudes : elle impose Drupal Canvas (l'ancien Experience Builder) comme outil de composition visuel par défaut, fait entrer l'IA dans le cœur (fabrication de pages, assistant d'administration, textes alternatifs automatiques, via amazee.ai, OpenAI ou Anthropic) et livre des site templates prêts à l'emploi, dont le gabarit « Byte » pensé pour le SaaS, qui raccourcissent fortement la mise en route.

Au fil de cet article, je clarifie d'abord ce que recouvre réellement Drupal CMS (qu'il ne faut pas confondre avec Drupal Core), puis ce que change la version 2.0, jusqu'où vont ses briques d'IA aujourd'hui, dans quels cas la préférer à un Drupal Core classique, et ce qu'il faut anticiper lors d'un passage depuis Drupal CMS 1.x. Mes sources : drupal.org, les communications des core managers et la documentation officielle de Drupal CMS. Pour replacer le tout dans la trajectoire 2026 de Drupal, je vous renvoie à ma roadmap Drupal 12.

Drupal Canvas, qui portait au départ le nom d'Experience Builder, constitue le virage majeur de Drupal CMS 2.0 côté expérience. Concrètement, c'est un atelier de composition visuel en glisser-déposer : les rédacteurs y montent des pages entières sans avoir à mobiliser un développeur à chaque ajustement.

Du côté des rédacteurs

• Pages assemblées en direct : un espace de composition visuel, un rendu mis à jour à la volée, et des blocs ou composants que l'on dépose à la souris.
• Catalogue de composants fondé sur les Single Directory Components (SDC), cohérent avec ce que le développeur a codé.
• Autonomie retrouvée : plus besoin d'appeler le développeur dès qu'il faut retoucher une mise en page ou insérer une section.
• Cadre éditorial intact : circuits de validation, droits et historique de versions s'appliquent exactement comme sur un contenu ordinaire.

Du côté des développeurs

• Ce qui est codé devient utilisable : les SDC écrits par le développeur surgissent directement dans le catalogue Canvas.
• Une seule référence entre design system et code, là où le tandem Layout Builder et Paragraphs avait tendance à s'écarter.
• Davantage d'heures pour le sur-mesure et les connexions externes, moins pour paramétrer des pages courantes.

Face à Layout Builder et Paragraphs

Layout Builder et Paragraphs continuent d'être pris en charge sur les sites en place, mais Canvas leur succède peu à peu sur les nouveaux projets. Il offre une prise en main plus actuelle (glisser-déposer fluide, aperçu instantané), un meilleur alignement entre maquette et code, et une connexion d'origine avec les briques d'IA.

Si un site tourne déjà sous Layout Builder, rien n'oblige à se précipiter. Mais pour tout ce qui se lance en 2026 et au-delà, Canvas est l'option que je recommande, dans la lignée des core managers Drupal.

Quand un site tourne encore en Drupal CMS 1.x, je recommande de viser la 2.0 : c'est le sésame vers Canvas, vers les fonctions d'IA et vers le design system rafraîchi. L'opération se conduit comme une montée de recipe, pas comme une refonte intégrale.

Les points techniques à ne pas négliger

• La compatibilité des modules contribués avec Drupal 11.3, qui sert de socle.
• Le basculement de Layout Builder vers Canvas : reprise des mises en page en place et vérifications visuelles méthodiques.
• Une batterie de tests de non-régression sur les circuits éditoriaux : droits, versions, modération.
• L'ajustement du thème maison le cas échéant, car certains hooks et templates bougent.
• Le multilingue, complet seulement à compter du T1 2026 : à éprouver si le site gère plusieurs langues.

Pour situer tout cela dans le cycle de vie des versions Drupal (10, 11, 12), je vous oriente vers ma roadmap Drupal 12 et mon guide sur la fin de vie de Drupal 10.