SRE & observabilité
Voir plus n'est pas le but. Ce dont une équipe d'exploitation a besoin, c'est d'être réveillée pour ce que les clients subissent vraiment, et qu'on lui laisse la paix le reste du temps. Cela commence par un objectif, pas par un outil.
Une alerte que personne ne traite apprend à tout ignorer.
Soixante à quatre-vingts pour cent des alertes sont des faux positifs, et un ingénieur d'astreinte reçoit une médiane de quarante-deux notifications par semaine. Le résultat n'est pas une équipe fatiguée, c'est une équipe qui ne lit plus, et le seul signal qui comptait passe inaperçu au milieu des soixante-trois qui ne valaient rien.
Nous prenons donc le problème par l'autre bout. Un objectif négocié avec le métier, un budget d'erreur qui rend l'arbitrage explicite, une alerte sur ce que le client subit plutôt que sur ce que la machine ressent, et une revue mensuelle qui supprime tout ce que personne n'a traité.
Ce que nous faisons
Quatre chantiers pour qu'une équipe d'exploitation soit réveillée pour les bonnes choses.
Niveaux de service et budget d'erreur
Un objectif négocié avec le métier, mesuré du point de vue du client, avec un budget d'erreur qui dit combien d'échecs sont acceptables. C'est un choix métier, pas une décision technique.
mesuré sur le parcours client, pas sur le serveur
- Un SLO par parcours critique
- Un budget d'erreur et sa règle d'arbitrage
- La livraison arbitrée sur le budget restant
Observabilité de bout en bout
Des traces propagées du navigateur au dernier système, des métriques par étape et des journaux échantillonnés, pour qu'un incident se lise sur un seul fil plutôt que dans quatre consoles.
avec un budget de cardinalité, là où se cache la facture
- Traces propagées à chaque saut
- Métriques par étape du parcours
- Un budget de cardinalité, posé avant la facture
Une alerte qui mérite le réveil
Alerter sur le symptôme plutôt que sur la cause, gradué par la vitesse à laquelle le budget d'erreur se consomme. Ce qui n'appelle pas d'action devient un ticket, ou disparaît.
aucune alerte créée sans qu'une autre soit supprimée
- Deux niveaux : réveiller, ou ouvrir un ticket
- Revue mensuelle, alertes sans action supprimées
- Aucun seuil sans action documentée
AIOps et analyse de cause racine
Des signaux corrélés automatiquement au lieu d'être additionnés, pour que l'investigation parte d'une hypothèse et non d'un tableau de bord. Ce qu'on gagne n'est pas la détection, c'est le délai avant le premier ordre.
le délai de décision se mesure comme le délai de détection
- Corrélation automatique des traces, journaux et métriques
- Cause racine proposée, puis confirmée par un humain
- Post-mortem sans recherche de coupable, avec un responsable
Ce que vous recevez
Un même projet traverse les quatre livrables ci-dessous : la mise sous SLO d'un parcours de paiement. Chaque étape dit ce qui est réellement remis, dans l'ordre où on le remet.
Le niveau de service et son budget d'erreur
Disponibilité et latence mesurées du côté client, sur une fenêtre glissante, avec un budget de quarante-trois minutes par mois et la règle qui dit ce qui se passe quand les trois quarts sont consommés.
parcours-paiement
- 01-slo.yaml
- 02-instrumentation.yaml
- 03-alertes.yaml
- 04-incident.yaml
L'instrumentation du parcours
Des traces propagées à chaque saut, des métriques par étape, des journaux échantillonnés et un budget de cardinalité. Une étiquette par identifiant client multiplie la facture par mille et n'aide personne à diagnostiquer.
parcours-paiement
- 01-slo.yaml
- 02-instrumentation.yaml
- 03-alertes.yaml
- 04-incident.yaml
Une alerte qui mérite le réveil
Deux niveaux seulement, et un critère de suppression écrit : toute alerte déclenchée cinq fois sans action est supprimée ou requalifiée. En créer une suppose d'en retirer une autre.
Un incident, rejoué
Quarante et une minutes d'indisponibilité partielle pour un budget mensuel de quarante-trois. Ce que le rejeu trouve n'est pas un signal manquant, et cela change toute la conclusion.
Comment on livre
Définir
selon le nombre de parcours critiques et de systèmes traversés
- SLO négociés avec le métier
- Budget d'erreur et règle d'arbitrage
- Cartographie des parcours critiques
Instrumenter
selon la profondeur des traces et les systèmes à raccorder
- Traces propagées de bout en bout
- Alertes sur symptôme, pas sur cause
- Un premier incident traité sur cette base
Réduire le bruit
selon le volume d'alertes existant et le nombre d'équipes d'astreinte
- Alertes sans action supprimées ou requalifiées
- Corrélation automatique des signaux
- Astreinte dimensionnée sur des pages utiles
Tenir
engagement de service défini avec vous
- Budget d'erreur suivi et arbitré
- Post-mortem sans recherche de coupable
- Revue mensuelle des alertes
À quoi ressemble vraiment une astreinte
Une production qu'on tient, pas qu'on surveille
Une charpente tient parce que chaque portique a été dimensionné, pas parce qu'on la regarde. C'est ce qu'une exploitation doit produire : un système où l'attention se porte là où elle sert, et nulle part ailleurs.
L'objectif avant l'outil. Un SLO par parcours critique et un budget d'erreur qui rend l'arbitrage de livraison explicite, plutôt qu'un tableau de bord sur lequel personne n'arbitre.
Des niveaux de service qui tiennent

