Observabilité

Le chapitre 6 a construit un déploiement canari : router 5 % du trafic, mesurer, décider. Le chapitre 9 a montré Kubernetes retirer des pods du service et arrêter un déploiement.

Deux mécanismes remarquables, et tous deux inutilisables tels quels — parce qu'il manque la partie qui regarde. Un canari sans mesure expose 5 % des utilisateurs et attend qu'ils se plaignent ; un orchestrateur qui redémarre en boucle sans que rien ne le signale produit une panne silencieuse.

L'observabilité est cette partie manquante. Sa question n'est pas « le serveur répond-il ? » mais « que fait mon système, et pourquoi ? ».

Trois piliers, trois questions

L'ordre n'est pas arbitraire : c'est celui du diagnostic. Une métrique alerte — le taux d'erreur est passé de 0,1 % à 4 %. Les journaux disent de quoi il s'agit — telle requête échoue avec tel message. Une trace dit où le temps est passé quand cinq services sont impliqués et qu'aucun ne semble fautif.

Les trois ne se remplacent pas. Beaucoup d'équipes n'ont que des journaux et cherchent une tendance en les lisant, ce qui ne marche pas : un journal répond mal à « combien » et « depuis quand ».

Métriques

Prometheus interroge périodiquement les applications, qui exposent leurs compteurs sur une adresse dédiée. Ce modèle par interrogation a une conséquence utile : l'absence de réponse est elle-même une information — un service qui ne répond plus est immédiatement visible.

Chaque métrique porte des étiquettes qui la découpent : par code HTTP, par point d'entrée, par version. C'est ce qui permet de comparer la version 1.4 et la version 1.5 pendant un canari, et donc de décider.

Quatre indicateurs suffisent à surveiller un service, et ils portent le nom de signaux dorés : la latence, le trafic, les erreurs, la saturation — c'est-à-dire à quel point les ressources sont pleines.

Un point de méthode sur la latence, souvent manqué : on ne surveille jamais une moyenne. Une latence moyenne de 200 ms peut cacher 95 % des requêtes à 50 ms et 5 % à plusieurs secondes. On regarde des centiles — le 95e, le 99e — parce que ce sont eux que les utilisateurs subissent, et parce qu'ils bougent bien avant la moyenne.

Journaux

Deux règles, et la première a une raison précise.

Les journaux quittent la machine. Une machine qui tombe emporte ses fichiers, et un conteneur détruit emporte les siens — le chapitre 3 l'a dit. Sur vingt exemplaires, chercher dans vingt endroits est impraticable. On les envoie donc vers un système central.

Les journaux sont structurés. Une ligne de texte libre se cherche mal ; un enregistrement avec des champs se filtre.

12026-03-14 10:22:31 ERROR échec de la commande 4471 pour l'utilisateur 882{"ts":"2026-03-14T10:22:31Z","niveau":"error","message":"échec de commande",3 "commande":4471,"utilisateur":88,"trace":"a3f9c1","service":"paiement"}

Le champ trace est ce qui relie les enregistrements d'une même requête à travers les services. Sans lui, un incident dans une architecture distribuée demande de recouper des horodatages à la main — c'est faisable sur deux services, impossible sur dix.

Deux mises en garde. Les journaux coûtent : en stockage, en indexation, en bande passante, et le niveau debug en production peut coûter plus cher que le service lui-même. Et ils contiennent des données personnelles — journaliser un corps de requête revient souvent à journaliser une adresse ou un moyen de paiement, ce qui a des conséquences réglementaires.

Alertes utiles, et bruit d'alertes

C'est la partie la plus importante du chapitre, et la plus mal faite en pratique.

Le mécanisme de dégradation est connu. On ajoute des alertes « au cas où ». Certaines se déclenchent sans qu'il y ait rien à faire. L'équipe apprend à les ignorer, met en sourdine celles qui reviennent le plus, et le jour où une vraie alerte part, elle est traitée comme les autres. C'est exactement le sort du test instable du chapitre 5.

Trois règles l'évitent.

Alerter sur les symptômes, pas sur les causes. « Le taux d'erreur dépasse 2 % » concerne les utilisateurs. « L'usage processeur dépasse 80 % » ne concerne personne : si le service répond correctement, il n'y a rien à faire. La cause s'investigue dans les tableaux de bord, une fois alerté par le symptôme.

Toute alerte doit être actionnable. La question à poser pour chaque alerte est : « que fait la personne réveillée ? » Sans réponse précise, l'alerte devient un tableau de bord, pas une alerte.

Distinguer ce qui réveille de ce qui attend. Une dégradation qui menace le service justifie une notification immédiate ; un disque à 70 % justifie un ticket. Mélanger les deux détruit la première catégorie.

SLI, SLO et budget d'erreur

Ces trois notions donnent au chapitre son cadre, et elles règlent un débat vieux comme le chapitre 1.

Un SLI est un indicateur de service : la part des requêtes servies en moins de 300 ms, par exemple. Un SLO est l'objectif qu'on se donne dessus : « 99,9 % des requêtes en moins de 300 ms, sur trente jours ».

Le budget d'erreur est le complément : $100\,\% - 99{,}9\,\% = 0{,}1\,\%$. Sur trente jours, cela représente 43 minutes d'indisponibilité autorisées.

Le renversement est là. Ce budget n'est pas une tolérance honteuse : c'est une ressource à dépenser. Tant qu'il reste du budget, l'équipe peut déployer vite et prendre des risques — le canari du chapitre 6, une refonte, une migration. Quand il est épuisé, on gèle les changements risqués et l'on consacre l'effort à la fiabilité.

