Qu’est-ce qu’Astro ? Son approche technique et son fonctionnement

Jusqu’à récemment, quand je montais un site d’entreprise, le choix habituel pour moi, comme pour presque tout le monde, était WordPress. Pour des raisons évidentes : c’est simple, presque tout ce dont tu as besoin existe déjà et, après de nombreuses années, mon flux de travail est très rapide.

Mais sur mon dernier projet, le site de Rondabus, j’ai utilisé Astro. 

Pourquoi ?

Parce qu’une newsletter sur l’IA que je suis le recommandait : selon elle, Astro s’intègre très bien avec les agents.

Et ce n’était pas exagéré.

J’ai surtout pris ce projet comme un test de l’état actuel du développement web. Pour voir ce qui dépend encore d’un humain et ce que l’IA peut déjà faire. C’est pour cela que j’ai utilisé le framework recommandé.

Évidemment, je me suis documenté pour vérifier qu’il convenait à ce que je voulais faire. C’est de cette documentation qu’est né cet article, où je te raconte ce qu’il faut savoir pour te lancer. Et un peu plus.

Mais avant d’entrer dans le vif du sujet, deux petites choses :

La première, c’est que j’ai adoré son approche HTML first. C’est exactement ce que je prêche depuis des années.

La deuxième, c’est qu’aujourd’hui, pour développer un site web, à part le jugement, tout le reste peut être fourni par ChatGPT ou Claude..

Maintenant, on commence.

Qu’est-ce qu’Astro exactement ?

Astro est un framework pour construire des sites web, c’est-à-dire un ensemble d’outils et de directives qui t’aide à générer le code de ton site.

Ni plus, ni moins.

Il en existe beaucoup, chacun avec ses particularités. Ici, je vais t’expliquer celles d’Astro.

Astro permet de travailler avec des éléments réutilisables, des données partagées et des templates. Il combine ensuite le tout pour produire le site.

Autrement dit, pense à ce qu’il faut pour monter le site d’une entreprise : en-tête, menu, pages de services, photos, textes, formulaire et pied de page. Tu pourrais écrire chaque page à la main en HTML, mais tu répéterais beaucoup de travail.

Si tu changes le numéro de téléphone, ajoutes un élément au menu ou un lien dans le footer, tu devrais le corriger dans tous les fichiers du site. Avec Astro, non, puisqu’il réutilise les éléments.

Tu me diras que WordPress fait pareil. Et oui, c’est vrai, mais ici il n’y a pas de base de données derrière.

Tu pourrais aussi répondre que c’est comme avec n’importe quel langage serveur tel que PHP, et je te répondrais qu’il n’est pas nécessaire d’avoir un langage installé côté serveur : il suffit d’y stocker les fichiers.

Comme on le faisait à l’origine : un fichier HTML par URL, avec ses CSS et JS associés.

En fait, tu peux utiliser HTML, CSS et JavaScript ou TypeScript, mais aussi intégrer des composants React, Vue ou Svelte si tu en as besoin, ce que je ne fais pas.

Et comment obtient-on des éléments réutilisables et beaucoup de fichiers HTML ?

La différence fondamentale : générer le site avant l’arrivée de l’utilisateur

Pour comprendre Astro, il faut distinguer les deux moments d’un site web :

1. Quand il est développé.
2. Quand quelqu’un le visite.

Sur un site dynamique traditionnel, le serveur prépare la page lorsqu’il reçoit une requête. Il exécute du code, récupère les données nécessaires, les place dans un template et renvoie le résultat au navigateur.

WordPress fonctionne par exemple ainsi : PHP exécute l’application, interroge sa base de données et utilise le thème et les plugins pour générer la page. Oui, le cache permet d’enregistrer une réponse et de la réutiliser, donc il n’est pas nécessaire de répéter tout le processus à chaque visite. L’important est de comprendre qu’une application est capable de fabriquer la réponse pendant que le site fonctionne.

En revanche, avec Astro tu peux faire ce travail avant de publier. Tu prépares les pages, génères les fichiers et places le résultat sur l’hébergement. C’est ce qu’on appelle un build..

Ainsi, quand quelqu’un ouvre la page de contact, le serveur livre un HTML déjà créé. Il n’a pas besoin de reconstruire l’en-tête, récupérer le téléphone et monter le pied de page pour ce visiteur.

