On en parle – WordPress, Drupal, TYPO3 : quel CMS pour un projet public en 2026 ?

TEMPS DE LECTURE : 13’20

Le match reste pourtant bien réel.

Derrière une même promesse, gérer des contenus, les trois plateformes ne racontent pas la même histoire. Elles n’ont ni la même profondeur sur les workflows, ni la même logique de gouvernance, ni la même facilité de prise en main, ni la même densité d’écosystème, ni la même trajectoire sur l’intelligence artificielle. Et dans le secteur public, ces écarts se traduisent concrètement en coûts, en délais, en dette technique, en facilité de mutualisation, en qualité de service et en réversibilité.

Premier constat, les parts de marché globales ne disent pas tout, mais elles donnent le décor.

WordPress reste ultra dominant avec 42,2 % de tous les sites web et 59,6 % des sites utilisant un CMS. Drupal est à 0,7 % de tous les sites et TYPO3 à 0,4 %.

Pourtant, dans le secteur public, la lecture change.

• Drupal dispose d’un ancrage historique fort dans les contextes gouvernementaux et territoriaux, avec un écosystème clairement orienté “government”.
• TYPO3 conserve une vraie densité dans le secteur public européen, au point d’avoir été retenu comme socle du Government Site Builder 11 en Allemagne.
• WordPress, lui, reste très présent sur les sites de communication et de publication, tout en équipant aussi de très grandes références publiques comme la Maison-Blanche ou la NASA.

WordPress : la vitesse, l’accessibilité, la force de l’écosystème

WordPress garde un avantage très net sur un point : il est le plus rapide à approprier.

Son modèle éditorial est familier à beaucoup de communicants, de contributeurs et de webmasters. Pour un site institutionnel, un webzine, un portail éditorial, un site évènementiel ou un dispositif de communication à complexité modérée, il reste redoutablement efficace. Son immense écosystème de thèmes, de plugins, d’hébergeurs et de profils techniques lui donne une vélocité que les autres CMS n’atteignent pas au même niveau. Ses rôles standards sont simples à comprendre, son API REST est mature, et le multisite existe nativement.

Mais la force de WordPress est aussi sa zone de risque.

La sécurité d’un projet WordPress ne dépend pas seulement du cœur du CMS. Elle dépend de la qualité des thèmes et des extensions, de la discipline de sélection, de la fréquence des mises à jour, de la rigueur d’hébergement, du cloisonnement des droits et de la qualité du code spécifique. WordPress n’est donc pas “moins sécurisé” par nature. En revanche, il est plus sensible à la qualité de la gouvernance qu’on lui impose, parce que son écosystème est immense et très hétérogène. C’est souvent moins WordPress qui échoue que la manière dont on l’empile. Un thème premium mal choisi, des plugins redondants, un constructeur visuel omniprésent et une maintenance sous-estimée suffisent à transformer un bon socle en dette technique durable.

Sur l’IA, WordPress a franchi un cap important en 2026.

WordPress 7.0 intègre désormais un AI Client dans le core, c’est-à-dire une couche technique agnostique vis-à-vis des fournisseurs, qui permet aux plugins d’appeler des modèles IA via une interface commune. Il faut être précis : cela ne signifie pas que l’IA est native au sens “prête à produire” sans configuration. Le core ne livre pas de fournisseur activé par défaut. En revanche, cela signifie que WordPress dispose maintenant d’une fondation unifiée et gouvernable pour brancher des usages IA dans l’administration et l’édition, ce qui change beaucoup de choses en matière d’industrialisation future.

Drupal : le plus cohérent quand le contenu devient un objet métier

Drupal garde une longueur d’avance dès que le projet sort du simple site éditorial pour entrer dans une logique de plateforme.

Quand il faut modéliser des contenus riches, gérer des taxonomies complexes, piloter des workflows à plusieurs niveaux, exposer des données propres, interfacer des briques métier, gérer des droits fins ou raisonner “hub de contenus”, Drupal devient très convaincant. Son module JSON:API est dans le cœur, avec une logique zéro configuration pour exposer les entités. Son module de content moderation permet de séparer clairement la version publiée de la version en cours de validation. Ce n’est pas un détail : pour le secteur public, où le contenu est souvent réglementaire, processé, relu et tracé, cette profondeur fait une vraie différence.

Ce n’est pas un hasard si Drupal reste aussi visible dans les collectivités, les administrations et les communautés gouvernementales.

