Construire ce portfolio comme un système calme

Je ne voulais pas que ce portfolio se comporte comme une brochure qu’on refait une fois, qu’on publie, puis qu’on oublie doucement. Je voulais qu’il ressemble à un petit système vivant : facile à modifier, honnête sur ce que je construis, et assez calme pour être utilisé longtemps.

Pourquoi le reconstruire

Le premier rôle d’un portfolio est simple : donner un signal rapide. En quelques secondes, quelqu’un devrait comprendre qui je suis, quel type de travail je fais, et où se trouvent les preuves.

Le rôle le plus difficile, c’est la maintenance. Un portfolio change chaque fois qu’un projet est livré, qu’une expérience devient utile, qu’un article est écrit ou qu’une information de contact bouge. Si chaque mise à jour demande de toucher au code de mise en page, le site commence à lutter contre son propre objectif.

C’est pour cela que cette version est statique, mais pilotée par le contenu. L’interface est construite avec Astro. L’écriture vit en Markdown. Les pages sont générées au build et déployées sur GitHub Pages.

Le but n’est pas de rendre le site compliqué. Le but est de rendre les futures modifications simples et prévisibles.

La règle d’architecture

La règle que je suis est petite, mais utile :

• Markdown porte le sens
• les composants Astro portent la structure
• les fichiers CSS portent la présentation
• les fonctions utilitaires portent les routes, les dates et la localisation

Cette séparation garde le projet lisible. Si je veux modifier le résumé d’un projet, j’édite le contenu. Si je veux améliorer l’apparence des cartes, j’édite un composant et son CSS. Si je veux ajouter une langue plus tard, l’arborescence de contenu a déjà une place pour cela.

Ce n’est pas une grande architecture. C’est une architecture calme.

Couche	Responsable de	Pourquoi c’est utile
Markdown	textes, projets, contenu localisé	Je peux modifier le site sans toucher au layout.
Astro	routes, rendu, collections	Le build transforme le contenu en pages statiques rapides.
CSS	espacements, typographie, états d’interaction	Les changements visuels restent proches du composant concerné.
GitHub Pages	hébergement	Le déploiement reste simple et prévisible.

Ce que la page d’accueil doit faire

La page d’accueil est pensée comme un signal, pas comme un pitch deck. Elle doit répondre vite à trois questions :

• qu’est-ce qu’Elsy construit ?
• quelles preuves peut-on inspecter ?
• quelle est la prochaine page utile ?

C’est pour cela que la page reste compacte. L’avatar ASCII donne une marque personnelle au site. La section projets montre quelques éléments au lieu de tout afficher. La section expérience donne du contexte. La section contact rend la prochaine étape évidente.

accueil
├─ signal : qui je suis
├─ preuve : projets sélectionnés
├─ contexte : expérience
└─ prochaine étape : contact

Ce que le log doit devenir

Le log n’est pas censé être un faux changelog. C’est l’endroit où le portfolio peut respirer.

Certains articles seront des notes techniques. D’autres expliqueront des décisions derrière les projets. D’autres documenteront des expériences, des erreurs et de petites leçons. L’important est que chaque article ait une raison d’exister.

Si la page projets montre la preuve, le log montre le chemin de pensée derrière cette preuve.

Ce que j’aime dans ce système

Cette organisation est modeste, mais elle correspond à ma manière de travailler. Je peux écrire un fichier Markdown, le commiter, builder le site et publier sans ajouter de backend ni ouvrir un CMS.

Cela garde le site proche de Git, proche du code, et proche du vrai travail. Pour l’instant, c’est exactement la bonne quantité de système.