Flux de l’étiquette Astro

[Signet] Astro SEO: the definitive guide

Mon, 13 Apr 2026 19:37:00 GMT

In 2008, I wrote WordPress SEO: the definitive guide. It became one of the most-linked SEO articles on the internet and laid the groundwork for what eventually became Yoast SEO. The tools have changed, the web has changed, and my thinking on several fundamentals has evolved. This is the Astro version.

[Signet] Astro Integrations Explained

Fri, 30 May 2025 19:10:00 GMT

If you’ve ever used Astro, you will no doubt have come across Astro’s integration system. You can think of integrations like plugins: They’re pieces of code that add new functionality and behavior to your project.

[Article] Participer au projet Astro

Sat, 08 Feb 2025 23:53:00 GMT

J’utilise des projets open-source depuis longtemps, mais je n’ai jamais réellement contribué à un projet existant. J’ai bien créé quelques tickets voire corrigé un ou deux bugs mineurs ou une erreur dans une documentation mais je n’ai jamais cherché à m’investir.

Puis, en 2024, j’ai finalement trouvé un projet qui m’a donné envie de participer. Ce projet s’appelle Astro ! Un an après, je partage avec vous mon parcours et quelques pistes si vous souhaitez également vous lancer.

Qu’est-ce qu’une contribution ?

Avant de m’aventurer plus loin, je pense qu’il est important de définir ce que j’entends par contribution. Pour beaucoup, participer à un projet open-source est synonyme de code. Certes, coder est une compétence recherchée et applicable à tous les projets mais il existe d’autres manières de contribuer.

De mon point de vue, tout acte qui aide à faire évoluer un projet peut être perçu comme une contribution :

Vous rencontrez un bug ? Créez un ticket détaillé avec une reproduction minimale pour qu’il puisse être corrigé et qu’il n’arrive pas à d’autres personnes !
Vous savez comment corriger un bug ? N’hésitez pas à créer une « pull request » (ou « merge request » suivant la plate-forme) !
Vous êtes plus à l’aise avec les mots ? Pensez à regarder ce qui peut être fait du côté de la documentation !
Vous êtes à l’aise en anglais et dans une autre langue ? N’hésitez pas à regarder si vous pouvez aider à traduire la documentation !
Vous n’êtes pas assez à l’aise en anglais pour traduire ? Vous pouvez toujours relire les traductions proposées dans votre langue et approuver ou proposer des améliorations !
Vous avez toujours apprécié recevoir des réponses à vos demandes d’aide ? Vous pouvez faire la même chose en fournissant une assistance technique aux autres utilisateur !

Vous avez compris l’idée ; il existe différentes formes de contribution. Toutes sortes de compétences peuvent être utiles.

Mon parcours en tant que contributeur pour Astro

Il y a un an, je me décide à tester Astro. Je rencontre un problème mais ne trouve pas l’information dans la documentation. Plutôt que d’ouvrir un ticket dans le dépôt principal d’Astro, je cherche si un problème similaire a déjà été remonté. Il s’avère que oui et qu’il ne s’agit pas d’un bug. Puisqu’il semble que je ne sois pas le seul à rencontrer ce problème, je me dis que la documentation devrait le préciser.

Ouverture de tickets

Je crée ainsi mon premier ticket dans le dépôt docs d’Astro. Ce ticket n’a pas reçu de réponse tout de suite, mais ça ne m’a pas empêché de continuer dans ma lancée en créant d’autres tickets dans les autres dépôts quand je rencontrais un problème qui ressemblait à un bug.

Ce n’est pas toujours évident au début de savoir dans quel dépôt il convient de faire remonter le problème. Il est possible de le faire dans le dépôt principal… mais je préfère quand je poste au bon endroit du premier coup. Ces tickets m’ont permis de me familiariser avec différents dépôts du projet : le cœur, la documentation, le compilateur et les outils dédiés aux éditeurs.

J’ai été surpris par l’accueil ; c’est plutôt rare qu’on me remercie pour avoir créé un ticket ! En soi, ce n’est pas important. Du moment que le problème est corrigé, c’est tout ce qui compte. Ceci dit, je reconnais que ce genre d’accueil fait une différence, surtout lorsque l’on n’est pas sûr si c’est un bug ou le fonctionnement attendu.

Suivis de « pull requests »

J’ai ensuite saisi l’opportunité d’un ticket étiqueté « Good first issue » (comprendre : les nouveaux venus sont bienvenus) pour faire ma première PR dans le dépôt principal d’Astro ! Il s’agissait de convertir un plugin Remark en plugin Rehype.

