Le contenu d'abord, le code ensuite
Une courte note sur pourquoi le contenu du portfolio vit en Markdown au lieu d'être codé directement dans les composants Astro.
- markdown
- architecture
- astro
Un site personnel doit être facile à modifier pendant que l’idée est encore fraîche. Si changer un paragraphe demande d’ouvrir un composant, de vérifier le code de layout et d’éviter de casser le style, le workflow est déjà trop lourd.
Pourquoi Markdown suffit
Ce portfolio n’a pas encore besoin d’une base de données. Il a besoin d’une manière propre d’écrire, relire, traduire et publier de petits contenus.
Markdown suffit pour cela. Il se lit bien dans l’éditeur, fonctionne très bien avec les diffs Git, et reste portable si le site change de framework plus tard. Il rend aussi l’écriture plus naturelle : on écrit du contenu, pas de la configuration.
C’est important parce que la majorité des mises à jour d’un portfolio ne sont pas des features techniques. Ce sont des changements de contenu :
- le résumé d’un projet devient plus précis
- un lien externe change
- un nouvel article est publié
- une traduction française demande une meilleure phrase
- une ancienne expérience devient moins importante
Ces changements doivent rester petits.
src/content/
├─ blog/
│ ├─ en/
│ └─ fr/
├─ pages/
│ ├─ en/
│ └─ fr/
└─ site/
├─ en/
└─ fr/La séparation propre
Le codebase suit une séparation simple :
- les fichiers de contenu décrivent le sens de la page
- les pages Astro décident quel contenu charger
- les composants rendent les structures répétables
- les fichiers CSS portent le système visuel
Cette séparation évite que le code devienne un amas de textes. Elle évite aussi que le Markdown connaisse trop de détails sur l’interface.
Par exemple, une entrée de projet peut contenir un nom, un résumé, une stack et des liens. Le layout de la carte peut changer plus tard sans réécrire le projet lui-même.
| Changement | Fichier à modifier | Code touché ? |
|---|---|---|
| Modifier le résumé d’un projet | src/content/pages/*/work.md | Non |
| Publier un article | src/content/blog/{locale}/nouvel-article.md | Non |
| Ajouter un nouveau layout de carte | composant + CSS | Oui |
| Traduire le footer | src/content/site/{locale}/footer.md | Non |
Pourquoi cela aide l’internationalisation
Quand le site existe en français et en anglais, la structure du contenu devient encore plus importante. Chaque langue peut avoir son propre fichier Markdown, mais les routes et les composants restent partagés.
La traduction n’est donc pas un cas spécial. Elle fait partie du workflow de contenu.
Si une autre langue est ajoutée plus tard, le même modèle continue : créer le dossier localisé, ajouter les traductions et laisser l’interface partagée les rendre.
Le compromis
Cette approche n’est pas magique. Si le modèle de contenu change, le schéma doit changer aussi. C’est une bonne contrainte. Elle force le site à définir clairement les types de contenu qu’il supporte.
Pour un portfolio, ce compromis vaut le coup. Le site reste statique, rapide et simple à déployer, tandis que le contenu garde assez de souplesse pour grandir.