Cette manière de travailler s’appelle SSG, ou génération de sites statiques. Et elle présente plusieurs avantages, notamment le fait que les sites ainsi créés, littéralement, volent..

Il y en a d’autres que je t’explique dans l’article.

Ce que je t’ai expliqué jusqu’ici suffit pour te faire une idée de ce dont on parle si tu n’as pas de connaissances techniques. Si tu en as, à partir de maintenant, on va approfondir le fonctionnement du framework.

Café serré pour amateurs de café. Tu es prévenu.

Parlons des builds

D’abord, il faut comprendre qu’un build n’est rien d’autre que le résultat d’un processus automatisé qui prend tous les fichiers que tu as écrits (code, images, styles) et les transforme en un paquet prêt à être exécuté par le serveur ou le navigateur web..

Et c’est tout.

Autrement dit, tu as une série de fichiers de code qui font différentes choses. Quand tu exécutes la commande pour compiler le build, Astro identifie les pages, récupère le contenu, exécute les templates et prépare les ressources pour finalement te rendre un site statique complet, avec ses HTML, CSS et JS (s’il en a besoin)..

Par exemple, tu peux avoir un template commun et huit fiches de services. Le build combine le template avec les données de chaque fiche et produit les pages correspondantes.

Dans Astro, cela se fait avec la commande npm run build , qui exécute normalement astro build. . Le site prêt à être mis en ligne se trouve dans le dossier dist , prêt à être envoyé sur le serveur vers lequel pointe ton domaine.

Comment construire une page dans Astro

Si tu n’as pas l’habitude, le vocabulaire paraît plus compliqué qu’il ne l’est. Voyons cela avec un petit site d’entreprise.

À quoi ressemble un fichier .astro

Un fichier .astro peut combiner une partie de code avec un template proche du HTML :

—

const titulo = 'Transporte para tu empresa';

—

<h1>{titulo}</h1>

<p>Organizamos los desplazamientos de tu equipo.</p>

Ce qui apparaît entre les deux groupes de tirets prépare les données. En dessous se trouve le template qui les utilise. Les accolades indiquent où insérer une valeur.

Ce code s’exécute lors de la construction du site et le navigateur reçoit un titre normal avec son texte et un paragraphe normal, avec le contenu de la variable titulo.

Composants

Les éléments qui sont réutilisés.. 

Par exemple, l’en-tête peut être un composant. Le pied de page, un autre. Un template pour le module hero banner des pages de services peut en être un autre. Tu les stockes séparément et les utilises sur les pages qui en ont besoin.

Par exemple, une page peut importer Header.astro et Footer.astro et placer <Header /> au début et <Footer /> à la fin. Astro transforme ces éléments en balisage HTML correspondant.

Props

Les props sont les données que tu fournis à un composant pour pouvoir le réutiliser avec un contenu différent..

Si tu as créé un composant pour le module hero banner des pages de services, tu peux lui transmettre un titre, une description et une image. La structure conserve son design tandis que les valeurs changent. Ainsi, le module hero du service 1 peut être différent de celui du service 2, avec un contenu différent mais le même design.

Dans Astro, le composant peut lire ces valeurs via Astro.props. 

Layouts et slots

Un layout est une structure partagée par plusieurs pages. Disons que c’est comme un composant passé au niveau supérieur : : un composant représente généralement une petite partie de la page, alors que le layout en couvre pratiquement la totalité..

Il peut inclure le document HTML, les métadonnées, l’en-tête et le pied de page.

Le slot est l’emplacement où l’on insère le contenu propre à chaque page. 

Si tu viens de WordPress, cela te rappellera les templates qui partagent l’en-tête et le pied de page tandis que le contenu principal varie d’une URL à l’autre. Ce n’est pas exactement le même fonctionnement, mais la fonction est similaire : éviter de reconstruire à chaque fois ce qui est commun.

Comment Astro organise les URL

Astro utilise un système de routage basé sur les fichiers. Dans un projet simple, l’emplacement d’une page dans src/pages détermine son adresse :

Fichier	Route
src/pages/index.astro	/
src/pages/contacto.astro	/contacto
src/pages/servicios/bodas.astro	/servicios/bodas

La barre oblique finale dépend de la configuration et de l’hébergement, mais la relation de base est celle-ci.

