Début 2025, j’annonçais la mise en ligne de ce nouveau site. J’ai brièvement abordé mes choix techniques. Ici, je compte apporter un peu plus de détails.

Un site statique construit avec Astro

Ce site est axé sur le contenu et nécessite peu de mises à jour côté client. Générer un site statique semble donc plus approprié qu’un site rendu à la demande.

Facteurs de décision

Voici une liste — plus ou moins exhaustive — des fonctionnalités que je souhaitais retrouver :

  • un formulaire de contact,
  • un formulaire de recherche avec un index généré au moment de la construction,
  • plusieurs flux RSS,
  • une prise en charge du multilingue,
  • la gestion des contenus avec Markdown (.md et non .mdx de préférence), incluant la prise en charge du frontmatter (au format YAML pour la portabilité),
  • étendre la syntaxe Markdown avec Remark/Rehype si besoin,
  • personnaliser le rendu des éléments Markdown,
  • séparer le code source du site des contenus,
  • inclure des paramètres utilisateurs (comme le changement de thème),
  • proposer une zone commentaire.

Je souhaitais également que le site fonctionne sans Javascript et qu’il n’y ait pas plus de scripts que nécessaires. J’ai donc exclut Next.js que j’utilisais pour mon ancien site.

Les options considérées

Parmi les solutions les plus populaires, il y a bien sûr Hugo et Jekyll. J’ai tout de même exploré d’autres choix possibles à l’aide du site Jamstack. La liste est longue, je n’ai pas tout consulté. Les projets qui m’ont paru les plus intéressants étaient : Zola, Astro, Nikola, Metalsmith, Pelican et Hexo.

La solution retenue

Après une comparaison entre les fonctionnalités que je souhaitais utiliser et ce qu’offrait les différents SSG, j’ai choisi d’utiliser Astro, avec Pagefind pour la recherche.

Astro semblait être le seul à répondre à tous mes besoins, ou presque. Je n’ai pas encore implémenté de zone pour les commentaires, mais je sais que c’est faisable. Le point que je n’ai pas résolu est l’utilisation du format .md plutôt que .mdx pour écrire mes contenus tout en personnalisant le rendu des éléments.

Concernant les composants nécessitant un peu d’interactivité comme le formulaire de contact, j’ai décidé d’utiliser des éléments personnalisés plutôt qu’un framework même si c’est possible avec Astro !

Gestion des contenus

Mon souhait de départ

Je souhaitais que mes contenus soient portables et éditables depuis n’importe quel éditeur de texte. Markdown me semble être un bon choix. À l’aide de l’écosystème unified (ie. Remark, Rehype), je peux étendre la syntaxe de base pour répondre à mes besoins éditoriaux. À partir de ce constat, je pensais pouvoir me passer de MDX et utiliser l’extension .md pour mes contenus.

Quelques problèmes

Astro supporte l’usage d’une propriété components lors de l’utilisation de <Content /> pour associer des composants à des éléments mais uniquement avec MDX. Il existe déjà des discussions autour de ce sujet (notamment celles ouvertes par noghartt et par wassfila), mais je doute que ce soit un jour possible.

De même, puisque Markdown est directement rendu en tant que HTML, il ne semble pas possible d’injecter un composant en utilisant Remark ou Rehype. En tout cas, je n’ai pas encore trouvé comment faire. MDX, lui, est rendu en tant que JSX ; il est donc possible de procéder ainsi pour éviter d’importer des composants dans le contenu.

Ma décision

J’ai donc choisi d’utiliser MDX pour le moment sans réellement utiliser MDX : tout contenu écrit peut être copié/collé dans un fichier Markdown sans aucun problème de compatibilité (je n’utilise aucune importation ou déclaration de variable). Ceci dit, je vais continuer de chercher une solution.

Entre le début du projet et la version actuelle (v1.0.3), j’ai déplacé certains styles déclarés dans les composants vers des styles globaux. Cela m’a permis de réduire le nombre de composants définis dans la propriété components. Par contre, je ne peux pas me passer de toutes les associations à moins de devenir un peu plus verbeux dans mes fichiers et de déplacer encore plus de styles.

Il y également le problème des composants injectés. Actuellement, le seul composant que j’injecte en utilisant Rehype est destiné aux blocs de code. Je peux peut-être trouver une autre idée. À suivre !

Déploiement

Dans mes facteurs de décision, j’évoquais le fait que je souhaitais séparer le code source du contenu. J’y suis parvenu en :

  • déclarant le chemin du dossier de contenus en tant que variable d’environnement
  • créant un deuxième dépôt abritant mes contenus et le code source du site en tant sous-module Git.

La solution n’est pas parfaite — j’ai quelques problèmes de cache (ou de routes) quand j’exécute la commande dev dans le dépôt utilisant le sous-module — mais elle me convient plutôt bien pour le moment. Je n’ai pas besoin du serveur pendant que j’écris, seulement à la fin pour vérifier le rendu.

Dans ce deuxième dépôt, j’utilise Docker pour construire une image du site avant de l’envoyer vers un registre privé. Sur mon VPS, il ne reste plus qu’à récupérer l’image et mettre à jour le conteneur.

En bref

Ce site est construit avec l’aide d’Astro (en utilisant vanilla CSS/JS et quelques éléments personnalisés), Pagefind, MDX et Docker. Je suis plutôt satisfait du résultat ! Enfin, je dis vanilla JS mais j’utilise surtout Typescript.