Passer à la télé sans que votre site tombe.
Une émission, un article de presse, une campagne : des milliers de visiteurs arrivent en quelques minutes. La plupart des sites n'y survivent pas — c'est prévisible, mesurable, et ça se prépare.
Trente secondes d'antenne, deux minutes de répit
Le scénario est toujours le même. Votre entreprise est citée dans Capital, passe dans Qui veut être mon associé ?, fait l'objet d'un sujet au journal régional ou d'un article dans la presse nationale. Pendant la diffusion, une partie des téléspectateurs sort son téléphone et tape le nom de votre entreprise. Deux à trois minutes plus tard, la vague atteint votre site : selon l'audience de l'émission et l'heure de diffusion, cela représente de quelques milliers à plusieurs dizaines de milliers de visites — dont l'essentiel concentré sur les dix premières minutes.
C'est précisément le trafic le plus précieux que votre site recevra de l'année : des visiteurs qui vous cherchent activement, au moment exact où votre notoriété est à son maximum. Et c'est le moment que choisissent la plupart des sites pour afficher une erreur 503, une page blanche, ou un chargement de trente secondes qui revient au même — au-delà de quelques secondes d'attente, la majorité des visiteurs abandonne.
L'ironie est cruelle : l'opération de communication a souvent coûté des mois de préparation, parfois le budget d'une campagne entière, et c'est le maillon technique — celui qui se règle en quelques jours — qui annule tout. Un passage TV ne se rejoue pas. La préparation du site devrait figurer dans la checklist de l'opération au même titre que le communiqué de presse.
Pourquoi les sites tombent
Un pic de trafic événementiel n'a rien à voir avec une croissance progressive : la courbe est verticale. Un site qui reçoit 200 visites par jour peut en recevoir 200 par seconde pendant un quart d'heure. Quatre goulots d'étranglement cèdent presque toujours dans le même ordre.
⚙️Les processus PHP
Chaque visiteur d'un site dynamique (WordPress, Presta…) mobilise un processus PHP le temps de générer sa page. Le nombre de processus simultanés est plafonné : au-delà, les visiteurs font la queue, puis reçoivent une erreur. C'est le premier maillon qui cède.
🧮La base de données
Une page WordPress non cachée déclenche des dizaines de requêtes SQL. Multipliez par des centaines de visiteurs simultanés : la base sature ses connexions, les temps de réponse s'allongent, et tout ce qui attend la base s'effondre en cascade.
🚦Les limites de l'hébergeur
Sur un mutualisé, des quotas (CPU, processus, I/O) protègent les autres clients du serveur. Ils sont invisibles au quotidien — et se déclenchent précisément au moment où vous avez besoin de toute la machine.
🔁L'effet d'avalanche
Un site lent aggrave son propre cas : les visiteurs rechargent la page, les navigateurs réessaient, les requêtes s'empilent. Un serveur à 90 % de charge peut passer à 300 % en quelques secondes uniquement à cause des ré-essais.
Le point commun de ces quatre goulots : ils ne se manifestent presque jamais en fonctionnement normal. C'est pour cela qu'un site « qui marche très bien » depuis des années n'est en rien une garantie pour le jour J — il n'a simplement jamais été soumis à la charge.
Les ordres de grandeur
Les chiffres exacts dépendent de la stack et de la machine, mais les ordres de grandeur de visiteurs simultanés tenables sont bien établis — et l'écart entre les lignes de ce tableau explique toute notre méthode.
| Configuration | Visiteurs simultanés (ordre de grandeur) | Pourquoi |
|---|---|---|
| Mutualisé, CMS sans cache | quelques dizaines | Chaque visiteur exécute PHP + SQL ; les quotas de l'hébergeur tombent vite |
| Serveur dédié, CMS avec cache pleine page | quelques centaines à quelques milliers | PHP est sorti du chemin ; la limite devient le serveur web et la RAM |
| Page statique + CDN | dizaines de milliers et au-delà | Des fichiers servis tels quels, répliqués au plus près des visiteurs |
La méthode, étape par étape
La préparation idéale démarre un mois avant la diffusion. Le calendrier ci-dessous est celui que nous suivons ; il se compresse si l'échéance est plus proche, en concentrant l'effort sur ce qui protège le plus.
- J-30 → J-15
1. Audit de capacité et test de charge
On commence par mesurer, pas par supposer. Un test de charge progressif établit combien de requêtes par seconde votre site tient réellement, et surtout quel composant cède en premier : processus PHP, base de données, bande passante ou quota d'hébergement. Ce chiffre, comparé à l'estimation du pic attendu, dicte toute la suite : simple optimisation, renfort temporaire de la machine, ou architecture à plusieurs frontaux.
- J-15 → J-7
2. Optimiser, cacher, dimensionner
La règle d'or : plus une requête est servie tôt dans la chaîne, moins elle coûte. Cache pleine page pour que PHP ne soit sollicité qu'une fois par version de page, CDN pour servir images et ressources au plus près des visiteurs, compression des images. Si l'écart avec la cible reste trop grand, on renforce l'infrastructure pour la période : montée en gamme temporaire du serveur, ou répartition de charge sur plusieurs frontaux pour les cas exigeants. Le sur-dimensionnement ne dure que quelques jours — son coût reste marginal comparé au budget de l'opération de communication.
- J-7
3. Page de secours et validation
On prépare le plan B avant d'en avoir besoin : une page d'atterrissage 100 % statique — votre message, votre offre, un moyen de vous contacter — hébergée séparément et capable d'encaisser des dizaines de milliers de visiteurs simultanés. Le TTL DNS est abaissé pour permettre une bascule rapide. Puis on rejoue le test de charge sur l'installation finale, à deux fois le pic estimé : si ça tient à ×2, la marge est réelle.
- Jour J
4. Supervision humaine pendant la diffusion
Un pic de trafic ne prévient pas : entre la citation à l'antenne et le sommet de la vague, il s'écoule deux à trois minutes. Pendant la diffusion, les métriques sont suivies en direct — requêtes par seconde, temps de réponse, charge CPU, connexions à la base — avec des seuils décidés à froid, à l'avance. Si un seuil est franchi, la bascule vers la page de secours est immédiate. Un humain devant les courbes prend cette décision en secondes ; un client qui découvre la panne la prend en minutes, trop tard.
- J+1
5. Redescente et bilan chiffré
Le lendemain, on redescend l'infrastructure à son échelle normale pour couper les coûts du renfort, et on livre un bilan : courbe de trafic, pic réel constaté, taux d'erreur (idéalement zéro), pages les plus vues, provenance des visiteurs. Ces chiffres servent aussi à préparer la prochaine opération — rediffusion, replay, reprise presse — qui génère souvent une seconde vague.
L'arme absolue reste la page statique.
Toute notre méthode converge vers un principe simple : le jour J, ce que voient les visiteurs doit être du HTML statique servi tel quel, sans exécution de code ni requête en base. Un fichier statique derrière un serveur web correctement configuré — a fortiori derrière un CDN — encaisse des dizaines de milliers de visiteurs simultanés sur une machine modeste. C'est la même conviction technique qui fonde nos sites statiques sécurisés.
Concrètement, deux mises en œuvre. Soit une page d'atterrissage dédiée à l'événement : votre message, l'offre annoncée à l'antenne, un formulaire de contact ou de capture d'email — souvent plus efficace commercialement que la page d'accueil générique, en plus d'être insubmersible. Soit la statification temporaire des pages clés du site existant, le back-office restant accessible à part. Dans les deux cas, le site dynamique complet reprend la main une fois la vague passée.
Questions fréquentes
Combien de visiteurs faut-il prévoir après un passage TV ?
Il n'existe pas de chiffre universel : tout dépend de l'audience de l'émission, de l'heure de diffusion et de la manière dont votre marque est citée. L'ordre de grandeur constaté va de quelques milliers à plusieurs dizaines de milliers de visites dans l'heure qui suit, dont l'essentiel concentré sur les dix premières minutes. La bonne pratique est de dimensionner pour un scénario haut (par exemple dix fois l'estimation médiane) : servir du contenu statique rend ce sur-dimensionnement peu coûteux.
Mon hébergement mutualisé suffira-t-il ?
Presque jamais en l'état. Un hébergement mutualisé applique des limites de ressources (processus PHP simultanés, CPU, connexions à la base) précisément pour protéger les autres clients du serveur. Un site WordPress sans cache y tient typiquement quelques dizaines de visiteurs simultanés. Deux issues : mettre en place un cache pleine page et une page d'atterrissage statique, ou basculer temporairement sur une infrastructure dimensionnée pour l'événement.
Combien de temps faut-il pour se préparer ?
L'idéal est un mois : le temps de mesurer la capacité réelle, de corriger les goulots d'étranglement et de valider par un test de charge. En une semaine, on met en place le cache, la page statique de secours et la supervision. En 48 heures, on ne fait plus d'architecture : on prépare une page statique capable d'encaisser le pic et un plan de bascule — c'est court, mais cela évite l'écran d'erreur.
Et si le pic dépasse les prévisions le jour J ?
C'est exactement le rôle de la supervision humaine pendant la diffusion : les métriques (requêtes par seconde, temps de réponse, saturation CPU et base de données) sont suivies en temps réel, avec des seuils d'alerte définis à l'avance. Si un seuil est franchi, la bascule vers la page statique de secours est déclenchée en quelques secondes : les visiteurs voient votre message et votre offre, pas une erreur 503.
Une diffusion prévue ?
Indiquez-nous la date, l'audience attendue et l'adresse de votre site : nous revenons sous 48 h ouvrées avec un plan de préparation chiffré. Plus l'échéance est proche, plus vite il faut commencer.
Des méthodes éprouvées à grande échelle
Bistrot Web, c’est une activité que je mène en direct. En parallèle, j’exerce depuis plus de dix ans comme directeur technique et administrateur système chez l’hébergeur o2switch, où j’administre au quotidien plus de 1 500 serveurs répartis sur deux datacenters. Les procédures que j’applique à votre serveur — supervision, sauvegardes vérifiées, durcissement, bascule — sont celles d’un environnement où l’indisponibilité n’est pas une option.
- +1 500
- serveurs administrés au quotidien
- 2
- datacenters exploités et maintenus
- +10 ans
- directeur technique chez o2switch
Technologies opérées en production
- Linux
- Nginx
- Apache
- MariaDB / Galera
- HAProxy
- Kubernetes
- TrueNAS
- Stockage objet S3
- restic / borg
Explorer le pôle infogérance & haute disponibilité
Infogérance de serveur
Supervision, mises à jour, sauvegardes testées, durcissement et réponse à incident.
Exploitation & supervisionReprise d’infogérance
Vous changez d’infogéreur ? On reprend l’existant, même sans documentation ni accès complets.
Depuis un autre prestataireHaute disponibilité
SPOF, redondance, failover, RTO/RPO : supprimer les points de panne uniques.
Concepts & architectureHA des frontaux web
Répartition de charge, health checks, VIP flottante, frontaux stateless.
Load balancing & failoverHA de la base de données
Réplication, failover automatique, cluster Galera, read/write split.
Réplication & basculeHA du stockage
Stockage partagé/répliqué, objet S3, sauvegardes 3-2-1, redondance géo.
Fichiers & données répliqués