Le lent éloignement de WordPress

WordPress est l’un des grands succès de l’open source. Né comme un outil pour blogs, il est devenu le logiciel qui se cache derrière une grande partie du web, gratuit à utiliser, libre à modifier, avec un écosystème de thèmes, d’extensions et d’hébergeurs qui permet à presque n’importe qui de publier.

En tant qu’agence, nous avons construit et entretenu des sites WordPress pendant des années, et beaucoup de bons sites tournent encore dessus. Ceci n’est pas une nécrologie. Mais trois choses ont changé en même temps, et une entreprise dont le site repose sur WordPress devrait les connaître toutes les trois : la part de marché a changé de sens, le risque se trouve dans les extensions, et la direction du projet traverse depuis deux ans un litige qui se dirige désormais vers un jury.

La part de marché a changé de sens

W3Techs, qui suit les technologies derrière les sites web, montre WordPress en progression pendant presque une décennie : de 23,3 pour cent de tous les sites web début 2015 à 43,2 pour cent début 2022. Puis la courbe s’est aplatie. Il en était à 43,6 pour cent en janvier 2025 et à 43,0 pour cent en janvier 2026. Le 12 octobre 2026, le chiffre était de 40,1 pour cent.

C’est encore plus que tous les autres systèmes de gestion de contenu réunis, et 58,6 pour cent des sites dont W3Techs peut identifier le système. Mais la direction est nouvelle. Sur la même période, Shopify est passé de 4,7 à 5,4 pour cent de tous les sites web et Wix de 3,3 à 4,2 pour cent, tandis que Joomla et Drupal ont continué à reculer. Ce genre de chiffres dépend de la méthode, la direction compte donc plus que la décimale.

Le risque se trouve dans les extensions

Le noyau de WordPress est en bonne santé. Patchstack, une société de sécurité qui suit l’écosystème, n’a compté que six vulnérabilités dans le noyau de WordPress en 2025, toutes de faible priorité.

L’écosystème qui l’entoure est une tout autre affaire. Patchstack a recensé 11'334 nouvelles vulnérabilités dans l’ensemble de WordPress en 2025, soit 42 pour cent de plus qu’en 2024. 91 pour cent se trouvaient dans des extensions et 9 pour cent dans des thèmes. Pour 46 pour cent d’entre elles, le développeur n’avait pas de correctif prêt lorsque la faille a été rendue publique. Et pour les failles les plus visées par les attaquants, le délai médian entre la divulgation et l’exploitation de masse était de cinq heures.

Patchstack vend une protection contre exactement cela, son cadrage mérite donc la prudence habituelle. Le schéma, lui, est structurel. Le site d’une entreprise fait souvent tourner de nombreuses extensions de nombreux auteurs, chacune avec son propre rythme de mises à jour, sa propre qualité et son propre modèle économique. Chacune est du code sur le serveur public. Les maintenir à jour est une tâche hebdomadaire, et les semaines où on l’omet sont celles qui comptent.

Deux ans de turbulences

En septembre 2024, lors de la conférence WordCamp US, Matt Mullenweg, directeur général d’Automattic et figure de proue du projet WordPress, a exhorté la communauté à cesser de payer WP Engine, l’un des plus grands hébergeurs WordPress. Dans un billet qui a suivi, il a qualifié l’entreprise de « cancer » pour WordPress. Mullenweg avait exigé une redevance pour l’usage de la marque WordPress : 8 pour cent du chiffre d’affaires brut mensuel de WP Engine.

Le 25 septembre, WordPress.org a banni WP Engine de ses ressources, ce qui a perturbé les mises à jour d’extensions et de thèmes pour certains des sites qu’il hébergeait. En octobre, WP Engine a poursuivi Automattic et Mullenweg en justice, et WordPress.org a pris le contrôle d’Advanced Custom Fields, une extension populaire que maintenait WP Engine. En décembre, un juge fédéral a accordé une injonction préliminaire qui a rétabli l’accès de WP Engine et l’extension.

