Internet a commencé avec du HTML et du CSS simples : des fichiers statiques, servis tels quels, sans serveur applicatif ni base de données. Puis les CMS — WordPress en tête — ont démocratisé la publication en ligne pour les profils non techniques, au prix d'une architecture plus lourde : un serveur PHP exécuté à chaque visite, une base de données interrogée à chaque affichage de page, et un écosystème de plugins qui n'a cessé d'élargir la surface d'attaque. En 2025, l'écosystème WordPress a cumulé plus de 11 300 nouvelles failles de sécurité, et le poids moyen d'une page web dépasse aujourd'hui 2,6 Mo sur mobile.

Ce compromis — simplicité d'édition contre sécurité et performance — n'a plus lieu d'être. L'intelligence artificielle conversationnelle a remplacé l'interface d'administration du CMS : on ne clique plus dans un back-office pour publier un article, on demande à l'IA de le rédiger, de le mettre en forme et de le publier directement dans les fichiers du site. Le site redevient un empilement de fichiers HTML/CSS statiques — sans PHP, sans base de données, sans plugin à surveiller, et donc sans la plupart des failles qui vont avec.

Florence Chatelot — Formatrice IA
À propos de l'auteure Florence Chatelot Formatrice IA & Consultante

J'accompagne des professionnels et des équipes à utiliser l'IA concrètement — sans jargon, sans gadget inutile. Mes formations et mes articles sont construits sur ce que je pratique et enseigne au quotidien.

451 apprenants · 4 730h de formation · +60 avis 5/5 Google · 23 avis 5/5 SuperProf

WordPress en 2026 : le prix caché de la simplicité

WordPress propulse encore autour de 43 % de tous les sites web dans le monde selon W3Techs — une position dominante qui en fait la cible privilégiée des attaquants. Les chiffres 2025 de Patchstack sont sans appel : 11 334 nouvelles vulnérabilités ont été recensées dans l'écosystème WordPress cette année-là, soit une hausse de 42 % par rapport à 2024 (7 966 failles). 96 % de ces failles proviennent des extensions tierces et 4 % des thèmes — le cœur de WordPress lui-même n'en concentre que 7 (source : Patchstack).

Le cœur n'est pourtant pas à l'abri. Le 17 juillet 2026, WordPress a dû publier trois correctifs d'urgence et déclencher une mise à jour automatique forcée après la découverte de « WP2Shell » : deux failles combinées — une confusion de routage qui contourne le contrôle d'accès (CVE-2026-63030) et une injection SQL dans WP_Query (CVE-2026-60137) — permettant une exécution de code à distance sans authentification, sur une installation WordPress standard, sans aucun plugin. Les versions concernées (6.9.0 à 6.9.4 et 7.0.0 à 7.0.1) équipaient à elles seules plus de 500 millions de sites selon ACA Group, et les deux CVE ont rejoint le catalogue des vulnérabilités activement exploitées de la CISA quatre jours après leur divulgation (source : SecurityWeek, Wiz).

Résultat mesurable côté infections : Sucuri constate que 96,2 % des sites CMS compromis analysés en 2024 tournaient sous WordPress — largement disproportionné par rapport à sa part de marché (source : Infosecurity Magazine). 93 % des failles WordPress proviennent de plugins ou thèmes tiers non maintenus, et 39 % des sites compromis tournaient simplement sur une version obsolète. Nettoyer un site infecté coûte en moyenne entre 300 et 1 800 € pour une infection courante, et peut dépasser 6 000 € pour un site e-commerce sérieusement touché (source : Stonegate Web Security).

Côté performance, le Web Almanac 2025 du HTTP Archive mesure une page mobile médiane de 2,6 Mo, en hausse de 8,4 % en un an ; sur les sites WordPress équipés d'un constructeur de pages visuel, les seules images représentent jusqu'à 70 % du poids total de la page (source : HTTP Archive). Un site statique bien conçu pèse généralement cinq à dix fois moins — voir notre approche de l'éco-conception web sur ce sujet.

