Quiconque a vendu des sites sans maintenance sait combien de fois on explique au client qu’il disposera d’un CMS ultra-simple permettant de faire facilement de petites ou grandes modifications.
Le client trouve ça formidable dans le devis, mais une fois le site livré, il ne touche à rien pendant des mois. Et, exceptionnellement, s’il veut changer quelque chose, il t’écrit pour que tu le fasses.
C’est normal : il se concentre sur son activité et attend seulement de son site qu’il lui apporte des clients. Rien à redire.
À force de voir ça, je me suis toujours dit que WordPress était génial, surtout pour le développeur, puisqu’il impose une maintenance qui ne devrait pas toujours être nécessaire..
Je pensais donc qu’il devait exister des alternatives. D’autres approches que je n’avais pas encore trouvées.
Avec du HTML pur, tu sais bien que la moindre modification, comme le numéro du service client, prend un temps fou. Et souvent, il faut des fonctionnalités complexes qui nécessitent en principe un langage serveur.
Et oui, PHP est une possibilité, avec ses includes et tout ce qu’il permet. Mais le développement devient nettement plus complexe qu’avec WordPress. Sans compter qu’il faut un hébergement avec ce langage installé et qu’il faut le mettre à jour.
Mais il y a peu, j’ai découvert Astro. Et tout s’est éclairé.
La philosophie d’Astro : HTML d’abord, JavaScript seulement si nécessaire
Si tu ne connais pas encore l’outil, commence par comprendre ce qu’est Astro et comment il fonctionne, surtout sur le plan technique. Ici, nous allons nous concentrer sur les conséquences pratiques de son architecture..
Son approche consiste à fournir le contenu en HTML et à réserver le code exécuté dans le navigateur aux parties qui en ont besoin. Et en plus de la génération statique, il accepte aussi le rendu à la demande.
Voyons ce que cela signifie.
Les avantages d’Astro
Avant de commencer, précisons que certains avantages sont universels, tandis que d’autres ne valent que pour certains types de sites.
Je t’explique.
Des performances inscrites dans l’architecture
Pour une page de service, fournir un document déjà prêt évite des traitements pendant la visite. Inutile de demander au serveur de reconstruire un contenu inchangé : renvoyer un fichier HTML stocké suffit.
C’est un très bon point de départ pour charger (très) vite. Surtout avec des images bien optimisées (coucou webp), des CSS optimisées et une bonne distribution des fichiers.
L’avantage, c’est que tu pars d’une structure légère, puis tu ajoutes seulement ce dont tu as réellement besoin, en toute connaissance de cause..
Astro cherche à éviter tout le JavaScript inutile, car en réduire la quantité diminue les téléchargements, mais aussi le travail de l’appareil. Sur un PC, c’est rarement un souci ; sur un téléphone, surtout d’entrée de gamme, c’est plus sensible : il doit interpréter et exécuter ce qu’il reçoit tout en assurant le reste.
Sur un site d’information, envoyer énormément de logique qui n’apporte presque rien au visiteur est un gaspillage de ressources.
Astro, de son côté, facilite l’intégration des petits outils interactifs réellement nécessaires. Cet avantage tient tant que tu surveilles ce que tu ajoutes.
Un HTML propre et une bonne base pour le SEO
Disposer du contenu principal en HTML en facilite l’accès.
Il est aussi assez facile de respecter les bonnes pratiques SEO, car on peut créer une structure claire de titres, de liens et de sections.
Une surface d’attaque réduite
Voilà un bon point si tu veux éviter la maintenance.
Dans un site statique, aucun CMS ni aucune base de données ne s’exécute dans la partie publique. Il y a moins de fonctions exposées à protéger..
Cela réduit ÉNORMÉMENT certains risques, sans rendre le projet invulnérable. Le compte d’hébergement, le dépôt GitHub et les services connectés doivent toujours être sécurisés. Et si tu utilises un formulaire avec un backend, celui-ci doit aussi valider les saisies et limiter les abus. Heureusement, certains sites n’en ont presque jamais besoin.
Un hébergement simple et peu cher
Autre avantage universel.
Servir des fichiers statiques demande généralement moins d’infrastructure que faire fonctionner une application avec base de données et langage serveur. Pour un petit projet, un hébergement statique peut entrer dans une offre gratuite ou économique, selon les conditions du fournisseur.
En réalité, un énorme avantage est de pouvoir déployer gratuitement le build du site sur CloudFlare et ne rien payer pour l’hébergement. Oui, tu supprimes totalement cette dépense.
Attention, il faut distinguer l’hébergement du site du reste du projet :
- Le nom de domaine sera toujours payant.
- La messagerie peut aussi être gratuite..
- Si tu utilises des API, celles de Meta ou d’autres, cela dépendra de leur utilisation.
Bref, se passer de serveur traditionnel ne rend pas tout le système gratuit, mais supprime la principale dépense d’un site d’entreprise.
Des composants sans transformer tout le site en SPA
Une SPA (Single Page Application) est une application dans laquelle une bonne partie de la navigation et de l’interface dépend du code du navigateur. Cela convient à certains produits (par exemple les réseaux sociaux et leurs fils d’actualité), mais un site de services en a rarement besoin.
Or, Astro permet de réutiliser des composants et des structures communes ponctuellement, sans imposer à tout le site le fonctionnement d’une SPA. Tu modifies une seule fois un bloc partagé tout en continuant à servir des pages comme des documents classiques.
Souplesse dans la gestion du contenu
Ne pas avoir besoin d’un CMS ne veut pas dire qu’on ne peut pas en intégrer un.
Tu peux commencer avec des fichiers statiques pour un site d’entreprise et connecter un CMS si tu veux, par exemple, lancer un blog. Tu peux aussi te connecter aux systèmes déjà utilisés par l’entreprise et en récupérer les données.
Cette liberté offre diverses solutions pour tous les types de sites.
Intégration à Git
Comme seuls les fichiers sont nécessaires, sans base de données, Astro s’intègre parfaitement à Git.
Conserver l’historique du projet dans Git facilite la vérification des changements, les tests avant publication et le retour à une version précédente.
Quand l’IA développe du code, cette traçabilité est particulièrement utile : tu peux examiner une modification précise sans compter sur la mémoire de l’assistant.
Séparation du frontend et des services externes
Oui, le HTML, c’est très bien, mais il ne suffit pas à faire fonctionner un formulaire et à te faire parvenir les réponses. Il faut un serveur pour cela.
L’avantage, c’est qu’avec le HTML, tu peux connecter l’API de certains services, comme celle de Zoho Mail et faire arriver les réponses à l’adresse e-mail de ton choix. Le tout gratuitement.
Si tu utilises déjà cet outil pour ta messagerie professionnelle, inutile d’en ajouter un autre à ton stack.
Les principales faiblesses d’Astro
Parlons maintenant des inconvénients qui rendent ce framework peu recommandable pour certains projets.
Pas de CMS prêt à l’emploi
Quand je développe un site, ma première question pratique est : qui va le mettre à jour ou l’entretenir ?
Si le client veut ouvrir un tableau de bord, remplacer une photo et publier, Astro seul ne lui offre pas cette expérience. Il faut manipuler des fichiers ou ajouter un outil d’édition.
Pour un client qui doit modifier son site sans t’appeler, Astro n’est pas le meilleur choix.
Davantage de décisions techniques à prendre
Tu dois décider où stocker les textes, comment publier les modifications, comment faire fonctionner le formulaire et que faire si un service tombe en panne.
Avec un CMS comme WordPress, presque tout cela existe d’emblée.
En revanche, l’avantage d’Astro est de pouvoir concevoir le système une fois et le réutiliser sur plusieurs sites différents.
Les intégrations demandent du développement
Certains services simplifient beaucoup le travail, mais tu ne trouveras pas toujours une solution prête à installer qui répond à tous tes besoins, comme les plugins classiques d’un CMS.
Par exemple, mettre en page un formulaire ne suffit pas. Il faut connecter son envoi, gérer les erreurs, protéger les identifiants et vérifier que les messages arrivent. Des réservations avec horaires, paiements et annulations multiplient les développements, donc les décisions.
L’IA peut accélérer la réalisation, mais il faut toujours quelqu’un capable de contrôler le résultat et d’en assumer la responsabilité.
Moins pratique pour les équipes éditoriales
Une personne qui publie occasionnellement peut travailler (relativement) bien avec Markdown. Une équipe avec plusieurs auteurs, des validations, un calendrier et une gestion constante des images a besoin d’une expérience éditoriale plus complète.
Bref, un bon vieux CMS.
On peut installer un CMS adapté au-dessus d’Astro, mais pourquoi le faire plutôt que d’utiliser simplement ce CMS ?
Les builds peuvent se compliquer sur les énormes projets
Avec la génération statique, il faut construire les pages publiées. Le temps nécessaire dépend de leur nombre, de la récupération des données et des traitements effectués.
Un gros catalogue avec de nombreuses images ou requêtes externes peut compliquer ce processus. Il n’existe aucun nombre magique d’URL au-delà duquel Astro ne convient plus : il faut mesurer le projet et décider ce qu’on génère à l’avance et ce qu’on rend à la demande.
Et si une mise à jour urgente dépend d’un build qui échoue, l’ancien contenu reste publié jusqu’à la résolution du problème.
Un écosystème plus petit que celui de WordPress
Astro dispose d’intégrations et de modèles, mais n’offre pas autant de solutions prêtes à l’emploi pour des besoins métier très variés.
Avec WordPress, on trouve souvent plusieurs solutions de réservation, d’abonnement ou de flux éditorial. Avec Astro, il faut parfois relier des services ou développer une partie du comportement. Cela affecte le temps de développement, le budget et la personne qui pourra assurer la suite.
Une courbe d’apprentissage pour qui vient de PHP ou WordPress
Si ton habitude est d’installer un thème et de configurer des plugins, tu découvriras de nouveaux outils : packages, dépôts, builds et déploiements.
Pas besoin de tout maîtriser d’un coup. Mais tu dois comprendre le chemin entre les fichiers modifiés et le site publié. Sinon, tu risques de demander une correction à l’IA, de la voir en local et de penser qu’elle figure déjà sur le vrai site.
Tous les projets ne conviennent pas à une architecture statique
Tout ce qui précède se résume à cela.
Une page publique assez stable et un tableau de bord contenant des données personnelles en temps réel n’ont pas les mêmes besoins.
Astro peut ajouter des fonctions serveur et dynamiques, mais une autre plateforme peut mieux répondre à l’ensemble. La question n’est pas de savoir si Astro en est capable, mais si cela vaut le coup.
Quelques précisions sur les limites d’Astro
J’en ai déjà parlé tout au long de l’article, mais je veux le résumer ici pour que ce soit clair.
Ne pas avoir de CMS intégré ne signifie pas ne pas pouvoir utiliser un CMS
Tu peux ajouter un éditeur et une source de contenu. La vraie limite est de devoir les choisir et les intégrer, avec leurs coûts et leur maintenance.
Ne pas exiger de base de données ne signifie pas ne pas pouvoir en utiliser une
Astro n’en exige pas pour un site simple.
Si le projet doit stocker des utilisateurs, des réservations ou des données variables, il peut se connecter à une base. Les clés et les requêtes sensibles doivent rester dans un environnement serveur sécurisé.
Générer du statique ne signifie pas qu’Astro ne sert que des sites statiques
Tu peux combiner plusieurs stratégies et services.
Une page préconstruite peut envoyer un formulaire à un backend. Le contenu public et le traitement du message sont deux tâches distinctes.
Pour le chargement, ce qui compte, c’est ce que reçoit le visiteur.
Une partie du code sert à fabriquer la page et ne participe pas à la visite. Confondre ces étapes fausse l’évaluation du poids réel du site.
Quand je choisirais Astro
Passons à l’essentiel.
J’envisagerais Astro pour :
- Un site d’entreprise.
- Un portfolio.
- De la documentation.
À condition que :
- Les pages soient relativement stables.
- Personne d’autre que moi n’y touche.
- Je recherche de bonnes performances.
- Un coût faible (sans serveur à payer).
- Et mon stack comprenne du développement avec IA et l’intégration à Git.
Quand je ne choisirais pas Astro
Je ne l’utiliserais pas si :
- Le client doit modifier le site lui-même.
- Le frontend change en permanence.
- Le blog est au cœur du site.
- Pour un magazine.
- Pour un site d’ecommerce.
- Pour un espace membres.
Bref, quand un CMS simplifie le travail.
Conclusion : Astro n’est pas toujours meilleur, tout dépend du projet
J’adore l’approche d’Astro. Je cherchais cela depuis longtemps : créer de nombreux sites au contenu statique avec une structure très, très proche de leurs besoins réels.
En plus, il s’intègre très bien à l’IA pour développer presque tout.
Mais il faut aussi penser à la vie du site après sa livraison.
Si le client peut l’entretenir, que les intégrations sont réglées et que le contenu convient, c’est une option très intéressante.
Comme tu l’auras deviné, la comparaison que je fais le plus souvent pour chaque projet est Astro vs WordPress. Dans l’article en lien, j’explique comment choisir en tenant compte de tout le travail, de l’édition à la maintenance, en passant par le budget du client.
Questions fréquentes
Quels sont les principaux inconvénients d’Astro ?
Il n’inclut pas de CMS prêt à l’emploi, impose plus de décisions techniques et certaines fonctions nécessitent du développement ou des services externes. Il est aussi moins pratique pour les équipes qui publient en continu.
Astro est-il bon pour le SEO ?
Oui, car il facilite la diffusion du contenu en HTML et la création de pages légères et bien structurées. C’est une bonne base technique, même si le référencement dépend aussi du contenu, des liens et d’autres facteurs.
Astro a-t-il besoin d’une base de données ?
Non. Un site simple peut fonctionner avec des fichiers statiques, mais Astro permet aussi de se connecter à des bases de données pour stocker ou consulter des informations dynamiques.
Peut-on utiliser un CMS avec Astro ?
Oui. Tu peux connecter un CMS pour gérer les contenus, mais tu devras le choisir, l’intégrer et l’entretenir. Astro n’inclut pas d’interface éditoriale complète par défaut.
Peut-on héberger gratuitement un site Astro ?
Oui. Un site statique peut être publié sur des services proposant une formule gratuite, comme Cloudflare, s’il en respecte les conditions. Le domaine, l’e-mail et d’autres services peuvent coûter séparément.
Astro permet-il de créer des sites dynamiques ?
Oui. Même s’il excelle dans la génération statique, il prend aussi en charge le rendu côté serveur et les connexions aux API et aux services externes pour ajouter des fonctions dynamiques.
Astro convient-il à un site d’entreprise ?
Pour moi, c’est l’un de ses meilleurs usages, surtout si le contenu change peu et que la maintenance est assurée par quelqu’un de compétent techniquement. Il permet de créer des sites rapides sans CMS traditionnel.
Astro est-il recommandé pour un blog ou un magazine ?
C’est possible, mais ce ne serait pas mon premier choix pour un magazine ou un blog publiant souvent avec plusieurs rédacteurs. WordPress offre généralement une gestion éditoriale plus confortable.
Astro est-il meilleur que WordPress ?
Cela dépend du projet. Je choisirais Astro pour les sites d’entreprise assez stables et WordPress si le client doit souvent modifier le contenu ou utiliser des fonctions déjà disponibles avec des plugins.
Laisser un commentaire