Construire une stratégie de monitoring SRE efficace : SLO, SLIs, SLA et observabilité moderne

Basé sur le Google SRE Workbook — Implementing SLOs et le Google SRE Book — Chapter 4

Introduction

Le monitoring en SRE part d’un principe fondateur : la fiabilité d’un service se mesure par la satisfaction de ses utilisateurs, pas par l’état de son infrastructure.

Un utilisateur mécontent cesse d’utiliser le service, génère des tickets de support, et ne recommande pas le produit. C’est cet impact qui doit guider la définition des SLOs — pas la disponibilité théorique d’une machine ou d’une API.

Pour construire cette stratégie de façon cohérente, il faut répondre à trois questions dans l’ordre :

1. Quels scénarios utilisateur sont critiques ? — identification des CUJs
2. Comment mesurer l’expérience réelle sur ces scénarios ? — RUM JavaScript
3. Quels engagements peut-on formaliser à partir de ces mesures ? — SLO, SLA, error budget

1. Le point de départ : les scénarios critiques utilisateur (CUJs)

Avant de définir le moindre SLO, la première étape est d’identifier les Critical User Journeys (CUJ) — les scénarios pour lesquels une défaillance a un impact direct sur la valeur perçue par l’utilisateur.

Cette approche top-down est délibérée : elle évite de définir des SLOs sur des composants sans impact utilisateur direct, ce qui dilue l’attention et multiplie les error budgets inutilement.

Illustration : e-commerce

CUJ 1 — Rechercher et consulter un produit
  → L'utilisateur trouve ce qu'il cherche
  → Impact si dégradé : abandon, perte de conversion

CUJ 2 — Ajouter un produit au panier
  → L'utilisateur exprime son intention d'achat
  → Impact si dégradé : friction, perte de session

CUJ 3 — Finaliser un achat
  → L'utilisateur complète la transaction
  → Impact si dégradé : perte de revenu directe

Des CUJs aux composants à couvrir

Chaque CUJ identifie les composants qui supportent le parcours — et donc ceux qui méritent un SLO formel.

CUJ 3 "Finaliser un achat"
  → Résolution DNS + CDN         (accessibilité réseau)
  → Chargement des assets        (performance front-end)
  → API catalogue                (fiche produit)
  → API panier                   (persistance panier)
  → API checkout                 (traitement commande)
  → Service de paiement          (validation transaction)

Un composant qui ne participe à aucun CUJ critique n’a pas besoin de SLO formel.

2. La hiérarchie SLI → SLO → SLA

Avant d’aller plus loin, il est essentiel de distinguer ces trois concepts souvent confondus.

SLI — Service Level Indicator

Le SLI est la mesure concrète qui quantifie un aspect de l’expérience utilisateur. Il prend toujours la forme d’un ratio :

SLI = nombre d'événements "bons" / nombre total d'événements

SLO — Service Level Objective

Le SLO est la cible interne fixée sur un SLI, sur une fenêtre de temps donnée. C’est l’engagement de l’équipe envers elle-même et envers les parties prenantes internes.

Exemple : "99,5% des parcours d'achat réels réussissent sur 30 jours"

SLA — Service Level Agreement

Le SLA est l’engagement contractuel externe vis-à-vis des clients ou partenaires. Il inclut des conséquences formelles en cas de non-respect (remboursements, pénalités, crédits de service).

Règle fondamentale : le SLA doit toujours être moins ambitieux que le SLO.

SLO interne : 99,5%
SLA externe : 99,0%

→ La marge de 0,5% absorbe :
  - Les imprécisions de mesure
  - Le temps de réaction avant correction
  - Les incidents en cours d'investigation
  - Les cas limites de définition contractuelle

Si le SLA est fixé au même niveau que le SLO, le moindre incident déclenche une violation contractuelle avant même que l’équipe ait pu réagir.

3. Mesurer l’expérience réelle : le RUM JavaScript

Pourquoi des données réelles