Pourquoi les CMS existaient (et pourquoi ce n'est plus une raison suffisante)

Le compromis avait du sens en 2005 : sans CMS, publier un article demandait de rouvrir un éditeur de code, modifier du HTML à la main, puis envoyer les fichiers par FTP. WordPress a supprimé cette friction en donnant à n'importe qui une interface de type traitement de texte — au prix d'un serveur PHP exécuté à chaque visite, d'une base de données interrogée à chaque affichage, et d'un écosystème de plugins devenu, avec le temps, la première porte d'entrée des attaquants.

Ce compromis n'a jamais été gratuit : il a simplement été accepté, faute de meilleure option pour les profils non techniques. La question n'a jamais été de savoir si un site statique est plus sûr et plus rapide qu'un CMS — cela n'a jamais été contesté. La vraie question était : comment un rédacteur sans compétence technique peut-il publier du contenu sans interface d'administration ? L'IA conversationnelle répond directement à cette question.

Ce qui a vraiment changé : l'IA devient l'interface d'édition

Publier ou modifier un contenu ne nécessite plus de se connecter à un back-office. Il suffit de décrire le changement à un assistant IA — Claude Code en tête — qui édite directement les fichiers HTML, Markdown ou les templates du site, en langage naturel. Sur le forum officiel de Hugo, plusieurs développeurs témoignent avoir construit des thèmes entiers — mise en page, CSS, archétypes de contenu — en donnant de simples instructions à Claude plutôt qu'en codant chaque ligne à la main (source : forum Hugo, retour d'expérience détaillé).

Pour les rédacteurs qui préfèrent tout de même une interface graphique, des CMS « Git-based » comme TinaCMS ou Decap CMS offrent un compromis intéressant : une interface d'édition visuelle façon Gutenberg, qui écrit directement des fichiers Markdown dans un dépôt Git plutôt que dans une base de données — sans serveur PHP à sécuriser, avec l'historique et le rollback natifs de Git, et une authentification déléguée à GitHub plutôt qu'à un système de login maison. C'est la même promesse que l'IA, formulée différemment : découpler la facilité d'édition de la fragilité d'un CMS traditionnel.

Vous voulez passer votre propre site en statique, sans plonger seul dans Hugo et les scripts de migration ?

❋ Voir l'offre de création de site ❋

Comment transformer un site WordPress en site statique avec Hugo et l'IA

Concrètement, la migration se déroule en quatre grandes étapes, largement automatisables avec l'aide d'un assistant IA :

  1. Exporter le contenu existant. WordPress expose nativement son contenu via l'export XML classique (Outils → Exporter) ou via son API REST (/wp-json/wp/v2/posts), disponible sans configuration depuis WordPress 4.7.
  2. Convertir en Markdown. Des outils dédiés comme wp2hugo (CLI en Go) ou le plugin wordpress-to-hugo-exporter automatisent la conversion. Un assistant IA peut aussi écrire ce script sur mesure — en gérant les particularités propres au site (champs personnalisés, taxonomies, médias) — et en profiter pour nettoyer les URLs et corriger les métadonnées au passage.
  3. Recréer le design avec l'IA. Templates, CSS, menu, pied de page : tout devient du HTML/CSS classique dans les dossiers layouts/ de Hugo, générable et ajustable en langage naturel avec Claude Code — y compris la reproduction fidèle de la charte graphique existante à partir du thème WordPress d'origine.
  4. Déployer sur un hébergement statique. La commande hugo --minify suffit à générer le site dans le dossier public/, prêt à être déployé sur Cloudflare Pages, Netlify ou GitHub Pages — gratuitement dans la plupart des cas, avec HTTPS et CDN mondial inclus, sans serveur à administrer. Les limites de chaque hébergeur gratuit (et l'hébergement gratuit d'OVH) sont comparées dans mon article créer un site web gratuitement avec l'IA.

C'est exactement la démarche suivie pour ce site : florence-chatelot.fr était un site WordPress/Divi classique jusqu'à sa migration complète vers un site HTML statique, hébergé sur Cloudflare Pages, conçu et maintenu avec l'aide de l'IA. Zéro base de données, zéro plugin, zéro mise à jour de sécurité à surveiller — et un formulaire de contact qui fonctionne très bien sans back-end applicatif.

