Observer un produit, c'est le traduire dans un langage que les ingénieurs comprennent : métriques, logs, traces. Et ce langage, on le code. On choisit les noms des métriques, on structure les labels, on expose des endpoints santé, on aligne les dashboards avec les contrats d'API.
Ce que signifie "observability as code"
- Définir ses métriques comme du code : elles ont un nom, un type, un owner et un seuil. On stocke leur définition dans un repo, on les versionne et on les teste.
- Automatiser la configuration (Alertmanager, dashboards Grafana, règles SRE) pour éviter les erreurs manuelles à chaque lancement.
- Documenter les incidents dans le même endroit : un incident devient une story dans la même base que le code qui le génère.
Quand tout est lisible, un ingénieur peut expliquer la gravité d'un incident à partir d'un seul commit et d'un tableau de bord cohérent.
Pourquoi cela change la donne
La plupart des alertes deviennent bruit quand les seuils sont arbitraires. En versionnant les règles, on peut revenir en arrière, comprendre quand une modification a brisé la sensibilité d'un indicateur, et prévenir les faux positifs avant qu'ils ne saturent l'équipe.
L'observabilité devient un produit à part entière. On la code, on la révise en revue, on l'intègre dans les plans de charge et on la mesure comme n'importe quelle API critique.