Pourquoi le blueprint a vécu, et comment l’IA réinvente votre architecture
Il y a encore trois ans, construire un site WordPress « pro » tenait de la recette de cuisine. Un thème multifonction, cinq ou six plugins par réflexe, Elementor Pro pour habiller le tout, et voilà : un site qui ressemblait à des milliers d’autres, lourd, lent, mais « complet ». On appelait ça un blueprint. On aurait dû appeler ça un piège.
Ce modèle est en train de mourir, et c’est une bonne nouvelle.
Le monolithe a fait son temps
Pendant des années, l’industrie WordPress a vendu une promesse simple : plus besoin de choisir ni d’assembler quoi que ce soit, un thème et un constructeur de pages suffisaient à tout gérer : design, fonctionnalités, e-commerce, animations. Une seule interface, un seul fournisseur, zéro décision à prendre. Résultat ? Des sites qui chargent quinze feuilles de style dont personne ne se souvient à quoi elles servent, des temps de chargement qui plombent le SEO, et une dépendance totale à un éditeur qui peut décider, du jour au lendemain, de changer de modèle économique ou de laisser tomber ses utilisateurs. Quiconque a vu son business dépendre d’un plugin soudainement abandonné sait de quoi je parle.
La vérité, c’est que « tout-en-un » n’a jamais voulu dire « bien fait ». Ça voulait dire « pratique pour vendre », pas « pratique pour faire tourner un site rapide et pérenne.
La nouvelle logique : la stack, pas le couteau suisse
Ce qui change en 2026, c’est le passage d’une logique de plugin monolithique à une logique de pile technique, où chaque brique fait une seule chose, mais la fait bien. C’est exactement la philosophie qui a gagné ailleurs dans la tech depuis longtemps : pourquoi WordPress y aurait-il échappé ?
La fondation doit redevenir invisible. Un thème n’a rien à faire d’autre que fournir une base propre et laisser le constructeur de blocs gérer la mise en page. GeneratePress , avec ses moins de 10 kb à l’installation, incarne cette discipline presque radicale. Quant à Astra, sa popularité est réelle, mais elle a un prix : celui de ressembler, par défaut, à des millions d’autres sites. Le message est clair : la performance n’est plus une option cochée après coup, c’est le point de départ.
Et il y a plus radical encore : ne pas installer de constructeur du tout. Avec les thèmes FSE (Full Site Editing), WordPress a fini par intégrer nativement ce que les page builders vendaient depuis dix ans. Twenty Twenty-Five, le thème par défaut, est redoutable de sobriété : zéro JavaScript superflu, entièrement pilotable depuis l’éditeur de site, et maintenu par le cœur de WordPress donc toujours à jour. Ollie et Ollie Pro vont plus loin encore : conçu spécifiquement pour montrer ce que le FSE sait faire, avec ses dizaines de compositions prêtes à l’emploi et son système de styles globaux, il permet de construire un site complet sans écrire une ligne de code ni ajouter le moindre plugin de mise en page. Pour beaucoup de projets vitrines, portfolios, blogs, c’est devenu le choix par défaut le plus honnête.
Si cette dépendance vous gêne, ou si Ollie ne correspond pas à votre projet, les alternatives sérieuses ne manquent pas. Raft joue la carte du minimalisme assumé, avec une cinquantaine de compositions et rien de superflu. Prime FSE de MotoPress mise sur la polyvalence, avec un mega-menu intégré et le plugin de blocs Getwid pour étoffer l’éditeur sans sortir du monde des blocs natifs. Neve FSE, porté par Themeisle, capitalise sur des années d’optimisation de performance et convient bien aux agences habituées à la version classique de Neve. Spectra One , signé Brainstorm Force, les créateurs d’Astra, cible plutôt les sites d’entreprise et portfolios avec des compositions orientées business (tarifs, équipes). Et si la maintenance à très long terme prime sur tout le reste, il reste Twenty Twenty-Five : moins spectaculaires, mais garantis par le cœur de WordPress lui-même, donc sans risque d’abandon.
Ce basculement rebat aussi les cartes du thème enfant. Le réflexe historique, dupliquer style.css et functions.php pour ne jamais perdre ses modifications à la moindre mise à jour reste indispensable dès qu’on touche du PHP. Mais sur un thème bloc comme Twenty Twenty-Five ou Ollie, la plupart des personnalisations visuelles passent désormais par theme.json et l’éditeur de site, pas par du code qu’on protège dans un thème enfant classique. Le plugin Create Block Theme peut générer ce thème enfant FSE en quelques clics, mais il ne faut pas en faire un passage obligé : sur une installation Multisite, la création de thème enfant via ce plugin est un point faible connu: le thème enfant peut être activé sans que son parent soit reconnu, et se retrouver classé comme « cassé ». Sur un réseau multisite, mieux vaut donc créer le thème enfant à la main (style.css + theme.json) ou passer par WP-CLI. Le principe reste néanmoins le même : le thème enfant n’a pas disparu, il a changé de nature : il protège moins de code, parce qu’il y a simplement moins de code à protéger.
Le constructeur de pages n’a plus d’excuse pour être lent. Si Elementor Pro est devenu synonyme de lourdeur pour beaucoup, ce n’est pas une fatalité, c’est le signe qu’un outil vieillissant a laissé le champ libre à des alternatives pensées différemment dès le premier jour. Bricks Builder, construit sur Vue.js, avec une gestion native des classes CSS, produit du code qu’on n’a pas honte de montrer. GreenShift pousse la logique jusqu’au bout : il ne charge que ce dont il a réellement besoin, un principe qui devrait être une évidence et qui reste, hélas, une exception. Oxygen va encore plus loin en désactivant purement et simplement le système de thème pour offrir un contrôle total, au prix d’une exigence technique réelle. C’est un choix qui reste pertinent techniquement (code propre, performance, et une refonte récente, Oxygen 6, avec un workflow class-first et un moteur d’interactions modernisé, mais à réserver aux projets où c’est l’agence qui garde la main sur la maintenance. Car sur le terrain, la demande a changé : les clients veulent de plus en plus une expérience « SaaS-like », une interface qu’ils peuvent reprendre eux-mêmes sans formation, comme sur Webflow ou Framer. Or c’est précisément le point faible d’Oxygen, dont l’interface pensée développeur reste nettement moins accessible que celle d’Elementor ou de Breakdance pour un client qui veut simplement changer une image ou un texte. Dans ce cas de figure, Bricks Builder ou Breakdance offrent un meilleur compromis entre code propre et prise en main autonome par le client. Et Breakdance tente le pari le plus ambitieux : la facilité d’Elementor sans son passif de performance.
Même Elementor a fini par comprendre le message : sa version V4, en adoptant une approche CSS-first, admet implicitement que le modèle précédent n’était plus tenable.
Le cas le plus révélateur reste Divi. Longtemps symbole même du couteau suisse : thème et builder vendus comme un tout indissociable, réputé lourd et daté, Elegant Themes a choisi une option radicale : ne pas rafistoler, mais tout reconstruire. Sorti officiellement en février 2026, Divi 5 abandonne les shortcodes hérités de PHP pour une architecture React et un système de contenu en JSON. Le résultat se mesure : jusqu’à 96 % de score de performance sur GTmetrix contre 81 % pour Divi 4, un chargement autour d’1,3 seconde contre 2,3, et un éditeur annoncé jusqu’à quatre fois plus réactif. Même les acteurs historiques du « tout-en-un » sont donc contraints d’adopter, sous le capot, la même discipline que les outsiders : code plus léger, moins de dépendances superflues, une architecture pensée pour durer. La nuance qui compte, en revanche : les modules et extensions tiers construits pour Divi 4 ne bénéficient de ces gains que s’ils sont réécrits nativement pour Divi 5 : sinon ils tournent en mode de compatibilité, sans aucun des bénéfices de performance. Autrement dit, même chez Divi, la promesse du « tout est déjà inclus » ne tient plus sans un vrai travail de mise à jour de l’écosystème autour.
L’automatisation n’est plus un gadget. C’est peut-être le vrai basculement. WordPress cesse d’être une simple vitrine pour devenir un nœud dans un système plus large, via le protocole MCP (Model Context Protocol) qui permet à des agents IA de dialoguer avec Slack, un CRM ou une messagerie et d’exécuter des workflows sans une ligne de code. Ce mouvement vient d’ailleurs du cœur même de WordPress : Automattic a fait passer son adaptateur MCP dans le noyau, et WordPress.com propose désormais une connexion MCP native avec authentification OAuth. Des plugins tiers comme Royal MCP s’appuient sur cette base pour exposer une centaine d’actions (contenu, WooCommerce, SEO) à des clients comme Claude ou ChatGPT. Des outils comme Webhook Actions transforment presque n’importe quel événement du site en webhook exploitable, bien plus fiable qu’un wp_remote_post() bricolé à la va-vite.
Pour la logique headless, mieux vaut donc s’appuyer sur des briques éprouvées et largement maintenues comme WPGraphQL , plutôt que sur la dernière solution « 10x plus rapide » en vogue. Le principe général de l’article tient toujours : composer une architecture plutôt que miser sur un outil unique. Mais cela vaut aussi pour chaque brique individuelle — mieux vaut vérifier régulièrement qu’un plugin tiers est toujours actif avant d’en faire une dépendance critique.
Ce que ça coûte vraiment
Soyons honnêtes : cette approche modulaire demande plus de réflexion en amont. On ne clique plus simplement sur « installer » en espérant que tout s’assemble tout seul. Il faut choisir ses briques, comprendre comment elles s’articulent, accepter une courbe d’apprentissage un peu plus raide : GeneratePress ou Ollie ne pardonnent pas l’improvisation.
Mais c’est précisément là que se joue la différence entre bricoler un site et construire une plateforme. Le confort du tout-en-un a un coût caché : la lenteur, la dette technique, la dépendance à un seul fournisseur. Le prix de la modularité, lui, se paie une fois, au moment de la conception et se rembourse ensuite en performance, en liberté et en capacité d’évolution.
Une architecture, pas un produit
Le vieux réflexe consistait à chercher LE PLUGIN, le BUILDER ou le THEME qui ferait tout. Le réflexe qui s’impose aujourd’hui consiste à assembler une architecture : une fondation minimaliste, un constructeur moderne, une couche d’automatisation dédiée. Trois rôles, trois outils, une cohérence d’ensemble plutôt qu’un empilement de fonctionnalités.
Ce n’est plus un blueprint qu’on télécharge. C’est une décision qu’on prend, brique par brique, en toute connaissance de cause. Et c’est très exactement ce qui manquait à WordPress depuis dix ans.
Les thèmes premium et les builders que vous achetez par réflexe ne sont plus des investissements durables : ce sont des achats de confort dont la valeur s’érode à chaque nouvelle version d’un modèle de langage. La vraie question n’est plus « quel outil choisir ? » mais comment piloter l’IA pour construire mon architecture.