Et pour vendre en ligne ? La nuance e-commerce

Le site statique n'est pas adapté à un e-commerce classique avec un catalogue important, une gestion de stock en temps réel, des comptes clients et un panier multi-produits : ces fonctionnalités reposent sur un état qui change à chaque commande, ce qui suppose un minimum de logique serveur. WooCommerce, Shopify ou une architecture headless avec panier dynamique restent alors les bons outils.

Mais pour vendre un produit ou un service simple — une formation, une consultation, un ebook, un tirage limité — l'intégration de paiement reste facile à ajouter à un site statique, et l'IA raccourcit encore le travail. Les Payment Links de Stripe génèrent une page de paiement hébergée en quelques clics, sans écrire une ligne de code : il suffit de coller le lien ou de l'intégrer en bouton sur la page statique. Stripe Checkout va un cran plus loin et permet d'insérer un vrai bouton de paiement sur la page, avec plus de 40 moyens de paiement pris en charge — un assistant IA comme Claude Code peut générer cette intégration (bouton, et une petite fonction serverless type Cloudflare Worker si un traitement personnalisé est nécessaire) en quelques échanges.

Le point de vigilance reste le même que pour tout site statique : jamais de clé secrète dans le JavaScript exposé au navigateur. Les Payment Links et Stripe Checkout sont justement conçus pour éviter ce piège, puisque la logique sensible reste hébergée chez Stripe et non sur le site lui-même.

WordPress vs site statique (Hugo + IA) : le comparatif

Critère WordPress classique Site statique (Hugo + IA)
Base de données MySQL, interrogée à chaque affichage Aucune
Nouvelles failles (2025) 11 334 dans l'écosystème Pas d'équivalent (rien à exécuter côté serveur)
Poids de page médian 2,6 à 2,9 Mo, jusqu'à 70 % en images Quelques centaines de Ko
Édition de contenu Back-office Gutenberg Conversation avec l'IA, ou CMS Git-based (TinaCMS)
Hébergement Serveur PHP/MySQL, 5-30 €/mois CDN statique, souvent gratuit (Cloudflare Pages)
Maintenance de sécurité Mises à jour cœur + thèmes + plugins en continu Aucune, rien à corriger côté serveur
E-commerce complexe (catalogue, stock) Adapté (WooCommerce) Non adapté sans backend dédié

Faut-il migrer votre site vers le statique ?

Le site statique convient à la grande majorité des sites vitrines, blogs, portfolios, sites d'association ou de TPE — c'est-à-dire l'essentiel des sites WordPress existants, qui n'exploitent en réalité jamais les fonctionnalités dynamiques qui justifiaient à l'origine le choix d'un CMS. Restez sur WordPress (ou un CMS équivalent) si votre site a réellement besoin d'un panier multi-produits avec gestion de stock, d'un espace membre avec logique métier complexe, ou d'un grand nombre de contributeurs internes publiant plusieurs fois par jour sans intervention technique possible.

Dans tous les autres cas, la question n'est plus « ai-je les compétences techniques pour un site statique ? » — l'IA les fournit désormais — mais « pourquoi continuer à payer, en sécurité et en performance, pour une flexibilité que je n'utilise pas ? »

Ce que je propose : reconstruire votre site avec Hugo et un assistant IA d'édition

Je propose justement ce service : reconstruire un site existant — WordPress, Joomla ou tout autre CMS — en site statique avec Hugo, avec un design fidèle à l'original (ou repensé si vous le souhaitez), sans rien perdre de votre contenu ni de votre référencement.

La différence avec une migration « brute » : je mets en place un assistant IA d'édition dédié à votre site, pour que vous puissiez continuer à modifier vos contenus vous-même — textes, images, nouvelles pages — encore plus facilement qu'avec l'ancien back-office de votre CMS. Plus besoin d'apprendre une interface d'administration : vous décrivez le changement en langage naturel, l'IA édite directement les bons fichiers, vous validez, c'est publié.

Vous voulez qu'on reconstruise votre site en statique, avec un assistant IA pour continuer à l'éditer vous-même ?

❋ Réserver 1h de consultation ❋ Résultat obtenu ou remboursé

Sources utiles