L’engagement SLO/SLA doit porter sur l’expérience effectivement vécue par les utilisateurs. Cela implique une source de données qui capture ce que le monitoring applicatif traditionnel ne peut pas voir : les événements réseau.

Exemples d'événements invisibles au monitoring applicatif :
→ Échec de résolution DNS (la requête n'atteint pas le serveur)
→ Timeout CDN (le contenu ne se charge pas)
→ Dégradation d'un point de présence réseau
→ Problème de cache navigateur
→ Incompatibilité avec un navigateur ou une géographie spécifique

Ces événements impactent directement l’utilisateur sans générer de trace côté serveur.

Le RUM JavaScript : capture depuis le navigateur réel

Le Real User Monitoring (RUM) consiste à instrumenter les pages web avec du JavaScript qui collecte des métriques de performance et d’expérience directement depuis le navigateur de l’utilisateur réel.

Les APIs navigateur natives permettent de capturer sans proxy :

// Navigation Timing API — performance du chargement de page
const [entry] = performance.getEntriesByType('navigation');
const dnsTime       = entry.domainLookupEnd - entry.domainLookupStart;
const tlsTime       = entry.connectEnd - entry.secureConnectionStart;
const cdnTime       = entry.responseStart - entry.requestStart;
const pageLoadTime  = entry.loadEventEnd - entry.startTime;

// Resource Timing API — performance des ressources individuelles
performance.getEntriesByType('resource').forEach(resource => {
  // Chaque asset : API call, image, script, font...
  const duration   = resource.duration;
  const cacheHit   = resource.transferSize === 0;
});

// Erreurs JavaScript non interceptées
window.addEventListener('error', (event) => {
  // Capture les erreurs front-end impactant l'utilisateur
});

Ces données sont ensuite enrichies avec le contexte de la session :

const context = {
  userAgent  : navigator.userAgent,     // navigateur, OS, device
  connection : navigator.connection?.effectiveType, // 4G, WiFi, etc.
  viewport   : `${window.innerWidth}x${window.innerHeight}`,
  // Pas d'identifiant utilisateur — conformité RGPD
};

Ce que le RUM capture sur les CUJs

Pour chaque CUJ, on instrumente les étapes clés du parcours avec des marqueurs de performance :

// Exemple sur le CUJ "Finaliser un achat"

// Étape 1 : chargement de la fiche produit
performance.mark('product-page-start');
// ... chargement de la page ...
performance.mark('product-page-ready');
performance.measure('product-page', 'product-page-start', 'product-page-ready');

// Étape 2 : ajout au panier
performance.mark('add-to-cart-start');
await addToCart(productId);
performance.mark('add-to-cart-done');
performance.measure('add-to-cart', 'add-to-cart-start', 'add-to-cart-done');

// Étape 3 : confirmation de commande
performance.mark('checkout-start');
await submitOrder(cart);
performance.mark('checkout-confirmed');
performance.measure('checkout', 'checkout-start', 'checkout-confirmed');

// Envoi vers le backend d'analyse
sendMetrics({
  journey : 'purchase',
  steps   : performance.getEntriesByType('measure'),
  success : orderConfirmed,
  context,
});

Les dimensions d’analyse disponibles

Le RUM offre une richesse analytique impossible à obtenir par d’autres moyens :

4. Conformité RGPD du RUM

Le RUM collecte des données techniques de navigation. Il est possible de l’opérer sous intérêt légitime (Article 6.1.f du RGPD) sans consentement explicite, sous réserve de respecter quatre obligations.

Les quatre obligations

1. Mentionner le traitement dans la politique de confidentialité

Exemple de mention :
"Nous collectons des métriques techniques de performance de navigation
(temps de chargement, erreurs, type de connexion) pour mesurer
la qualité de notre service. Ces données ne contiennent aucune
information permettant d'identifier personnellement un utilisateur."

2. Inscrire le traitement dans le registre (Article 30)

Registre des traitements — entrée RUM :
→ Finalité       : mesure de la qualité de service (SLO/SLA)
→ Base légale    : intérêt légitime
→ Données        : métriques de performance, navigateur,
                   géographie (pays/région), type de connexion
→ Exclusions     : aucun identifiant utilisateur, aucun cookie
→ Destinataires  : équipe SRE / ingénierie
→ Durée de rétention : données brutes 7 jours,
                       agrégats 13 mois

3. Durée de rétention courte

Données brutes (événements individuels) : 7 jours maximum
Agrégats (SLIs calculés, percentiles)   : 13 mois
  → Permet la comparaison annuelle pour les SLOs
  → Élimine les données individuellement identifiables

4. Pas de croisement avec d’autres données utilisateur

Interdit :
→ Associer les métriques RUM à un compte utilisateur
→ Croiser avec des données de session authentifiée
→ Utiliser les données RUM à des fins publicitaires

Autorisé :
→ Agréger par navigateur, géographie, type de connexion
→ Calculer des percentiles de performance
→ Identifier des patterns de dégradation

5. Définir les SLIs à partir du RUM

La forme recommandée

SLI = sessions CUJ avec expérience "bonne" / total sessions CUJ instrumentées

Une expérience est considérée “bonne” si elle respecte les seuils définis sur les métriques clés du parcours.

SLIs concrets pour notre e-commerce

CUJ 3 — Finaliser un achat

SLI availability =
  sessions où toutes les étapes du parcours achat
  se sont complétées sans erreur
  / total sessions ayant initié le parcours achat

SLI latency =
  sessions où le parcours achat complet
  s'est complété en < 5s (end-to-end navigateur)
  / total sessions ayant initié le parcours achat

CUJ 1 — Rechercher et consulter un produit

SLI availability =
  sessions où la page produit s'est chargée sans erreur
  / total sessions ayant initié une recherche

SLI latency =
  sessions où la page produit s'est affichée en < 2s (LCP)
  / total sessions ayant chargé une page produit

Fixer les SLOs à partir des mesures réelles

On mesure d’abord les performances réelles sur 4 semaines, puis on aligne le SLO sur ce qui est effectivement tenu — jamais sur un objectif arbitraire.

Mesures sur 4 semaines — CUJ "Finaliser un achat" :
→ 124 850 sessions instrumentées
→ 122 480 succès (availability) → 99,10%
→ 119 230 sous 5s (latency p95) → 95,50%

SLOs proposés :
→ Availability : 98,5%
→ Latency p95  : 95% des parcours complétés en < 5s

6. Construire le SLA

Principes

Le SLA est basé sur les mêmes SLIs RUM que le SLO, avec deux différences :

1. Le seuil est moins ambitieux que le SLO pour préserver une marge opérationnelle
2. La méthode de mesure est documentée contractuellement pour éviter toute ambiguïté

Exemple de formulation contractuelle

DISPONIBILITÉ ET PERFORMANCE DU SERVICE

1. Méthode de mesure
   La disponibilité et la performance sont mesurées par
   instrumentation JavaScript côté navigateur (Real User Monitoring),
   collectant des métriques techniques anonymisées sur les parcours
   critiques des utilisateurs réels du service.

   Les métriques collectées couvrent :
   - La résolution DNS et la connectivité réseau
   - Le chargement des ressources (CDN, assets)
   - L'exécution des étapes fonctionnelles du parcours
   - La performance perçue (temps d'affichage, de réponse)

   Un parcours est considéré réussi si l'ensemble de ses étapes
   se complètent sans erreur en moins de 5 secondes.

2. Calcul
   Disponibilité mensuelle =
     sessions réussies / total sessions instrumentées × 100

   Seules les sessions ayant initié le parcours
   sont incluses dans le calcul.

3. Engagement
   Disponibilité garantie : 98,0% par mois calendaire

4. Conséquences en cas de non-respect
   Entre 97% et 98%   → crédit de service de 10%
   Entre 95% et 97%   → crédit de service de 25%
   En dessous de 95%  → crédit de service de 50%

5. Exclusions
   Ne sont pas comptabilisées dans le calcul :
   - Les maintenances planifiées notifiées 48h à l'avance
   - Les incidents causés par des tiers documentés
     (fournisseurs cloud, opérateurs réseau)
   - Les sessions sur navigateurs non supportés
     (liste maintenue dans la documentation technique)

7. L’error budget : piloter par l’impact réel

L’error budget transforme le SLO en outil de décision concret.

SLO availability : 98,5% sur 30 jours
→ 124 850 sessions instrumentées sur la période
→ Budget d'erreurs : 1,5% × 124 850 = 1 873 sessions en échec autorisées

Ce que l’error budget permet de décider

Budget intact :

• Déploiements libres, expérimentations, nouvelles features
• Le service est plus fiable que nécessaire : on peut accepter du risque

Budget consommé :

• Gel des déploiements non critiques
• Priorité donnée aux corrections de fiabilité
• Application de l’error budget policy formalisée

Comparer les incidents par leur coût réel en expérience utilisateur

Incident A — Dégradation CDN Europe (2h, 312 sessions impactées)
→ Consomme 312 / 1 873 = 17% du budget mensuel

Incident B — Timeout API checkout (45min, 1 140 sessions impactées)
→ Consomme 1 140 / 1 873 = 61% du budget mensuel
→ Bien que 3× plus court, l'incident B est 3,5× plus coûteux
→ La priorité de fiabilité va vers la résilience du checkout

La richesse du RUM permet également de qualifier les incidents :

Incident A — détail RUM :
→ Impacte uniquement les utilisateurs en France et Belgique
→ Temps DNS × 4 sur ces géographies
→ Cause : point de présence CDN Paris dégradé
→ Utilisateurs mobiles 4G les plus impactés

8. Le synthetic monitoring : détection proactive optionnelle

Le RUM étant basé sur le trafic réel, il a une limite structurelle : il ne peut pas détecter une panne en l’absence d’utilisateurs actifs.

Panne checkout à 3h du matin
→ Aucun utilisateur actif
→ Aucune session RUM
→ Panne non détectée jusqu'à la reprise du trafic

Le synthetic monitoring peut compléter cette limite de façon optionnelle, en simulant des parcours en continu indépendamment du trafic réel.

Son rôle dans cette architecture

Le synthetic monitoring est ici un outil de détection proactive, pas un référentiel de SLO ou de SLA. Son objectif est de permettre à l’équipe de détecter et corriger une panne avant que les utilisateurs réels ne soient impactés.

Synthetic monitoring → "Le parcours checkout échoue depuis 14 minutes" 🔴
  → L'équipe est alertée et corrige avant la reprise du trafic
  → Aucune session RUM impactée
  → Error budget préservé

Ce qu’il apporte en complément du RUM

Limites du synthetic monitoring

• Discret : un incident survenu et résolu entre deux runs peut ne pas être détecté
• N’alimente pas le SLO ni le SLA — c’est un filet de sécurité, pas un référentiel

9. L’observabilité : uniquement pour le diagnostic

L’observabilité — l’ensemble des signaux internes du système — n’alimente pas le SLO. Son rôle est exclusivement de comprendre l’origine d’un incident une fois qu’il a été détecté par le RUM ou le synthetic monitoring.

Le flux de diagnostic

RUM → "61% des sessions checkout échouent depuis 20 minutes" 🔴
  ↓
Observabilité → diagnostic :
  → Quel composant est défaillant ?
  → Quelle est la cause racine ?
  → Quelle est la propagation entre services ?
  → Quelle action corrective appliquer ?

L’observabilité répond aux questions pourquoi et où — le RUM répond aux questions quoi et combien.

10. Architecture complète

┌────────────────────────────────────────────────────────────────────┐
│  ÉTAPE 1 — IDENTIFICATION DES CUJs                                 │
│  "Quels scénarios ont un impact utilisateur direct ?"              │
│  → Périmètre des composants à couvrir par un SLO                   │
├────────────────────────────────────────────────────────────────────┤
│  ÉTAPE 2 — RUM JAVASCRIPT (référentiel d'engagement)               │
│  Instrumentation navigateur sur les CUJs instrumentés              │
│  → Couvre réseau, CDN, DNS, cache, navigateur, géographie          │
│  → Base du SLO (engagement interne)                                │
│  → Base du SLA (engagement contractuel externe)                    │
│  → Conformité RGPD : intérêt légitime, politique confidentialité,  │
│    registre article 30, rétention courte, pas de croisement        │
├────────────────────────────────────────────────────────────────────┤
│  ÉTAPE 3 — ERROR BUDGET (pilotage)                                 │
│  Budget = (1 - SLO) × sessions instrumentées                       │
│  → Décisions déploiement / fiabilité                               │
│  → Comparaison objective des incidents par impact réel             │
├────────────────────────────────────────────────────────────────────┤
│  ÉTAPE 4 — SYNTHETIC MONITORING (optionnel, proactif)              │
│  Parcours simulés end-to-end, toutes les 60s                       │
│  → Détection des pannes sans trafic réel                           │
│  → N'alimente pas le SLO ni le SLA                                 │
├────────────────────────────────────────────────────────────────────┤
│  ÉTAPE 5 — OBSERVABILITÉ (diagnostic uniquement)                   │
│  Signaux internes du système                                       │
│  → Déclenché par une alerte RUM ou synthetic                       │
│  → Répond à : pourquoi ? où ? comment corriger ?                   │
│  → N'alimente pas le SLO ni le SLA                                 │
└────────────────────────────────────────────────────────────────────┘

11. Bonnes pratiques et anti-patterns

✅ Ce qu’il faut faire

• Partir des CUJs pour identifier les composants qui méritent un SLO
• Instrumenter les CUJs en RUM JavaScript pour capturer l’expérience réelle, réseau inclus
• Baser SLO et SLA sur le RUM — données réelles, pas des simulations
• Documenter la méthode de mesure RUM dans le SLA pour éviter toute ambiguïté contractuelle
• Fixer le SLA en dessous du SLO pour conserver une marge opérationnelle
• Partir des mesures réelles pour calibrer les SLOs — pas d’objectifs arbitraires
• Respecter les obligations RGPD du RUM : politique de confidentialité, registre article 30, rétention courte, pas de croisement
• Ajouter le synthetic monitoring si la détection proactive hors trafic est un besoin opérationnel
• Réserver l’observabilité au diagnostic — pas au calcul du SLO

❌ Ce qu’il faut éviter

Conclusion

Une stratégie SRE efficace repose sur une séparation claire et assumée des rôles de chaque outil.

Les CUJs définissent ce qui compte pour l’utilisateur et délimitent le périmètre des engagements de fiabilité.

Le RUM JavaScript est le référentiel d’engagement — il mesure l’expérience réellement vécue par les utilisateurs, réseau inclus, et fonde à la fois le SLO interne et le SLA contractuel. Sa conformité RGPD est assurée sous intérêt légitime avec des obligations documentées.

Le synthetic monitoring est un filet de sécurité optionnel — utile pour détecter les pannes avant qu’elles n’impactent les utilisateurs, mais sans rôle dans les engagements de fiabilité.

L’observabilité est le microscope d’incident — elle explique ce qui s’est passé et comment le corriger, sans alimenter les SLOs.

L’error budget est l’outil de décision — il transforme les SLOs en arbitrages concrets et quantifiés entre vitesse de livraison et fiabilité.

On ne s’engage pas sur la disponibilité théorique d’une infrastructure. On s’engage sur l’expérience réellement vécue par les utilisateurs — et on utilise l’observabilité pour comprendre quand et comment elle se dégrade.

Références :

• *Google SRE Workbook — Implementing SLOs*
• *Google SRE Book — Service Level Objectives*
• *Google Cloud Blog — Practical guide to setting SLOs*
• *Google Cloud Blog — How to design good SLOs*
• *W3C Navigation Timing API*
• *W3C Resource Timing API*