En juin, mon premier ticket — lié à la documentation — était sur le point d’être résolu, il ne manquait plus qu’une PR. Je m’en suis chargé.

Mes différentes interactions avec l’équipe et les contributeurs d’Astro m’ont donné envie de continuer à contribuer. J’ai donc regardé ce qui pouvait être dans mes cordes.

Implication dans Astro Docs

Puisque j’étais en train d’apprendre à utiliser Astro, j’ai décidé de m’attarder dans le dépôt docs d’Astro.

Traduction en français

La documentation n’était pas encore complètement traduite en français. Je me suis donc dit que participer à la traduction était un bon moyen pour me familiariser avec tous les concepts !

J’ai commencé à mettre à jour des traductions et à traduire des pages manquantes. J’ai également participé à la relecture des traductions proposées par d’autres contributeurs.

Participer à la traduction m’a fait découvrir un nouvel outil : Lunaria. Si vous maintenez une documentation multilingue, je vous recommande d’y jeter un œil !

Relecture de la documentation en anglais

J’étais curieux de voir le processus pour construire la documentation dans son ensemble. Dans le même temps, la version 5 d’Astro faisait son apparition en tant que bêta. Je me suis donc mis à m’intéresser aux autres PR et tickets, en anglais cette fois.

J’étais certes moins à l’aise pour juger de la formulation en anglais, mais j’ai pu me rendre utile en corrigeant d’éventuelles coquilles ou problèmes de formattage.

Diverses améliorations dans la documentation

Pendant la traduction, il m’arrivait de noter quelques fautes de frappe ou problèmes de formattage dans la version originale ; c’était une bonne occasion pour mettre un pied dans la documentation anglaise en les corrigeant.

Je me suis ensuite attaqué à la page de référence de l’API d’Astro pour apporter un peu plus de consistence, ajouter des informations manquantes et corriger d’éventuelles erreurs. Cela m’a donné l’occasion d’échanger avec un autre membre de l’équipe.

Lorsque la v5 était encore en bêta, j’ai finalement testé le tutoriel d’Astro ! Un peu tard… mais il n’était pas question d’apprendre ici. Je souhaitais aider à vérifier que tout fonctionnait correctement et apporter des modifications là où c’était nécessaire. Je dois dire qu’il reprend bien les concepts nécessaires pour débuter rapidement avec Astro !

Participation à l’événement « Talking & Doc’ing »

Chaque jeudi, ou presque, un événement « Talking & Doc’ing » est organisé sur le serveur Discord d’Astro. L’idée autour de cet événement est d’échanger sur la meilleure manière de traiter certains tickets, sur les modifications à apporter à une PR en cours, sur les changements au niveau de l’organisation de la documentation, etc. Puisque je m’intéressais au processus pour créer la documentation, j’ai finalement décidé d’y assister.

Depuis, je continue d’y assister. Je dis bien « assister » plutôt que « participer » parce que je dois admettre que je suis plutôt passif. Pour commencer, je n’aime pas trop parler même en français (ce qui peut contraster avec mes écrits). Ensuite, autant je peux écrire en anglais, autant je ne suis pas particulièrement à l’aise pour parler en anglais. Ainsi, je laisse ma webcam (pour le micro) rangée et j’interviens uniquement par écrit. Je dois l’admettre, ce n’est pas pratique d’autant plus quand il s’agit de discuter d’une PR créé par soi-même… Peut-être qu’un jour je me déciderai à intervenir oralement.

Un peu d’assistance technique

Il m’arrivait de répondre aux questions au sujet d’Astro sur StackOverFlow. Puis, quand j’ai commencé à traduire la documentation d’Astro, j’ai rejoint Discord pour pouvoir me coordonner avec les autres traducteurs et ainsi éviter de proposer une traduction en double exemplaire. J’ai alors commencé à intervenir occasionnellement dans la rubrique « support ».

À côté de ça, j’essaie d’aider dans le tri des tickets du dépôt docs et de temps en temps, ceux du dépôt principal. Si je vois une problème qui a été déjà abordée, c’est l’occasion de proposer une solution ou de renvoyer vers un ticket couvrant déjà ce cas de figure.

Des contributions amenant des surprises

En décembre 2024, Astro 5 devient finalement stable. Un billet de blog accompagne sa sortie officielle. Je connaissais déjà les différents changements apportés, mais je le lis tout de même avec attention. Surprise en bas de page : je vois mon nom apparaître dans les remerciements !