Tu n’as pas besoin de créer manuellement un fichier différent pour chaque article ou service. Cela permet de générer de nombreuses pages à partir d’un template et d’un jeu de données, sans recopier le même code encore et encore.

Où stocker le contenu si Astro n’a pas de base de données

Le fait qu’Astro n’exige pas de base de données signifie que les textes et les données doivent être stockés dans une source quelconque ; à toi de choisir laquelle.

Fichiers, Markdown, JSON et YAML

Pour un petit site, une partie du texte peut rester directement dans les pages. Les données partagées, comme le numéro de téléphone, ont intérêt à être séparées pour éviter de devoir les corriger à vingt endroits.

Un article peut être stocké en Markdown, un format texte avec un balisage simple pour les titres, les listes et les liens. JSON et YAML servent à organiser les données : fiches de services, informations sur des véhicules ou textes par langue, par exemple.

Ce sont des formats différents pour des besoins différents. Tu n’as pas à tous les utiliser ni à transformer chaque phrase de ton site en structure compliquée.

Content Collections

Les Content Collections, ou collections de contenu, servent à organiser des ensembles d’entrées de données et à définir leur structure..

Imagine une collection de services où chaque fiche doit comporter un titre, une description et une image. Tu peux définir ces règles et valider les données, ce qui permet de détecter plus facilement une fiche incomplète ou une valeur du mauvais type.

Si tu connais les types de contenu et les champs personnalisés de WordPress, l’idée d’organiser des fiches te semblera familière.

Contenu avancé : API, CMS et bases de données externes

Même si nous générons des sites statiques, le contenu peut aussi provenir d’un CMS, d’une API ou d’une base de données. Une API est un moyen pour deux systèmes d’échanger des informations : Astro demande des données et l’autre système les lui fournit.

Tu peux même utiliser WordPress comme source d’articles et construire la partie publique avec Astro. Nous reviendrons sur cette combinaison dans Astro vs WordPress..

La question décisive est quand tu récupères ces informations. Si elles sont intégrées pendant le build, les modifier à la source ne change pas le HTML publié tant que tu ne le régénères pas. Si elles sont récupérées lors d’une requête ou depuis le navigateur, le comportement est différent et se rapproche davantage des pages dynamiques traditionnelles.

Que sont les Islands d’Astro

Une page peut contenir beaucoup de contenu que tu veux seulement lire et une petite partie avec laquelle tu veux interagir. Par exemple, un calculateur de devis dans une page de service. Ou un formulaire..

L’architecture en îlots permet à ce composant d’avoir son propre comportement sans transformer toute la page en application exécutée dans le navigateur.

Que signifie hydrater un composant

Hydrater consiste à ajouter le code d’un composant interactif à un HTML déjà généré afin qu’il puisse répondre aux actions de l’utilisateur.

Le calculateur ou le formulaire peuvent s’afficher au chargement de la page puis activer leur logique.. 

Ici, nous parlons d’îlots côté client. Astro dispose aussi d’îlots côté serveur pour traiter séparément certaines parties dynamiques, même s’il n’est pas nécessaire d’entrer dans ce détail pour comprendre cette première explication.

Quand le navigateur a besoin de JavaScript

Toute interaction n’exige pas un îlot. Un lien fonctionne en HTML. Un menu déroulant simple peut être géré avec HTML et CSS.

En revanche, un calculateur qui met à jour les résultats lorsque tu modifies des options aura généralement besoin de JavaScript. Et le formulaire a besoin d’une intégration ou d’un langage serveur pour envoyer les données.

Et c’est là que j’adore l’approche d’Astro : la décision se prend selon la fonction que tu veux offrir, pas selon l’idée rebattue qu’ un site moderne doit charger une application entière..

Astro essaie d’envoyer zéro JavaScript par défaut

Attention, ne mélangeons pas tout : nous parlons du site tel que l’utilisateur le voit.. 

Parce qu’ Astro utilise bien JavaScript pour travailler et compiler, mais les composants .astro n’ont pas besoin d’envoyer leur code de préparation au navigateur. 

Les scripts que tu ajoutes, les îlots que tu hydrates et les outils externes peuvent malgré tout ajouter du JavaScript. Un chat, une plateforme d’analytics (GA4) ou une vidéo intégrée en ont besoin.

Par conséquent, « zéro JavaScript par défaut » est le point de départ, pas une obligation.

