Temps de lecture estimé : 4 min · Publié le 2 octobre 2026
Choisir le parcours à protéger
Décrivez l’action essentielle, sa population et les dépendances qui peuvent l’interrompre. Pour une vitrine, il peut s’agir de lire une offre puis envoyer une demande. Pour une boutique, le résultat utile est une commande correctement enregistrée. Séparez le chargement de la page, la réussite de l’action et son traitement ultérieur : ces étapes peuvent connaître des problèmes différents.
Le SRE Workbook de Google expose une méthode d’objectifs de service fondée sur des indicateurs et un accord entre les parties. Adaptez cette démarche à la taille du site. Une équipe réduite peut commencer avec un parcours, un indicateur observable et un responsable plutôt qu’une collection de tableaux sans décision associée.
Définir les événements et leur fenêtre
Écrivez ce qui compte comme tentative et réussite, où l’information est observée et quelles exclusions sont justifiées. Une erreur de validation provoquée par une saisie volontairement invalide ne décrit pas la même chose qu’une perte de demande valide. Une surveillance synthétique et les données d’usage observent des populations différentes ; gardez leurs résultats distincts.
Fixez la fenêtre de lecture et le minimum d’information nécessaire. Sur un site à faible trafic, quelques événements rendent les pourcentages instables. Affichez nombres de tentatives et d’échecs à côté du taux, puis cherchez les cas reproductibles. Ne rassemblez pas inutilement de messages ou de données personnelles pour mesurer un résultat technique.
Choisir un objectif avant un engagement
Un objectif interne décrit le niveau souhaité et guide une décision. Un engagement contractuel comporte un périmètre et des conséquences qui demandent un accord distinct. Évitez d’adopter un pourcentage élevé parce qu’il semble rassurant. Comparez besoins des visiteurs, contraintes d’exploitation et coût de récupération.
À titre de calcul fictif, 10 échecs sur 1 000 tentatives donnent 99 % de réussites. Cela ne précise ni leur durée, ni les personnes affectées, ni la gravité : les mêmes nombres peuvent couvrir une gêne mineure ou une perte de commandes. Une disponibilité mesurée en temps doit utiliser une autre définition ; ne convertissez pas ces indicateurs l’un dans l’autre sans préciser la méthode.
Relier les seuils à des actions
Décidez qui vérifie une alerte, quelle preuve permet de qualifier l’incident et quel canal informe les personnes concernées. Une panne confirmée peut nécessiter un contournement ou un retour à une version précédente. Une alerte isolée peut demander une vérification avant mobilisation. L’objectif est de réduire l’incertitude et le temps de réponse, pas d’envoyer un message pour chaque variation.
Documentez le cas où la qualité baisse pendant un changement. Le chapitre sur la politique de budget d’erreur présente le principe d’une réponse convenue aux écarts de fiabilité. Pour un petit site, vous pouvez simplement prévoir de différer une évolution facultative jusqu’à résolution d’un défaut critique, sans prétendre appliquer le même dispositif qu’un grand service.
Vérifier les observateurs et relire les incidents
Testez le contrôleur lui-même : distingue-t-il page disponible et action réussie ? Détecte-t-il une notification perdue ? Produit-il une alerte compréhensible et reçoit-elle une réponse ? N’exécutez des scénarios perturbateurs que dans un environnement autorisé. Les contrôles de production doivent éviter commandes fictives et messages involontaires.
Après un incident, reliez chronologie, impact, correctif et test de non-régression. Révisez l’indicateur si le défaut a échappé au contrôle. Le guide de réponse à un incident et le carnet de recette aident à attribuer les actions et conserver les résultats. Un objectif utile évolue avec le parcours et les risques observés.
Documents de référence
Contenu mis à jour le 2 octobre 2026
Consigner les contrôles et constats dans le carnet de recette