Cette mécanique transforme une dispute en arithmétique. « Faut-il livrer vite ou être stable ? » n'est plus une question d'opinion entre deux équipes aux objectifs opposés : c'est un budget, mesuré, que tout le monde regarde. Et un SLO à 100 % est un mauvais SLO — il interdit tout changement, et il coûte un ordre de grandeur de plus que 99,9 % pour un bénéfice que personne ne perçoit.

La séance qui compte : casser la production

Tout ce chapitre s'apprend en une séance, et elle mérite d'être décrite parce qu'elle transforme une liste d'outils en réflexe.

On déploie volontairement une version défaillante. On laisse l'alerte se déclencher — et l'on mesure combien de temps elle a mis. On diagnostique par les journaux et les tableaux de bord, sans regarder le code fautif. On exécute le retour arrière du chapitre 6. Et l'on écrit un post-mortem, avec les cinq parties du chapitre 1.

Ce que la séance apprend et qu'aucun cours ne transmet : le temps réel entre la panne et l'alerte, celui entre l'alerte et le diagnostic, la sensation de chercher dans les journaux sous pression, et le soulagement d'avoir un retour arrière qui a déjà été testé.

C'est aussi la seule façon de vérifier que le dispositif fonctionne. Une alerte jamais déclenchée, un retour arrière jamais exécuté et un tableau de bord jamais consulté en incident ne sont pas des garanties : ce sont des hypothèses.

À vous

L'exercice calcule ce qui se discute habituellement à l'estime.

D'abord le budget d'erreur : à partir d'un journal d'incidents, vous calculerez la disponibilité réalisée, le budget consommé et ce qu'il reste — puis vous verrez ce que change un SLO à 99,99 % au lieu de 99,9 %.

Ensuite la qualité des alertes. Vous disposez d'un mois d'alertes, chacune étiquetée « vraie » ou « fausse », et vous mesurerez la précision — quelle part des alertes méritait une action — et le rappel — quelle part des vrais incidents a été détectée. Vous ajusterez le seuil et vous constaterez qu'on ne peut pas améliorer les deux à la fois.

Enfin, la chronologie d'un incident : détection, diagnostic, rétablissement. Vous calculerez le temps de rétablissement du chapitre 1, et vous verrez lequel des trois segments dominait — ce qui dit sur quoi travailler.

// ── 1. Budget d'erreur ────────────────────────────────────────────────────
const MOIS_MINUTES = 30 * 24 * 60;   // 43 200

const INCIDENTS = [
  { jour: 3,  minutes: 4,  cause: "déploiement défaillant, retour arrière" },
  { jour: 11, minutes: 2,  cause: "sonde mal réglée, redémarrages" },
  { jour: 18, minutes: 22, cause: "panne du fournisseur de base" },
  { jour: 26, minutes: 6,  cause: "migration bloquante" },
];

function budget(slo, incidents) {
  const autorise = 0;    // ← à écrire : (1 − slo) × minutes du mois
  const consomme = 0;    // ← à écrire
  return { autorise, consomme, restant: autorise - consomme,
           realise: 0 }; // ← disponibilité réellement atteinte
}

// ── 2. Qualité des alertes ────────────────────────────────────────────────
// Chaque alerte : la valeur mesurée, et s'il y avait VRAIMENT un problème.
const ALERTES = [
  { valeur: 2.4, vraiProbleme: true },  { valeur: 0.9, vraiProbleme: false },
  { valeur: 5.1, vraiProbleme: true },  { valeur: 1.2, vraiProbleme: false },
  { valeur: 3.8, vraiProbleme: true },  { valeur: 0.6, vraiProbleme: false },
  { valeur: 1.8, vraiProbleme: false }, { valeur: 4.2, vraiProbleme: true },
  { valeur: 1.1, vraiProbleme: true },  { valeur: 0.8, vraiProbleme: false },
  { valeur: 2.9, vraiProbleme: false }, { valeur: 6.0, vraiProbleme: true },
];

function qualite(seuil, alertes) {
  // ← à écrire : précision = part des alertes qui méritaient une action ;
  //   rappel = part des vrais problèmes détectés.
  return { declenchees: 0, precision: 0, rappel: 0 };
}

// ── 3. Chronologie d'un incident ──────────────────────────────────────────
const CHRONOLOGIE = {
  panne: "10:04",        // le déploiement défaillant part
  alerte: "10:31",       // quelqu'un est prévenu
  diagnostic: "10:44",   // la cause est comprise
  retabli: "10:46",      // le retour arrière est terminé
};

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Écrivez budget(). Que reste-t-il à 99,9 % ? Et à 99,99 % ?
// 2. Écrivez qualite() et faites varier le seuil de 0,5 à 5. Peut-on
//    améliorer précision ET rappel en même temps ?
// 3. Découpez la chronologie en trois segments. Lequel domine, et sur quoi
//    faut-il donc travailler en priorité ?

console.log(JSON.stringify(budget(0.999, INCIDENTS)));

En travaux pratiques

Ce que la suite en fait

Le chapitre 11 clôt le semestre en ajoutant la sécurité au flux plutôt qu'à sa fin. La logique sera la même que dans ce chapitre : mesurer, alerter sur ce qui compte, et éviter le bruit — un analyseur de vulnérabilités qui signale trois cents alertes non exploitables sera désactivé exactement comme une alerte trop bavarde.

À retenir