Ce qui a suivi a davantage blessé le projet que l’hébergeur. En janvier 2025, Automattic a réduit sa contribution promise à WordPress à environ 45 heures par semaine, contre environ 2'560, pour consacrer ses ressources à la bataille juridique. En avril, elle a licencié 16 pour cent de son personnel, et WordPress a annoncé que la version 6.8 serait la dernière version majeure de 2025. Fin mai, Automattic a fait marche arrière et est revenue sur le noyau. En juin, la Linux Foundation a lancé FAIR, un dépôt fédéré pour extensions et thèmes, conçu pour qu’aucune source unique ne contrôle les mises à jour.

L’affaire est loin d’être close. Le 24 septembre 2026, la juge a relancé les plaintes antitrust de WP Engine, qu’elle avait rejetées un an plus tôt, et a jugé qu’Automattic et Mullenweg ne sont ni propriétaires ni titulaires d’enregistrement des marques WordPress qu’ils revendiquaient. La plupart des demandes reconventionnelles d’Automattic subsistent aussi. Un procès devant jury de dix jours est fixé pour octobre 2027.

Ce que cela signifie pour une entreprise sur WordPress

Rien de tout cela ne rend un site WordPress dangereux du jour au lendemain. Une installation bien entretenue, avec peu d’extensions, un bon hébergeur et une personne nommément responsable des mises à jour peut servir une entreprise pendant des années. Pour un blog, un petit site vitrine ou une équipe qui maîtrise bien la plateforme, rester est souvent le choix raisonnable.

Ce que les deux dernières années ont montré, c’est la dépendance. Les mises à jour d’un site, ses extensions et la confiance dans sa chaîne d’approvisionnement passent par un seul dépôt, et pendant un temps, les décisions concernant ce dépôt ont été prises au sein d’un litige commercial. Ajoutez un écosystème où près de la moitié des nouvelles failles sont publiques avant d’être corrigées, et la question n’est plus de savoir si WordPress fonctionne. C’est de savoir quelle part de son site web une entreprise accepte de faire reposer sur des éléments qu’elle ne contrôle pas.

Des sites compilés, avec un CMS par-dessus

C’est pourquoi de plus en plus d’entreprises passent à des sites compilés : un site web compilé à partir de code en pages rapides, avec un système de gestion de contenu par-dessus pour les personnes qui l’éditent. Le site public n’a alors ni extensions ni connexion d’administration à attaquer. Chaque modification passe par une compilation testée avant sa mise en ligne. Le contenu vit dans des fichiers que l’entreprise possède, et non dans une base de données façonnée par un fournisseur.

Le compromis est réel. Un site compilé nécessite des développeurs pour les nouvelles fonctions, là où WordPress a une extension pour presque tout. Et l’édition doit être bien conçue, sinon l’équipe marketing regrettera l’ancien panneau d’administration en moins d’une semaine.

C’est le problème pour lequel Studio a été conçu. Son cœur est un CMS posé sur des sites construits en Next.js, Vite ou TanStack, sans extensions ni PHP sur le site public. Chaque publication est vérifiée, compilée une fois, testée, mise en ligne, contrôlée, puis annulée d’elle-même si quelque chose échoue, et chaque publication enregistre le contenu dans le propre dépôt de l’entreprise. Les rédacteurs cliquent sur un mot pour le modifier et voient la page en direct. Studio est en accès anticipé.

Les machines peuvent reprendre les compilations, les tests et les retours en arrière. Ce que dit une page, et si elle est assez bonne pour sortir, reste aux personnes qui en répondent.

Par où commencer

Comptez vos extensions et notez qui maintient chacune, quand elle a été mise à jour pour la dernière fois et ce qu’elle fait. Retirez ce dont personne n’a besoin. Assurez-vous que chaque extension, payantes comprises, reçoit ses mises à jour, et qu’une personne nommée les vérifie chaque semaine. Exportez une fois votre contenu et voyez si vous pourriez le déménager en cas de besoin.

Décidez ensuite en connaissance de cause. Gardez WordPress là où il vous sert, avec moins de pièces et un responsable clair. Là où le site web est central pour l’activité, un site compilé avec un CMS par-dessus mérite une conversation.