Tenir un pic de trafic viral sans faire tomber son site

Un article qui devient viral, un passage à la télévision, une promotion partagée massivement : en quelques minutes, votre trafic peut être multiplié par dix. Si le site n'est pas préparé, il tombe au pire moment. Voici comment absorber un pic de trafic sans interruption.

Tenir un pic de trafic : ce qui casse en premier

Un pic de trafic ne fait pas « planter » un serveur par magie : il sature un maillon précis de la chaîne. Le plus souvent, c'est l'un de ces trois :

• Le processeur, qui ne suit plus quand chaque requête déclenche un calcul (génération de page, requête en base) ;
• La base de données, qui devient un goulot d'étranglement quand des centaines de visiteurs lancent les mêmes requêtes lourdes ;
• La bande passante ou le serveur web, qui plafonnent sur le nombre de connexions simultanées (voir Espace disque et bande passante).

Identifier le maillon faible avant le pic, c'est déjà la moitié du travail. Un test de charge le révèle en quelques minutes.

Cache de pages et d'images

Le cache est le levier le plus rentable. Si une page peut être servie telle quelle à tous les visiteurs, le serveur la calcule une fois puis la recopie : le processeur et la base de données sont soulagés.

Pour un pic, le cache doit être agressif : mettre en cache des pages entières, pas seulement des fragments, et purger au moment de la publication plutôt que de recalculer à chaque visite. Les images et fichiers statiques, qui représentent souvent l'essentiel du poids d'une page, doivent être mis en cache longtemps. Pour une boutique, cette vitesse se traduit directement en ventes : voir Vitesse d'une boutique en ligne.

CDN : déporter la charge

Le CDN répartit vos contenus sur des serveurs proches des visiteurs, partout dans le monde, et absorbe une grande partie des requêtes. Pour un pic viral, c'est un amortisseur décisif : les images, les fichiers et les pages en cache sont servis par le CDN, pas par votre serveur d'origine.

Le CDN apporte aussi une protection : il filtre le trafic abusif et les robots avant qu'ils n'atteignent votre infrastructure. Sur ce point, consultez Protection anti-DDoS : comprendre et se protéger.

Serveurs ajoutés à la demande

Quand le cache et le CDN ne suffisent plus, il faut ajouter de la puissance de calcul. Deux approches :

• Redimensionner un serveur unique (monter en CPU et en RAM) : simple, mais limité par la machine et par le temps de l'opération.
• Ajouter des serveurs derrière un répartiteur de charge : plusieurs serveurs web identiques se partagent le trafic ; on en ajoute un pour absorber un pic, on le retire ensuite.

La seconde approche est celle des architectures haute disponibilité. Atlas Hoster conçoit et déploie des architectures redondantes — répartiteur, plusieurs serveurs web, cache, base de données répliquée, CDN — et ajoute des serveurs à la demande pour un pic. Voir l'offre haute disponibilité.

Tests de charge avant l'événement

On ne devine pas la tenue d'un site sous charge : on la mesure. Un test de charge simule des centaines ou des milliers de visiteurs simultanés et montre ce qui plie en premier — le temps de réponse, le taux d'erreur, la base ou le processeur.

Atlas Hoster réalise ces tests avec des outils comme k6 ou Locust avant un lancement ou une opération commerciale, et corrige ce qui limite : cache, requêtes, dimensionnement. La méthode complète est décrite dans Test de charge : valider son site avant un pic de trafic.

Surveiller et réagir en temps réel

Pendant le pic, il faut voir ce qui se passe, pas le découvrir après coup. Une supervision continue — charge du processeur, mémoire, disque, temps de réponse — permet de réagir avant la panne : ajouter un serveur, étendre le cache, écarter un serveur qui ne répond plus.

C'est la différence entre une infrastructure qui « tient » et une infrastructure tenue par une équipe qui surveille. Pour les sites d'actualité et les médias, ce sujet est détaillé dans Héberger un site d'actualité ou média à fort trafic. La surveillance sert aussi à distinguer un pic légitime d'une attaque : une vague de requêtes peut être l'un ou l'autre, et le pare-feu applicatif fait le tri. Pour bloquer une adresse IP ou un domaine suspect, consultez Bloquer une adresse IP ou domaine. Voir aussi notre article sur la protection anti-DDoS.

Préparer une opération commerciale

Un pic ne se subit pas : il se prépare. Si vous savez qu'une opération va générer du trafic — promotion, lancement, passage média —, voici la marche à suivre :

1. Estimer le pic attendu : combien de visiteurs en pointe, sur quelles pages.
2. Tester en charge : simuler ce pic et corriger ce qui plie, avant l'événement.
3. Mettre en cache : les pages d'atterrissage et les images doivent être servies par le cache et le CDN.
4. Prévoir la marge : ajouter un serveur ou augmenter les ressources à l'avance, pas pendant le pic.
5. Surveiller : suivre la charge en temps réel et définir qui intervient si un seuil est franchi.

Le but n'est pas de tout prévoir, mais de ne pas être pris au dépourvu : un site préparé encaisse un pic de trafic sans que personne ne s'en aperçoive. C'est exactement la méthode d'Atlas Hoster pour les boutiques, les médias et les applications : conception, déploiement, test de charge, puis exploitation avec astreinte. Le détail de l'approche est présenté sur la page haute disponibilité. Pour les sites d'actualité, voir aussi Héberger un site d'actualité ou média à fort trafic.

FAQ

Combien de visiteurs simultanés un site classique peut-il tenir ?

Cela dépend entièrement du site, de son code et de son serveur. Il n'y a pas de chiffre universel : c'est précisément ce qu'un test de charge mesure pour votre cas.

Le CDN suffit-il à tenir un pic ?

Pour des contenus largement statiques, souvent oui. Dès que chaque visite déclenche du calcul ou un accès en base (panier, recherche, compte), il faut aussi du cache applicatif et de la puissance de calcul.

Faut-il surdimensionner en permanence pour un pic rare ?

Non. Mieux vaut une architecture qui s'étend à la demande, quitte à ajouter puis retirer des serveurs, plutôt que de payer toute l'année pour un pic de quelques heures.