Au-delà des références, il existe un véritable outillage sectoriel. LocalGov Drupal, par exemple, a été conçu pour aider les conseils locaux britanniques à publier plus vite, moins cher et mieux. Ce type de distribution n’est pas seulement un bonus produit. C’est le signe d’une maturité sectorielle très forte : Drupal parle naturellement aux organisations qui gèrent des fiches de démarches, des annuaires, des workflows multi-acteurs, des contenus structurés, des espaces contributifs et des échanges inter-plateformes.

Le revers de la médaille, c’est l’exigence.

Drupal demande plus de méthode, plus d’architecture, plus de rigueur projet. Sa prise en main contributive peut être excellente, mais elle n’est jamais “automatique” : elle dépend d’un vrai travail d’UX du back-office et d’une modélisation éditoriale bien pensée. Et sa trajectoire de versioning impose une vigilance continue. Drupal 12 est déjà dans le cycle 2026. Cela veut dire qu’un projet Drupal bien gouverné se pilote sur la durée, avec une vraie stratégie d’évolution. En échange, il offre un niveau de contrôle et de cohérence que peu de CMS open source atteignent.

Sur l’IA, Drupal est aujourd’hui le plus structuré des trois dans sa démarche produit.

Le projet a lancé une initiative stratégique dédiée, avec une équipe de pilotage, des work tracks, une feuille de route 2026 et une base de financement déjà active. Vingt-huit organisations soutiennent l’initiative, représentant plus de vingt-trois équivalents temps plein. Cela ne veut pas dire que tout est stabilisé ou prêt à l’emploi dans le cœur du CMS. Cela veut dire que Drupal traite désormais l’IA comme un chantier stratégique coordonné, pas comme une juxtaposition de modules opportunistes. Pour un acteur public qui veut concilier innovation, gouvernance, auditabilité et trajectoire produit, ce signal est fort

TYPO3 : le spécialiste très solide des plateformes publiques mutualisées

TYPO3 reste souvent sous-estimé en France, alors qu’il colle remarquablement bien à certains environnements publics complexes.

Son terrain naturel, c’est le multisite, le multilingue, la gouvernance éditoriale avancée, la plateforme mutualisée, la stabilité sur plusieurs années et la standardisation entre entités. TYPO3 se présente de plus en plus clairement comme un CMS enterprise open source pour des organisations qui veulent industrialiser leur présence web sans s’enfermer dans une solution propriétaire. Son positionnement officiel met d’ailleurs explicitement en avant le secteur public, les performances de diffusion de contenu et les capacités multisites.

Techniquement, TYPO3 dispose d’arguments très sérieux.

Les workspaces introduisent des workflows avec étapes personnalisées et versioning. Le système de droits est particulièrement fin, au niveau utilisateur, groupe, pages, fonctions, contenus et montages de base. Les site sets permettent de factoriser configurations et standards entre plusieurs sites. Et sa trajectoire LTS reste très lisible : TYPO3 14 LTS est sorti le 21 avril 2026, avec des correctifs gratuits jusqu’en décembre 2027 et des mises à jour de sécurité jusqu’en juin 2029. Pour une administration ou un grand établissement qui cherche à lisser ses risques d’exploitation, cette prévisibilité compte beaucoup.

En contrepartie, TYPO3 exige un écosystème de compétences plus rare, notamment en France.

Le sujet n’est pas qu’il serait “compliqué” par principe. Le sujet est qu’il a été pensé pour des dispositifs structurés, durables et gouvernés. Cela joue sur le recrutement, sur la reprise, sur la capacité de certaines équipes à se sentir autonomes rapidement, et sur le coût de maintenance si l’architecture initiale est trop dépendante de l’intégrateur. TYPO3 est donc très pertinent quand le besoin de plateforme est clair. Il l’est moins quand on cherche avant tout la simplicité immédiate.

Sur l’IA, TYPO3 avance surtout par son écosystème.

Des extensions officielles ou publiées dans le repository TYPO3 portent déjà des usages de génération, traduction, accessibilité, intégration multi-providers et fondation partagée pour d’autres extensions. C’est prometteur, et cela progresse vite. Mais, à ce stade, la trajectoire reste moins centralisée que celle de Drupal, et moins intégrée au core que la nouvelle fondation IA de WordPress 7.0. TYPO3 avance donc sérieusement, mais encore davantage par couches d’écosystème que par doctrine centrale du produit.

Usine à sites, syndication, headless : les écarts sont là.

Sur l’usine à sites, les trois CMS savent faire, mais pas avec la même élégance.

