De WordPress à un site statique : pourquoi j'ai sauté le pas
Thèse — Pour un site web de contenu (portfolio, blogue, site corporatif léger), un site statique versionné dans Git est aujourd'hui un meilleur outil que WordPress sur tous les axes qui comptent : sécurité, vitesse, coût, réversibilité, et — paradoxalement — simplicité de gestion. WordPress reste pertinent pour les sites où le contenu est saisi quotidiennement par plusieurs auteurs non techniques. Pour tout le reste, on paye chaque mois pour de la complexité dont on n'a pas besoin.
On utilise WordPress par défaut, et c'est souvent une erreur
WordPress propulse aujourd'hui environ 40 % du web. Ce n'est pas par hasard : c'est gratuit, ouvert, mature, et il y a un thème ou un plugin pour tout. Mais cette domination crée un réflexe dommageable : on installe WordPress comme on installait jadis Apache, par habitude, sans se demander si l'outil correspond au besoin.
Or, WordPress est une application web complète : base de données, langage serveur, écosystème de plugins, interface d'administration, mécanisme de mise à jour, gestion d'utilisateurs et de droits. C'est conçu pour des sites où plusieurs personnes publient du contenu chaque jour, gèrent des médias en volume, modèrent des interactions. Pour ce besoin-là, WordPress est probablement le meilleur outil au monde.
Le problème, c'est qu'on l'utilise aussi pour servir un site de 17 pages qui changent une fois par mois. Et là, on importe gratuitement toute la complexité — donc tous les coûts de maintenance, toutes les failles potentielles, toute la lenteur — sans bénéficier d'aucune des forces qui justifieraient cette complexité.
Le déclencheur : un site cassé un dimanche soir
Mon site jeanphilippeblais.ca tournait sous WordPress depuis seulement une année. Thème, page builder, plugins SEO, plugins de sécurité, certificat SSL renouvelé automatiquement, mises à jour mensuelles. Tout ça fonctionnait — jusqu'à ce qu'une mise à jour de routine d'un plugin populaire casse l'affichage de plusieurs pages.
Réparation : possible, mais elle a demandé d'aller fouiller dans le code d'un plugin tiers et d'y appliquer un correctif. Du temps que je ne facture pas, et un site qui projette une image d'amateurisme tant qu'il est cassé. Ce genre d'incident n'est pas exceptionnel — c'est la signature même de WordPress : un écosystème de plugins interdépendants, chacun mis à jour selon son propre calendrier, qui peuvent casser l'ensemble sans préavis.
Le calcul que je n'avais pas fait
Mon site n'accepte pas de commentaires — non par incapacité technique, mais par choix : modérer demande un suivi régulier qui n'apporte rien à mes lecteurs. Je n'ai pas de boutique, pas de membres, pas de contenu dynamique. Je payais pour une application web complète afin de servir 17 pages HTML qui changent rarement.
Mises bout à bout, les coûts réels de WordPress pour mon usage :
- Hébergement WHC : ~150 $/an
- Maintenance plugins/PHP : quelques heures par année à mon taux horaire = des centaines de dollars de temps perdu
- Performance : Lighthouse ~50/100 sur mobile, parce que WP charge des dizaines de feuilles CSS et de scripts JS pour rendre un paragraphe de texte
- Risque permanent : à chaque mise à jour de plugin, une chance non nulle que tout casse
Ce qu'est un site statique en 2026
Un site statique, c'est du HTML, du CSS et des images — déjà rendus, prêts à servir, sans base de données ni serveur applicatif. Mes articles sont écrits en Markdown (un format texte lisible, qui survivra à n'importe quel outil), versionnés dans Git (chaque modification est traçable et réversible), et publiés via un pipeline d'intégration continue qui se déclenche à chaque push.
Le générateur que j'utilise s'appelle Eleventy (11ty). Il prend mes fichiers Markdown et mes gabarits HTML, et génère un dossier public/ avec tout le site. Build complet : 0,3 seconde.
Ce dossier est ensuite déployé sur Firebase Hosting (CDN global, HTTPS automatique, gratuit pour mon volume). Pour publier un nouvel article, j'écris un fichier .md, je git push, et 90 secondes plus tard il est en ligne — partout dans le monde.
Le nouveau flow de rédaction : l'IA dans l'environnement, pas à côté
Avant, mon flow ressemblait à ça : j'écrivais directement dans WordPress, sauf pour les articles co-rédigés avec un assistant IA — où je copiais-collais des morceaux entre l'interface de chat et l'éditeur WP, en perdant la mise en forme à chaque aller-retour.
Aujourd'hui, l'IA est dans l'environnement de développement lui-même. Je discute avec elle dans le même endroit où vit le fichier Markdown de l'article. Elle peut lire mes anciens articles pour calquer mon ton, proposer une structure, écrire un brouillon, le réviser, et l'appliquer directement au fichier — sans que je quitte mon outil.
Pour un développeur, c'est une expérience nettement supérieure : pas de copier-coller, pas de perte de format, l'historique Git conserve chaque révision, et je peux comparer/annuler n'importe quelle modification.
Et pour un non-développeur, c'est aussi devenu accessible : la même IA m'assiste sur les aspects techniques (configuration, débogage, mise en page CSS) que je ne maîtrise pas en profondeur. Là où autrefois il fallait être à la fois rédacteur ET intégrateur web pour gérer son propre site, l'IA comble l'écart. Quelqu'un qui sait écrire peut maintenant maintenir un site statique de qualité professionnelle, en confiant les tâches techniques à un assistant qui les exécute en temps réel.
C'est un changement de fond : l'autonomie technique n'est plus réservée aux techniciens.
Les bénéfices concrets, mesurés
| WordPress | Site statique | |
|---|---|---|
| Coût annuel | ~150 $ + maintenance | 0 $ (free tier Firebase) |
| Temps de chargement | 2-4 s | <300 ms |
| Score Lighthouse | ~50-65 | >95 |
| Surface d'attaque | DB + PHP + plugins | Aucune (HTML statique) |
| Mises à jour de sécurité | Mensuelles, manuelles | Aucune |
| Réversibilité | Backup SQL + dump fichiers | git revert ou rollback Firebase en un clic |
| Previews avant publication | Plugin payant | Inclus dans le pipeline |
Pour qui cette approche fonctionne
✅ Sites de contenu : portfolios, blogues, sites corporatifs informatifs, documentation ✅ Sites avec moins de 5 personnes qui publient régulièrement ✅ Équipes prêtes à travailler avec un assistant IA qui comble l'écart technique ✅ Sites où la performance et la sécurité comptent
❌ E-commerce avec inventaire en temps réel (Shopify, WooCommerce) ❌ Forums, communautés, contenu généré par les utilisateurs ❌ Équipes éditoriales de 10+ personnes sans appétence ni accompagnement IA ❌ Sites dont le contenu doit changer plusieurs fois par jour par des non-développeurs
Le vrai changement : reprendre possession de son site
Ce qui m'a le plus surpris dans cette migration, c'est le sentiment de propriété retrouvée. Mon site n'est plus une application qui tourne quelque part en attendant qu'on l'attaque. C'est un dossier de fichiers texte que je peux ouvrir, lire, modifier, et déplacer ailleurs en 5 minutes si Firebase change ses tarifs ou disparaît.
C'est un détail philosophique avec une portée pratique : un site statique vous appartient vraiment. WordPress, malgré son code ouvert, vous lie à un écosystème de plugins, à un hébergeur compatible, et à une dette de maintenance qui s'accumule. Un site statique, lui, est portable, archivable, et résilient — exactement les qualités qu'on attend de quelque chose qui représente notre identité professionnelle en ligne.
Vous envisagez la même démarche pour votre entreprise ? Discutons-en — je peux vous aider à évaluer si l'approche convient à votre contexte et à planifier la transition sans interrompre votre activité.