Et, comme je l’explique plus bas, cela correspond énormément à ma façon de développer des sites d’entreprise, par exemple.

Astro peut être statique, dynamique ou hybride

Bien, jusqu’ici je me suis concentré sur une seule approche, mais il y en a deux possibles.

SSG

Ce que nous avons vu jusqu’ici : la page est générée avant les visites, pendant le build. 

C’est parfait lorsque le contenu peut rester identique pour tout le monde jusqu’à la prochaine publication. Autrement dit, pour des pages qui changent peu.

SSR

La page est générée à la demande sur le serveur. Elle peut utiliser des informations qui ne sont pas disponibles pendant le build, comme des données liées à une session. 

N’importe quel serveur ne suffit plus : il faut un environnement d’exécution compatible et l’adaptateur correspondant.

Rendu hybride

Tu peux combiner des pages prérendues et des pages générées à la demande. Par exemple, garder les pages publiques préparées à l’avance et traiter une zone privée sur le serveur.

Quel rôle jouent Node.js et Vite

Node.js permet d’exécuter JavaScript en dehors du navigateur. Dans un projet Astro classique, il intervient pendant le développement et la construction du build, où npm aide à gérer les paquets et les commandes. Pour un site statique, Node.js n’a pas besoin de fonctionner sur le serveur de production qui héberge le build.

Vite est un moteur utilisé par de nombreux frameworks modernes. Il fait partie de la mécanique qu’Astro utilise pour travailler avec les fichiers et fournir l’environnement de développement. 

Ça suffit pour te faire une idée.

Comment s’organise un projet Astro

Quand tu ouvres un projet, tu vois des dossiers qui ne sont pas des pages et des fichiers qui ne sont pas publiés. Cette petite carte t’aidera à les distinguer.

src

Contient le code source : pages, composants, layouts et autres fichiers de travail. C’est ici qu’une grande partie du site est construite.

public

Contient des ressources servies sans le traitement habituel des fichiers importés : un robots.txt ou certaines images, par exemple. Tout ce que tu places ici sera public ; ce n’est donc pas un endroit pour des identifiants.

package.json

Décrit le projet, ses dépendances et ses scripts. C’est là que l’on définit ce qu’exécutent des commandes comme npm run build. Le fichier de verrouillage des dépendances aide à conserver des versions précises pour reproduire l’installation.

node_modules

C’est le dossier dans lequel sont installés les paquets dont le projet a besoin. Il est normalement reconstruit à partir des fichiers de dépendances et n’est pas stocké en entier dans Git.

dist

Contient la sortie de production après le build. Pour un site statique, tu y trouveras les fichiers prêts à publier.

Ce que chargent réellement le navigateur et Google

Je vais le répéter une fois de plus pour ceux du dernier rang : le navigateur ne reçoit pas ton projet tel que tu le vois dans l’éditeur. Il reçoit le HTML et les ressources nécessaires pour afficher et utiliser la page.

Un moteur de recherche qui demande cette URL recevra le HTML, que tu l’aies préparé pendant le build ou généré sur le serveur. Cela ne garantit ni son indexation ni un bon classement : le contenu, les liens et les réglages d’exploration et d’indexation comptent toujours, mais, d’après mon expérience, on peut optimiser très, très bien ce qu’il reçoit.

L’idée que je veux que tu retiennes est la suivante : tous ces templates, collections et composants servent à produire un site qui continue d’utiliser les technologies de toujours. Astro dirige la création du site ; le HTML obtenu est reçu par un navigateur.

Conclusion : pour quels types de sites Astro a du sens

Cette façon de travailler convient bien aux sites dont le contenu ne change pas excessivement :

• Sites d’entreprise.
• Portfolios
• Pages d’acquisition.

Je ne le recommanderais pas pour les magazines, blogs et sites où l’on crée beaucoup de contenu ou où plusieurs créateurs de contenu travaillent. Pour cela, je continue de préférer WordPress à Astro..

Si cette approche t’a plu et que tu veux en savoir plus, tu peux continuer avec les avantages et les inconvénients d’Astro..

Et si tu préfères l’appliquer à un projet complet, j’ai préparé le processus pour créer un site d’entreprise locale avec l’IA, en utilisant mon dernier projet comme exemple.

Je te garantis qu’une fois que tu l’auras essayé, tu ne voudras plus revenir en arrière.