J’ai commencé à toucher à Drupal du temps de la version 6. À l’époque, on parlait de hooks partout, de node, de hook_menu(), et monter un site correct demandait de connaître par cœur une API dont la courbe d’apprentissage tenait plus de la falaise que de la pente douce. Ça m’a formé, ça m’a aussi parfois rendu fou. Alors quand on me demande, en 2026, si Drupal est encore un choix raisonnable, je ne réponds pas par nostalgie. Je réponds en regardant ce que le projet est devenu.
Ce qui a vraiment changé : Drupal CMS
Le fait marquant, ce n’est pas Drupal 11 en tant que tel. C’est Drupal CMS, sorti en version 1.0 le 15 janvier 2025, issu de l’initiative Starshot annoncée par Dries Buytaert à la DrupalCon Portland 2024. Concrètement, c’est un téléchargement prêt à l’emploi, bâti sur le cœur de Drupal 11, qui vise un public que Drupal avait historiquement snobé : les marketeurs, les créateurs de contenu, les site builders sans une ligne de code.
La vraie rupture tient en deux briques : les Recipes (des paquets de configuration qui installent une fonctionnalité complète en un clic) et les Single Directory Components côté theming. Ajoutez l’Experience Builder, l’outil d’édition visuelle, et vous obtenez une promesse que l’ancien Drupal n’a jamais tenue : aller de l’installation à la mise en ligne vite. Vous pouvez consulter l’initiative Drupal CMS sur drupal.org pour le détail officiel.
Drupal CMS ne cherche plus à remplacer WordPress sur le blog du coin. Il vise le projet complexe qu’un WordPress bricolé ne tiendra jamais dans la durée.
Le pari 2026 : l’IA au cœur, et le e-commerce
La roadmap 2026 est explicite : huit capacités structurantes autour de l’IA dans Drupal CMS, avec des agents capables d’assister la configuration, et une poussée sérieuse côté Commerce (recipes e-commerce, express checkout, Experience Builder sur les pages produit). Autrement dit, le projet ne se contente pas de rattraper son retard d’UX : il parie que la construction de site assistée par IA sera un différenciateur.
Est-ce que j’y crois ? À moitié. L’ambition est saine, la direction est la bonne, mais « AI agents qui configurent le site » est exactement le genre de promesse qu’on juge sur pièces, pas sur slides. Je reste prudent tant que je ne l’ai pas cassé sur un vrai projet.
Drupal ou WordPress ? La comparaison honnête
Je fais tourner beaucoup de WordPress (dont en Bedrock) et je n’ai aucun dogme. Voici comment je place les deux, sans langue de bois :
| Critère | Drupal (CMS / 11) | WordPress |
|---|---|---|
| Prise en main débutant | Correcte depuis Drupal CMS | Imbattable |
| Modélisation de contenu | Excellente, native | Plugins (ACF & co.) |
| Gestion fine des droits | Native, granulaire | Limitée sans extensions |
| Multilingue | Dans le cœur | Plugin (Polylang, WPML) |
| Écosystème / plugins | Plus restreint | Gigantesque |
| Coût / vitesse d’un petit site | Plus élevé | Plus bas |
| Robustesse d’un gros projet | Supérieure | Dépend de la discipline |
Mon raccourci de décision. Si le contenu est structuré (types imbriqués, relations, workflows éditoriaux, permissions par rôle, multilingue sérieux), Drupal vous fait gagner du temps sur la durée. Si c’est du contenu éditorial classique avec besoin d’itérer vite et pas cher, WordPress reste le choix par défaut.
Quand je choisirais Drupal en 2026
- Institution, secteur public, université : gouvernance, droits et multilingue de série.
- Application éditoriale complexe où la modélisation prime sur le time-to-market.
- Projet à durée de vie longue, avec une équipe technique interne à maintenir.
- Contraintes de sécurité et d’audit fortes, où l’écosystème plus resserré est un atout.
Quand je passerais mon tour
- Blog, site vitrine, petit e-commerce à lancer en deux semaines.
- Client sans budget de maintenance récurrent.
- Besoin d’un plugin de niche précis qui n’existe que côté WordPress.
- Équipe qui ne fera jamais l’effort de monter en compétence sur l’outil.
Le vrai risque, il est humain
Le point faible de Drupal n’a jamais été technique. C’est le vivier. Trouver un bon dev Drupal coûte plus cher et prend plus de temps qu’un intégrateur WordPress, et cette réalité pèse dans un devis comme dans une reprise de projet. Drupal CMS abaisse la barrière d’entrée pour construire, pas forcément pour maintenir un site sur mesure. C’est un point que j’aborde toujours avec un client, au même titre que le choix d’hébergement — un CMS ambitieux mérite un socle propre, et je penche pour de l’auto-hébergement maîtrisé plutôt qu’un mutualisé au rabais.
Et pour ceux qui, comme moi, ont connu l’ancien monde : le fameux modèle du node est toujours là, en dessous. La logique de fond n’a pas changé, elle a juste enfin une couche d’expérience utilisateur digne de ce nom par-dessus.
Ce que j’en retiens
Drupal en 2026 est un choix raisonnable — à condition de le choisir pour les bonnes raisons. Ce n’est plus l’outil punitif de mes souvenirs de Drupal 6 : Drupal CMS lui donne enfin un visage accueillant, et la roadmap IA montre un projet qui regarde devant lui, pas dans le rétroviseur. Mais ce n’est toujours pas un outil « par défaut ». Je le sors quand le contenu est structuré, l’enjeu long et l’équipe prête à investir. Pour tout le reste, WordPress fait le job plus vite et moins cher, et je n’ai aucun scrupule à le dire. Le bon réflexe, ce n’est pas de choisir un camp — c’est de faire correspondre l’outil à la nature réelle du projet.
