En janvier 2024, j’ai convaincu un client — un cabinet de conseil lyonnais avec un site WordPress vieillissant — de passer sur Astro. Pas parce que c’était à la mode. Parce que leur site prenait 8 secondes à charger, que l’éditeur de contenu était un champ de mines de plugins en conflit, et que moi j’en avais assez de déboguer du PHP des années 2015.
Six mois en production. Voilà ce que j’en retire.
Ce qui a fonctionné sans surprise
La vitesse, évidemment. Un site statique bien construit, ça charge vite. On est passé de 38 au PageSpeed mobile à 94. Le client a arrêté d’en parler au bout d’une semaine parce que c’était devenu tellement évident que c’était même plus un sujet.
Le déploiement. Pipeline GitLab CI, rsync sur le serveur. La mise en prod d’une modification de contenu prend 90 secondes. Avant, c’était une opération à risque avec FTP et des doigts croisés.
Le coût d’hébergement. On est passé d’un mutualisé OVH à 15€/mois à un VPS que je partage entre plusieurs clients. Le client paie moins, j’ai plus de contrôle. Tout le monde est content.
Ce qui m’a surpris (en bien)
Le fait que le client ait appris à écrire du Markdown en deux séances. Je pensais que ce serait le point de friction principal. En réalité, dès qu’ils ont compris que c’était juste du texte avec quelques ** et #, ils ont adopté ça sans résistance. L’interface GitHub pour éditer les fichiers directement, avec la prévisualisation Markdown native, a beaucoup aidé.
L’autre surprise : la durabilité. Aucune mise à jour de plugin à gérer, aucune faille WordPress à patcher en urgence un vendredi soir. Le site tourne, tranquille.
Ce qui a été galère
Les formulaires. Le formulaire de contact. C’est stupide, mais j’ai sous-estimé le temps que ça prendrait. Avec WordPress, tu mets Contact Form 7 et c’est réglé. Avec Astro statique, tu dois choisir : service tiers (Formspree, Basin…), une Netlify Function, ou une API maison. J’ai fini avec un endpoint sur mon propre serveur Express. Ça marche, mais j’ai perdu deux jours sur quelque chose de basique.
Convaincre l’équipe IT du client. Leur DSI voulait rester sur WordPress parce que “on sait maintenir”. J’ai dû défendre le choix technique en réunion, expliquer que non, Astro ce n’est pas “juste pour les développeurs”, que oui, c’est maintenable par quelqu’un d’autre que moi. Ce travail de conviction, personne ne me l’a payé. C’est du non-facturé que j’aurais dû anticiper.
Ce que je referai pareil
Tout le reste. La stack Astro + Markdown + Git pour le contenu, c’est exactement ce qu’il faut pour un site vitrine qui doit durer sans maintenance permanente. Le client est autonome pour les contenus, moi je ne reçois plus d’appels paniqués pour des mises à jour de plugins.
Je n’aurais pas choisi Next.js pour ce projet. Trop lourd, trop de JS côté client pour ce besoin précis. Astro a la bonne philosophie : envoyer le moins de JS possible au navigateur, générer statiquement ce qui peut l’être, et rester flexible pour le reste.
Si c’était à refaire, je facturerai les séances de formation Markdown et Git comme une prestation à part entière, pas comme un bonus gratuit. Et je prévoirai une ligne “infrastructure formulaires” dans le devis.
Si tu travailles sur un projet similaire et que tu veux en parler — écris-moi.