WordPress multisite est très efficace quand les sites se ressemblent, que l’on veut partager certains plugins ou thèmes et que la gouvernance reste assez centralisée. Drupal devient plus pertinent quand il faut mutualiser tout en gardant des modèles de contenus, des workflows et des logiques de publication plus complexes. TYPO3 est souvent le plus à l’aise quand la mutualisation devient un sujet de plateforme pérenne, avec plusieurs entités, plusieurs langues, plusieurs équipes et plusieurs niveaux de droits.

Sur la syndication de données, il faut être nuancé.

WordPress peut syndiquer et diffuser via son API REST, et son écosystème sait très bien le faire. Mais il y arrive plus souvent par assemblage. Drupal y est plus naturellement préparé grâce à sa logique d’entités, à JSON:API dans le cœur et à un écosystème comme Feeds. TYPO3 est lui aussi à l’aise dès lors qu’on raisonne plateforme, API, multisite et headless, même si l’outillage repose davantage sur une bonne architecture et sur des extensions que sur une promesse “tout est prêt nativement” pour tous les cas. Donc oui, votre intuition est bonne : WordPress est souvent moins confortable que Drupal ou TYPO3 dès qu’il s’agit de penser syndication et réemploi des données à grande échelle.

Sur le headless, en revanche, aucun des trois n’est éliminé.

WordPress s’appuie sur son API REST et une quantité gigantesque de frameworks front compatibles. Drupal est particulièrement propre pour les contenus structurés grâce à JSON:API. TYPO3 s’appuie sur son extension headless, qui expose une API JSON pour les contenus et la navigation. En clair, le headless n’est plus le critère décisif. Le vrai critère est la qualité du modèle de contenu, la discipline de gouvernance, et la capacité de vos équipes à exploiter l’architecture dans le temps.

Quel est le CMS le plus sécurisé ?

La réponse la plus sérieuse est : aucun, si l’on cherche un champion absolu hors contexte.

Les trois projets ont une équipe sécurité, un processus de signalement, une politique de correction et une culture de maintenance. WordPress backporte encore certains correctifs sur des versions plus anciennes à titre gracieux. Drupal dispose d’une culture sécurité historiquement très structurée. TYPO3 met en avant sa politique de sécurité et ses contrôles d’accès fins. Donc non, la question ne se résume pas à “quel code source est le plus pur ?”.

La vraie différence est d’usage.

Dans un environnement peu gouverné, WordPress est souvent le plus exposé aux mauvaises pratiques, parce qu’il permet plus facilement d’empiler des briques hétérogènes. Dans un environnement très gouverné, bien audité, bien hébergé et bien maintenu, il peut être parfaitement robuste. Drupal et TYPO3 offrent souvent un cadre plus naturel pour les organisations qui ont besoin d’une granularité forte sur les droits, les workflows et l’urbanisation technique. La sécurité, dans les trois cas, dépend donc d’abord de la façon dont le CMS est utilisé, maintenu et hébergé. Votre remarque sur “n’importe quel template WordPress” est donc très juste : le risque ne vient pas seulement du CMS, il vient de la qualité des choix autour du CMS.

Faut-il choisir le CMS tout de suite ?

Non. En tout cas, pas sérieusement.

Choisir le CMS avant d’avoir qualifié les parcours, les contenus, les rôles, les flux, les interfaces, les contraintes d’hébergement, les enjeux de sécurité et le coût d’exploitation, c’est souvent choisir un outil sur la base d’habitudes internes. La bonne méthode consiste à cadrer d’abord, puis à arbitrer. Pas à la fin du projet, mais à la fin d’un vrai travail de spécification fonctionnelle et technique. C’est à ce moment-là que le choix devient rationnel : quand vous savez si vous achetez avant tout de la simplicité éditoriale, une logique de plateforme, une profondeur de workflow, une puissance multisite, une trajectoire headless, ou une capacité à tenir le long terme.

Et oui, il existe de vrais écarts de web mastering d’un CMS à l’autre.

Les gestes de base se ressemblent toujours : créer, corriger, illustrer, publier. Mais dès qu’on entre dans les composants, les taxonomies, les révisions, les workflows, les traductions, la gestion des médias, les permissions ou la mutualisation, les cultures changent fortement. WordPress reste le plus accessible pour un webmaster généraliste. Drupal et TYPO3 demandent plus de méthode, mais donnent aussi plus de contrôle quand l’organisation se complexifie.

Le plus prometteur en 2026 ?

Si l’on parle de masse critique, d’adoption et de vitesse de mise en œuvre, WordPress restera incontournable.

Si l’on parle de gouvernance des contenus structurés, d’API, de workflows et de trajectoire IA sérieuse, Drupal a aujourd’hui une avance stratégique.

