En résumé
Un site statique (Next.js, Hugo, Gatsby) génère des fichiers HTML au build et les sert depuis un CDN — TTFB sous 60ms, zéro base de données exposée, hébergement gratuit. WordPress génère chaque page à la demande (PHP + MySQL) — TTFB de 400–800ms, maintenance permanente, 90% des CMS piratés sont WordPress (Sucuri 2024). Pour un site vitrine ou blog, l'architecture statique est supérieure sur tous les critères techniques.
Un site statique génère ses pages une seule fois, au moment du build, et les distribue depuis un CDN mondial. WordPress régénère chaque page à chaque visite, via PHP et une base de données MySQL. Cette différence d'architecture détermine tout : vitesse, sécurité, coûts et maintenance.
WordPress alimente 43,4 % du web mondial selon W3Techs — un chiffre qui reflète sa popularité historique, pas nécessairement ses mérites techniques en 2026. Ce guide compare les deux architectures sans parti pris, avec des données précises.
Vous cherchez une alternative concrète ? Consultez notre liste des meilleures alternatives à WordPress — outils statiques, CMS headless et solutions hybrides.
Comment fonctionne un site statique ?
Un site statique est construit en une seule étape : le build. Le framework (Next.js, Hugo, Gatsby) lit vos fichiers de contenu, génère des fichiers HTML, CSS et JavaScript, et les envoie sur un CDN.
Chaque visiteur reçoit un fichier HTML déjà généré, stocké sur un serveur CDN géographiquement proche de lui. Pas de base de données consultée. Pas de PHP exécuté. Pas de latence serveur.
Le flux d'une requête sur un site statique
Visiteur → CDN (edge node local) → Fichier HTML pré-généré
↑
Build (GitHub Actions / Vercel CI)
← Fichiers MDX / contenu
Le TTFB (Time to First Byte) d'un site statique sur Vercel Edge Network se situe entre 20 et 60ms. C'est structurellement impossible à atteindre avec une architecture dynamique sans cache complexe et coûteux.
Mise à jour du contenu
Modifier un article ou ajouter une page déclenche un nouveau build. Sur Vercel ou Netlify, ce build prend 30 à 90 secondes et se déploie automatiquement via un push Git ou un webhook depuis un CMS headless.
Ce n'est pas "instantané" comme WordPress — mais pour un site vitrine ou un blog, aucun visiteur ne verra jamais la différence.
Comment fonctionne WordPress ?
WordPress génère chaque page à la demande, au moment où un visiteur la charge. Le serveur exécute du PHP, interroge une base de données MySQL, assemble le HTML, et renvoie la réponse.
Cette architecture date de 2003. Elle était raisonnable quand le contenu changeait constamment et que les CDN n'existaient pas. En 2026, pour un site dont le contenu change rarement, c'est un surcoût sans bénéfice.
Le flux d'une requête WordPress
Visiteur → Serveur PHP → Base de données MySQL → Assemblage HTML → Réponse
(400–800ms de latence typique)
Chaque requête interroge la base de données, même si la page n'a pas changé depuis des semaines. Les plugins de cache (WP Rocket, W3 Total Cache) contournent partiellement ce problème — mais ajoutent de la complexité, du coût et des conflits potentiels.
WordPress propulse des sites très différents : blogs personnels, boutiques WooCommerce, intranets d'entreprise, médias à fort trafic. Cette polyvalence est une force — et aussi la source de sa complexité.
Site statique vs WordPress : les performances
Les données HTTP Archive sont sans appel : seulement 36 % des sites WordPress passent le seuil "Good" sur mobile pour le LCP (Largest Contentful Paint), contre plus de 75 % pour les sites statiques Next.js correctement configurés.
Google définit un bon LCP sous 2,5 secondes (source : web.dev). WordPress atteint en moyenne 2,8 à 4,2s sur mobile. Next.js statique atteint 0,8 à 1,4s.
Comparatif performances
| Métrique | WordPress (moyen) | Site statique Next.js |
|---|---|---|
| TTFB | 400–800ms | 20–60ms |
| LCP mobile | 2,8–4,2s | 0,8–1,4s |
| Score Lighthouse | 45–70 | 90–100 |
| Core Web Vitals "Good" (mobile) | 36 % | 75 %+ |
| Time to Interactive | 4–8s | 1–2s |
Google utilise les Core Web Vitals comme facteur de classement depuis mai 2021 (Google Search Central). Un site statique est donc structurellement avantagé en SEO face à un WordPress non optimisé — à contenu identique.
Pourquoi WordPress est lent par défaut
La lenteur de WordPress n'est pas un défaut de code — c'est une conséquence de l'architecture dynamique. Chaque visite déclenche 20 à 80 requêtes SQL selon la complexité du site. Chaque plugin actif ajoute du PHP et souvent du JavaScript côté client.
Un WordPress bien optimisé (WP Rocket + CDN + images compressées + hébergement dédié) peut approcher les 70–80 en Lighthouse. Cela coûte du temps, de l'argent et de la maintenance permanente.
Site statique vs WordPress : la sécurité
WordPress est la cible numéro un des attaques web en 2026. 90 % des CMS piratés tournaient sous WordPress selon le Sucuri Security Report 2024. Cette statistique n'est pas liée à la qualité du code WordPress — elle reflète la taille de sa surface d'attaque.
Pourquoi WordPress est vulnérable structurellement
Chaque site WordPress expose plusieurs vecteurs d'attaque en permanence :
- L'interface
/wp-adminest accessible publiquement — cible des attaques par force brute - La base de données MySQL est connectée en permanence au serveur PHP
- Chaque plugin introduit du code tiers avec accès complet au filesystem et à la base de données
- Les mises à jour manquées (WordPress core, thèmes, plugins) créent des failles CVE connues et exploitables automatiquement
Un site WordPress avec 15 plugins actifs a potentiellement 15 surfaces d'attaque indépendantes. Les scanners automatisés explorent le web en permanence à la recherche de versions vulnérables.
La sécurité d'un site statique par construction
Un site statique n'a pas de base de données exposée. Pas d'interface d'administration publique. Pas de PHP. Pas de plugins tiers avec accès serveur.
La surface d'attaque se réduit à deux éléments : votre hébergeur (Vercel, Netlify) et votre dépôt Git (GitHub). Les deux gèrent leur propre sécurité infrastructure — certificats SSL, protection DDoS, mises à jour système. Vous n'avez rien à surveiller côté serveur.
Le risque zéro n'existe pas — mais le profil de risque d'un site statique est radicalement inférieur à celui d'un WordPress.
Site statique vs WordPress : les coûts
Le coût apparent de WordPress est faible — un hébergement mutualisé à 5€/mois. Le coût réel sur 3 ans est significativement plus élevé quand on intègre les plugins, la maintenance et la sécurité.
Tableau de coûts sur 36 mois (site vitrine + blog)
| Poste | WordPress | Site statique (Next.js + Vercel) |
|---|---|---|
| Hébergement | 15–80€/mois × 36 | 0€/mois (plan gratuit) |
| Nom de domaine | ~15$/an × 3 = 45$ | ~15$/an × 3 = 45$ |
| Plugins premium | 200–800$/an = 600–2 400$ | 0$ |
| Plugin SEO (Yoast/RankMath) | 99–229$/an = 297–687$ | Inclus nativement |
| Plugin cache (WP Rocket) | 59$/an = 177$ | Inutile |
| Maintenance sécurité | 5–15h/an × 80$/h = 1 200–3 600$ | <1h/an |
| Total estimé | 2 919–8 232$ | 45–645$ |
Sur 3 ans, un site WordPress professionnel coûte 2 874$ à 7 587$ de plus qu'un site statique équivalent. Cette estimation exclut les coûts de remise en état après une infection malware — fréquents et imprévisibles.
Le plan gratuit Vercel couvre la quasi-totalité des sites vitrines et blogs : 100 GB de bande passante, déploiements illimités, CDN mondial. Le passage au plan Pro (20$/mois) n'est nécessaire qu'à partir d'un trafic commercial significatif.
Site statique vs WordPress : le SEO
Les deux architectures permettent un bon SEO. Mais les sites statiques offrent un avantage structurel sur les métriques techniques qui influencent directement le classement.
Google intègre les Core Web Vitals dans son algorithme depuis mai 2021 (Google Search Central). LCP, FID/INP et CLS sont des signaux de classement directs. Un site statique obtient systématiquement de meilleurs scores sur ces métriques qu'un WordPress non optimisé.
Comparatif SEO technique
| Fonctionnalité | WordPress | Site statique (Onyx) |
|---|---|---|
| Métadonnées par page | ✅ Via Yoast/RankMath | ✅ Automatique (frontmatter) |
| JSON-LD structuré | ⚠️ Plugin payant | ✅ Généré automatiquement |
| Sitemap XML | ✅ Plugin | ✅ Dynamique natif |
| Flux RSS | ✅ Natif | ✅ Natif |
| Core Web Vitals | ⚠️ Variables, souvent mauvais | ✅ Optimisés par défaut |
| TTFB (impact crawl) | 400–800ms | 20–60ms |
| Canonical URLs | ✅ Via plugin | ✅ Natif |
Le TTFB impacte directement le crawl budget. Un Googlebot qui attend 600ms à chaque page crawle moins de pages par session. Un site statique à 30ms de TTFB est exploré plus efficacement — avantage concret pour les sites de plus de 200 pages.
Le JSON-LD (données structurées) est particulièrement important en 2026. Les moteurs de recherche génératifs (Google SGE, Perplexity) utilisent ces données pour citer les sources avec précision. Onyx génère automatiquement les schémas BlogPosting, Organization et BreadcrumbList — sans plugin, sans configuration.
Les limites du site statique
Un site statique n'est pas la solution universelle. Il faut être honnête sur ses contraintes réelles.
Pas adapté à certains cas d'usage
Le contenu temps réel est limité. Un site statique ne peut pas afficher des données qui changent en permanence (prix en temps réel, stock e-commerce, flux live) sans une couche JavaScript côté client ou des API calls dynamiques. C'est faisable, mais plus complexe.
Les non-développeurs ne peuvent pas gérer le contenu seuls sans configuration supplémentaire. Écrire du Markdown dans VS Code et pousser sur GitHub n'est pas à la portée d'un rédacteur marketing. Un CMS headless (Sanity, Tina CMS, Decap) résout ce problème — mais ajoute une couche de configuration.
Chaque modification nécessite un build. Corriger une faute de frappe déclenche un déploiement de 30 à 90 secondes. Pour un blog mis à jour plusieurs fois par heure, ce délai peut être perceptible.
Le site statique est inadapté à : les boutiques e-commerce complexes, les plateformes à fort contenu dynamique, les applications web avec authentification complexe, les sites nécessitant une interface d'administration autonome pour plusieurs rédacteurs non techniques.
Quand choisir un site statique ?
Un site statique est le bon choix dans ces situations :
- Site vitrine, portfolio, landing page — contenu stable, pages comptables sur les doigts
- Blog professionnel géré par un développeur ou une agence
- La performance et le SEO sont stratégiques — e-commerce marketing, lead generation, SEO local
- La sécurité est prioritaire — cabinet médical, juridique, institutionnel
- Le budget est contraint — 0$/mois d'hébergement vs 15–80€/mois WordPress
- Vous voulez zéro maintenance serveur — pas de mises à jour WordPress, pas de sauvegardes à gérer
- L'équipe maîtrise React / Next.js et préfère un workflow Git
Quand garder WordPress ?
WordPress reste pertinent dans ces cas précis :
- Des non-développeurs publient du contenu de façon autonome plusieurs fois par semaine
- Vous avez besoin de WooCommerce — l'écosystème e-commerce WordPress est difficile à remplacer
- Un LMS ou une plateforme de membership est nécessaire (LearnDash, MemberPress)
- L'équipe maîtrise WordPress et le coût de transition vers Next.js n'est pas justifié
- Le site est déjà WordPress avec un contenu riche — la migration représente un coût réel à évaluer
- Vous avez besoin d'une interface d'administration multi-rôles sans développement sur mesure
Conclusion : architecture statique en 2026
Pour un site vitrine, un portfolio ou un blog professionnel, l'architecture statique surpasse WordPress sur tous les critères techniques : TTFB 10 à 20 fois plus faible, scores Lighthouse systématiquement au-dessus de 90, zéro surface d'attaque côté base de données, hébergement gratuit.
WordPress reste légitime pour les projets avec une forte composante dynamique ou des rédacteurs non techniques qui doivent agir de façon autonome. Mais pour un site dont le contenu évolue modérément, payer 15 à 80€/mois d'hébergement et des heures de maintenance pour une architecture plus lente et moins sécurisée n'a plus de justification technique.
Vous hésitez encore entre les deux approches ? Consultez notre comparatif Onyx vs WordPress pour un analyse approfondie sur les performances, la sécurité et les coûts.
Prêt à passer au statique ? Onyx, template Next.js open source — déployable sur Vercel en moins d'une heure, gratuitement, avec SEO automatique et scores Lighthouse optimisés dès le premier build.
