On lit partout qu'il n'y aurait plus besoin d'un CMS — WordPress, Shopify ou autre — pour créer un site. Il suffirait de décrire ce qu'on veut à une IA, et le site apparaît. C'est techniquement vrai : on peut aujourd'hui générer un site fonctionnel de A à Z par la seule conversation. Mais cette méthode a des limites que quiconque a tenté l'expérience reconnaîtra :
Le premier essai est toujours impressionnant. C'est ce qui alimente l'engouement. Le problème arrive juste après : affiner les réglages graphiques ou homogénéiser les pages pose encore de vraies difficultés. L'IA modifie des éléments qu'on ne lui a pas demandé de toucher, comprend mal certaines demandes, régénère au lieu d'ajuster. La démo séduit ; la mise au point frustre.
On revient, paradoxalement, à un mode de fabrication des années 90. Le site est développé depuis une page blanche, ligne à ligne. Le développeur est désormais une machine — avec les approximations du point précédent — mais le principe est le même : on ne sait pas exactement comment le site est codé. Or cette opacité a des conséquences très concrètes sur l'évolution du site, la sécurité, les performances et le référencement. Ce qu'on ne maîtrise pas, on ne peut ni auditer ni faire évoluer sereinement.
Sans travail préalable, le résultat reste générique. Une IA produit une réponse par probabilité, fondée sur ses données d'entraînement. Pour la génération de sites, ces données sont l'ensemble des sites existants — dont la grande majorité sont basiques et pas toujours bien conçus. Sans effort investi dans la définition d'un système de design propre à votre entreprise et dans l'affinage d'un prompt précis, le site convergera vers cette moyenne : correct, mais sans identité différenciante.
Ces limites ne sont pas rédhibitoires. Mais elles montrent que le code 100 % IA n'est pas la voie magique annoncée. Pour un site de qualité, bien référencé et doté d'une identité propre, il faudra y passer du temps et savoir quoi demander à l'IA — sur la structure et le design, mais aussi sur des aspects plus techniques de performance et de SEO/GEO.
C'est précisément pour cela que les CMS gardent tout leur sens dans un workflow assisté par IA.
Pourquoi un CMS reste pertinent, même à l'ère de l'IA
Loin d'être rendu obsolète par l'IA, un CMS comme WordPress apporte un cadre qui répond directement aux limites ci-dessus.
La preuve la plus parlante vient des vendeurs eux-mêmes. Les solutions de génération de sites par IA commercialisées par les hébergeurs ne se passent pas de CMS — au contraire, elles reposent dessus. Elles s'appuient sur un CMS (le leur, ou WordPress) et y intègrent un builder (le leur, ou le plus souvent Elementor) pour produire le site. Autrement dit, ceux qui vendent la promesse du « site généré par IA » n'abandonnent pas l'architecture CMS + builder : ils la gardent sous le capot, précisément parce qu'elle apporte la structure, la sécurité et l'éditabilité qu'un code brut généré à la volée ne garantit pas. Si le CMS était vraiment devenu inutile, les acteurs les mieux placés pour s'en affranchir seraient les premiers à le faire.
Une structure éprouvée plutôt qu'une page blanche. Là où le code 100 % IA repart de zéro à chaque fois, le CMS fournit une architecture testée sur des millions de sites : gestion des contenus, des utilisateurs, des rôles, des médias, des URL. On ne réinvente pas — et on ne redébogue pas — ce qui existe déjà et fonctionne.
- Un modèle de sécurité mature. Mises à jour du cœur, correctifs de vulnérabilités, gestion des permissions, écosystème de plugins de sécurité : autant de garde-fous qu'un site codé de zéro par IA n'offre pas nativement. Sur du site client en production, cet écart est décisif.
- La séparation du contenu et de la présentation. Le contenu vit dans une base de données structurée, indépendante du design. On peut refondre l'apparence sans toucher au contenu, et migrer le contenu sans le perdre. C'est le fondement de la portabilité — l'exact inverse de l'opacité du code généré à la volée.
- Une édition autonome pour le client non technique. L'interface d'administration permet à un client de gérer ses contenus sans écrire une ligne de code ni relancer une génération IA hasardeuse. C'est ce qui rend un site vivant après livraison, pas figé.
- Des fondations SEO solides et un écosystème d'extension. Structure d'URL propre, gestion des métadonnées, sitemaps, plugins SEO matures, compatibilité avec les standards du référencement : le CMS intègre ce que l'IA générative traite au mieux comme une réflexion après coup. S'y ajoute un écosystème de milliers d'extensions et de thèmes pour étendre les fonctionnalités sans tout redévelopper.
- Un savoir-faire et un vivier partagés. Des millions de développeurs connaissent WordPress. Un site bâti sur ce socle peut être repris par un large vivier de professionnels — là où un site 100 % IA codé sur mesure ne peut être maintenu que par qui accepte d'en déchiffrer le code.
L'enjeu n'est donc pas « CMS ou IA », mais CMS avec IA : garder le cadre robuste du CMS, et y injecter l'IA là où elle accélère réellement le travail.
Une réserve de périmètre avant d'aller plus loin : nous laissons de côté la voie la plus répandue, qui consiste à partir d'un thème préfait et à le personnaliser (l'IA aide d'ailleurs à en ajuster les réglages). Elle atteint vite ses limites dès qu'on vise un vrai sur-mesure. L'article se concentre donc sur la création de sites professionnels à forte identité — et c'est là que la façon d'articuler l'IA avec WordPress se scinde en deux.
Deux façons de faire travailler l'IA avec WordPress : natif ou builder
Le choix est acté : on construit sur WordPress, et on s'appuie sur l'IA. Mais l'IA ne s'y intègre pas d'une seule manière. Tout dépend d'une décision initiale qui conditionne tout le reste — construit-on avec l'éditeur natif (Gutenberg, thème de blocs) ou avec un builder (Divi, Elementor) ? Ce n'est pas un détail d'outillage : les deux entrées font intervenir l'IA à des moments différents, avec des forces et des limites opposées.
Posons tout de suite la conclusion, car elle éclaire le reste. On présente souvent la voie native comme « propre et pérenne » et la voie builder comme « lourde et captive ». C'est une caricature.
La réalité est un arbitrage : la voie native optimise la propreté technique, la portabilité du contenu et la protection de la charte ; la voie builder optimise la vitesse de production visuelle, l'autonomie du client et la facilité de maintenance. Le bon choix dépend du type de relation que vous entretenez avec le client, pas d'un dogme.
Gardez cette grille en tête. Tout ce qui suit s'y rattache.
Panorama des méthodes disponibles
1. Les builders tout-en-un
Ces outils génèrent un site complet à partir d'une simple description. WordPress.com AI Website Builder produit un site en quelques minutes ; 10Web s'appuie sur Elementor pour livrer une mise en page, du contenu et les pages essentielles ; Bluehost AI Site Creator combine hébergement et génération.
Ils conviennent à des structures qui veulent être en ligne vite, avec un budget contenu, et qui acceptent une structure rigide sous le capot. Pratiques pour démarrer, peu adaptés à un projet sur-mesure ou évolutif.
2. Les plugins IA des builders (Divi, Elementor)
Rappelons d'abord ce que sont ces builders. Ce sont des solutions no-code qui offrent bien plus d'options de mise en page que le format natif de Gutenberg, sans écrire une ligne de code. Pour un utilisateur non technique, c'est un gain d'autonomie réel : on construit et on modifie visuellement des mises en page riches, là où le natif impose plus vite ses limites.
Sur ces deux builders, les plus répandus, on ajoute une extension intégrant de l'IA au sein de WordPress. Le principe est constant : décrire ce qu'on veut, et le plugin génère une mise en page dans le format du builder, éditable ensuite visuellement. C'est l'entrée de gamme du « design assisté par IA » — on dégrossit avec l'IA, on affine à la main. Mais ce partage des rôles est plus précis qu'un simple « affinage », et il diffère d'un builder à l'autre. Deux tests concrets le montrent.
Divi AI : un générateur de squelette, pas de contenu. Demandez-lui une section de statistiques — trois colonnes, des cartes, des compteurs animés. La structure est parfaite (colonnes, cartes, bons modules, libellés presque justes), mais les valeurs chiffrées sont ignorées : l'IA inscrit sa valeur par défaut, « 100 », partout. Ce n'est pas un bug. Ces IA traitent le contenu comme du remplissage : excellent squelette, mauvais exécutant du contenu précis, ton de marque et données spécifiques ratés. D'où une division du travail nette : l'IA fait la structure, vous saisissez les données à la main (pour un compteur, la valeur va dans le champ numérique dédié, le suffixe « % » dans les options du module). Second constat, plus limitant : Divi AI génère mais ne réitère pas. Impossible de lui demander de retravailler une structure existante en dialogue — c'est un générateur one-shot, et comme le premier jet tombe rarement juste, on bascule vite en édition manuelle.
Elementor AI : un cran au-dessus sur l'itération. Il permet, lui, de revenir sur une structure existante — clic droit sur un conteneur, demande de modification, l'IA propose des variations éditables ; son AI Copilot analyse même le contenu en place pour suggérer la section suivante. Sans surévaluer pour autant : le mécanisme reste la régénération de variations par lots (l'IA propose plusieurs options entières, on en retient une, chaque cycle consomme des crédits), pas l'affinage chirurgical en dialogue. Position intermédiaire, donc : plus souple que le one-shot de Divi, sans atteindre le va-et-vient fin d'un copilote conversationnel.
Ces deux comportements tranchent avec la voie native décrite plus loin, où l'itération conversationnelle avec Claude Code est le cœur du processus. Là où Divi AI s'arrête après un jet et où Elementor AI régénère par lots, Claude Code dialogue, corrige et harmonise entre les pages, à la phrase près. Deux philosophies : le builder offre un démarrage visuel rapide puis vous rend la main (plus ou moins tôt) ; la voie native garde l'IA dans la boucle du début à la fin.
La leçon dépasse le cas Divi : ces IA visuelles accélèrent la mise en forme, pas la justesse du contenu ni, à des degrés divers, l'itération fine. C'est précisément pour cela qu'elles conviennent à un client autonome sur ses données — il complète et ajuste lui-même — et moins à une livraison « clé en main » qu'on croirait finie alors qu'elle est truffée de valeurs par défaut et d'agencements approximatifs.
3. La méthode MCP : piloter le site par conversation
C'est le vrai changement de paradigme de 2026. Une fois Claude connecté à votre site — via un plugin dédié, la configuration se fait en quelques minutes —, vous ne pilotez plus WordPress en cliquant dans l'administration, mais en le demandant en langage naturel. La connexion technique importe peu ici ; ce qui compte, c'est ce qu'elle permet une fois établie.
Ce que Claude sait faire, une fois branché. L'essentiel tourne autour du contenu et de l'opérationnel : créer et modifier des articles ou des pages, remplir et mettre à jour du texte, gérer les médias, organiser les catégories et les étiquettes, lire l'existant pour s'en servir de base, appliquer des changements en masse (renommer, reclasser, mettre à jour des dizaines de pages d'un coup), auditer le site ou son référencement. Pour tout ce qui est répétitif ou volumineux, c'est un gain de temps considérable : ce qui prendrait une heure de clics se fait en une phrase.
Ce que la connexion ne fait pas : designer. C'est ici qu'on survend le plus. La connexion transmet du contenu et des actions, pas du design visuel libre. Concrètement, sur un site en blocs natifs, Claude peut structurer une page et la styliser dans le cadre défini par le thème — mais il ne conçoit pas une mise en page originale par un simple prompt. Et sur un site construit avec un builder (Divi, Elementor), la limite est plus dure encore : la connexion standard ne sait pas éditer une mise en page de builder au niveau d'un bouton ou d'une section. Elle pousse du contenu, pas de la mise en forme de builder.
Deuxième limite, tout aussi importante : Claude agit à l'aveugle. Il ne voit pas le rendu de ce qu'il produit. Il manipule la structure et le contenu sans retour visuel, si bien que tout ajustement esthétique fin — « remonte ce bloc », « ce contraste est insuffisant » — se fait en boucle ouverte : vous décrivez, il applique, vous allez vérifier dans le navigateur. Ce n'est pas du design en temps réel.
Le bon mental model : une fois branché, Claude est un rédacteur-intégrateur très efficace, pas un webdesigner. Il excelle sur le contenu, le volume et la maintenance ; il ne remplace pas le travail de conception visuelle.
4. Les MCP spécialisés builder
Une catégorie d'outils tiers comble précisément la limite « designer dans un builder ». Des solutions comme Respira apprennent à l'IA à « parler » le langage de Divi, Elementor, Bricks : elles comprennent que « agrandis le titre de la hero » vise tel module précis et appliquent la modification au bon endroit, avec des garde-fous (duplication avant édition pour ne rien casser).
C'est aujourd'hui la seule voie pour éditer réellement une mise en page de builder par prompt de façon relativement sûre. Réserve d'usage : ce sont des solutions commerciales récentes, à éprouver sur un site de test avant tout déploiement client.
5. Le développement assisté : générer le code, l'intégrer
C'est le cœur de la voie native, la plus pérenne. Une précision d'abord, car elle dédramatise l'approche : construire en Gutenberg avec un thème de blocs se rapproche finalement beaucoup d'un builder. On assemble des blocs (colonnes, boutons, images, sections) exactement comme on empilerait des modules dans Divi ou Elementor. La différence tient à l'indépendance : comme ces blocs sont natifs à WordPress, on ne dépend plus d'un builder tiers ni de son format propriétaire. Même logique de construction visuelle, meilleure portabilité.
Sur le design, restons brefs. L'IA peut aider à le concevoir — avec les réserves déjà posées en introduction (résultat qui tend vers le générique, ajustements laborieux). Mais ce n'est pas le sujet ici : le parti pris graphique peut tout aussi bien venir d'un graphiste, d'une charte existante ou d'une maquette fournie. Peu importe son origine, ce qui compte est ce qu'on en fait ensuite.
Le vrai apport de Claude Code : transformer un design en site. À partir d'une maquette (HTML, visuel, ou design validé), Claude Code génère le code correspondant — le thème de blocs et ses gabarits. Concrètement, on récupère ce code et on l'importe dans WordPress : les fichiers de thème d'un côté, et les mises en page qui se collent directement dans l'éditeur Gutenberg sous forme de blocs de l'autre. La page apparaît, construite avec des blocs natifs éditables, fidèle à la maquette.
L'enjeu est dans le prompt. La difficulté n'est pas de générer une page isolée, mais de faire en sorte que Claude Code produise d'abord les styles transverses — palette, typographie, espacements, styles par défaut des blocs, regroupés dans le theme.json du thème. Ce sont eux qui garantissent que toutes les autres pages se déclinent dans la même identité, sans avoir à tout re-spécifier à chaque fois. Bien prompté, on obtient un système cohérent où une nouvelle page hérite automatiquement de la charte. Mal prompté, on obtient des pages qui divergent les unes des autres. C'est là que se joue la qualité du résultat — et là que la compétence compte.
Un geste utile au passage : on peut verrouiller la charte en ne laissant aux éditeurs que les couleurs et styles définis, pour que le client (ou quiconque édite ensuite) ne puisse pas sortir de l'identité visuelle. On y revient dans la partie sur la gouvernance.
Les limites, en toute honnêteté. L'approche reste la plus exigeante. La génération peut demander des itérations : prompts à reformuler, incohérences à corriger entre les pages. Et tant que le design tient dans les réglages natifs des blocs, c'est propre ; dès qu'il faut aller au-delà, on écrit du CSS sur-mesure, avec la dette technique associée. Règle empirique : élégant tant que c'est simple, plus complexe et chronophage dès qu'on dépasse les options natives. S'ajoute un coût réel en crédits d'IA sur les gros projets, et un temps de prise en main pour qui n'est pas technique.
Comment choisir
Le choix natif vs builder n'est pas une question d'outil, c'est une question de relation client. Une précision de fond avant de trancher : aucune des deux voies ne supprime la dépendance, elle en change seulement la nature. Le builder crée une dépendance à son format propriétaire (migrer ailleurs casse les mises en page) ; la voie native crée une dépendance au code et à qui sait le lire. La bonne question n'est donc pas « serai-je autonome ? » mais « si je change de prestataire, qu'est-ce que j'emporte, et qui peut reprendre ? ». À cette question, la voie native répond mieux — à condition de livrer un thème propre et documenté, faute de quoi on recrée un lock-in, cette fois vers l'agence.
Le tableau ci-dessous synthétise l'arbitrage.
| Critère | Voie builder (Divi, Elementor) | Voie native (Gutenberg, thème codé) |
|---|---|---|
| Construction du design | Visuelle, assistée par IA, réglages rapides | Générée par code (Claude Code) à partir d'une maquette |
| Vitesse de production | Élevée | Moyenne (itérations, prompt à calibrer) |
| Autonomie du client | Élevée (édition visuelle libre) | Bonne sur le contenu, encadrée sur le design |
| Facilité de maintenance | Élevée | Exige des compétences dès qu'on dépasse le natif |
| Propreté technique / performance | Variable (couche builder) | Optimale (blocs natifs) |
| Nature de la dépendance | Au format propriétaire (lock-in) | Au code et à qui sait le reprendre |
| Portabilité du contenu | Faible (migrer casse les layouts) | Élevée (blocs natifs standard) |
| Qui peut reprendre | Un spécialiste de ce builder | Tout développeur WordPress maîtrisant les blocs |
Concrètement : pour une petite structure qui veut tout maîtriser elle-même, avec un budget récurrent limité et un besoin d'autonomie maximale sur le contenu comme sur la mise en page, le builder est cohérent — on assume le lock-in en échange de la liberté du client. Pour un client dont la cohérence de marque prime, engagé dans une relation durable et soucieux de pouvoir un jour emporter son site, la voie native protège mieux ses intérêts : le design relève de votre périmètre, le contenu du sien, et le patrimoine reste portable.
L'IA n'a pas tranché ce débat. Elle a rendu les deux voies plus rapides, et elle a surtout rendu le choix plus lisible : il ne s'agit plus de capacités techniques, mais de gouvernance. La bonne méthode est celle qui correspond au niveau d'autonomie que vous voulez vraiment confier — et au coût de sortie que votre client est prêt à accepter.