Pourquoi j'ai refait le site de Bee Interactive en Astro

Le site de Bee Interactive tournait sous Laravel depuis mai 2024. Il marchait, il était rapide, personne ne s’en plaignait. Je l’ai quand même réécrit de zéro avec Astro.

Je pourrais trouver de bonnes raisons techniques après coup. La vraie raison est plus simple : j’avais envie de voir comment on travaille ailleurs.

Ce qu’était l’ancien site

Une application Laravel 11 classique : des vues Blade, un peu de Livewire, Tailwind pour le style. Une base de données servait au formulaire de contact. Le blog vivait à part, sur blog.bee-interactive.ch, dans une application Next.js hébergée chez Vercel.

Mais au fond, c’était un site vitrine. Son contenu ne change que quand je le change, dans le code. Chaque visite passait par PHP pour produire une page qui aurait pu être un simple fichier HTML posé sur un serveur. Rien de grave, mais c’est un site statique qui ne le savait pas.

Ce n’est pas un divorce avec Laravel

Je tiens à le dire clairement : je n’ai rien contre Laravel. C’est l’outil avec lequel je travaille tous les jours, celui sur lequel repose Lochness, mon CMS, et la grande majorité des sites de mes clients. Ça ne change pas.

Cette refonte n’est pas une recommandation. Si vous avez un site Laravel qui fonctionne, gardez-le. Je ne suis pas passé à Astro parce que Laravel avait un problème, mais parce que j’avais un terrain de jeu sous la main.

Pourquoi Astro

Astro est un framework JavaScript qui génère des pages HTML au moment de la compilation, avant même que le premier visiteur arrive. Par défaut, il n’envoie aucun JavaScript au navigateur : on ajoute de l’interactivité seulement là où elle sert.

Ce qui m’intéressait, c’était moins l’outil que la manière de penser. Avec Laravel, je raisonne au moment de la requête : un visiteur arrive, le serveur calcule, la page part. Avec Astro, tout se joue au build. Les pages, les images, le plan du site, les métadonnées : tout est prêt d’avance, et le serveur n’a plus qu’à envoyer des fichiers.

C’est aussi changer de langage au quotidien. Après des années de PHP, je passe mes journées sur ce site en TypeScript. Les réflexes ne sont pas les mêmes, les erreurs non plus, et c’est exactement ce que je cherchais.

Ce que j’ai découvert en chemin

Des composants qui ressemblent à du Blade. Un fichier .astro, c’est un bout de code en haut, du HTML en dessous. La prise en main est rapide quand on vient de Blade, et c’est probablement ce qui m’a convaincu de pousser l’essai jusqu’au bout.

Le blog dans le même dépôt que le site. Les articles sont des fichiers Markdown, validés par un schéma au moment du build. J’ai rapatrié les articles de l’ancien blog sur /blog, et le projet Next.js n’a plus de raison d’exister.

Les données au centre. Les projets, les services et les applications sont décrits une seule fois, dans des fichiers TypeScript. Les pages, le plan du site et les données structurées pour les moteurs de recherche sont générés à partir de cette même source. Une modification à un endroit, et tout suit.

Le build comme atelier. C’est la partie que j’ai le plus aimé construire. À chaque compilation, le site génère son sitemap, une image de partage pour chaque page, signale les titres manquants ou en double, et prépare chaque vidéo en plusieurs versions (AV1 et H.264, plusieurs tailles) pour que le navigateur prenne la plus légère qu’il sait lire. Côté images, chaque photo est servie en AVIF ou WebP sans que j’aie à y penser.

Et oui, le Flappy Bird de la page 404 a survécu au déménagement. Testez-le ici.

Ce qui a demandé plus de réflexion

Un site statique n’a pas de serveur derrière lui, et certaines choses allaient de soi avec Laravel.

Le formulaire de contact, par exemple. Il n’y a plus de contrôleur pour recevoir le message : il est envoyé à mon outil de gestion interne, qui s’occupe de l’anti-spam et me prévient. Les redirections des anciennes adresses doivent être pensées en amont. Et le build prend plus de temps qu’avant, surtout quand une nouvelle vidéo doit être encodée.

Rien d’insurmontable, mais ça oblige à se poser des questions que le framework réglait avant pour moi. C’est aussi pour ça que l’exercice valait la peine.

Ce que ça change pour mes clients

Rien, dans l’immédiat. Les sites que je développe continuent de reposer sur Laravel et Lochness, parce qu’ils ont besoin d’un back-office, de contenus mis à jour par le client, de logique métier.

En revanche, j’ai maintenant une deuxième option que je connais de l’intérieur. Pour un site vitrine sans contenu à gérer au quotidien, une page de lancement ou un site d’événement, Astro peut être le bon choix. Je ne l’aurais pas proposé sans l’avoir éprouvé sur mon propre site.

Apprendre là où on peut se tromper

Mon site est le seul projet où je peux changer de technologie sur un coup de tête, me tromper, recommencer, sans que personne d’autre en paie le prix. C’est le meilleur endroit pour apprendre.

Je ne sais pas encore si je garderai Astro dans cinq ans. Mais je sais déjà que je code un peu différemment depuis, y compris en Laravel.