Monter à 200 000 utilisateurs actifs sans lâcher le niveau de service
SLO de 99,99 % atteint · MTTR P1 divisé par trois
Une banque en ligne du groupe Crédit Agricole en montée vers 200 000 utilisateurs actifs, où un ralentissement au moment d'un pic n'est pas un sujet de performance mais des clients qui n'accèdent plus à leurs comptes.
Une équipe transverse performance et observabilité : les pics anticipés au lieu d'être encaissés, un délai de détection divisé par cinq, et un niveau de service qui tient pendant que la base d'utilisateurs est multipliée par quatre.

Une performance éditoriale qui cesse de s'éroder de livraison en livraison
−45 % de temps de chargement · 5 Core Web Vitals verts sur 6
Un site éditorial dont la performance s'érodait à chaque livraison, sur un titre où le confort de lecture fait partie du produit, et où personne ne pouvait dire quel changement avait coûté quoi.
La mesure branchée sur la chaîne de livraison plutôt que menée en audit : ce qui se dégrade se voit à la livraison suivante, et la maintenance garde la mesure en marche après la refonte.
Insights & Perspectives

Combler l'écart SRE : vers l'observabilité autonome
Comment un agent IA corrèle journaux, métriques et traces pour automatiser l'analyse de cause racine, et à quelle condition cela réduit le MTTR au lieu d'ajouter un tableau de bord.

Analyse de causalité profonde au niveau kernel avec MCP
Descendre sous l'applicatif pour lire ce que dit le noyau, et transformer cela en une explication sur laquelle un ingénieur d'astreinte peut agir à trois heures du matin.

Chaos engineering : bonnes pratiques pour des systèmes résilients
Casser volontairement, en production, sous contrôle. Ce que la discipline exige réellement avant que la première expérience vaille la peine d'être menée.
Soyez réveillé pour les bonnes choses
Des niveaux de service négociés avec le métier, une observabilité qui se lit sur un seul fil, et une astreinte dimensionnée sur des notifications utiles.
Questions fréquentes
Par les objectifs. Un outil montre ce qu'on lui désigne, et sans niveau de service convenu, chaque incident s'arbitre dans l'instant. Un SLO négocié avec le métier est ce qui transforme un tableau de bord en décision.
À rendre l'arbitrage explicite. Viser zéro incident revient soit à ne plus livrer, soit à livrer et encaisser. Le budget dit combien d'échecs sont acceptables, et arrête les livraisons non critiques quand les trois quarts sont consommés.
Parce qu'une cause qui ne gêne aucun client ne mérite pas un réveil, et qu'un symptôme le mérite toujours. L'usage processeur seul ne dit rien de ce que vit un client, et c'est l'une des premières alertes que nous supprimons.
En supprimant ce que personne n'a traité. Une alerte déclenchée cinq fois sans action est supprimée ou transformée en ticket. Le risque n'est pas de rater un signal, c'est que l'utile passe inaperçu dans un flot que plus personne ne lit.
Non. Il corrèle les signaux et propose une cause racine, ce qui raccourcit le délai avant le premier ordre. La décision reste humaine, parce qu'agir sur un système critique d'après une suggestion de machine est exactement ce qu'un post-mortem regrette ensuite.
Surtout de la cardinalité. Une étiquette par identifiant client multiplie le volume par mille et n'aide personne à diagnostiquer. Le budget se pose à la conception, étiquette par étiquette, ce qui coûte bien moins cher que de le découvrir sur la facture.
Les définir prend 2 à 6 semaines selon le nombre de parcours critiques et de systèmes traversés, et produit les SLO, le budget d'erreur et la cartographie des parcours critiques. L'instrumentation et un premier incident traité sur cette base suivent en 4 à 10 semaines.
