L’ancienne version du site fonctionnait. Elle affichait mon parcours, mes liens et quelques projets : sur le papier, il n’y avait donc aucune raison urgente de la remplacer. Le problème était surtout ailleurs. Le code devenait plus important que ce que le site avait réellement à montrer.
J’ai préféré repartir d’un dossier presque vide plutôt que de continuer à corriger une structure qui ne correspondait plus à son usage.
Pourquoi recommencer#
La version précédente reposait sur SolidStart, Nitro, Tailwind et une configuration prévue pour une application exécutée côté serveur. Même le lien Gravatar était préparé par une fonction serveur qui calculait le hash de l’adresse e-mail à chaque requête.
Ce n’était pas incorrect, simplement disproportionné. Le site ne contient ni compte utilisateur, ni formulaire, ni base de données. Il n’a pas besoin d’un serveur pour assembler des informations qui changent rarement.
À force d’essayer des bibliothèques et des idées de mise en page, j’avais aussi accumulé plusieurs manières de faire la même chose. Modifier un texte ou déplacer une section demandait de retrouver le bon composant, le bon fichier de configuration et parfois une abstraction qui n’avait plus vraiment de raison d’exister.
Définir ce que le site doit faire#
Ce site est une présentation, pas un produit. Il doit permettre de comprendre rapidement qui je suis, où j’ai travaillé et sur quoi je passe du temps. Rien n’est vendu et je ne cherche pas à guider le visiteur dans un tunnel de conversion.
La nouvelle base part donc de quelques besoins assez simples :
- une page d’accueil lisible sur téléphone comme sur un écran 4K ;
- des pages séparées pour les expériences et les projets ;
- un thème clair, sombre ou calé sur le système ;
- des contenus disponibles en français et en anglais ;
- un blog discret, accessible directement mais absent de la navigation principale ;
- aucun service distant, à l’exception de l’image Gravatar.
Cette liste sert aussi de limite. Une fonctionnalité qui ne répond pas à l’un de ces besoins doit avoir une bonne raison d’être ajoutée.
Une base statique avec SvelteKit et Bun#
Le site utilise maintenant SvelteKit et son adaptateur statique. Bun installe les dépendances et lance les commandes du projet. Au moment du build, SvelteKit génère les fichiers HTML, CSS et JavaScript qui seront servis tels quels par GitHub Pages.
Il n’y a donc plus de processus Node à maintenir en production. Les routes restent de vraies routes Svelte — /projects, /experiences, /blog et /blog/:slug — mais leur résultat est produit à l’avance.
Svelte est surtout utile ici pour les quelques comportements interactifs : le changement de langue, le thème, la navigation mobile, les animations d’apparition et le suivi du sommaire dans les articles. Le reste peut rester du HTML et du CSS ordinaires.
Garder les données près du code#
Les expériences, les projets et les textes généraux vivent dans src/lib/data. Chaque champ traduit suit la même forme : { fr: ..., en: ... }. Cette organisation évite d’avoir deux grandes versions du site qui finissent par diverger.
Les articles sont de simples fichiers Markdown placés dans src/articles. Le nom du fichier devient le slug, tandis que le titre, la description, la date et le temps de lecture sont déclarés dans le frontmatter. Le parser ajoute ensuite un identifiant aux titres de niveau deux et trois pour construire automatiquement le sommaire.
Le chemin complet reste court :
Ajouter un article revient ainsi à créer un fichier, écrire le texte et lancer le build. Il n’y a pas d’interface d’administration, de jeton d’accès ou de contenu à synchroniser avec un service externe.
Un blog volontairement discret#
J’ai d’abord imaginé le blog comme une partie presque cachée du site, avec uniquement des URL directes. J’ai finalement ajouté une page /blog, principalement pour retrouver les articles sans devoir connaître leur slug.
Le lien n’apparaît toujours pas dans la navigation principale. Il reste dans le footer et les articles peuvent être partagés directement. Cela lui donne une place claire sans transformer la page d’accueil en sommaire de tout ce que je publie.
Ce que cette refonte simplifie#
La différence la plus visible est le design, mais le gain principal se trouve dans les modifications ordinaires. Ajouter une expérience ne demande plus de toucher au composant qui l’affiche. Une nouvelle traduction reste dans le même objet que le texte français. Un article n’est qu’un fichier Markdown versionné avec le reste du projet.
Le build statique réduit aussi les choses à surveiller une fois le site en ligne. Il reste des dépendances et du JavaScript côté client, mais il n’y a plus de serveur applicatif ni de données distantes dont dépend l’affichage d’une page.
Garder cette limite#
Repartir de zéro ne garantit pas que le projet restera simple. Il est toujours possible de reconstruire progressivement la même complexité avec une autre stack.
La règle que je veux conserver est donc assez concrète : le contenu doit rester modifiable directement dans le dépôt, les pages doivent pouvoir être générées sans connexion à un service tiers et chaque dépendance doit correspondre à un besoin visible. Pour ce site, c’est largement suffisant.