Astro ou Inertia : quel socle pour un site de contenu ?

« Astro ou Inertia ? » La question nous revient à chaque nouveau projet, et notre premier réflexe, chez Netilpa, est toujours de la reformuler. Ce ne sont pas deux frameworks rivaux : ce sont deux visions du web qu’un accident de vocabulaire met parfois face à face. L’un pense un site comme une application — un serveur, une base de données, des sessions. L’autre le pense comme un document : des fichiers, du texte balisé, du HTML livré déjà prêt. Choisir, pour nous, ce n’est pas comparer des performances, c’est décider ce qu’est, au fond, le projet de notre client.

Deux philosophies avant deux technologies

Inertia, adossé à Laravel et React, résout un problème précis et le résout admirablement : construire une application riche sans écrire d’API. On conserve les contrôleurs, les routes et les modèles Eloquent côté serveur ; Inertia projette les données dans des composants React sans qu’aucune couche REST ne s’intercale. Ses auteurs parlent d’un « monolithe moderne », et l’expression est juste : c’est le socle du tableau de bord, de l’espace client, du back-office.

Astro raisonne à l’envers. Son pari fondateur tient en une formule — zéro JavaScript par défaut — et en une idée d’architecture, les islands : la page est du HTML statique, seuls les rares fragments réellement interactifs embarquent du script, hydratés isolément. Pour un article, une page « à propos », une documentation, c’est une évidence structurelle : il n’y a rien à faire tourner, donc rien à envoyer.

Ce qu’Inertia fait mieux, et personne d’autre

Soyons honnêtes : sur son terrain, Inertia est difficile à battre, et nous l’employons sans hésiter. Un seul critère le convoque : l’état. Un utilisateur connecté, un panier, des droits, des données qui changent d’une seconde à l’autre — dès qu’il y en a, le rendu statique devient un mensonge. On ne met pas en cache un solde bancaire ni une liste de commandes personnelles.

Prenez un SaaS de facturation, une plateforme de réservation, un espace membre : chaque écran dépend de qui regarde, et de quand. La boucle courte d’Inertia — le contrôleur interroge la base, renvoie les props, React affiche — nous épargne alors des semaines de plomberie : pas d’API à versionner, pas de logique métier dupliquée entre back et front, une authentification native via Fortify ou les starter kits Laravel. C’est cohérent, rapide à produire pour nos clients, et cela vieillit bien parce que la vérité reste au seul endroit sensé : le serveur. Le bâtir en pur statique serait un contresens : on réimplanterait à la main un serveur d’application dans des fonctions edge, avec moins de garanties et plus de dettes.

Pourquoi le statique gagne sur un site de contenu

Renversons la scène. Une revue, un blog d’entreprise, une documentation, un site vitrine : le contenu est écrit une fois, lu des milliers de fois, et ne dépend pas du visiteur. Le servir depuis une application qui interroge une base à chaque requête, c’est allumer un moteur diesel pour traverser la rue.

Le statique répond point par point. Le HTML pré-généré arrive complet, indexable sans exécuter la moindre ligne de script — atout décisif là où le budget de crawl et le temps jusqu’au premier octet pèsent lourd, pour Google comme pour les moteurs de réponse qui alimentent les IA. Pas de base à maintenir, donc une surface d’attaque quasi nulle et un hébergement trivial sur un CDN. Et surtout, les articles vivent dans des fichiers Markdown versionnés par Git, relus en pull request comme du code : pour une rédaction, ce flux — écrire, réviser, fusionner — vaut tous les back-offices.

Ce magazine en est la démonstration la plus directe. Kunavi, que vous lisez à l’instant, nous l’avons bâti en Astro — précisément parce qu’il coche toutes les cases du site de contenu à fort enjeu SEO et GEO. Aucune authentification, aucun état, mais des articles qui doivent se charger instantanément et se faire trouver, par les moteurs classiques comme par les IA génératives. Y faire tourner un serveur applicatif n’aurait rien apporté.

Pour un site éditorial, la base de données n’est pas une fonctionnalité : c’est une charge que l’on s’inflige sans contrepartie.

Comment nous tranchons, projet par projet

Le statique n’est pas pour autant une religion. Deux réserves méritent d’être posées. D’abord l’échelle de publication : un site de dix mille pages regénéré à chaque coquille corrigée impose des builds longs, et c’est là que le rendu à la demande et le cache incrémental d’Astro reprennent la main. Ensuite l’hybridation, car la frontière n’est pas étanche : un site Astro peut parfaitement héberger une île interactive — recherche, commentaires, espace abonné — adossée à une API Laravel. Le contenu reste statique, l’interactif reste circonscrit.

Voilà, au fond, notre méthode. Nous ne partons pas d’un framework favori pour y plier le projet ; nous partons du besoin du client pour choisir le socle qu’il exige. Application à état, authentification, données vivantes ? Inertia et Laravel, sans détour. Contenu éditorial, référencement, longévité, coût d’exploitation ? Astro, et il gagne largement. Le plus souvent, la bonne réponse s’impose dès la première conversation — à condition de se la poser avant d’écrire la première ligne de code. C’est ce cadrage que nous menons en amont de chaque projet ; si vous hésitez sur le socle du vôtre, c’est exactement la discussion que nous aimons avoir.