Le choix qui détermine 5 ans de vie de votre site : sa sécurité, son coût total, qui doit le maintenir, comment il vieillit. On ne fait pas de prosélytisme — on explique vraiment, on dit quand chaque choix gagne, et on vous laisse décider.
Sans jargon : la différence se joue à un seul endroit, le moment où un visiteur arrive sur votre site.
Le serveur a un fichier accueil.html
tout prêt. Quand vous arrivez sur le site, il vous l'envoie tel quel.
Aucun calcul, aucune base de données interrogée.
Analogie : un menu imprimé à l'imprimerie. Le serveur le distribue tel quel, le menu n'évolue pas entre deux clients qui le lisent.
Technologies typiques
Astro, Hugo, Eleventy, Jekyll, Next.js export statique, sites HTML/CSS purs.
Quand vous arrivez sur le site, le serveur lance un programme PHP (par exemple), interroge une base de données pour récupérer le contenu, assemble le HTML, et vous l'envoie. À chaque visite.
Analogie : un serveur de restaurant qui va en cuisine pour chaque commande, attend que le chef prépare, et revient avec l'assiette. Plus flexible, mais plus de pièces qui peuvent tomber en panne.
Technologies typiques
WordPress, PrestaShop, Joomla, Drupal, Magento, Symfony, Laravel, Ruby on Rails.
Cinq ans de différence sur 8 critères qui pèsent vraiment sur le coût total et la tranquillité.
| Critère | Site statique | Site dynamique |
|---|---|---|
| Architecture | Fichiers HTML/CSS/JS pré-compilés, servis tels quels | Code serveur (PHP, Python, Node…) + base de données interrogée à chaque requête |
| Surface d'attaque | Quasi nulle — pas de DB, pas de back-office, pas d'interpréteur exécuté | Étendue — chaque plugin / dépendance / login est un point d'entrée potentiel |
| Mises à jour requises | Zéro maintenance régulière (le serveur sert juste des fichiers) | CMS + plugins + PHP + MySQL + OS — tous à patcher en continu |
| Performance (TTFB) | 5-50 ms (cache CDN possible) | 100-800 ms typique (calcul PHP + requêtes DB à chaque hit) |
| Coût hébergement | 0 à 10 € / mois (mutualisé ou CDN gratuit type Netlify/Cloudflare) | 5 à 50 € / mois minimum (RAM + DB + sauvegardes) |
| Modifier le contenu | Via le code — par votre prestataire ou vous si vous touchez à Git | Back-office accessible 24/7 (mais à protéger comme un coffre-fort) |
| E-commerce, espace membres | Non, ou seulement via API tierce (Stripe, Shopify Buy Button) | Natif (WooCommerce, Magento, Prestashop, espaces membres complets) |
| Crash sous charge | Tient des milliers de visiteurs / sec sans transpirer | La DB ou le PHP-FPM sature au-delà de quelques dizaines de visiteurs / sec |
Ce n'est pas une opinion — c'est de la mécanique. Un site dynamique expose des points d'entrée que le statique n'a pas. Les attaquants scannent automatiquement Internet 24/7 à la recherche de ces points.
tentatives d'intrusion bloquées chaque jour en moyenne sur un site WordPress (Wordfence Threat Intelligence Report, 2024). La majorité sont automatisées et inoffensives si le site est à jour, mais une seule réussie suffit.
CVE plugins WordPress publiées en 2024 (vulnérabilités connues, dont ~80 critiques — Wordfence + Patchstack).
CVE applicative possible sur un site statique (HTML/CSS/JS sans code serveur exécuté). Reste l'OS et Apache, vecteurs identiques pour tout site web.
/wp-admin, /administrator) — bombardé de tentatives de login automatiques (brute-force, credential stuffing). Un mot de passe faible = compte admin compromis en quelques heures.
site.sql à la racine), .env avec les clés API, dossier .git non bloqué. Les scanners automatiques cherchent ça en premier.
Un site statique n'a ni back-office, ni base de données, ni interpréteur serveur exécuté à chaque requête. Apache lit un fichier HTML et l'envoie. Le seul vecteur d'attaque restant, c'est le serveur lui-même (OS, Apache, SSH) — et c'est exactement le même que pour héberger un dynamique. La différence : sur un statique, on s'arrête là. Sur un dynamique, on rajoute tout ce qui est dans la liste ci-dessus.
C'est ici que se cache le coût caché d'un site dynamique. Une "petite" maintenance qui prend 10-15 min, multipliée par 30-50 fois par an, finit par valoir un site neuf.
| Le code source du site | Quand vous voulez le modifier (jamais d'urgence sécurité) |
| Le serveur Apache/Nginx | Patchs OS via apt-get, ~tous les 3-6 mois |
| Le certificat SSL | Auto-renouvelé par Let's Encrypt tous les 90 jours |
| Une dépendance JavaScript | Quasi jamais sur un site statique vitrine, on en utilise très peu |
Total : ~2-3 interventions par an, principalement côté serveur. Le code du site lui-même n'a pas besoin de mises à jour de sécurité.
| Le cœur du CMS (WordPress, Drupal, Joomla) | Mineure tous les 1-2 mois, majeure tous les 6-12 mois |
| Le thème actif | Variable selon l'éditeur — souvent 1-2× / an, parfois zéro (thème abandonné = risque) |
| Chaque plugin installé | Indépendant — un site avec 25 plugins reçoit ~30-50 updates / an, dont des urgentes (CVE) |
| PHP | Major tous les 12-18 mois, fin de support tous les 2-3 ans (oblige à migrer) |
| MySQL / MariaDB | Updates trimestrielles, migrations majeures tous les 3-5 ans |
| Le serveur Apache/Nginx | Patchs OS via apt-get, ~tous les 3-6 mois |
| Le certificat SSL | Auto-renouvelé par Let's Encrypt tous les 90 jours |
Total : ~30-50 interventions par an pour un WordPress moyen avec 15-25 plugins. Une seule oubliée peut suffire pour un piratage.
Ordre de grandeur indicatif (TPE / PME, hors évolutions fonctionnelles majeures). Le tarif catalogue Bistrot Web est utilisé pour l'hébergement (9,90 € HT/mois) et pour la désinfection (à partir de 399 € HT).
Site statique vitrine : 0 maintenance récurrente. Hébergement 9,90 €/mois × 60 mois = 594 €. + ~600 € de petites évolutions ponctuelles facturées à la prestation sur la période. Pas de surprise.
Site WordPress équivalent : Hébergement 10-30 €/mois + maintenance plugins / CVE 30-50 €/mois (si confiée à un prestataire) + risque d'1 ou 2 désinfections sur 5 ans (399-599 € l'unité). Sans compter les heures perdues en panne et la perte de confiance des visiteurs.
Pas de réponse universelle. La bonne question c'est : qu'est-ce que mon site doit faire que des fichiers HTML ne peuvent pas faire ? Si la réponse est "rien", le statique gagne.
Note : les frontières bougent grâce aux Headless CMS (Sanity, Contentful, Strapi) qui combinent un back-office dynamique pour l'édition + un front-end statique pour la performance et la sécurité. Mais c'est un choix d'architecture qui se justifie surtout au-delà de 100 pages régulièrement éditées par plusieurs personnes.
Pas du tout. Un WordPress bien tenu (audits réguliers, plugins minimalistes, mises à jour automatiques activées) reste un choix valide. Le passage au statique se justifie quand : (a) personne ne maintient activement le site, (b) le site est piraté pour la deuxième fois, (c) vous payez un mainteneur 50-100 €/mois pour faire des updates qui n'ajoutent rien fonctionnellement. Si rien de ça n'est vrai, gardez WordPress.
Sur un site statique moderne (Astro, Hugo, Eleventy), un blog se gère très bien : chaque article est un fichier Markdown, le générateur recompile le site à chaque ajout. Pas de back-office mais aussi pas de surface d'attaque. Pour un blog avec plusieurs auteurs et un workflow de validation éditoriale, là par contre un CMS dynamique (Headless CMS comme Sanity ou Strapi + frontend statique) ou WordPress restent plus pratiques.
Si vous avez votre site sur le web, il reçoit dès aujourd'hui des tentatives de connexion automatisées sur /wp-admin, des scans de versions de plugins, des requêtes vers des fichiers exposés (.env, wp-config.php). Wordfence rapporte ~2 milliards d'attaques bloquées par mois sur leur base d'utilisateurs. Sur un seul site moyen, ça représente plusieurs centaines à plusieurs dizaines de milliers de tentatives par jour. La plupart sont automatiques et inoffensives si le site est à jour — mais une seule réussie suffit.
C'est l'argument numéro 1 pour rester dynamique. Si votre client veut publier un article hebdomadaire sans appeler un dev, WordPress reste imbattable. Mais beaucoup de clients qui pensent vouloir ça finissent par ne jamais toucher au back-office (ou le toucher mal et casser le site). Une question utile : sur les 3 derniers mois, combien de modifications votre client aurait fait lui-même vs combien aurait été déléguées ? Si la réponse est < 1/mois, le statique avec modification à la prestation revient moins cher.
Oui, plusieurs options : (a) un service tiers comme Formspree ou Web3Forms qui reçoit le POST et envoie un mail (gratuit jusqu'à ~50 envois/mois), (b) une fonction serverless (Cloudflare Workers, Netlify Functions) déclenchée à la soumission, (c) un endpoint sur un mini-backend séparé. Sans dynamisme côté serveur principal, donc pas de risque de SQL injection sur le formulaire.
Parce que c'est gratuit, qu'il y a une communauté énorme, qu'on trouve un dev WordPress sur n'importe quelle place de marché, et que pour 60-70 % des cas (blog, vitrine modifiable, e-commerce léger) c'est suffisant. Mais ces 60-70 % de cas sont aussi ceux où des sites statiques modernes feraient mieux côté sécurité, performance et coût total. WordPress paye sa popularité par sa surface d'attaque massive — chaque vulnérabilité touche des millions de sites simultanément.
C'est probablement dynamique (90 % des sites pros sur internet le sont). Indices : URL avec /wp-admin/, /administrator/, /typo3/ ; logo "Powered by WordPress" ou "PrestaShop" en footer ; un back-office accessible avec login. Sinon, regardez le code source de la page (clic droit → "Code source de la page") : si vous voyez beaucoup de scripts JS et de fichiers compilés, c'est plutôt statique ; si vous voyez des références à wp-content/themes/ ou à des plugins, c'est dynamique.
Décrivez ce que vous voulez faire en 3-4 lignes — on vous dit franchement si le statique est le bon choix, ou si c'est WordPress (auquel cas on ne fera pas la création, on vous orientera vers un collègue WP de confiance).