Près de quatre sites web sur dix tournent sur WordPress : 39,6 % exactement au 23 octobre 2026, selon W3Techs. Posez pourtant la question à un développeur, et la réponse tient souvent en un soupir. Le CMS le plus utilisé du web reste l’un des plus moqués par ceux qui écrivent du code.
Vous devez choisir la technologie de votre prochain site, ou décider de l’avenir de l’actuel ? Ce soupir mérite d’être décortiqué. Certaines critiques visent juste. D’autres datent d’une autre époque. Les trier, c’est savoir quoi exiger de votre site et de ceux qui s’en occupent.
Nous construisons des sites WordPress et des applications sur mesure, parfois pour le même client. Nous n’avons donc aucun camp à défendre.
Le « simple outil de blog » a bien grandi
WordPress est né en 2003 pour publier des blogs, et la réputation lui en est restée. Le logiciel, lui, a changé de catégorie. Il gère des types de contenus sur mesure et expose ses données à d’autres applications. Il sert de socle à des sites qui n’ont plus rien d’un blog.
La version 7.0, sortie le 20 mai 2026, a poussé plus loin. Elle intègre au cœur du logiciel de quoi dialoguer avec les modèles d’IA générative, et refond l’interface d’administration. L’annonce officielle y voit « le début d’une nouvelle ère ». Le ton est celui d’un communiqué, mais l’outil de blog est loin.
Ce reproche-là est le plus facile à écarter. Les suivants le sont beaucoup moins.
Les extensions, vrai talon d’Achille
C’est la critique la plus solide, et les chiffres lui donnent raison. En 2025, l’éditeur de sécurité Patchstack a passé au crible les nouvelles failles de l’écosystème. Sur l’ensemble, 91 % se trouvaient dans des extensions et 9 % dans des thèmes. Le cœur de WordPress n’en comptait que six, toutes de faible priorité.
Le problème tient au modèle. Chaque extension est un logiciel tiers, mis à jour au rythme de son auteur, ou plus du tout. Nous éditons nous-mêmes une extension WooCommerce, Colisly : nous savons ce que ce suivi demande dans la durée. Près d’une faille sur deux n’avait d’ailleurs aucun correctif au moment d’être rendue publique. Les plus recherchées par les pirates sont exploitées dans les heures qui suivent leur publication. Le jour où cela arrive, nettoyer un site piraté coûte bien plus cher que la mise à jour oubliée.
Une extension mal réglée suffit aussi à couler un site, sans le moindre pirate. Un blog vivant de la publicité est tombé de plus de 1 500 visiteurs par jour à moins de 50. Son propriétaire a passé des mois à soupçonner les mises à jour de Google. La cause tenait en une option de son extension de sécurité, qui bloquait aussi le robot de Google. Notre diagnostic l’a trouvée en quelques heures. Le trafic, lui, a mis des mois à revenir.
Même scénario, autre décor, sur un site de recettes belge. Ses visiteurs atterrissaient par intermittence sur la page d’installation de WordPress. L’extension de cache avait gardé en mémoire un état transitoire du site, et le resservait.
Le reproche vise donc surtout ce qui entoure WordPress. Pour vous, la conclusion est pratique : moins d’extensions, mieux choisies, et suivies.
Un code qui traîne son passé
Autre grief, plus technique : WordPress ménage ses vieux sites avant de séduire les développeurs. Sa version 7.1, sortie en août 2026, accepte encore PHP 7.4 comme minimum. Cette version du langage n’est plus corrigée depuis novembre 2022. Les versions recommandées sont pourtant PHP 8.4 et 8.5.
Cette fidélité se lit dans le code. Les fonctions globales et les « hooks » des débuts cohabitent avec l’éditeur de blocs, écrit en React depuis 2018. Un développeur formé aux frameworks récents y voit un empilement de couches, et il n’a pas tout à fait tort. Pour vous, cette fidélité a un avantage : un site de dix ans peut encore tourner. Elle a aussi un revers : il tourne aussi bien sur un serveur que plus personne ne met à jour.
L’éditeur de blocs, surtout, divise encore. L’extension officielle qui ramène l’ancien éditeur, Classic Editor, tourne toujours sur plus de huit millions de sites. Sa fiche promet un support « jusqu’en 2024, ou aussi longtemps que nécessaire ». Deux ans après l’échéance, l’extension est toujours mise à jour. L’API des blocs bouge encore : en 2026, WordPress encourage leurs auteurs à passer à sa version 3. Pour qui maintient un thème sur plusieurs années, chaque changement de ce type se paie en heures de migration.
Là où ça nous gêne, nous aussi : les constructeurs de pages. Divi, Elementor et leurs cousins permettent de monter un site sans code. Le prix : des pages lourdes et difficiles à reprendre. Bien des critiques adressées à WordPress visent en réalité ces sites-là. Nous l’avons vu chez Tenakoe : un site sous Divi, lent, faible sur mobile, encombré d’extensions en conflit. Nous l’avons reconstruit avec un thème écrit pour lui, sans constructeur. Les adresses n’ont pas bougé, et Google n’a trouvé aucune page cassée.
Depuis 2024, la gouvernance inquiète
Le grief le plus récent ne touche pas au code. En septembre 2024, Matt Mullenweg, cofondateur de WordPress et patron d’Automattic, s’en prend publiquement à l’hébergeur spécialisé WP Engine. « Il faut le dire et le répéter : WP Engine n’est pas WordPress », écrit-il. C’est le début d’un conflit qui dure encore. Dans la foulée, WordPress.org coupe à WP Engine l’accès à ses extensions et à ses mises à jour.
Le mois suivant, WordPress.org prend la main sur ACF, une extension de WP Engine présente sur des millions de sites. En décembre, un tribunal fédéral américain ordonne de rétablir ces accès. L’affaire n’est pas close. Fin septembre 2026, la juge Araceli Martínez-Olguín a maintenu les quatre griefs de WP Engine pour pratiques anticoncurrentielles.
Le projet en a payé le prix. En janvier 2025, Automattic a réduit sa contribution au cœur de WordPress pour se consacrer à ses produits commerciaux. En juin, la Linux Foundation a annoncé FAIR, un système de distribution d’extensions qui ne dépend plus d’une source unique.
Dernier épisode, le 9 septembre 2026 : le conseil d’Automattic a voté la mise en congé de Matt Mullenweg. Trente-trois heures plus tard, il avait repris la main. Deux administrateurs ont démissionné, une troisième a été écartée. Le directeur financier, nommé PDG par intérim, a été licencié, tout comme le directeur juridique. Mullenweg affirme détenir environ 84 % des droits de vote de l’entreprise.
Pour vous, la leçon de ces épisodes tient moins au feuilleton qu’à ce qu’ils révèlent. WordPress.org, dont dépend une grande partie de l’écosystème, appartient à Matt Mullenweg, à titre personnel, de son propre aveu. Et le même homme contrôle Automattic, l’entreprise qui édite WordPress.com. Un site suivi par quelqu’un qui lit l’actualité du projet voit venir ce genre de secousse. Un site laissé à lui-même la découvre au pire moment.
WordPress ou sur-mesure : la question porte sur votre métier
Tenakoe accompagne les entreprises du bâtiment vers la qualification RGE. Son site public est resté sur WordPress. Présenter des services, une équipe, une foire aux questions et des témoignages : c’est exactement ce que WordPress fait bien. Le suivi des dossiers, lui, est parti dans Kiwi, un CRM que nous avons développé sur mesure. Les étapes de qualification, les branches de Qualibat par département et l’attribution des dossiers n’entraient dans aucun outil standard.
La règle qui s’en dégage est simple. WordPress convient quand le besoin consiste à publier et à présenter, et que des extensions éprouvées couvrent le reste. Le sur-mesure s’impose quand la valeur tient dans un processus propre à votre activité. Avec WordPress, il faudrait l’approcher en empilant des extensions.
Entre les deux, il existe une voie que les débats oublient souvent : WordPress, plus une extension écrite pour vous. Le simulateur de crédit que nous avons écrit pour un client en est un exemple. Il transmet les demandes des visiteurs aux banques partenaires du client. Une extension pensée pour un seul besoin ajoute moins de code tiers qu’un empilement d’extensions génériques. Donc moins de portes d’entrée.
Ce que vous pouvez vérifier vous-même cette semaine
Cinq contrôles, sans rien installer.
Ouvrez Outils > Santé du site. WordPress y signale lui-même les problèmes critiques, et l’onglet Informations indique la version de PHP de votre hébergement. Comparez-la aux versions recommandées, PHP 8.4 ou 8.5 aujourd’hui.
Passez en revue vos extensions actives. Pour chacune, ouvrez sa fiche sur WordPress.org. Regardez la date de la dernière mise à jour, et la dernière version de WordPress testée. Ces deux mentions disent si quelqu’un s’en occupe encore. Une extension qui n’a pas bougé depuis des années se remplace ou se supprime.
Listez les comptes administrateurs. Un ancien prestataire ou un stagiaire parti depuis longtemps n’a rien à y faire.
Demandez à qui s’occupe du site quand date la dernière sauvegarde, et si une restauration a déjà été testée. Une sauvegarde jamais restaurée reste une hypothèse.
Enfin, si une extension de sécurité filtre les robots, vérifiez que Google accède bien à vos pages. L’inspection d’URL de la Search Console sert à ça. C’est le contrôle qui aurait épargné des mois de chute au blog cité plus haut.
Si vous préférez déléguer ces vérifications, c’est le quotidien de nos contrats de maintenance. Les mises à jour y sont testées sur une copie du site avant d’être appliquées. Les sauvegardes sont quotidiennes, et la sécurité surveillée. Et si votre projet relève du sur-mesure, exposez-nous votre besoin.
[…] constructeurs de pages, souvent accusés, n’entament guère cette réactivité. Ils pèsent sur le chargement. Selon […]