Vendredi 9 h 00 : ouverture des inscriptions pour un colloque de 800 places. À 9 h 03, le site affiche une erreur 503. À 9 h 15, les réseaux sociaux reprennent déjà les captures d'écran. L'équipe comms panique, l'équipe technique redémarre Apache « pour voir », et personne n'a testé la page de paiement sous charge réelle.
Un site événementiel n'est pas un blog qui grossit progressivement. C'est une fenêtre de trafic compressée — parfois quelques minutes — que vous ne pourrez pas rejouer. La bonne question n'est donc pas « quel hébergeur est le meilleur ? », mais quelle page doit absolument tenir, à quelle heure, et avec quel plan B visible ?
Cartographier le jour J avant de choisir l'offre
Commencez par séparer les flux :
| Flux | Charge typique | Tolérance à la panne |
|---|---|---|
| Pages info (programme, intervenants) | Forte, surtout en lecture | Moyenne — une page statique de secours suffit |
| Inscription / billetterie | Pic extrême, écritures DB | Nulle — c'est le cœur métier |
| Espace participant (badge, PDF) | Modérée, après achat | Faible |
| API partenaires / scan entrée | Variable | Faible le jour de l'événement |
Ensuite, chiffrez le pire scénario crédible : combien de requêtes simultanées à l'ouverture ? Combien d'écritures en base par seconde ? Une billetterie avec file d'attente virtuelle n'a pas les mêmes besoins qu'un simple formulaire Google Forms embarqué.
Le dimensionnement utile part du premier clic qui fait peur, pas de la moyenne mensuelle Analytics.
Architecture : séparer ce qui doit tenir de ce qui peut attendre
Trois patterns qui fonctionnent sur le terrain :
1. Pages vitrine en cache agressif + back-office isolé. Programme, FAQ, plan d'accès : servis en statique ou via CDN avec TTL long. La billetterie tourne sur un sous-domaine ou un service dédié avec pool de connexions et sessions Redis.
2. File d'attente explicite. Mieux vaut afficher « vous êtes n° 847 » avec un site stable qu'un spinner infini suivi d'un 503. Des solutions comme une page statique + token JWT ou un service de queue dédié évitent de faire exploser PHP-FPM d'un coup.
3. Montée en charge temporaire. Sur cloud (OVH Public Cloud, Scaleway, Hetzner Cloud), préparez une image ou un snapshot, un script de scale-out, et surtout un retour à la normale automatisé — sinon vous payez trois serveurs jusqu'en décembre pour un événement de juin.
Hébergement : mutualisé, VPS ou cloud élastique ?
| Profil événement | Produit cohérent | Pourquoi |
|---|---|---|
| Conférence < 500 places, formulaire simple | VPS modeste + CDN | Contrôle cron, PHP, Redis |
| Festival, billetterie tierce (Eventbrite, Weezevent) | Mutualisé ou statique | La charge critique est externalisée |
| Billetterie maison, pic > 1000 req/s | Cloud + load balancer | Élasticité et isolation DB |
| Live streaming intégré | CDN vidéo + origine séparée | Le flux vidéo ne doit pas partager PHP-FPM |
Le mutualisé échoue le plus souvent sur trois limites : connexions MySQL simultanées, workers PHP-FPM, et absence de montée en charge rapide. Ce n'est pas une question de « mauvaise volonté » de l'hébergeur — c'est un modèle pensé pour un trafic lissé.
Observabilité et runbook : le jour J ne se improvise pas
Deux semaines avant, fixez :
- Qui regarde quoi : CPU, latence TTFB, erreurs 5xx, taille file MySQL, connexions Redis.
- Seuils d'alerte avec numéros de mobile, pas seulement des emails.
- Runbook écrit : « si 503 > 2 min → activer page statique / désactiver recherche / augmenter workers ».
- Fenêtre gel code : aucun déploiement la veille, sauf hotfix validé.
Testez la restauration d'une sauvegarde de base — pas « nous faisons des backups », mais « voici le temps pour remonter la billetterie à 8 h 55 ».
Le sommet : le pic est prévisible, la panne ne doit pas l'être
La promesse « hébergement illimité » ne remplace ni le test de charge, ni la file d'attente, ni la page de secours. Le prestige du datacenter compte moins que la cartographie du premier quart d'heure.
Décider et avancer sans angle mort
- Identifiez la page unique qui ne doit pas tomber (souvent paiement ou validation d'inscription).
- Mettez le reste en cache ou en statique au moins 72 h avant l'ouverture.
- Charge-testez cette page avec un scénario réaliste (pas un ab test sur la home).
- Documentez le plan B : page statique, message comms, prolongation d'ouverture des ventes.
- Prévoyez la descente : scale-down, facturation, archivage des logs.
Comparez les offres élastiques dans notre annuaire et le comparateur. Pour le volet cache, voir Cache de page dynamique : décider ce qui peut réellement être mis en cache.
Questions fréquentes
Faut-il surdimensionner le serveur toute l'année pour le jour J ?
Non. Utilisez cache, CDN, montée en charge temporaire ou architecture élastique pour le pic, puis revenez à un coût normal.
Le mutualisé suffit-il pour un site événementiel ?
Rarement pour billetterie ou ouverture d'inscriptions concentrée. Un VPS, du cloud élastique ou une page statique + API séparée est plus réaliste.
Quand activer le CDN pour un événement ?
Dès que les pages d'information sont stables — plusieurs semaines avant. Le jour J, vous surveillez, vous ne configurez plus.
Que tester avant l'ouverture des ventes ?
Test de charge sur la page critique, simulation de panne base, procédure de bascule vers une page statique documentée.
Un événement ne vous laisse qu'une prise. Dimensionnez pour ce quart d'heure — et dormez la veille parce que le runbook est écrit, pas parce que le serveur est surdimensionné toute l'année.