« Nous nous engageons sur un temps de réponse serveur inférieur à 200 millisecondes. » Cette phrase, qui apparaît dans certains devis ou contrats de maintenance, mérite d’être décortiquée avant signature, car le temps de réponse perçu par un visiteur dépend de bien plus de facteurs que ceux qu’un développeur ou une agence peuvent réellement maîtriser.
Distinguer ce qui relève du code applicatif, de la configuration serveur, et de ce qui échappe totalement au prestataire permet de rédiger un engagement contractuel qui protège autant le client que le prestataire, sans promesse intenable.
Ce que le prestataire maîtrise réellement
Le temps de génération d’une page côté serveur — depuis la réception de la requête par PHP-FPM jusqu’à l’envoi du premier octet de réponse — dépend directement du code applicatif (requêtes SQL, appels externes, complexité des templates), de la configuration du serveur (réglages PHP-FPM, présence d’un object cache, tuning MySQL), et du choix de l’hébergement. Sur ce périmètre précis, un engagement chiffré et mesurable a du sens.
Un moyen fiable de mesurer cette partie consiste à exposer un en-tête Server-Timing, calculé directement dans WordPress, indépendamment du temps de trajet réseau vers le visiteur :
add_action( 'send_headers', function () {
$debut = $GLOBALS['timestart'] ?? microtime( true );
$duree_ms = ( microtime( true ) - $debut ) * 1000;
header( sprintf( 'Server-Timing: wp;dur=%.1f', $duree_ms ) );
} );Cette valeur, mesurée côté serveur, constitue une base saine pour un engagement contractuel, car elle ne dépend d’aucun facteur extérieur au périmètre technique du prestataire.
Ce qui reste hors de son contrôle
Le TTFB (Time To First Byte) mesuré depuis le navigateur d’un visiteur inclut, en plus du temps de génération serveur, le temps de résolution DNS, l’établissement de la connexion TCP et TLS, et surtout la latence réseau entre le visiteur et le serveur. Un visiteur connecté en 3G depuis une zone rurale ou depuis un autre continent que celui de l’hébergement observera un TTFB nettement plus élevé qu’un visiteur en fibre optique situé à proximité du datacenter, sans que le code applicatif n’y soit pour quoi que ce soit.
Un engagement contractuel raisonnable porte toujours sur une mesure prise depuis un point de référence connu et stable, jamais sur une moyenne agrégée de tous les visiteurs réels, dont la répartition géographique échappe totalement au prestataire.
Les pics saisonniers, un cas à part
Un site institutionnel peut voir son trafic multiplié par dix lors d’un événement ponctuel (rentrée scolaire, période de soldes, actualité soudaine). Un engagement de temps de réponse doit préciser explicitement la charge de référence sur laquelle il porte, faute de quoi un pic de trafic imprévu, sans lien avec la qualité du code livré, pourrait être interprété à tort comme un manquement contractuel.
Ce que doit contenir une clause d’engagement raisonnable
- Le point de mesure précis : un temps de génération serveur mesuré en
Server-Timing, pas un TTFB agrégé côté visiteur. - La charge de référence : un nombre de requêtes simultanées ou un volume de trafic mensuel au-delà duquel l’engagement ne s’applique plus sans révision.
- L’environnement d’exécution : la configuration d’hébergement précise sur laquelle l’engagement a été validé, car un changement d’hébergeur décidé unilatéralement par le client sort du périmètre.
- Les éléments exclus explicitement : latence réseau du visiteur, appels vers des services tiers non maîtrisés par le prestataire, pics de trafic exceptionnels non anticipés.
Un exemple de formulation contractuelle
« Le temps de génération serveur des pages principales du site, mesuré via l’en-tête Server-Timing sur l’environnement de production décrit en annexe, et pour une charge n’excédant pas cinquante requêtes simultanées, restera inférieur à 300 millisecondes en moyenne sur une fenêtre de sept jours glissants. » Cette formulation évite tout engagement sur des facteurs échappant au prestataire, tout en offrant au client un indicateur vérifiable et objectif.
En résumé
Un contrat de résultat sur la performance a de la valeur seulement s’il porte sur ce que le prestataire contrôle réellement : le code, la configuration serveur, l’architecture applicative. Tout engagement qui ignore la part du réseau visiteur ou des pics de charge imprévisibles finit par créer des litiges évitables, au détriment de la relation de confiance entre le prestataire et son client.
