Drupal CMS 2.0 & Drupal Canvas

Il y a un an, dans mon article sur Drupal CMS 1.0, je concluais en attendant le Drupal Experience Builder annoncé pour la suite. Promesse tenue : Drupal CMS 2.0 est sorti, et l'Experience Builder a désormais un nom officiel — Drupal Canvas.

Pour aller plus loin que les release notes, j'ai monté une sandbox qui reproduit la home d'ipsosenso.com sous Canvas. Voilà ce que j'en retiens.

1. Drupal CMS 2.0

CMS 2.0 reste fidèle à la promesse : démarrer un projet Drupal en quelques minutes. Drupal CMS est un ensemble de recipes — de la config appliquée une fois, modifiable comme dans n'importe quel projet Drupal. Si demain je veux retirer un module ou en ajouter un autre, je le fais. Pas de lock-in, pas d'héritage figé.

Ce qu'on y gagne :

• Drupal Canvas inclus par défaut — c'est l'objet de cet article.
• Site Templates : des starters par cas d'usage (non profit avec Haven, gouvernement avec Convivial Gov, éducation, healthcare, événementiel…). Un pas de plus vers le « démarrer en quelques minutes ».
• Mercury : thème de référence basé Single Directory Components (SDC) + Tailwind 4, fournissant une trentaine de composants prêts à l'emploi.
• Drupal AI : rassemble des modules orientés IA (alt-text, traduction, suggestions) connectables à OpenAI, Claude ou un modèle local.
• Project Browser & Auto-updates : le premier passe en stable, et le second sort enfin du statut expérimental.

Au-delà des features, le shift est stratégique : Drupal core n'a plus à être à la fois un framework et un produit. Core reste le framework pour les devs aguerris qui construisent du sur-mesure. Drupal CMS devient le produit qui rend Drupal accessible aux profils moins expérimentés. C'est la séparation qui débloque tout — fin des débats sans fin sur ce qui doit aller en core.

L'ensemble réduit la distance entre « j'installe Drupal » et « j'ai un site éditable ». Layout Builder n'est pas mort mais devient l'option historique : sur les nouveaux projets, Canvas est la voie par défaut.

2. Drupal Canvas — Visual page builder, version Drupal

Canvas, c'est l'UX d'un Webflow ou d'un Hubspot, mais à l'intérieur de Drupal : panneau de composants à gauche, preview live à droite, drag & drop fluide entre les deux.

Ce qui me convainc, ce n'est pas tant l'UX que le choix d'architecture. Canvas n'invente pas une abstraction propriétaire : il s'appuie sur les Single Directory Components, le standard Drupal Core depuis Drupal 10. Un composant Canvas, c'est un dossier qui contient un .component.yml (props et slots déclarés en JSON Schema) et un .twig.

Canvas est livré vide par défaut, aucun composant fourni. C'est volontaire — Bring Your Own Library. Mercury joue le rôle de starter kit (~30 composants SDC + Tailwind) mais reste un thème contrib remplaçable. C'est exactement ce qui m'a permis d'arriver avec mes 11 composants custom et de m'intégrer sans friction. Le contraste avec les page builders concurrents — où la bibliothèque est figée par l'éditeur — est marqué.

Conséquence directe : pas de lock-in. Si demain Canvas disparaît ou change d'API, mes composants restent utilisables comme n'importe quel SDC. C'est ce qui le rend crédible pour un projet long.

Autre point fort : le versioning par hash de schéma. Chaque modification d'un composant produit un nouveau hash. Les pages existantes restent figées sur leur version, la migration est explicite. On évite l'effet « j'ai cassé la home en renommant un prop » qui hante les builders moins rigoureux.

3. La sandbox — ipsosenso.com sous Canvas

Pour ne pas en rester à la théorie, j'ai pris la home d'ipsosenso.com comme cible et je l'ai entièrement reconstruite sous Canvas. Identité visuelle, animations, gradients, multilingue FR/EN : tout y est.

Le setup :

• Drupal CMS 2.0
• Un thème enfant de Mercury qui ajoute 11 composants SDC custom (navbar, hero-carousel, expertise-card, etc.)
• Le contrib canvas_multilingual pour gérer les traductions dans l'éditeur

Trois enseignements de cette construction :

• Les slots changent la donne. Mon premier hero-carousel avait six props en dur (slide1_title, slide2_title, etc.) — 3 slides max, édition pénible. Refactor en slot : le carrousel expose des slides et on dépose des hero-slide dedans. Le JS s'adapte au nombre d'enfants (les dots se génèrent dynamiquement). La composition libre se gagne en quelques lignes.
• L'intégration aux concepts Drupal classiques se fait par le thème custom. Pour les menus, j'ai écrit un mini module ipsosenso_menu (~80 lignes de PHP) qui expose une extension Twig. La navbar SDC l'appelle, l'admin édite dans /admin/structure/menu comme dans un Drupal standard. Le pattern est transposable à n'importe quelle vue, taxonomie ou référence d'entité.
• Le multilingue tient sans compromis. Page (~34 composants × 2 langues), menus FR/EN, nodes Expertise : tout est traduisible sans dégradation UX ni doublons à gérer à la main.

4. Content Templates

Canvas ne sert pas qu'à composer des Canvas Pages uniques. Il propose un second usage : les Content Templates, gabarits attachés à un content type. Un template défini une fois, partagé par N nœuds, avec des props bindés dynamiquement aux fields.

Dans la sandbox : un content type expertise, un gabarit node.expertise.full, trois nœuds × deux langues = six pages rendues à partir d'un seul gabarit. Côté éditeur lambda, c'est le même geste qu'éditer un article classique — il ignore qu'un Content Template existe en arrière-plan.

C'est ce que j'appelle le combo gagnant : Canvas pour les power-users qui composent (homepage, landings), fields Drupal pour les content editors quotidiens. La cohabitation est naturelle.

5. Les limites

Derrière les promesses, l'outil reste récent et implique quelques contraintes en développement :

• La validation API est stricte : c'est sain en production pour garantir la structure, mais cela ralentit le scripting lors des phases de dev.
• La documentation évolue vite : Canvas reste en bêta, l'écosystème bouge beaucoup et les ressources demandent une veille constante.
• L'autosave et l'écriture programmatique : la sauvegarde automatique est performante mais peut entrer en conflit avec des scripts si une session d'édition est restée ouverte ailleurs.

Conclusion

Pour mes futurs projets Drupal CMS 2.0, Canvas sera le choix par défaut sur les pages où la composition est l'enjeu. Pour les structures rigides, Paragraphs et fields classiques restent pertinents.

Au-delà de Canvas, l'équipe Drupal CMS positionne l'ensemble comme la réponse enterprise au vibe-coding : un site généré rapidement avec une IA, qui peut ensuite scaler avec une vraie gouvernance, des permissions, des workflows et des intégrations tierces sous forme de recipes. C'est le terrain naturel pour Drupal CMS dans les prochaines années.

L'équipe Drupal vise l'intégration de Canvas dans Drupal Core, vraisemblablement pour Drupal 12. Si cette trajectoire tient, Canvas deviendra le standard de fait. On en reparle l'an prochain.

N'hésitez pas à jeter un œil au code source sur mon GitHub : ads6yy/sandbox-drupal-canvas.