Depuis quelques mois, une petite musique revient régulièrement dans les discussions entre professionnels du web :
« Avec l’IA, on revient vingt ans en arrière : plus besoin de WordPress, on refait des sites en HTML. »
Certains vont plus loin :
« J’ai remplacé mes sites WordPress par des sites HTML : ils sont plus rapides, plus sûrs, mieux référencés et je peux tout modifier en quelques minutes grâce à l’IA. »
Sur le papier, l’idée est séduisante.
Et contrairement à ce que l’on pourrait penser de la part d’une agence qui travaille avec WordPress depuis de nombreuses années, nous n’allons pas expliquer ici qu’elle est absurde.
Parce qu’elle ne l’est pas.
L’intelligence artificielle est réellement en train de bouleverser la manière dont nous concevons et développons des sites web. Elle rend accessible en quelques minutes ce qui pouvait autrefois nécessiter plusieurs heures de développement.
Elle remet même en cause certaines habitudes installées depuis vingt ans.
Mais de là à conclure que WordPress serait devenu inutile et qu’un site HTML constitue désormais la meilleure solution pour tout le monde, il y a un pas que nous ne franchirions certainement pas.
La vraie question n’est d’ailleurs probablement pas :
« WordPress ou HTML ? »
Elle est beaucoup plus intéressante :
Quelle architecture est réellement adaptée à votre site, à votre organisation et à son évolution future ?
Oui, l’IA redonne beaucoup d’intérêt aux sites statiques
Commençons par reconnaître ce qui a changé.
Créer un site sans système de gestion de contenu n’est évidemment pas nouveau. C’est même ainsi que l’immense majorité des sites internet étaient construits à l’origine.
Des fichiers HTML pour les contenus, du CSS pour la présentation, du JavaScript pour les interactions.
Puis les CMS se sont progressivement imposés afin de répondre à un problème évident : un site internet n’est généralement pas figé.
Il faut pouvoir modifier une page, publier une actualité, ajouter une image, créer un nouvel utilisateur, optimiser une page pour les moteurs de recherche…
Sans avoir à appeler un développeur à chaque modification.
WordPress et les autres systèmes de gestion de contenu ont précisément répondu à cette problématique.
Mais l’arrivée des outils d’intelligence artificielle change en partie l’équation.
Aujourd’hui, un développeur peut demander à une IA de modifier une mise en page, créer un composant, réorganiser un contenu ou générer une nouvelle page extrêmement rapidement.
Des outils modernes permettent également de générer des sites dont les pages finales sont essentiellement constituées de fichiers statiques extrêmement légers.
Et pour certains projets, c’est une excellente architecture.
Un site institutionnel de cinq ou dix pages, rarement modifié, sans espace utilisateur, sans catalogue complexe et sans véritable besoin éditorial peut parfaitement fonctionner ainsi.
Pourquoi faudrait-il installer un CMS, une base de données et une dizaine d’extensions si le site n’en a réellement pas besoin ?
Sur ce point, l’IA nous oblige à reposer de bonnes questions.
Et c’est plutôt une bonne nouvelle.
Un site statique peut effectivement être extrêmement rapide
C’est probablement son avantage le plus évident.
Une page HTML déjà générée demande très peu de traitement au serveur.
Il n’est pas nécessaire d’interroger une base de données, d’exécuter du PHP, de charger un CMS et différentes extensions avant d’envoyer la page au navigateur.
Associée à un CDN et à une infrastructure correctement configurée, cette architecture peut produire des performances remarquables.
Mais attention à une confusion fréquente :
un site statique n’est pas rapide parce qu’il est « meilleur pour Google ».
Il est rapide parce que son architecture permet de servir des pages très simplement.
La performance contribue bien à l’expérience utilisateur et les Core Web Vitals font partie des signaux pris en compte par les systèmes de Google. Mais Google précise lui-même qu’obtenir d’excellents scores de performance ne garantit aucunement d’apparaître en tête des résultats : pertinence et qualité du contenu restent essentielles.
Un site WordPress correctement conçu, hébergé et optimisé peut lui aussi obtenir d’excellentes performances.
Inversement, il est parfaitement possible de créer un site statique catastrophique rempli de JavaScript, d’images surdimensionnées et d’animations inutiles.
L’architecture compte. La manière dont elle est mise en œuvre compte encore davantage.
« Le HTML est meilleur pour le SEO » : non
C’est probablement l’un des arguments qui mérite le plus d’être nuancé.
Google ne récompense pas un site parce qu’il a été développé avec WordPress, Webflow, un framework JavaScript ou des fichiers HTML.
Un moteur de recherche analyse avant tout le résultat qui lui est présenté.
Parmi de nombreux critères entrent notamment en jeu :
la pertinence du contenu, sa structure sémantique, le maillage interne, les performances, l’expérience mobile, les liens obtenus par le site, son autorité, la qualité technique des pages, les données structurées, la capacité du moteur à explorer le contenu ou encore l’adéquation entre une page et l’intention de recherche.
Le CMS utilisé n’est donc pas, en lui-même, un avantage SEO.
Un site statique peut être remarquablement bien référencé.
Un WordPress également.
Et dans les deux cas, le contraire est tout aussi possible.
Il suffit d’ailleurs de regarder le Web actuel pour relativiser l’idée selon laquelle WordPress serait devenu une technologie marginale ou dépassée : en septembre 2026, W3Techs le détecte encore sur environ 40 % de l’ensemble des sites web et sur près de 59 % des sites utilisant un CMS identifié.
Cela ne signifie évidemment pas que WordPress soit la solution universelle.
Mais cela relativise quelque peu l’annonce de sa disparition imminente.
« Plus de WordPress, donc plus de piratage »
c’est plus compliqué…
Le raisonnement contient ici aussi une part de vérité.
Un site purement statique dispose généralement d’une surface d’attaque beaucoup plus réduite.
- Pas d’interface
/wp-admin. - Pas de base de données à compromettre.
- Pas de PHP exécuté pour chaque page.
- Pas d’extension vulnérable permettant éventuellement une injection SQL ou une prise de contrôle.
C’est un avantage réel.
Mais dire qu’un site HTML ne peut plus être attaqué serait faux.
- Le serveur ou le compte d’hébergement peut être compromis.
- Un formulaire peut s’appuyer sur une API vulnérable.
- Des scripts tiers peuvent présenter des risques.
- Le site peut être victime de scraping, de bots, de spam ou d’attaques par déni de service.
- La chaîne de déploiement elle-même peut être compromise.
La bonne formulation serait donc plutôt :
un site statique réduit considérablement certains risques applicatifs. Il ne supprime pas la problématique de sécurité.
Il faut également éviter l’autre raccourci consistant à considérer WordPress comme intrinsèquement peu sûr.
WordPress dispose d’une équipe de sécurité dédiée et de mécanismes automatiques de mises à jour de sécurité. Le projet recommande notamment de maintenir le cœur, les extensions et les thèmes à jour et de limiter les composants inutiles afin de réduire la surface d’attaque.
Depuis 2026, WordPress.org a même renforcé le contrôle des nouvelles versions d’extensions avec un processus automatisé de revue de sécurité avant leur distribution.
La sécurité n’est donc pas uniquement une question de technologie.
C’est aussi une question de maintenance, d’hébergement, de configuration et de gouvernance.
Le véritable sujet commence lorsque quelqu’un doit modifier le site
Prenons maintenant un exemple très simple.
Une entreprise remplace son ancien WordPress par un site statique.
Le résultat est excellent.
- Dix pages.
- Très rapides.
- Très propres.
Quelques mois passent.
L’entreprise souhaite maintenant :
- publier régulièrement des actualités ;
- ajouter une nouvelle personne à son équipe ;
- modifier une référence client ;
- créer une nouvelle landing page ;
- mettre en ligne des documents ;
- gérer elle-même ses balises SEO ;
- programmer la publication d’un contenu ;
- ajouter un formulaire avec notifications ;
- créer plusieurs comptes contributeurs ;
- gérer différentes autorisations ;
- conserver l’historique des modifications ;
- ajouter une seconde langue.
Toutes ces demandes sont parfaitement réalisables sans WordPress.
Mais progressivement, il va falloir créer une interface permettant de gérer les contenus.
- Puis gérer les utilisateurs.
- Puis les médias.
- Puis les droits.
- Puis les formulaires.
- Puis le référencement.
- Puis les redirections.
- Puis éventuellement des workflows de publication.
Autrement dit…
nous sommes progressivement en train de… reconstruire un CMS.
Et probablement un CMS disposant de beaucoup moins de fonctionnalités, de documentation et de recul qu’un outil développé depuis plus de vingt ans.
C’est ici que l’équation économique devient beaucoup plus intéressante.
« Avec l’IA, les modifications prennent cinq minutes »
C’est sans doute vrai.
Pour certaines modifications.
Et lorsque la bonne personne dispose du bon environnement de développement.
Changer une phrase, modifier une couleur ou déplacer un composant peut effectivement ne prendre que quelques minutes avec les outils actuels.
Mais ce raisonnement pose une question beaucoup plus importante :
Qui doit pouvoir modifier le site ?
- Le développeur ?
- L’agence ?
- Une intelligence artificielle ?
- Ou le service communication de l’entreprise ?
Car l’une des principales fonctions d’un CMS n’a jamais été d’aider les développeurs à développer.
Elle est de permettre aux personnes qui ne développent pas d’administrer le contenu.
Publier un article dans WordPress ne nécessite ni Git, ni terminal, ni environnement de développement, ni prompt.
- On se connecte.
- On rédige.
- On publie.
Ce niveau d’autonomie a une valeur considérable pour de nombreuses organisations.
L’intelligence artificielle change pourtant réellement la donne
Ce serait une erreur de minimiser ce qui est actuellement en train de se produire.
L’IA réduit considérablement le coût de création de logiciels et d’interfaces sur mesure.
Des fonctionnalités qui auraient autrefois nécessité plusieurs jours de développement peuvent parfois être prototypées en quelques heures.
Elle permet également d’imaginer beaucoup plus facilement des architectures hybrides.
Un site peut par exemple disposer d’un back-office tout en générant des pages statiques.
Une application métier peut communiquer avec WordPress par API.
Un CMS peut servir uniquement de gestionnaire de contenu tandis qu’une autre technologie assure l’affichage.
Des fonctionnalités spécifiques peuvent cohabiter avec des outils standards.
La conséquence la plus intéressante n’est donc probablement pas :
« L’IA va remplacer WordPress. »
Mais plutôt :
« L’IA nous permet enfin d’arrêter d’utiliser WordPress lorsqu’il n’apporte rien au projet. »
Et cela constitue une évolution particulièrement saine.
Dans quels cas choisir un site statique ?
Il peut être parfaitement pertinent lorsqu’un site :
- comporte relativement peu de pages ;
- évolue rarement ;
- est administré par une personne disposant d’un accompagnement technique ;
- ne nécessite pas de gestion complexe des utilisateurs ;
- comporte peu de contenus dynamiques ;
- n’a pas besoin de fonctionnalités métier importantes ;
- privilégie au maximum la simplicité d’infrastructure et la performance.
Pour une landing page événementielle, un microsite temporaire, certaines opérations marketing ou un petit site institutionnel, cette approche peut être excellente.
Et dans certains cas, nous la conseillerions nous-mêmes.
Dans quels cas WordPress conserve-t-il tout son intérêt ?
Dès que le site devient réellement administrable et évolutif, la situation change.
WordPress conserve notamment beaucoup de sens lorsqu’une organisation souhaite :
- publier régulièrement des contenus ;
- gérer elle-même ses pages ;
- disposer de plusieurs contributeurs avec différents rôles ;
- gérer une médiathèque importante ;
- intégrer formulaires, CRM ou automatisations ;
- disposer de fonctionnalités de référencement avancées ;
- créer facilement de nouvelles pages ;
- gérer des contenus structurés ;
- proposer plusieurs langues ;
- vendre en ligne ;
- faire évoluer régulièrement son site sans redévelopper son infrastructure.
Son immense écosystème constitue ici un avantage considérable.
Une fonctionnalité qui nécessiterait plusieurs jours de développement sur mesure peut parfois être obtenue avec une solution existante, maintenue et éprouvée.
Et ce facteur compte énormément dans le coût global d’un projet.
Le coût d’un site ne s’arrête pas au jour de sa mise en ligne
C’est probablement le point le plus important de toute cette discussion.
Lorsqu’on compare deux technologies, on regarde souvent uniquement leur coût de création.
C’est une erreur.
Un site professionnel peut rester en ligne cinq, huit ou dix ans.
Pendant toute cette période, il faudra probablement :
- Le faire évoluer.
- Ajouter des contenus.
- Modifier son design.
- Répondre à de nouvelles réglementations.
- Connecter de nouveaux outils.
- Changer d’hébergement.
- Faire évoluer son référencement.
- Former de nouveaux collaborateurs.
- Corriger des problèmes.
- Ajouter de nouvelles fonctionnalités.
La véritable question n’est donc pas :
« Quelle technologie permet de fabriquer mon site le plus rapidement aujourd’hui ? »
Mais :
« Quelle architecture restera la plus pertinente pour mon entreprise dans trois ou cinq ans ? »
Et la réponse peut être très différente.
L’avenir du Web ne sera probablement ni « tout WordPress » ni « tout HTML »
Pendant longtemps, une agence web pouvait raisonnablement choisir son outil préféré et l’utiliser pour presque tous ses projets.
Cette époque est probablement en train de disparaître.
Un projet peut aujourd’hui nécessiter :
- un CMS traditionnel ;
- un site statique ;
- un CMS headless ;
- une plateforme SaaS ;
- une application métier sur mesure ;
- une architecture hybride combinant plusieurs de ces approches.
L’intelligence artificielle élargit encore davantage le champ des possibles.
Elle ne rend donc pas l’architecture moins importante.
Elle la rend au contraire plus importante que jamais.
Chez OXICAT, nous utilisons WordPress. Mais nous ne vendons pas WordPress.
Nous travaillons avec WordPress depuis plus de 15 années et continuons à le considérer comme une excellente plateforme lorsqu’elle correspond au projet.
Mais notre métier n’est pas d’installer WordPress à chaque fois qu’une entreprise souhaite créer un site.
Notre métier consiste à comprendre un besoin, ses contraintes, ses usages futurs et son environnement technique pour concevoir l’architecture digitale la plus pertinente.
- Un site WordPress lorsque son CMS et son écosystème constituent un avantage.
- Une architecture plus légère lorsqu’un CMS n’apporte rien.
- Une application sur mesure lorsqu’un métier nécessite des fonctionnalités spécifiques.
- Ou une combinaison de plusieurs solutions lorsque le projet l’exige.
L’outil vient après le besoin, pas l’inverse.
Alors, faut-il abandonner WordPress pour un site HTML ?
Certainement pas simplement parce que l’intelligence artificielle permet désormais de produire du code plus rapidement.
Pour certains sites, une architecture statique pourra être une excellente évolution.
Pour d’autres, supprimer WordPress reviendrait surtout à abandonner un système de gestion extrêmement mature… pour devoir progressivement en reconstruire les fonctionnalités ailleurs.
Avant toute migration, il faut donc analyser ce que fait réellement le site aujourd’hui, qui l’administre, quelles sont ses dépendances et comment il est susceptible d’évoluer.
La meilleure technologie n’est pas la plus récente, la plus populaire ou la plus légère.
C’est celle qui répond au besoin avec le moins de complexité possible, sans sacrifier l’évolutivité future.
Et c’est finalement peut-être cela que l’intelligence artificielle est en train de changer le plus profondément dans notre métier : elle ne rend pas les choix technologiques inutiles. Elle nous oblige à mieux les faire.