Si l’on parle de plateforme multisite institutionnelle, de stabilité et de culture public sector en Europe, TYPO3 reste un acteur très solide, parfois trop peu regardé en France. Il n’y a donc pas un CMS prometteur. Il y a trois futurs possibles, selon votre horizon.

Pour Stratis, le bon CMS est celui qui reste cinq ans après la mise en ligne

A Stratis, nous travaillons sur WordPress, Drupal et TYPO3 depuis de nombreuses années.

Nous concevons, développons, hébergeons, maintenons et faisons évoluer des plateformes publiques exigeantes, avec des enjeux de droits, d’authentification, d’interfaces métier, de multisite, de réversibilité et, de plus en plus, d’intégration IA. C’est précisément pour cela que nous refusons les réponses automatiques. Nous n’avons pas intérêt à forcer un CMS. Notre rôle est de vous orienter vers la solution la plus juste pour vos usages, votre maturité technique, votre organisation éditoriale et votre trajectoire de maintenance. Cette logique de conseil, d’accompagnement IA et de réalisations publiques figure d’ailleurs déjà au cœur de notre positionnement.

Dans bien des cas, les trois CMS font le travail. Mais ils ne le font ni au même coût, ni avec la même profondeur, ni avec la même soutenabilité.

Nous regardons donc toujours le projet sous deux angles. D’abord l’angle fonctionnel : nature des contenus, intensité des workflows, logique de syndication, rôle du multisite, interfaces avec le SI, ambitions headless et IA. Ensuite l’angle économique et opérationnel : coût total de possession, politique de versions, disponibilité des compétences, autonomie que vous souhaitez garder, niveau de dette technique acceptable. C’est dans cet équilibre que se joue un bon choix.

Nous développons sur ces trois CMS en mode classique comme en mode headless.

Avec une exigence constante : des architectures sobres, performantes, documentées et réversibles. Le bon conseil n’est pas de choisir un CMS à la mode. Le bon conseil est de choisir un CMS qui restera administrable, sécurisable, transmissible et utile longtemps après la recette.

En synthèse…

WordPress, Drupal et TYPO3 ne s’opposent plus aujourd’hui entre “petit CMS simple” et “gros CMS complexe”. Les trois sont capables de porter des projets publics avancés. En revanche, ils ne répondent pas avec la même logique.

WordPress domine très largement le marché mondial et conserve son avantage historique sur la vitesse, la simplicité d’appropriation et la richesse d’écosystème.

Pour un site institutionnel, éditorial ou évènementiel à complexité maîtrisée, il reste souvent le choix le plus efficace. Mais cette puissance a une contrepartie : sa sécurité et sa robustesse dépendent fortement de la gouvernance du projet, du choix des thèmes et extensions, de la qualité de l’hébergement et de la discipline de maintenance.

WordPress peut être très sûr, mais il devient rapidement fragile quand il est traité comme un empilement de briques hétérogènes.

Sur l’IA, il a franchi un cap important avec WordPress 7.0, qui intègre un AI Client dans le core. Cela ne fournit pas des usages IA prêts à l’emploi par défaut, mais cela crée une fondation technique unifiée et plus gouvernable.

Drupal garde pour sa part un avantage net dès que le contenu devient un objet métier structuré.

Sa logique d’entités, son JSON:API natif, ses workflows et sa content moderation en font un excellent choix pour les plateformes où il faut gérer des droits fins, des contenus complexes, des validations multi-acteurs, des annuaires, des démarches, des hubs de contenus ou des échanges de données.

C’est pour cela qu’il reste très fort dans le secteur public. Il demande en revanche plus de méthode, plus d’architecture et une vraie stratégie d’évolution. En 2026, c’est aussi le CMS le plus structuré sur le sujet IA, avec une initiative stratégique financée, coordonnée et portée collectivement.

TYPO3, enfin, est probablement le plus sous-estimé des trois sur le marché français.

Pourtant, il est extrêmement pertinent pour les plateformes publiques multisites, multilingues et mutualisées. Ses workspaces, sa finesse de permissions, sa logique de standardisation entre sites et sa trajectoire LTS très lisible en font un CMS particulièrement solide pour des organisations qui raisonnent plateforme sur plusieurs années. Son principal frein n’est pas technique, mais opérationnel : les compétences sont plus rares, donc le coût d’entrée et la perception de complexité peuvent être plus élevés. Sur l’IA, TYPO3 progresse sérieusement, mais davantage via son écosystème d’extensions que par une stratégie centrale de produit.