Puis, début 2025, je reçois un message privé sur Discord venant du co-fondateur d’Astro. Il me propose d’intégrer l’équipe de mainteneurs d’Astro. Je ne m’y attendais pas. J’ai certes été plutôt actif depuis juin, mais je ne pensais pas qu’on me ferait suffisamment confiance pour ce rôle et aussi vite. J’ai bien sûr accepté cette opportunité et je remercie encore l’équipe pour cette confiance !

L’intégration de nouveaux mainteneurs dans le projet est basé sur un système de nomination et de votes. Il ne s’agit pas de volontariat ou de candidature. Ce qui explique pourquoi je fus surpris.

Finalement, en octobre 2025, je reçois un nouveau message du co-fondateur d’Astro pour me proposer, cette fois, d’intégrer l’équipe des mainteneurs principaux d’Astro ! Évidemment, j’ai accepté ; il ne me reste plus qu’à devenir plus à l’aise pour parler en anglais à l’oral, haha.

En fin de compte

Je ne vais pas vous le cacher, oui, j’ai trouvé ça un peu intimidant. Pour commencer, je suis plutôt du genre introverti et je ne suis pas particulièrement à l’aise pour communiquer en anglais. Ensuite, n’étant pas habitué à participer à des projets open-source, je me demandais si je faisais bien d’intervenir un peu partout — et notamment dans les PR de l’équipe d’Astro — ou si j’en faisais trop…

Ceci dit, je ne regrette pas de m’être lancé et de m’être impliqué dans ce projet. Je dois dire que l’accueil au sein de la communauté d’Astro y est pour beaucoup. Je ne doute pas qu’il existe d’autres projets accueillants, mais, je ne sais pas, il y a un petit truc en plus. Donc, je suis content d’être tombé sur ce projet et d’en faire parti !

Pour le moment, je compte rester côté documentation même si je la connais plutôt bien maintenant. Il y a toujours des choses à faire, et je peux m’exercer à la rédaction technique en anglais. Non, maintenir la doc ce n’est pas simplement corriger des fautes de frappe. D’ailleurs, elle a même le droit à son propre site de documentation !

Vous souhaitez participer ?

L’architecture du projet Astro

Astro dispose de plusieurs dépôts, voici les principaux :

withastro/astro qui correspond au cœur du projet,
withastro/compiler qui est utilisé derrière la scène pour transformer les templates,
withastro/language-tools qui se concentre sur les outils nécessaires aux éditeurs pour comprendre la syntaxe Astro,
withastro/starlight qui contient les sources de l’outil dédié à la création de sites de documentation,
withastro/docs qui contient la documentation d’Astro (et ses traductions).
roadmap qui permet de proposer des idées — et d’échanger autour de ces idées — afin de développer les fonctionnalités d’Astro.

Toutes sortes de compétences peuvent être utiles

Qui dit plusieurs dépôts, dit également des compétences diverses. Par exemple, si vous êtes plutôt développeur Go, le compilateur d’Astro peut vous intéresser tandis que pour le cœur du projet, il vous faudra connaître Typescript. Si vous êtes plutôt doué avec les mots, n’hésitez à rejoindre l’équipe Docs !

Vous pouvez également contribuer sans avoir beaucoup de temps à consacrer. Vous pouvez par exemple aider au tri des tickets, à la vérification du code ou à la relecture de la documentation. Si vous êtes sur Discord, vous pouvez également aider à résoudre les demandes d’aide. Même occasionnellement, ce type de contribution est toujours la bienvenue !

Vous ne vous retrouvez dans aucune description ? Ma liste n’est pas exhaustive, n’hésitez pas à vérifier par vous-même s’il y a un endroit où vous pouvez apporter votre contribution ! Et, rappelez-vous, vous n’avez pas besoin de vous engager à plein temps, même occasionnelle, une contribution est toujours la bienvenue.

Avant de commencer

Si vous avez encore une hésitation, je vous invite à lire la page Contribuer à Astro dans la documentation. Ensuite, sachez que chacun de ces dépôts contient un fichier CONTRIBUTING.md. Je vous recommande de le lire avant de vous lancer.

Que ce soit pour les tickets, les RFC ou encore les PR, chaque dépôt dispose de modèles à remplir. Ces derniers ne sont pas là pour vous embêter mais pour faire gagner du temps aux personnes qui essaieront de vous aider (que ce soit à résoudre votre problème, à relire votre contribution, etc.). Il s’agit donc d’un système gagnant-gagnant.

Enfin, n’hésitez pas à rejoindre le serveur Discord d’Astro. Y être présent est utile pour se coordonner si besoin, mais cela peut également vous permettre de trouver de l’aide ou de demander des conseils.

[Projet] Armand.Philippot.Eu

Sat, 25 Jan 2025 17:04:00 GMT

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 créé 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 prend en charge 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.