Un traiteur qui couvre les mariages d’une région entière connaît un calendrier très particulier : les demandes de devis, les visites virtuelles de salles et les téléchargements de plaquettes se concentrent presque exclusivement entre avril et septembre, avec des pointes le samedi matin quand les couples comparent plusieurs prestataires avant de se décider. Le reste de l’année, le site fonctionne comme une simple vitrine consultée au compte-gouttes.
Ce profil de trafic pose un problème classique de dimensionnement : un serveur taillé pour les samedis de juin est très largement surdimensionné en janvier, et un serveur taillé pour janvier s’effondre en juin. Entre les deux, la bonne réponse n’est pas un compromis fixe mais une infrastructure capable de respirer avec la saison.
Identifier ce qui charge vraiment le serveur
Avant de dimensionner quoi que ce soit, il faut savoir ce qui consomme réellement des ressources. Sur ce type de site, ce n’est presque jamais l’affichage des pages de prestations, qui sont majoritairement statiques et se prêtent bien au cache de pages complètes. Le point de tension se situe ailleurs :
- le formulaire de devis, qui déclenche une requête d’écriture en base à chaque soumission et souvent l’envoi d’un e-mail de confirmation via
wp_mail(); - la galerie photo des prestations passées, chargée en haute résolution et consultée en boucle par les visiteurs indécis ;
- le calendrier de disponibilité, s’il interroge la base à chaque affichage plutôt que de s’appuyer sur un cache de résultat.
Un formulaire mal protégé contre les soumissions automatisées peut, à lui seul, saturer le pool PHP-FPM un samedi matin bien avant que les visiteurs humains ne posent problème.
Choisir une architecture qui suit la saison
Un VPS redimensionnable à la demande convient mieux ici qu’un serveur dédié loué à l’année. La plupart des fournisseurs cloud permettent de faire évoluer le nombre de vCPU et la mémoire allouée en quelques minutes, avec un redémarrage du service. Le principe retenu pour ce traiteur a été le suivant :
| Période | Configuration | Coût mensuel indicatif |
|---|---|---|
| Octobre à mars | 2 vCPU, 4 Go de RAM | Base |
| Avril et septembre | 4 vCPU, 8 Go de RAM | Intermédiaire |
| Mai à août | 8 vCPU, 16 Go de RAM | Pic |
Le redimensionnement se planifie à l’avance, sans attendre l’incident : un simple rappel calendaire début avril et fin septembre suffit à déclencher le changement de gabarit, plutôt que de réagir a posteriori après un samedi difficile.
Protéger le formulaire de devis en amont
Plutôt que d’ajouter des ressources pour absorber un formulaire qui reçoit des soumissions automatisées, il est plus efficace de filtrer en amont. Un champ honeypot invisible couplé à une vérification de délai minimal entre l’affichage et la soumission élimine l’essentiel du bruit sans recourir à un service tiers de captcha, souvent perçu comme un frein par des visiteurs pressés sur mobile pendant une visite de salle.
add_action( 'wp_footer', function () {
if ( is_page( 'devis' ) ) {
echo '<script>document.querySelector("form#devis").dataset.loaded = Date.now();</script>';
}
});
add_filter( 'wpcf7_validate', function ( $result, $tag ) {
// Rejette toute soumission envoyée en moins de trois secondes.
if ( isset( $_POST['loaded'] ) && ( time() * 1000 - (int) $_POST['loaded'] ) < 3000 ) {
$result->invalidate( $tag, 'Soumission trop rapide.' );
}
return $result;
}, 10, 2 );
Mettre les photos en cache sans dégrader la qualité
La galerie de prestations passées reste la ressource la plus lourde du site. Un cache de page complète associé à un lazy-loading natif via l’attribut loading="lazy" réduit fortement la charge sur les images qui ne sont jamais affichées entièrement, notamment sur mobile où le défilement s’arrête souvent avant la fin de la galerie.
Redescendre après l’événement
Le point souvent négligé n’est pas la montée en charge mais la redescente. Un VPS laissé sur son gabarit maximal d’octobre à mars coûte, sur une année, l’équivalent de plusieurs mois de prestation facturée pour rien. La discipline consiste à traiter le redimensionnement comme une tâche récurrente au même titre qu’une sauvegarde, avec une date fixe au calendrier plutôt qu’une décision laissée à la mémoire de chacun.
Un serveur dimensionné pour le pic et jamais redescendu coûte plus cher sur l’année qu’un incident occasionnel en pleine saison.
Notre verdict
Pour un traiteur événementiel dont l’activité se concentre sur une poignée de mois, la bonne réponse n’est ni le serveur dédié surdimensionné à l’année ni le mutualisé sous-dimensionné en pleine saison, mais une infrastructure élastique pilotée par un calendrier connu à l’avance. Le vrai travail d’optimisation ne porte d’ailleurs pas sur les pages de prestations, déjà légères, mais sur le formulaire de devis et la galerie photo, qui concentrent l’essentiel de la charge réelle un samedi de juin.
