Construire un site sobre.

Le bon outil pour le bon projet

Le réflexe dominant en 2026 reste de partir sur un framework JavaScript (Next.js, Astro, SvelteKit, Remix) pour le moindre site. C'est souvent une erreur. Le framework a un coût permanent en complexité, en dépendances, en surface d'attaque. Pour un site dont le contenu change peu et qui ne requiert pas d'interactivité poussée, l'HTML/CSS/JS vanilla reste la solution la plus durable.

Critères de décision :

Pour ce site (cinq pages de fond, un journal de bord, quelques contenus interactifs comme la galerie devices), la réponse était vanilla.

Cadrer avant de coder

Un site sobre commence par un cadrage explicite. Trois questions à régler avant la première ligne de HTML :

1. Positionnement. Qui parle, à qui, pour dire quoi. En une phrase, sans superlatif. Pour ce site : « praticien de terrain qui transforme une expertise pédagogique en outils concrets avec l'aide de l'IA ».
2. Architecture de contenu. Les pages principales, la profondeur de l'arborescence. Trois niveaux maximum, sinon les utilisateurs se perdent.
3. Critère de réussite. Comment on sait que le site fait son travail. Ici : un visiteur professionnel comprend en deux minutes qui je suis, ce que j'ai produit, comment me contacter.

Un système de design minimal mais cohérent

Même sans framework, un site doit avoir un design system. Sinon chaque page dérive et la maintenance devient impossible. La structure adoptée ici, dans assets/css/ :

• tokens.css : variables CSS pour les couleurs, typographies, espacements, rayons, ombres. Tout est modifiable en un seul endroit.
• base.css : reset léger, styles par défaut des titres, paragraphes, listes, citations, code.
• layout.css : header, footer, navigation, sections.
• components.css : cartes, boutons, badges, callouts, devices (smartphone et tablette), poster vidéo, grilles. Chaque composant est isolé et nommé en BEM.

Quatre fichiers, environ 1500 lignes de CSS au total. Lisible d'un coup d'œil, pas de magie, pas de surcharge.

Choisir des polices et une palette qui durent

Les polices et couleurs sont les éléments qui datent un site le plus vite. Pour éviter ça : choisir des typographies éditoriales déjà installées dans le paysage (pas des modes passagères) et une palette qui s'éloigne du « SaaS bleu et blanc » générique.

Ici, le choix s'est porté sur :

• Newsreader (serif éditoriale, Google Fonts) pour les titres et le corps principal.
• Inter Tight (sans-serif moderne) pour l'interface, les boutons, les métadonnées.
• JetBrains Mono pour le code.
• Palette : fond papier crème (#f6f1e7), texte presque noir, accent vert sapin profond (#1e4d3a), accent rouille ponctuel (#b8541a). Inspirée de Stripe Press et de certaines revues éditoriales en ligne.

Pas de build, du HTML écrit à la main

Aucune étape de build ne sépare le code source du site servi. Les fichiers .html qu'on édite sont ceux que le navigateur reçoit. Aucun bundler, aucun transpileur, aucun gestionnaire de paquets.

Conséquences pratiques :

• Une modification est visible localement en rafraîchissant la page, sans serveur de dev ni hot-reload.
• Pas de node_modules, pas de package.json à maintenir, pas de vulnérabilités de dépendances à surveiller.
• Une personne qui ne code pas (Pierre) peut modifier une phrase dans un fichier HTML sans casser le site.

La duplication du header et du footer entre les pages est le seul coût. Pour ~12 pages, c'est négligeable et un agent applique une modification globale en quelques secondes.

Le journal de bord, le seul morceau dynamique

Le journal a été le seul vrai défi technique. Les entrées doivent pouvoir s'ajouter facilement par quelqu'un qui ne code pas. Solution adoptée :

• Une entrée par fichier .md dans journal/entries/, avec front-matter (date, titre, résumé).
• Un index.json qui liste toutes les entrées pour la page liste.
• Côté client, un parseur Markdown maison en JavaScript vanilla (~200 lignes), pas de bibliothèque.
• Une page entry.html qui charge la bonne entrée selon le paramètre d'URL et l'affiche.

Pour ajouter une entrée : copier le modèle, modifier le contenu, ajouter une ligne à l'index, pousser sur GitHub. Aucun build, aucun déploiement manuel.

Versionnement et déploiement automatique

Le combo qui s'impose en 2026 reste GitHub + Vercel. Configuration en quatre étapes :

1. Dépôt GitHub avec le code du site (privé ou public).
2. Compte Vercel relié au dépôt, qui détecte automatiquement qu'il s'agit d'un site statique.
3. Un vercel.json à la racine pour configurer les clean URLs, les en-têtes de cache pour les assets, les en-têtes de sécurité (X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Permissions-Policy).
4. Domaine personnalisé pointé sur Vercel via les DNS du registrar (OVH, Gandi, etc.).

À partir de là, chaque git push sur la branche main redéploie le site en 30 secondes, automatiquement, avec HTTPS et CDN mondial. Coût mensuel pour un site personnel : 0 €.

SEO et performance, les fondamentaux

Sans framework, on garde la main sur tout ce qui compte pour le référencement et la performance :

• Sémantique HTML correcte. Un seul h1 par page, hiérarchie cohérente, main/article/section utilisés à bon escient.
• Meta tags par page : title, description, canonical, Open Graph pour les partages sociaux.
• sitemap.xml et robots.txt à la racine.
• Images optimisées, attributs width/height renseignés, loading="lazy" sur les images hors écran.
• Polices chargées via Google Fonts avec preconnect et display=swap.

Résultat : un Lighthouse Mobile typiquement entre 95 et 100 sur les quatre axes (Performance, Accessibilité, Best Practices, SEO). Sans optimisation acrobatique.

Accessibilité de base, non négociable

• lang="fr" sur la balise html.
• Skip link clavier en début de page pour sauter directement au contenu.
• Contrastes vérifiés (texte principal au moins WCAG AA).
• Attributs alt descriptifs sur les images porteuses d'information, vides sur les images purement décoratives.
• Focus visible sur les liens et boutons (outline 2px accent, offset 3px).
• Navigation entièrement utilisable au clavier, y compris le menu mobile.
• aria-label sur les boutons sans texte (toggle thème, ouverture menu).
• Respect de prefers-reduced-motion pour désactiver les animations chez les utilisateurs sensibles.

Maintenir un site qu'on ne code pas soi-même

La vraie réussite d'un site sobre se mesure deux ans plus tard, quand il faut le modifier sans avoir tout en tête. Quatre pratiques qui rendent ça possible :

• Un README pour soi-même. Le README.md de ce dépôt explique en français comment ajouter une entrée de journal, modifier une couleur, déployer. Écrit pour Pierre, qui ne code pas.
• Du code commenté avec parcimonie mais aux bons endroits : pourquoi un choix non-évident, pourquoi un composant existe.
• Une convention de nommage stable. BEM pour le CSS, slugs en kebab-case pour les URLs, YYYY-MM-DD-titre pour les entrées du journal.
• Un agent IA pour la maintenance. Quand il faut modifier quelque chose dans deux ans, on relit le README, on ouvre Claude Code ou équivalent, on décrit le changement, on relit le diff.