Pourquoi j'ai choisi un site statique (et pourquoi c'est un choix stratégique)
Je n’ai pas choisi un CMS. J’ai construit un système.
Quand j’ai commencé mon portfolio, je n’avais pas envie de “faire un site”.
Je voulais construire quelque chose de simple, durable, et surtout maîtrisé.
Pas un outil qui m’impose sa logique.
Mais un système qui s’adapte à la mienne.
C’est pour ça que j’ai choisi une architecture statique avec Astro.
1️⃣ Je voulais éditer du contenu sans toucher au code
Le besoin de base était très simple :
👉 pouvoir écrire, publier et modifier du contenu facilement.
Sans casser l’existant.
Sans interface complexe.
Sans friction.
Avec cette approche :
- j’écris en Markdown
- je versionne comme du code
- je génère le site automatiquement
Et c’est tout.
Pas de backend.
Pas de CMS.
Pas de couche inutile entre moi et mon contenu.
2️⃣ Un site statique, c’est aussi un choix économique et opérationnel
Je n’avais pas besoin d’une infrastructure lourde.
Un site statique permet :
- un hébergement simple (serveur classique suffisant)
- pas de base de données
- pas de serveur applicatif
- pas de maintenance backend
Pour un portfolio personnel, c’est exactement le bon niveau de complexité.
👉 Je ne veux pas gérer un système. Je veux publier.
3️⃣ La sécurité vient naturellement de la simplicité
Moins il y a de surface technique, moins il y a de risques.
Un site statique, c’est :
- pas d’API exposée
- pas de base de données à protéger
- pas d’authentification à maintenir
- moins de dépendances critiques
👉 La sécurité n’est pas une feature ajoutée.
Elle est une conséquence de l’architecture.
4️⃣ Je garde une liberté totale sur la logique
Le statique ne veut pas dire limité.
Au contraire, il me permet de faire exactement ce que je veux :
- ajouter du JavaScript ciblé
- automatiser le traitement de contenu
- générer des galeries de photos
- créer des règles de tri personnalisées
- appeler des APIs externes ou internes
👉 C’est du contrôle total, sans framework imposé.
5️⃣ Pourquoi pas une PWA avec React ou Angular ?
J’aurais pu partir sur une stack plus “app” :
React : écosystème mature, composants réutilisables, très adapté aux applications complexes
Angular : framework complet, structure opinionnée, idéal pour les grandes applications d’entreprise
Mais dans ce cas, j’aurais dû gérer :
- un frontend plus lourd
- une architecture applicative complète
- un backend obligatoire pour certaines fonctionnalités
- une API à maintenir
- une complexité globale largement supérieure à mon besoin
👉 Pour un portfolio, c’est surdimensionné.
Je n’ai pas besoin d’une application.
J’ai besoin d’un système de publication.
6️⃣ Wix / WordPress : simples… jusqu’à ce que ça devienne sérieux
J’ai évidemment regardé les solutions no-code ou CMS classiques :
Wix : éditeur visuel, drag & drop, interface intuitive
WordPress : CMS le plus populaire, écosystème immense, plugins pour tout
Sur le papier :
- rapide à mettre en place
- facile à éditer
- accessible sans développement avancé
Mais dès qu’on sort du simple contenu, les limites apparaissent.
❌ Le problème de Wix
Wix est pratique, mais :
- logique technique très fermée
- personnalisation avancée limitée
- difficulté à structurer des traitements complexes
- peu adapté à une logique de développement sur mesure
❌ Le problème de WordPress
WordPress est puissant, mais :
- backend complet à maintenir
- base de données obligatoire
- mises à jour fréquentes (plugins, sécurité)
- complexité qui augmente avec le temps
👉 On commence simple, et on finit avec un système lourd.
⚖️ Le vrai problème : la complexité cachée
Le sujet n’est pas “quelle techno est meilleure”.
Le sujet est : 👉 quel niveau de complexité suis-je prêt à payer ?
7️⃣ Là où mon approche change vraiment la donne
Ce que je voulais dépasser, c’est la limite des CMS :
- difficulté à créer des logiques de tri personnalisées
- dépendance aux plugins ou extensions
- rigidité des modèles de données
- intégration API souvent lourde
Dans mon cas, je voulais aller plus loin :
- trier automatiquement mes photos selon des règles JS
- transformer mes contenus librement
- intégrer des outils externes ou internes côté dev
- générer des pages de manière déterministe
👉 Sans friction. Sans couche intermédiaire.
8️⃣ Le résultat : un système simple, mais extensible
Aujourd’hui, mon setup me permet :
- Markdown pour le contenu
- génération statique rapide
- JavaScript pour les cas spécifiques
- automatisation (photos, structure, pages)
- déploiement quasi instantané
👉 Je n’ai pas simplifié le projet.
J’ai réduit la complexité inutile.
🔥 Conclusion
Ce choix n’est pas un choix “tech”.
C’est un choix de conception.
Je n’ai pas cherché l’outil le plus complet.
J’ai cherché le système le plus maîtrisable.
Et dans ce contexte, le site statique n’est pas une solution minimale.
C’est la solution optimale.