Je me méfie des discours qui commencent par rabaisser une technologie pour mieux vendre celle que l’on utilise.
On voit régulièrement passer ce genre de publication. WordPress serait trop lourd, trop fragile, trop dépendant des plugins, trop souvent à mettre à jour, trop limité ou simplement dépassé. Et derrière ce constat, rarement neutre, arrive généralement la solution présentée comme plus propre, plus moderne, plus sérieuse : un framework.
Ce qui me gène ce n’est pas de défendre un framework. Un framework peut être un excellent choix, parfois même le meilleur. Mais plutôt de construire un argumentaire en montrant uniquement les défauts d’une technologie tout en passant sous silence les contraintes de celle que l’on propose.
WordPress a des défauts. Mais ça ne fait pas tout…
WordPress a effectivement des défauts. Il peut être mal utilisé, mal maintenu, surchargé de plugins, monté sans logique claire ou repris dans un état tellement confus que chaque modification devient pénible.
Il serait malhonnête de prétendre le contraire.
J’ai vu des sites WordPress où l’administration était un labyrinthe, où les contenus étaient dispersés partout, où les extensions s’empilaient sans cohérence et où la moindre intervention demandait de comprendre plusieurs couches de décisions techniques douteuses.
Mais j’ai aussi vu l’inverse.
Il m’est arrivé de reprendre des sites WordPress construits par d’autres agences et de constater que le travail avait été fait proprement. La structure était claire, les contenus étaient bien organisés, les composants étaient réutilisables, l’administration était logique et le client pouvait réellement gérer son site sans dépendre constamment d’un développeur.
Dans ces cas-là, presque rien n’était à changer.
Le site était simplement bien pensé.
Un site ne s’arrête pas à sa mise en ligne
C’est exactement ce point qui est souvent absent des discours anti-WordPress : un site web ne s’arrête pas à sa mise en ligne.
Il continue de vivre.
Six mois plus tard, le client veut ajouter une section. Un an plus tard, il veut revoir une page de service. L’équipe marketing veut tester une nouvelle landing page, ajouter un bloc témoignage, modifier une structure de contenu, insérer une zone d’appel à l’action ou faire évoluer une page sans repartir dans un nouveau chantier complet.
Et c’est là que la réalité opérationnelle devient importante.
Avec un WordPress bien monté, une partie de ces ajustements peut être faite rapidement par une personne formée, dans un cadre prévu à l’avance. Ce ne sera pas toujours parfait, et il faut évidemment éviter de transformer le site en terrain de jeu incontrôlé, mais l’entreprise conserve une marge d’autonomie réelle.
Avec un site développé sur un framework, si cette autonomie n’a pas été pensée dès le départ, la moindre évolution peut devenir un mandat. Une demande. Une estimation. Un délai. Une validation. Une facture (bien évidement).
Le coût caché de l’évolution
Prenons un exemple assez concret.
Imaginons qu’une entreprise souhaite créer plusieurs nouvelles pages avec un template un peu plus travaillé que les pages existantes. Pas une refonte complète. Pas un nouveau site non plus. Simplement une évolution logique de la base déjà en place, pour mieux présenter ses services, mieux structurer son expertise, mieux répondre aux nouveaux usages liés au SEO, au GEO et aux moteurs de recherche alimentés par l’IA.
Sur le papier, la demande semble raisonnable.
L’entreprise veut enrichir son site, ajouter des sections plus précises, mieux organiser ses contenus, créer des pages plus solides pour soutenir sa visibilité et son positionnement. C’est exactement le genre d’évolution normale qu’un site devrait pouvoir absorber avec le temps.
Mais si le site a été développé de façon trop rigide, sans système de blocs suffisamment flexible, sans interface éditoriale bien pensée et sans marge de manœuvre pour l’équipe interne, cette évolution peut rapidement coûter cher.
Il faudra peut-être créer un nouveau template, adapter des composants, revoir certaines structures, passer par le fournisseur, attendre une estimation, valider le budget, planifier l’intervention et tester le tout.
Finalement, l’entreprise ne paie pas seulement pour “ajouter quelques pages”.
Elle paie pour faire évoluer une architecture qui n’a peut-être pas été pensée pour évoluer facilement.
Et c’est précisément ce coût-là qui est rarement expliqué au départ.
Une technologie propre peut quand même devenir contraignante
C’est rarement mentionné dans les publications qui expliquent que WordPress est dépassé.
On parle de performance, de sécurité, de propreté du code, de modernité, de scalabilité et de dette technique. Très bien. Ce sont de vrais sujets.
Mais alors il faut aussi parler de dépendance fournisseur, de coût d’évolution, de maintenance spécialisée, de rigidité éditoriale, de budget moyen terme et de l’autonomie réelle du client après la livraison.
Parce qu’un site peut être très propre techniquement et pourtant pénible à faire évoluer au quotidien. Il peut être moderne dans son architecture, mais mal adapté à l’équipe qui devra le gérer.
Il peut même avoir été parfaitement cohérent au moment de sa création, puis devenir limitant quelques mois plus tard lorsque les besoins marketing, SEO ou IA demandent plus de profondeur, plus de pages, plus de variantes et plus de souplesse éditoriale.
C’est là que le discours devient problématique.
Un framework peut être une solution formidable pour un produit web, une plateforme applicative, un projet complexe ou une entreprise qui possède une vraie équipe technique à l’interne.
Mais si l’objectif principal est de publier du contenu, de faire évoluer des pages, de tester des messages, de créer des campagnes et de garder une certaine liberté sans repasser constamment par un fournisseur, alors le choix doit être discuté avec beaucoup plus de nuance.
Le vrai sujet, c’est de savoir qui va gérer le site après sa mise en ligne, avec quel budget, quelles compétences, quelle fréquence d’évolution, quel niveau d’autonomie et quelle tolérance à la dépendance technique.
Ces questions sont moins spectaculaires qu’une publication qui démolit WordPress pour générer des réactions. Mais elles sont beaucoup plus utiles pour un client.
Conseiller, ce n’est pas défendre une chapelle technique
J’utilise WordPress depuis 2013. J’ai commencé avec Joomla et Prestashop. J’ai travaillé sur Webflow, même si ce n’est pas ma tasse de thé. J’ai aussi fait quelques expérimentations avec React.
Je ne prétends pas tout maîtriser, et c’est justement pour cette raison que je pense qu’un professionnel sérieux doit savoir reconnaître les limites de son propre champ d’expertise.
Je peux conseiller WordPress pour certains projets. Je peux recommander Webflow dans d’autres contextes. Je peux orienter vers Shopify lorsque l’équipe a besoin d’une solution e-commerce plus encadrée. Je peux aussi dire à un client que son projet devrait être traité comme une vraie solution applicative et le référer vers une autre équipe si le besoin dépasse le cadre pertinent d’un CMS traditionnel.
Le rôle d’un professionnel du web n’est pas de défendre sa technologie préférée comme une religion (ou de rabaisser de façon cacher une techno, pour son image).
Son rôle est de comprendre le projet, l’équipe, les contraintes, les ambitions et la capacité réelle de l’entreprise à maintenir ce qu’elle achète.
Ce qui me dérange dans certains discours, ce n’est pas qu’ils critiquent WordPress. WordPress mérite parfois d’être critiqué.
Ce qui me dérange, c’est qu’ils le critiquent comme si leurs propres solutions n’avaient aucun coût caché, aucune limite, aucune dépendance, aucune rigidité et aucune zone d’ombre.
Comparer un mauvais site WordPress à un site développé proprement sur un framework, ce n’est pas une analyse.
C’est plus… une mise en scène.
La vraie comparaison devrait être plus honnête : un WordPress mal conçu contre un framework mal cadré, un WordPress bien conçu contre un framework bien cadré, une équipe autonome contre une équipe dépendante, un besoin éditorial contre un besoin applicatif, un projet marketing contre un produit numérique.
Et avec l’IA, la discussion devient encore plus intéressante
Avec l’IA, cette discussion risque de devenir encore plus houleuse.
On entend déjà l’argument arriver : puisque les frameworks reposent sur du code plus direct, plus structuré, plus proche du développement pur, ils seraient naturellement mieux placés dans un monde où l’IA peut générer des composants, des interfaces et des sites entiers en quelques minutes.
Peut-être.
Je ne suis pas dupe. Il est évident que l’IA va faciliter énormément de choses. Elle va accélérer la création de maquettes, de composants, de pages, de structures, de contenus et même de sites complets. Une partie de ce qui demandait autrefois plusieurs heures, voire plusieurs jours, pourra probablement être produite beaucoup plus rapidement (et le plus grand nombre).
Mais je me méfie encore une fois des conclusions trop rapides.
Rien ne dit que les CMS ne vont pas évoluer avec l’IA. Rien ne dit que WordPress restera figé dans son fonctionnement actuel. Rien ne dit que les frameworks seront les seuls gagnants de cette transformation. Et rien ne dit non plus que de nouveaux outils ne viendront pas fragiliser les frameworks eux-mêmes, exactement comme certains annoncent aujourd’hui la fin des CMS.
L’IA ne va pas seulement renforcer les technologies modernes. Elle va aussi changer la donne.
Elle pourrait rendre certains développements sur mesure plus accessibles. Elle pourrait améliorer l’expérience d’édition dans les CMS. Elle pourrait permettre à des outils open source de se moderniser plus vite. Elle pourrait faire réapparaître d’anciens acteurs sous une nouvelle forme. Elle pourrait aussi faire émerger des plateformes hybrides, capables de mélanger édition visuelle, génération de code, logique métier et automatisation.
Le futur pourrait être beaucoup plus désordonné, plus hybride et plus surprenant que cela.
Il serait dommage de croire qu’une technologie open source, utilisée massivement, avec un écosystème aussi vaste, ne puisse pas évoluer. Il serait tout aussi naïf de croire que les frameworks actuels sont protégés contre les prochaines vagues d’automatisation.
C’est justement pour cette raison que les discours-à-like me semblent incomplets.
Oui, l’IA va changer la création de sites web. Certains métiers, certaines méthodes et certains outils vont être bousculés. Mais tirer une ligne droite entre “l’IA est dans notre quotidien” et “WordPress va être dépassé” me semble être une lecture trop simple d’un changement beaucoup plus vaste.
Dans notre métier, il faut savoir regarder ce qui arrive sans panique, mais sans aveuglement non plus. Il faut accepter que nos outils puissent être remis en question, y compris ceux que l’on aime, ceux que l’on maîtrise et ceux qui nous font vivre.
Mais il faut aussi garder une vue d’ensemble.
Un discours de vente comparative peut faire réagir. Une vision globale aide davantage à conseiller.
Une vraie compétence demande parfois de ne pas vendre sa solution
À mon avis, la compétence ne consiste pas à dire : ma technologie est meilleure que la tienne, c’est de savoir reconnaître quand sa technologie n’est pas la meilleure réponse.
Et demain, avec l’IA, cette compétence deviendra probablement encore plus importante.
Parce que si les outils changent, si les CMS évoluent, si les frameworks se transforment, si de nouvelles plateformes apparaissent et si l’IA redistribue une partie des cartes, alors le rôle du professionnel ne sera pas seulement de défendre l’outil qu’il connaît.
Ce sera de comprendre ce qui reste pertinent, pour qui, dans quel contexte, et pour combien de temps.
Et ça, forcément, c’est plus difficile à vendre qu’une comparaison arrangée pour faire réagir.
Mais c’est beaucoup plus proche du métier.
Image : @cottonbro
