Migration
Migrer de Gulp à Astro
Notes sur le passage du workflow frontend hérité à Astro.
Refonte WordPress avec Astro : le frontend de pro(G, pensé pour évoluer.
Refonte WordPress avec Astro : migrer un ancien thème vers une architecture Astro moderne, en préservant le workflow éditorial, le SEO et la maintenabilité à long terme.
Défi
Migrer vers Astro un frontend Gulp hérité, étroitement couplé à WordPress, sans interrompre la production ; permettre la prévisualisation des contenus non publiés sur un frontend statique ; et réduire la dépendance aux plugins WordPress pour les formulaires et les performances.
Solution
Reconstruire le frontend avec Astro et TypeScript, reconnecter WordPress via WPGraphQL, et mettre en place deux déploiements Vercel séparés, Production (statique) et Preview (SSR), pour la prévisualisation des éditeurs.
Résultat
Un frontend plus rapide, moins de plugins WordPress, une architecture plus propre, un workflow de déploiement amélioré, et une production qui reste disponible même si le back-office ne l’est pas.
Résumé
Le projet est parti d’une occasion d’explorer un framework frontend moderne, tout en gardant en vie un site déjà en production.
Plutôt que de refaire le design du site, l’objectif était de reconstruire ses fondations techniques et de créer un frontend plus facile à faire évoluer dans le temps.
Contexte
L’ancien frontend reposait sur un workflow Gulp vieillissant, étroitement couplé à WordPress.
Avec le temps, la dette technique s’est accumulée et la maintenance du frontend est devenue plus difficile.
Les performances dépendaient souvent de plugins WordPress supplémentaires, alors que je voulais réduire cette dépendance et aller vers une architecture plus propre et plus maintenable.
Défis
Migrer un frontend Gulp hérité vers Astro tout en apprenant un framework entièrement nouveau.
Concevoir un système de prévisualisation permettant aux éditeurs de voir leurs contenus non publiés, malgré un frontend statique.
Repenser la gestion des formulaires en quittant les plugins WordPress pour des services basés sur des API.
Choix techniques
Le choix d’Astro
Plutôt que Next.js ou Nuxt, j’ai choisi Astro, parce que sa philosophie rejoignait ma propre approche du développement frontend.
Envoyer le moins de JavaScript possible par défaut, une excellente génération statique et une architecture tournée vers la performance : c’était le bon choix pour ce projet.
Architecture de prévisualisation
Comme Astro génère des pages statiques, la prévisualisation classique de WordPress ne pouvait pas être utilisée.
J’ai conçu un workflow de prévisualisation dédié, basé sur deux déploiements :
- Production (statique)
- Preview (SSR)
Des déploiements Vercel séparés et des variables d’environnement ont permis aux éditeurs de prévisualiser leurs contenus non publiés, tout en gardant la production entièrement statique.
Démarche
- 1
Construire la nouvelle base Astro.
Réutiliser les styles existants tout en reconnectant le frontend à WordPress via WPGraphQL.
- 2
Concevoir une architecture de prévisualisation sur mesure.
Mettre en place des environnements Production et Preview séparés sur Vercel, chacun avec sa stratégie de rendu.
Stack technique
- Astro
- TypeScript
- Tailwind CSS
- WordPress
- Headless WordPress
- WPGraphQL
- Cloudflare
- Vercel
- GitHub
- Cursor
Résultats
- Un frontend nettement plus rapide.
- Une dépendance bien moindre aux plugins WordPress.
- Une architecture plus propre et plus maintenable.
- Un workflow de déploiement amélioré.
- Une meilleure sécurité, grâce à la séparation complète du frontend et du CMS.
- La production reste disponible même si le back-office devient indisponible.
Carnet
Prévisualisation
Construire une architecture de prévisualisation sur mesure
Notes sur les déploiements séparés : Production statique et Preview en SSR.
Couche de contenu
Connecter Astro à WPGraphQL
Notes sur la reconnexion du frontend à WordPress via WPGraphQL.
Architecture
Réduire les dépendances à WordPress
Notes sur le transfert de responsabilités frontend des plugins vers des services basés sur des API.
