Six semaines. C’est le temps qui restait avant l’ouverture de la billetterie de la prochaine édition d’un festival de théâtre de rue itinérant, quand l’équipe organisatrice nous a contactés. Le site Wix existant plantait régulièrement lors des pics de trafic liés aux annonces de programmation, et la personne qui l’administrait avait quitté l’association sans laisser de documentation sur sa configuration.
Le brief tenait en une phrase : un site capable d’encaisser un pic de visites le jour de l’annonce de la programmation, sans jamais retomber, et prêt avant la date fixée par le conseil d’administration. Aucune marge de négociation sur le calendrier n’était possible, l’ouverture de la billetterie étant elle-même calée sur des contraintes de partenaires publics.
Pourquoi Wix ne tenait plus la charge
Wix n’est pas conçu pour un pic de trafic soudain et concentré sur quelques heures : sa mutualisation d’hébergement privilégie la stabilité moyenne plutôt que la pointe. Lors de l’édition précédente, l’annonce de la programmation avait fait tomber le site pendant près de deux heures, un désastre en termes d’image pour un événement culturel suivi par la presse régionale.
L’autre problème, plus structurel, tenait à l’absence d’export propre du contenu. Wix ne propose pas d’API REST publique permettant de récupérer les pages, les fiches spectacles ou les biographies des compagnies dans un format structuré. Il a fallu reprendre chaque contenu à la main, compagnie par compagnie, ce qui a mobilisé une bonne partie de la première semaine.
Le choix d’un front entièrement statique
Face au délai, la question du framework front s’est réglée vite : plutôt qu’un rendu à la demande, nous avons opté pour une génération statique complète au moment du build, avec Eleventy consommant l’API REST de WordPress. Chaque page HTML est pré-calculée et livrée depuis un CDN, ce qui élimine tout risque de surcharge côté serveur au moment de l’annonce de programmation.
Les types de contenus ont été limités au strict nécessaire pour tenir les délais : spectacle, compagnie, lieu, et page d’information pratique. Chacun déclaré simplement avec register_post_type() et show_in_rest activé, sans champ personnalisé superflu.
register_post_type( 'spectacle', array(
'label' => 'Spectacles',
'public' => true,
'show_in_rest' => true,
'rest_base' => 'spectacles',
'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
'has_archive' => true,
) );Ce que le délai a obligé à écarter
La billetterie en ligne ne fait pas partie de ce chantier : le festival utilisait déjà un prestataire spécialisé pour la vente de billets, intégré par un simple lien externe depuis le site. Retravailler cette intégration en six semaines aurait mis en péril le reste du projet, la décision a donc été de la laisser fonctionner exactement comme avant, en dehors du périmètre headless.
Le déroulé des six semaines
- Semaine 1 : reprise manuelle du contenu Wix, création de la structure WordPress
- Semaine 2 : mise en place des types de contenus et des endpoints REST
- Semaines 3 et 4 : construction du front Eleventy et des gabarits de fiches spectacles
- Semaine 5 : import des visuels, relecture éditoriale, tests de charge simulés
- Semaine 6 : mise en ligne progressive, redirections depuis les anciennes URLs Wix
Le point le plus tendu a été la semaine 5 : un test de charge simulant l’affluence de l’annonce précédente a révélé que le CDN choisi initialement limitait le nombre de requêtes simultanées sur son offre gratuite. Un changement de plan d’hébergement en urgence a évité de reproduire l’incident de l’année passée.
Un délai court n’autorise pas à sauter les tests de charge : c’est justement quand le temps manque qu’une panne coûte le plus cher, parce qu’il n’en reste plus pour la corriger avant l’échéance.
Le jour de l’annonce
Le site a tenu sans ralentissement mesurable pendant le pic de consultation, avec un nombre de visiteurs simultanés supérieur à celui de l’édition précédente. Aucune page n’a dépassé une seconde de temps de réponse, un résultat qui aurait été difficile à atteindre avec un rendu dynamique classique dans le délai imparti.
Notre verdict
Ce projet illustre un cas où le headless n’a pas été choisi pour des raisons de flexibilité front ou de séparation des équipes, mais simplement parce qu’un front statique était la façon la plus sûre de tenir un pic de charge dans un délai serré. WordPress a servi d’outil d’édition pour l’équipe, sans jamais intervenir dans le rendu final des pages consultées par le public. Une répartition des rôles simple, qui a permis de respecter l’échéance sans compromis sur la stabilité.
