WordPress fait tourner plus de 40 % du web, et personne ne va l’enterrer cette année. Mais la question qu’on peut se poser : que met-on dessus pour construire son site web ?
Deux options dominent aujourd’hui la conversation. Continuer avec Elementor, le builder visuel devenu standard, ou basculer vers une construction assistée par IA, avec Claude Code en tête.
Cet article ne cherche pas à enterrer Elementor. Il essaie de poser honnêtement où chacun des deux camps fait sens en 2026, et de donner un cadre de décision utile.
WordPress en 2026 : où on en est vraiment
WordPress est devenu une infrastructure mature
Avant d’attaquer le débat du builder, il faut remettre WordPress à sa place. Plus de 40 % du web tourne encore dessus. Le chiffre n’a pas bougé significativement depuis trois ans, malgré les annonces régulières de mort prématurée.
Ce qui a bougé, en revanche, c’est l’intérieur de la maison. Gutenberg, l’éditeur natif, est devenu utilisable. Le Full Site Editing (FSE) a rendu possible la construction de thèmes entiers en blocs, sans builder tiers.
Les thèmes par défaut (Twenty Twenty-Four, Twenty Twenty-Five) sont propres, légers, accessibles. WooCommerce reste la première solution e-commerce open source du marché, et l’écosystème de plugins s’est assaini : les petits éditeurs ont disparu, les gros se sont professionnalisés.
WordPress 7.0 : AI-ready par défaut
WordPress 7.0, sorti en avril 2026, intègre directement le PHP AI Client SDK dans le core, et un MCP Adapter officiel a été publié début 2026. Le CMS ne se contente pas de tenir : il devient nativement AI-ready.
Le choix s’est déplacé
WordPress n’est ni en déclin ni en renaissance. C’est une infrastructure stable, mature, sur laquelle on continue de construire.
Du coup, le choix du builder devient autrement plus intéressant. On ne choisit plus si on reste sur WordPress. On choisit comment on construit dessus.
Elementor, ce que la promesse a tenu
Pourquoi je continue à le déployer
Avant d’attaquer les limites, je veux être honnête : je continue à livrer des projets sous Elementor en 2026. Plusieurs clients du studio tournent dessus, et ce n’est pas par défaut ou par paresse. C’est parce que pour leurs besoins, c’est encore la meilleure réponse.
Je le dis tout de suite parce que la suite va être nuancée. Je ne viens pas enterrer un outil que j’utilise.
Ce que le builder a résolu
Quand Elementor s’est imposé vers 2017-2019, il a résolu un problème réel. Avant lui, créer un site WordPress avec une vraie identité visuelle demandait soit du code, soit un thème premium bricolé jusqu’à approcher ce qu’on voulait.
Elementor a apporté une interface visuelle accessible aux non-développeurs. Logique de sections, de colonnes, de widgets. Courbe d’apprentissage douce, rendu prévisible.
Surtout, il a tenu une promesse qui compte côté client : l’autonomie après livraison. Le client peut modifier ses pages, ajouter une section, dupliquer un template, sans toucher au code ni appeler son prestataire pour chaque virgule.
Là où il reste imbattable : WooCommerce et l’écosystème
Elementor Pro reste un outil très utile dès qu’on touche à l’e-commerce. L’intégration WooCommerce native couvre la majorité des besoins courants : pages produit personnalisées, mini-paniers dynamiques, conditions d’affichage selon le statut du visiteur, vitrines filtrables.
Les widgets natifs couvrent 80 % de ce qu’on demande sur un site vitrine ou un e-commerce simple. Formulaires conditionnels, sliders, accordéons, témoignages, tableaux de prix, pop-ups, sans empiler des addons tiers. C’est rare de pouvoir le dire d’un produit dans l’écosystème WordPress.
L’écosystème s’est densifié autour : templates kits, widgets tiers, intégrations avec les principaux plugins formulaires et marketing. Pour un site vitrine, un e-commerce simple ou intermédiaire, ou un projet qui doit évoluer en autonomie côté client, c’est devenu un standard légitime.
Là où la facture technique commence à monter
La performance : un sport de combat
C’est sur la performance que le sujet pique le plus en 2026.
Un site Elementor moyen charge plusieurs centaines de kilo-octets de CSS et JavaScript avant même d’afficher quoi que ce soit. Le builder injecte son propre framework, ses styles globaux, ses scripts d’animation.
Ajoutez Elementor Pro, un pack d’addons (Essential Addons, Crocoblock JetEngine) pour combler deux ou trois widgets manquants, un cache, un optimizer, un plugin de minification. Vous obtenez un site qui charge, certes, mais qui se bat avec Lighthouse à chaque audit.
Core Web Vitals et accessibilité
Les Core Web Vitals deviennent un sport de combat. Le LCP est régulièrement au-dessus de 2,5 secondes sur mobile sans intervention sérieuse. Le CLS bouge à chaque animation tierce mal calibrée.
L’INP (qui a remplacé le FID début 2024) souffre dès qu’un widget fait du JavaScript en arrière-plan. On y arrive avec un travail d’optimisation poussé : cache niveau objet, lazy loading agressif, dégonflement des polices, suppression conditionnelle d’assets. Ce travail prend du temps, et il est à refaire à chaque mise à jour majeure de l’écosystème.
L’accessibilité est rarement native. Les widgets Elementor ont progressé, mais les addons tiers sont très inégaux. Un site builder respectueux du RGAA demande des corrections manuelles dans le code injecté, ce qui défait en partie la promesse d’autonomie.
La dette de plugins
L’autre coût est plus insidieux : la dette de plugins. Chaque widget tiers ajouté, chaque addon installé pour combler un manque, c’est une dépendance de plus.
Quand un plugin n’est plus maintenu, ou qu’un autre rentre en conflit à la version suivante, c’est le studio qui ramasse. Le client, lui, voit juste que « le site bug depuis la mise à jour ».
La frustration sur les pages complexes
Il y a un dernier coût, plus difficile à mesurer. Toute personne ayant passé des heures dans Elementor le connaît : la rapidité d’exécution durant la construction de pages complexes.
Sur une page simple, l’éditeur visuel est fluide. Dès qu’on empile les sections, qu’on imbrique des containers, qu’on travaille en responsive avec des règles conditionnelles, l’interface ralentit.
Un clic pour modifier une marge, l’attente du panneau, la sauvegarde de plusieurs secondes, le rechargement de l’aperçu. Une section qui devrait prendre dix minutes en prend trente. La frustration s’installe, et avec elle des décisions de design prises pour en finir plutôt que par choix.
Rien de tout ça n’est rédhibitoire. C’est juste une facture qui s’allonge, et qu’il faut savoir qu’on paie.
Le procès business : ce qu’on paie pour rester dans le système
Le cumul des licences
Au-delà de la technique, il y a la dimension économique. Elementor Pro se décline en plusieurs plans annuels : Essential à 60 €/an (1 site), Advanced Solo à 84 €/an (1 site, fonctionnalités complètes), Advanced à 99 €/an (3 sites), Expert à 204 €/an (25 sites). Crocoblock va de 40 €/an pour JetEngine seul à 185 €/an pour la suite All-Inclusive, et Essential Addons Pro tourne autour de 50 €/an.
La facture réelle dépend du profil. Un site unique avec stack minimaliste (Advanced Solo + JetEngine) tourne autour de 120 à 140 €/an. Un freelance multi-sites avec arsenal complet (Advanced + Crocoblock All-Inclusive + Essential Addons) couvre trois sites pour 330 €/an environ.
Dans les deux cas, c’est de la dépense récurrente pour faire tourner un site qui pouvait fonctionner sur WordPress nu il y a dix ans.
Le verrouillage progressif
Le coût n’est pas le problème principal. Le problème, c’est le verrouillage progressif. Un site construit entièrement avec Elementor ne peut plus s’en passer.
Désactivez Elementor : toutes les pages deviennent du code shortcode illisible. Migrer hors d’Elementor revient à refaire les pages une par une. À deux ou trois ans d’existence, c’est un coût de sortie qui pèse dans toute décision de refonte.
C’est moins grave qu’un SaaS fermé type Wix ou Squarespace, puisque le contenu (articles, produits, médias) reste portable via WordPress. Mais le travail de design, lui, est captif.
Le pivot 2026 : pourquoi la conversation n’est plus la même
Avant : code = développeur = inaccessible
Jusqu’en 2024, choisir « WordPress sans builder » voulait dire choisir le code. Faire appel à un développeur, écrire un thème custom ou un thème enfant, gérer soi-même les templates PHP. Un investissement initial plus lourd, un délai plus long, une autonomie client réduite.
Pour beaucoup de TPE, le calcul ne valait pas le coup. Elementor restait le compromis raisonnable.
Maintenant : l’effet de seuil Claude Code
L’arrivée des assistants de code à maturité (Claude Code en tête) a redistribué les cartes. Construire un site WordPress en code propre est devenu accessible à des profils qui n’étaient pas développeurs full-stack auparavant.
Le travail qui demandait deux semaines de dev en prend quelques heures, parfois quelques minutes. Le résultat : un site sans builder, sans dépendance plugin pour le visuel. Il charge en moins d’une seconde sur mobile et tient le RGAA sans bricolage.
Ce n’est pas une promesse magique. Le site de Studio Paraflow a d’ailleurs été refondu de cette manière, et c’est ce qu’on retrouve sur les projets livrés cette année. Ce qui n’était pas rentable hier le devient, et ça remet en question la position d’Elementor comme choix par défaut.
Et les autres alternatives ?
Le paysage des alternatives s’est lui aussi consolidé. Webflow est devenu un standard pour les sites marketing premium avec gros budget design. Framer reste autour de 0,2 % de part de marché : vague design-led réelle, qui touche surtout les SaaS, startups et agences créatives premium.
Bricks mérite une mention sérieuse. Il s’est imposé chez certaines agences techniques qui veulent un WordPress sans dette : lifetime license, code propre, performances natives bien au-dessus d’Elementor. Il vise le même créneau « WordPress performant » que Claude Code, et reste un builder donc garde l’avantage autonomie design côté client.
La nuance, c’est que Bricks demande quand même un profil technique côté studio. Claude Code va un cran plus loin en supprimant la couche builder. Breakdance et Gutenberg en FSE natif existent aussi dans ce créneau, mais c’est bien l’option « WordPress + Claude Code » qui change le plus la donne aujourd’hui.
Le cadre de décision : quatre questions à se poser
Les deux outils ont chacun leur terrain de jeu. Le bon choix dépend de votre rapport au site une fois qu’il est en ligne.
Quatre questions, dans cet ordre.
1. Votre site va-t-il bouger beaucoup et structurellement après la livraison ?
Beaucoup, ça veut dire : vous prévoyez d’ajouter régulièrement de nouvelles sections, de nouveaux blocs visuels, de nouveaux types de mise en page. Pas juste des articles ou des produits, ça c’est du contenu, tous les CMS le gèrent. On parle de structure visuelle qui évolue.
Si oui : Elementor reste le bon choix. C’est exactement la promesse que tient le builder. Vous avez la main, vos équipes peuvent expérimenter, vous ne dépendez pas du studio à chaque idée.
Si non, si la structure va rester stable pendant 2 à 3 ans et que vous ferez surtout du contenu, Claude Code devient pertinent.
2. Êtes-vous seul à intervenir sur le site, ou plusieurs personnes y accèdent-elles ?
C’est sans doute la question la plus structurante, et celle qu’on oublie le plus.
Un entrepreneur solo peut fonctionner en full Claude Code. Les modifications sont gérées par son prestataire, ou par lui-même s’il a monté en compétences. Le workflow brief-livraison est fluide parce qu’il n’y a qu’une seule personne à coordonner.
Une équipe de plusieurs personnes change complètement l’équation. Direction, marketing, communication, assistante administrative ne se mettront pas à Claude Code. Ils ont besoin d’une interface visuelle accessible où chacun peut modifier sa zone sans risque de casser quoi que ce soit.
3. Tenez-vous à toucher vous-même au design visuel ?
Certains dirigeants et marketeurs veulent garder la main sur le visuel. Ouvrir la page, glisser un bloc, changer une couleur, prévisualiser. C’est rassurant, c’est rapide pour les petites itérations, et ça donne un sentiment de contrôle qui compte.
D’autres préfèrent briefer et déléguer. Une demande envoyée, un résultat livré, validation et mise en ligne. Le temps économisé est consacré à autre chose.
Les deux postures sont légitimes. La première oriente vers Elementor. La seconde ouvre la porte au code assisté par IA, qui s’accommode très bien d’un workflow brief-livraison.
4. Le SEO technique et la performance sont-ils déterminants pour votre activité ?
Pour beaucoup d’entreprises, la performance technique du site est un confort. Important, mais pas vital. Le trafic vient d’ailleurs (réseaux sociaux, prescription, salons, Google Ads), et un Elementor sérieusement optimisé fait le travail.
Pour d’autres, le SEO est le canal d’acquisition principal. Un e-commerce concurrentiel, une activité de service très Google-dépendante, un média qui vit de son trafic organique. Là, chaque dixième de seconde de LCP compte, et chaque Core Web Vital dans le rouge se paye en positions perdues.
Claude Code donne un site qui part avec plusieurs longueurs d’avance : le code est propre dès la première ligne, sans couche builder à compenser. Et quand un problème de PageSpeed Insights apparaît, on peut directement demander à Claude Code de le corriger.
Synthèse en tableau
Les quatre questions, en un coup d’œil :
| Critère | Elementor | Claude Code (WordPress en code) |
|---|---|---|
| Évolution structurelle fréquente | ✅ Avantage clair | ⚠️ Demande de revenir vers le studio |
| Équipe de plusieurs personnes côté client | ✅ Interface accessible à tous | ❌ Inadapté aux profils non-techniques |
| Autonomie design côté client | ✅ Builder visuel accessible | ⚠️ Workflow brief-livraison |
| Performance et Core Web Vitals | ⚠️ Travail d’optim continu | ✅ Propre dès la première ligne |
| SEO technique critique | ⚠️ Possible mais coûteux | ✅ Naturellement optimal |
| E-commerce WooCommerce avancé | ✅ Widgets natifs très complets | ⚠️ Possible mais plus de dev |
| Coût récurrent licences | ❌ 120-330 €/an cumulés | ✅ WordPress + hébergement uniquement |
| Lock-in / portabilité | ❌ Design captif d’Elementor | ✅ Code standard, portable |
| Courbe d’apprentissage client | ✅ Douce, écosystème mature | ⚠️ Brief plus structuré nécessaire |
| Délai initial de production | ✅ Rapide sur projets simples | ✅ Rapide depuis l’arrivée de Claude Code |
| Vitesse d’exécution sur pages complexes | ❌ Interface qui ralentit, frustration | ✅ Fluide avec un process maîtrisé |
En clair, vous arbitrez entre ce qui se gagne à court terme (autonomie visuelle, accessibilité multi-profils) et ce qui se gagne à long terme (légèreté, performance, indépendance).
Mon process aujourd’hui sur les projets Claude Code
Construire un site WordPress avec Claude Code n’a rien à voir avec demander à une IA de « faire un site ». Le résultat dépend entièrement du process en amont. Voici l’essentiel.
Inspiration, V1, puis construction
L’inspiration vient en amont, et ce n’est pas négociable. Pinterest, Dribbble, Mobbin pour les patterns d’interface, sites concurrents, sites de référence du secteur. On ne génère pas un site à partir de rien : on le génère à partir d’une direction graphique déjà mentalement validée.
Ensuite, une V1 dans Claude.ai sert de validation rapide. J’itère sur la page d’accueil et deux ou trois sections clés, j’ajuste palette, typographie, rythme. Quelques heures qui évitent de partir trois jours dans la mauvaise direction.
Une fois cette V1 validée, la construction du site complet part de cette base. Code propre dès la première itération, composants réutilisés d’une page à l’autre. Sur les pages complexes, le gain est net : ce qui demandait trente minutes de clics dans un builder se fait en quelques minutes par instruction.
Les deux pièges à connaître
Le premier piège, c’est le slop. Un site monté à la chaîne avec une IA brute, ça se voit autant qu’un article ChatGPT non retravaillé.
C’est pour ça que j’utilise des skills personnalisés : ils cadrent composants, conventions de code et ton rédactionnel. Travail de studio invisible, mais c’est ce qui sépare un site IA d’un site fait par quelqu’un qui utilise l’IA.
Le second piège, plus structurel, c’est la dette technique. Claude Code rend le développement WordPress accessible à des profils non développeurs, mais « accessible » ne veut pas dire « sans prérequis ». Sans culture minimale en PHP, JavaScript, HTML/CSS, en architecture de thème, en hooks et en sécurité, on construit un site qu’on ne pourra plus maintenir dans deux ans.
L’IA ne dispense pas du métier : elle le démultiplie pour qui le connaît, et l’invente mal pour qui ne le connaît pas.
La passerelle : Elementor + Claude Code via MCP
Pour les projets qui ne veulent pas trancher de façon binaire, une option émerge depuis quelques mois. Les serveurs MCP (Model Context Protocol) rendent les builders pilotables par les assistants de code, sur le même principe que ce que fait déjà le MCP Figma côté design.
Concrètement, un MCP Elementor permet à Claude Code de manipuler widgets, sections et templates Elementor depuis du code, en gardant l’interface visuelle accessible au client. Vous gardez Elementor côté édition client. Le studio orchestre les évolutions structurelles côté code.
C’est un sujet à part entière, qui mérite son propre article. La frontière entre builder visuel et code assisté est en train de devenir poreuse.
Alors, faut-il passer à autre chose ?
WordPress reste. Ce n’était pas la question.
Elementor n’est pas mort, et ne le sera pas avant longtemps. Il reste la meilleure réponse pour trois profils de site :
- ceux qui ont besoin d’autonomie visuelle côté client ;
- ceux où plusieurs personnes doivent pouvoir intervenir sans formation technique ;
- ceux dont la structure va bouger souvent.
Je continue à le déployer chez les clients où ce profil correspond.
Ce qui a changé, c’est qu’Elementor a cessé d’être la réponse universelle. Sur les projets où la performance, le SEO technique ou la portabilité du code comptent vraiment, le calcul s’inverse. Et ça vaut surtout quand une seule personne, ou une petite équipe technique, intervient sur le site.
Claude Code donne alors un site plus rapide et plus propre, qui va tenir dans la durée. Et c’est toujours du WordPress derrière.
La question à se poser en 2026, ce n’est plus « WordPress ou pas WordPress ». C’est « sur WordPress, qu’est-ce qui sert le mieux mon projet à 3 ans, compte tenu de qui va vraiment toucher au site ».
