Dans les discussions sur la création de sites internet, on oppose souvent « WordPress contre un constructeur visuel en ligne », « un éditeur de sites en ligne contre du code sur-mesure » ou « CMS dynamique contre site statique ». Ces débats masquent une réalité technique fondamentale que le marketing oublie fréquemment de préciser : quel que soit l'outil utilisé, votre navigateur web ne reçoit et n'exécute jamais rien d'autre que du code standard (HTML, CSS et JavaScript).
Google Chrome, Apple Safari ou Mozilla Firefox n'exécutent ni PHP, ni requêtes SQL, ni tableaux de bord d'administration. Les CMS dynamiques ne sont que des usines logicielles intermédiaires dont la mission est d'assembler ce code HTML lors de chaque visite.
La question architecturale n'est donc pas de savoir quel format d'affichage choisir, mais de comprendre : pourquoi mobiliser un serveur applicatif à chaque visiteur pour fabriquer à la volée un fichier qui ne change presque jamais ?
1. Le principe fondamental : votre navigateur ne traite que du code standard
Pour afficher une page web sur un écran d'ordinateur ou de smartphone, un navigateur exécute un processus invariable :
- Le parseur HTML lit le squelette du document et construit l'arborescence des éléments (le DOM ou Document Object Model).
- Le moteur de rendu associe les feuilles de style CSS pour déterminer les dimensions, polices, couleurs et espacements.
- Le moteur d'exécution JavaScript applique les éventuelles animations et interactions dynamiques.
Tout ce qui se passe en amont (l'exécution d'un script serveur, l'interrogation d'une base de données, la compilation d'un thème) est totalement invisible pour le client. Ce qui conditionne directement la vitesse de chargement perçue et les métriques Google Core Web Vitals (LCP, INP, CLS), c'est la charge utile brute (le poids des fichiers transmis) et le temps de réponse initial du serveur (le TTFB ou Time To First Byte).
Dit autrement, et sans le vocabulaire : un site statique, c'est une carte de visite — non pour ce qu'elle raconte, mais pour la façon dont elle arrive dans la main. Elle est imprimée une fois, à mille exemplaires, identique pour tout le monde ; quand quelqu'un la demande, on la sort de la poche et on la tend. Un CMS, c'est la même carte, mais qu'on ferait réimprimer à chaque poignée de main. À chaque personne qui se présente, on appelle l'imprimeur, on réveille la machine, on refait composer la carte, on attend qu'elle sorte, et on la tend.
Le visiteur reçoit la même carte dans les deux cas. Ce qui change, c'est le temps qu'il a passé à attendre, et le nombre d'endroits où ça pouvait coincer : l'imprimeur fermé un dimanche soir, la machine à court d'encre, ou simplement dix commandes avant la vôtre dans la file.
Rien de tout cela n'est fatal, et un atelier sérieux sort ses commandes toute l'année sans incident. La question n'est pas de savoir si la chaîne casse un jour : c'est de savoir combien de maillons il faut tenir pour qu'elle tienne, et qui les tient.
Règle d'or de l'ingénierie web : Moins le serveur effectue de calculs lors d'une requête et plus le code délivré est épuré, plus la page s'affiche vite et de manière stable sur un smartphone.
2. L'histoire du Web : l'essor de WordPress et la dette technique d'universalité
Pour comprendre le paysage actuel, un rappel historique est nécessaire :
Les années 1990 : l'âge du HTML pur et du bas débit
Aux débuts du web grand public, tous les sites étaient intégralement statiques : de simples fichiers .html reliés par des liens hypertextes et déposés sur un serveur via FTP. Si la navigation globale était alors particulièrement lente pour l'internaute en raison des modems 56k et des connexions RTC facturées à la minute, le serveur web, lui, n'avait aucun calcul à exécuter : aucun interpréteur PHP à réveiller, aucune base de données MySQL à interroger. La page était délivrée brute dès la réception du signal réseau, avec une surface d'attaque logicielle quasi inexistante.
Mais cette architecture historique présentait une barrière humaine majeure : la moindre modification de texte ou de tarif nécessitait d'éditer manuellement les balises dans le code source, ce qui excluait les utilisateurs non-techniciens.
L'ère des CMS : du blog spécialisé au couteau suisse (2003 à aujourd'hui)
À l'origine, WordPress n'a pas été conçu pour construire tout le web : il a été créé en 2003 (en reprenant le projet b2/cafelog) dans un but unique : permettre à des particuliers de tenir facilement un blog personnel avec des articles chronologiques et un espace de commentaires, sans toucher au code.
Forts de leur succès, WordPress (qui fait tourner aujourd'hui plus de 40 % des sites mondiaux), Drupal et Joomla ont progressivement étendu leur champ d'action grâce aux extensions et aux types de contenus sur-mesure (apparus vers 2010), jusqu'à devenir des CMS généralistes tentant de tout faire avec le même socle logiciel :
- Un blog d'actualités avec des milliers d'articles et de commentaires,
- Une boutique e-commerce avec gestion de panier et de stocks (WooCommerce),
- Un intranet d'entreprise ou un réseau social communautaire,
- Ou un simple site vitrine de 5 pages pour un artisan ou une profession libérale.
Le coût d'un moteur de blog devenu géant
Pour faire cohabiter autant d'usages disparates sur un même moteur, un CMS universel empile une machinerie complexe : requêtes SQL multiples, filtres de sécurité, modules d'authentification et dizaines de scripts. Lorsqu'on l'utilise pour un simple site vitrine local (qui n'a besoin que d'afficher des photos, des prestations et un numéro de téléphone), le serveur exécute pour chaque visiteur une mécanique de blog lourdement modifiée, là où quelques kilooctets de HTML pur suffiraient.
3. Anatomie d'une requête : que se passe-t-il sous le capot ?
La différence de performance et de résilience entre les deux modèles s'explique par le chemin que parcourt chaque requête sur le réseau :
Sur le plan de la sécurité informatique, la différence est tout aussi marquée :
- Sur un CMS dynamique classique : Le serveur héberge du code PHP exécutable et une base de données MySQL. Chaque extension tierce ou formulaire représente une porte d'entrée potentielle (injections SQL, failles Cross-Site Scripting XSS, attaques par force brute sur
/wp-login.php). - Sur un site statique hébergé sur CDN : Le serveur public ne contient aucun interpréteur PHP ni base de données accessible. La surface d'attaque dynamique est quasi nulle.
Ce nom de domaine a été déposé en avril 2026. Les robots l'ont trouvé dès sa mise en ligne, et le moyen n'a rien de mystérieux : chaque certificat de sécurité — le cadenas affiché devant l'adresse — est inscrit dans un registre public que n'importe qui peut consulter. Un domaine neuf y apparaît le jour où son cadenas est délivré. C'est une liste d'adresses fraîches, gratuite, mise à jour en continu.
Ces robots ne choisissent pas leurs cibles. Ils ne savent pas ce que vend votre entreprise, ni si elle a trois clients ou trois cents : ils essaient toutes les adresses, dans l'ordre, et passent à la suivante. Le carreleur qui se dit qu'il est trop petit pour intéresser quelqu'un a raison, et ça ne le protège de rien — on ne frappe pas à sa porte parce que c'est la sienne, on frappe à toutes les portes. La question n'est donc pas de savoir si on frappera, mais s'il y a une porte derrière.
Le détail que presque aucun site ne tient : la liste des scripts autorisés
Un navigateur ne fait aucune différence entre le script que vous avez écrit et celui qu'un attaquant a réussi à glisser dans un formulaire. Les deux s'exécutent, avec les mêmes droits. C'est ce trou que bouche l'en-tête Content-Security-Policy : la liste des sources autorisées à exécuter du code sur votre page. Ce qui n'y figure pas, le navigateur le refuse de lui-même, sans rien demander au serveur.
Ce n'est pas le format du fichier qui permet d'écrire cette liste. Un site HTML statique bardé de widgets extérieurs — un chat, un compteur de visites, un carrousel d'avis, une police de caractères, une carte — a exactement le même problème qu'un WordPress. Deux décisions la rendent tenable, et aucune des deux ne dépend de la technologie employée : n'exécuter aucun script écrit au milieu de la page, et n'appeler aucun domaine extérieur.
Sur un site assemblé par des extensions, ces deux décisions ne vous appartiennent pas. Chaque extension écrit ses propres scripts dans la page et appelle ses propres serveurs. Une mise à jour publiée un mardi matin peut en ajouter un, sans que vous ayez touché à quoi que ce soit. La liste stricte, elle, casse la page à la seconde près.
Des contournements existent, et ils sont ingénieux. Le plus courant marque chaque script autorisé d'un jeton unique, regénéré à chaque affichage. Mais un jeton qui change à chaque affichage interdit de servir la même page à tout le monde — c'est-à-dire exactement la mise en cache dont vit un CMS, celle de la section suivante. L'autre méthode enregistre l'empreinte de chaque script, et cette empreinte change à chaque mise à jour d'extension. Reste la troisième voie, de loin la plus fréquente : autoriser d'avance tout ce qui est écrit dans la page. C'est écrire la règle et renoncer à la faire respecter.
Ce n'est pas un travers de petits sites mal entretenus. Le 1er septembre 2026, nous avons relevé cet en-tête sur douze sites publics et sectoriels français, du portail de l'assurance maladie à celui d'une organisation professionnelle du bâtiment. Le navigateur reçoit ceci :
| Ce que renvoie le serveur | Sur 12 sites relevés |
|---|---|
| Aucune liste : tout script présent dans la page s'exécute | 6 |
| Une liste, mais qui autorise les scripts écrits dans la page | 4 |
| Non mesurable de l'extérieur (filtre anti-robot devant le site) | 2 |
| Une liste stricte, capable de bloquer un script injecté | 0 |
Aucun de ces sites n'est piraté pour autant, et le laisser croire serait malhonnête. Cette liste est une ceinture de sécurité, pas un moteur : son absence ne dit pas qu'un site est vulnérable, elle dit que le jour où un défaut apparaît, rien ne l'arrêtera. Quant aux deux sites non mesurables, ils nous ont renvoyé une page de vérification anti-robot au lieu de leur contenu : l'en-tête reçu est celui du filtre, pas le leur, et ils ne sont comptés d'aucun côté.
Un site produit par Sitigo répond script-src 'self' : tout son JavaScript vient de sa propre adresse, aucun tag extérieur n'est chargé, et rien ne s'exécute depuis le corps de la page. Cette règle se paie, et c'est pour cela qu'elle est rare — elle interdit de coller un outil de statistiques ou un widget d'avis en trois clics. Les nôtres ont été retirés pour la tenir. Le contrôle, lui, tient en une ligne, sur n'importe quelle adresse, la vôtre comprise :
curl -sSLI https://votre-site.fr | grep -i content-security-policy
Aucune ligne en retour signifie qu'aucune liste n'est envoyée. Si la ligne contient 'unsafe-inline' dans script-src, la liste existe mais laisse passer les scripts écrits dans la page.
Un site qui ne peut pas tenir cette liste n'est pas condamné pour autant. Quand la façade change toutes les semaines et que chaque extension amène ses propres scripts, la garde se déplace en amont : pare-feu applicatif, mises à jour automatiques, surveillance par l'hébergeur. C'est la bonne réponse, et elle se paie tous les mois. La différence tient en une image : un garde posté devant la porte surveille le trou, il ne le referme pas.
Ce que la démocratisation de l'IA a changé, et ce qu'elle n'a pas changé
Le balayage automatique des sites n'a rien de nouveau. Des robots testent /wp-login.php à trois heures du matin depuis quinze ans, sur des millions d'adresses, et cela ne coûtait déjà presque rien. Les modèles de langage n'ont rendu les attaquants ni plus nombreux, ni leurs scans moins chers.
Ce qui a changé, c'est le délai. Transformer un correctif publié en attaque qui fonctionne demandait un vrai niveau technique : lire le code corrigé, comprendre ce qui vient d'être bouché, écrire l'exploitation. C'est exactement l'étape qu'un modèle abrège. Le jour où une extension publie sa mise à jour, elle publie aussi la carte du trou qu'elle rebouche.
Le second effet touche la traîne longue : ces milliers de petites extensions installées sur quelques centaines de sites, écrites par une personne seule le week-end, que personne n'avait le temps de relire. Les auditer coûte désormais beaucoup moins cher — du côté des chercheurs en sécurité comme de celui des attaquants.
Le camp d'en face y gagne aussi : mises à jour automatiques activables extension par extension, pare-feu de l'hébergeur, correctifs appliqués sans intervention. La conclusion n'est donc pas qu'un CMS serait devenu dangereux. C'est que le retard tolérable a raccourci. Un site laissé six mois sans mise à jour était un pari risqué il y a cinq ans ; c'est aujourd'hui un pari perdu d'avance.
Un site statique n'est pas invulnérable pour autant, et personne ne devrait vous le vendre ainsi. Il n'a simplement aucune extension à mettre à jour, donc aucune fenêtre à rater. Le code qui reçoit vos demandes de devis existe bel et bien, mais il tourne chez le prestataire, corrigé une fois pour tous les sites d'un coup, pas dans votre tableau de bord un dimanche soir.
Le cas qu'on ne voit pas venir : votre site devient l'adresse de quelqu'un d'autre
Un courrier arrive au nom d'une administration : en-tête officiel, tampon, un QR code dans un cadre, une date limite dans huit jours. La personne scanne, tombe sur une page qui reprend trait pour trait les couleurs de l'État, et saisit ses identifiants. Cette fausse page existe bien quelque part, sur une machine, à une adresse. Et le plus souvent, ce n'est pas un domaine acheté pour l'occasion : c'est le site d'un professionnel qui n'en sait rien.
Google le décrit dans sa documentation destinée aux propriétaires de sites : des attaquants prennent le contrôle de sites « innocents » pour y héberger du contenu d'ingénierie sociale, en modifiant le contenu du site ou en y ajoutant des pages. C'est le second terme qui compte. Votre page d'accueil reste intacte, vos photos aussi, votre numéro aussi. Vous pouvez ouvrir votre site chaque matin pendant trois semaines sans rien remarquer, pendant qu'une page que vous n'avez pas écrite vit à une adresse que vous ne visitez jamais.
Ce que vous finissez par voir, c'est le jour où cela se retourne. Chrome affiche alors un avertissement pleine page devant votre vitrine — la documentation de Google le nomme « Deceptive site ahead ». Le signal envoyé au visiteur n'est plus « ce site est lent », c'est « ce site est dangereux », et personne ne clique sur « continuer quand même » pour demander un devis. Le retour à la normale ne vous appartient pas davantage : il faut retirer les pages, puis demander une revue de sécurité depuis le rapport « Problèmes de sécurité » de la Search Console — une revue qui, prévient Google, prend plusieurs jours.
Reste la question qui intéresse ce guide : par où entre-t-on ? Cybermalveillance.gouv.fr, le dispositif public d'assistance aux victimes, liste dans sa fiche sur la défiguration de site les trois cas les plus fréquemment rencontrés : un mot de passe d'administration « trop simple ou par défaut qui n'aurait pas été changé », « un défaut de configuration du site », et « une faille de sécurité souvent connue et non corrigée ». Deux de ces trois portes supposent qu'il existe une administration à ouvrir et du code à corriger. C'est exactement ce qu'une vitrine statique n'a pas — non par vertu, par soustraction.
La même fiche publie le témoignage d'un webmaster indépendant qui gérait les sites de ses clients :
« J'ai reçu un message de mon hébergeur qui me signalait que plusieurs sites Internet que j'avais créés et dont j'assurais la gestion pour mes clients avaient été « défigurés ». […] Pendant que j'essayais de trouver une solution, mes clients, des collectivités, des artisans et professions libérales m'appelaient pour se plaindre de la situation. Je n'avais pas fait les mises à jour de ces sites depuis pas mal de temps. […] J'ai quand même perdu des clients suite à cet incident. »
Témoignage publié par Cybermalveillance.gouv.fr — webmaster indépendant de la région Hauts-de-France.
Reste à dire ce que cette soustraction ne couvre pas, sinon la promesse devient un mensonge. Il reste toujours un compte chez le bureau d'enregistrement du domaine, une boîte mail, un accès à l'espace de gestion. Ces trois-là s'hameçonnent exactement comme le reste, et un courrier à en-tête officiel est précisément l'outil taillé pour ça — reconnaître ces courriers est un sujet à part entière. Ce qu'une vitrine statique retire, c'est une page de connexion publique, à une adresse que tout le monde connaît, testée par des robots toute la nuit. Pas la vigilance.
4. L'ironie technique des extensions de mise en cache
Il existe une réalité technique révélatrice bien connue des développeurs web : que fait une extension de cache sur un CMS dynamique comme WordPress (ex. WP Rocket, W3 Total Cache ou LiteSpeed Cache) ?
Lorsqu'un visiteur ou un robot pré-génère la page, l'extension exécute l'ensemble des scripts PHP et des requêtes SQL une première fois, puis enregistre le résultat sous forme de fichier HTML statique sur le disque ou dans la mémoire du serveur. Les visiteurs suivants se voient alors directement servir ce fichier HTML sans réveiller la base de données.
Le paradoxe du cache : Pour rendre un CMS dynamique rapide, la solution la plus efficace consiste précisément à le forcer à se comporter comme un site HTML statique.
Cependant, cette conversion artificielle comporte deux limites majeures :
- Elle ne nettoie pas le code superflu : Si le cache évite le temps de calcul processeur (TTFB), le fichier HTML généré par un constructeur visuel de pages reste souvent 5 à 10 fois plus volumineux qu'un code taillé sur mesure, forçant le smartphone du visiteur à télécharger et analyser des centaines de kilo-octets de styles inutilisés.
- Elle ajoute une couche de fragilité : Règles de purge de cache, conflits lors des mises à jour, licences payantes annuelles.
5. La renaissance du statique : Jamstack, Edge CDN et l'IA en 2026
Le HTML statique n'a jamais disparu. Les leaders de la technologie (la documentation de Stripe, GitHub Docs, les sites d'Apple ou de Cloudflare) ont toujours utilisé le statique pour leurs pages à fort trafic.
Mais depuis quelques années, trois évolutions majeures ont démocratisé cette architecture :
1. L'essor des générateurs de sites statiques modernes (SSG)
Des outils comme Astro, 11ty (Eleventy), Hugo ou les modes statiques de Next.js permettent aux développeurs de composer des pages modulaires sans jamais déployer de base de données en production.
2. La puissance des réseaux Edge mondiaux
Des infrastructures comme Cloudflare Pages, Vercel ou Netlify distribuent désormais les fichiers statiques sur des centaines de centres de données à travers le monde. Un visiteur à Paris, Lyon ou Marseille charge le site depuis un serveur situé à quelques kilomètres de chez lui, garantissant un affichage quasi immédiat.
3. L'intelligence artificielle comme compilateur déclaratif
La barrière historique du statique résidait dans le coût de développement initial : rédiger et structurer 15 pages locales avec leurs balises Schema.org en JSON-LD demandait des dizaines d'heures d'ingénierie manuelle. Aujourd'hui, l'IA agit comme un compilateur sémantique ultra-rapide capable de générer un code HTML pur, rigoureux et structuré pour Google à partir de données déclaratives.
6. Le modèle découplé : concilier HTML statique et interface d'édition
Une question légitime se pose alors : « Si le site public est un ensemble de fichiers HTML statiques, comment un professionnel non-technicien peut-il modifier ses horaires, ses tarifs ou ses photos sans coder ? »
C'est tout l'apport de l'architecture découplée (Headless / Jamstack) :
- L'interface de gestion privée : L'utilisateur dispose d'un espace d'administration épuré et sécurisé pour mettre à jour ses informations.
- Le moteur de régénération (Build Serverless) : Dès qu'une modification est enregistrée, un script réécrit les fichiers HTML concernés et les republie ; ils sont ensuite servis depuis le nœud le plus proche du visiteur.
- Le site public : Les internautes et les robots d'indexation ne visitent que des pages HTML statiques, ultra-rapides et totalement déconnectées de la base de données.
C'est la réconciliation moderne : la simplicité d'utilisation d'un espace d'édition pour le propriétaire du site, combinée à la robustesse, la sécurité et la vitesse du HTML statique pour les visiteurs.
7. Tableau comparatif critère par critère
| Critère technique | Site HTML Statique Moderne | CMS Dynamique Traditionnel (ex. WordPress) |
|---|---|---|
| Temps de réponse serveur (TTFB) | ⚡ 10 à 50 ms (servi directement depuis le réseau Edge CDN) | ⏱️ 200 à 1 500 ms (dépend de la charge serveur et du moteur PHP) |
| Core Web Vitals & Stabilité visuelle | 🟢 Excellent nativement (code épuré, CSS inline minifié, CLS faible) | 🟡 Variable (souvent dégradé par les scripts d'extensions tierces) |
| Surface d'attaque & Sécurité | 🛡️ Minimale (zéro PHP public, zéro risque d'injection SQL) | ⚠️ Élevée (cible privilégiée des attaques automatisées et failles de plugins) |
| Maintenance & Mises à jour | 🧘 Nulle (aucun conflit de plugins ni fin de support PHP) | 🔧 Régulière (mises à jour de sécurité régulières indispensables) |
| Résistance aux pics de trafic | 🚀 Quasi illimitée (fichiers distribués sur des centaines de serveurs Edge) | ⚠️ Risque de saturation serveur si non dimensionné |
| E-commerce à fort catalogue (5 000 produits) | ❌ Complexe (nécessite des briques logicielles tierces via API) | ✅ Idéal et éprouvé (WooCommerce, Magento, PrestaShop) |
| Publication quotidienne multi-auteurs | ⚠️ Moins direct (nécessite un pipeline éditorial adapté) | ✅ Idéal (gestion native des rôles rédacteurs, brouillons, planification) |
| Coût d'infrastructure et d'entretien | 💰 Très faible (hébergement statique économique, 0 licence de plugin) | 💳 Modéré à élevé (serveur dynamique dimensionné + licences + maintenance) |
8. Matrice de décision : quelle architecture pour votre projet ?
🎯 Choisissez le HTML Statique si :
- Vous créez un site vitrine professionnel, d'artisan, de TPE, de profession libérale ou de PME de services.
- Vous visez une vitesse de chargement mobile maximale et des scores parfaits pour le référencement local (SEO).
- Vous voulez une tranquillité totale sans maintenance logicielle ni risque de plantage après une mise à jour.
- Votre contenu évolue ponctuellement (prestations, avis, coordonnées, photos).
🎯 Choisissez un CMS Dynamique si :
- Vous lancez une boutique en ligne avec des milliers de références et gestion de stock en temps réel.
- Vous éditez un média d'actualité ou un blog collaboratif avec plusieurs journalistes publiant chaque jour.
- Vous développez un espace communautaire avec profils membres et interactions en direct.
- Vous disposez d'un budget régulier pour assurer la maintenance et la sécurité du serveur.
Besoin d'un site rapide, sécurisé et sans abonnement ?
Sitigo génère votre site multi-pages en HTML pur pour 69 € HT une seule fois, et vous le voyez avant de payer. Le SEO local (pages de zone, données structurées) est construit d'origine.
Voir mon site avant de payer →Prix hors taxes. Service réservé aux professionnels enregistrés : Sitigo ne facture aucune TVA, le client assujetti l'autoliquide. Détail
9. Questions fréquentes
Un navigateur internet peut-il lire directement du PHP ou du SQL ?
Non. Les navigateurs (Chrome, Safari, Edge, Firefox) ne traitent que du HTML pour la structure, du CSS pour le style et du JavaScript pour l'interactivité. Le PHP s'exécute uniquement sur le serveur web pour interroger la base de données et assembler un document HTML avant de l'envoyer au client.
Pourquoi WordPress domine-t-il autant le marché mondial du web ?
WordPress fait tourner plus de 40 % des sites web dans le monde grâce à son interface d'édition accessible sans compétence technique, son écosystème de plus de 60 000 extensions et sa grande polyvalence (blogs, e-commerce WooCommerce, médias, sites associatifs).
Un site HTML statique peut-il comporter un formulaire de contact ou un espace de gestion ?
Oui. C'est le principe de l'architecture Jamstack et des micro-services : les formulaires envoient leurs données via des fonctions légères sans serveur (Serverless), et l'édition de contenu s'effectue depuis un espace de gestion privé (Headless CMS) qui régénère automatiquement les pages HTML sans exposer de base de données aux visiteurs.
Qu'est-ce que l'ironie du cache sur les CMS dynamiques ?
Pour accélérer un CMS dynamique, la méthode la plus répandue consiste à installer une extension de cache (comme WP Rocket). Cette extension exécute la page une première fois et en enregistre une copie en HTML statique pour la servir directement aux visiteurs suivants. L'optimisation maximale d'un CMS dynamique consiste donc précisément à le faire fonctionner comme un site statique.
Dans quels cas un CMS dynamique reste-t-il indispensable ?
Un CMS dynamique est indispensable pour les boutiques en ligne avec des milliers de références et des stocks en temps réel, les médias publiant des dizaines d'articles par jour avec plusieurs journalistes, ou les plateformes communautaires nécessitant des comptes membres interactifs.
Un site HTML statique est-il vraiment plus sûr qu'un WordPress ?
Pas par magie, et pas parce qu'il serait « en HTML ». Un site statique qui charge dix scripts extérieurs est aussi exposé qu'un autre. La différence tient à trois absences : aucun interpréteur PHP, aucune base de données publique, aucune extension à mettre à jour. Il n'y a donc pas de correctif à rater ni d'identifiant d'administration à protéger sur la vitrine. En revanche, une page statique qui appelle un widget de chat, une régie publicitaire ou une police hébergée ailleurs récupère la surface d'attaque de ces services.
Mon site peut-il héberger une page frauduleuse sans que je le sache ?
Oui, et c'est un mode opératoire que Google décrit dans sa documentation : un attaquant prend le contrôle d'un site existant et y ajoute des pages, sans toucher à la page d'accueil, qui reste intacte. Le propriétaire l'apprend rarement seul : plutôt par son hébergeur, par le rapport Problèmes de sécurité de la Search Console, ou en découvrant l'avertissement pleine page de Chrome devant sa propre vitrine. Une vitrine statique n'expose ni page d'administration ni extension à corriger, ce qui ferme deux des trois portes d'entrée les plus fréquentes recensées par Cybermalveillance.gouv.fr. Les comptes autour du site, eux, restent à protéger : domaine, messagerie, espace de gestion.
Guide d'architecture web publié en août 2026. Rédigé pour éclairer les choix technologiques des créateurs d'entreprises, développeurs et professionnels indépendants.