Aller au contenu principal

Cas d'usage réels + FAQ complète

Résumé : l'observabilité n'est pas une théorie — c'est ce qui permet à Google d'exploiter des millions de machines avec des équipes réduites, et ce qui distingue une équipe qui apprend de ses incidents d'une équipe qui les répète. Cette dernière leçon présente cinq cas documentés, la culture du post-mortem sans blâme, et répond aux 14 questions fréquentes.

1. Cas d'usage 1 — Google et la naissance du SRE​

La règle des 50 % est un mécanisme d'incitation remarquablement bien conçu. Elle ne se contente pas de protéger les SRE de l'épuisement : elle crée une pression structurelle sur l'équipe de développement pour améliorer la fiabilité. Si votre service génère trop de travail manuel, vous récupérez ce travail. C'est de l'ingénierie organisationnelle, pas seulement technique.

À savoir : le livre « Site Reliability Engineering » de Google est disponible gratuitement en ligne. C'est probablement la meilleure lecture technique gratuite du domaine.

2. Cas d'usage 2 — L'anatomie d'un incident bien géré​

Comparez avec le scénario de la leçon 1 : là, deux heures d'incident dont une heure vingt de diagnostic à l'aveugle, découvert par un client. Ici, dix minutes au total, détecté automatiquement, diagnostiqué en quatre minutes grâce à l'enchaînement métrique → trace → log.

La différence n'est pas le talent de l'équipe. C'est l'instrumentation.

3. Cas d'usage 3 — La culture du post-mortem sans blâme​

La reformulation des questions est le cœur de la pratique. « Qui a fait l'erreur ? » produit de la défensive et aucun apprentissage. « Comment notre système a-t-il permis cette erreur ? » produit un garde-fou qui protégera toutes les futures personnes. L'erreur humaine n'est jamais la cause racine — c'est le symptôme d'un système qui la rendait possible.

Précision importante : « sans blâme » ne signifie pas « sans responsabilité ». Les actions correctives ont des responsables nommés et des échéances. Ce qui est écarté, c'est la recherche d'un coupable de l'incident, pas la responsabilité de l'amélioration.

4. Cas d'usage 4 — Une PME qui démarre de zéro​

C'est le cas d'usage le plus utile à retenir pour la majorité des lecteurs. Aucun outil sophistiqué, aucune équipe SRE dédiée, moins de 100 euros par mois — et une transformation complète de la capacité à exploiter le service.

Notez l'ordre des étapes : la surveillance externe de la page d'accueil en semaine 1. C'est l'action au meilleur rapport bénéfice sur effort qui existe en observabilité, et elle prend quinze minutes à mettre en place.

5. Cas d'usage 5 — Quand l'observabilité coûte trop cher​

Un principe à garder en tête : le but n'est pas de tout collecter, c'est de collecter ce qui répond à des questions utiles. Un log de niveau DEBUG que personne ne lira jamais coûte de l'argent chaque mois et dégrade la lisibilité de ce qui compte.

6. Les 14 questions les plus fréquentes​

1. Par où commencer si je n'ai rien du tout ?

Dans cet ordre précis, du plus rentable au moins rentable :

  1. Une surveillance externe de votre page d'accueil ou d'un point de santé, toutes les 60 secondes, avec alerte. Quinze minutes de configuration, quelques euros par mois. Vous ne découvrirez plus les pannes par vos clients.
  2. Le taux d'erreur de vos points d'entrée principaux, avec une alerte.
  3. La latence p99 de ces mêmes points d'entrée.
  4. Des logs structurés centralisés, avec une conservation courte.
  5. Le traçage distribué, uniquement si vous avez plus de trois services.

Ne commencez pas par installer une pile complète. Commencez par le point 1, aujourd'hui.

2. Combien coûte l'observabilité ?

Ordres de grandeur mensuels :

  • Projet personnel : gratuit (offres gratuites de Grafana Cloud, Prometheus auto-hébergé).
  • Petite équipe, quelques machines : entre 0 et 100 euros.
  • Équipe moyenne, 20 à 50 machines : entre 300 et 2 000 euros selon la solution.
  • Grande organisation : de quelques milliers à plusieurs dizaines de milliers d'euros — c'est un poste budgétaire à part entière.

Repère utile souvent cité : au-delà de 10 à 15 % du coût de votre infrastructure, votre observabilité mérite un audit. Le plus souvent, la cause est le volume de logs.

3. Combien de temps garder les données ?

Recommandations par type de donnée :

  • Métriques : 15 mois pour les données agrégées (utile pour comparer d'une année sur l'autre), 15 jours en pleine résolution. Elles sont peu coûteuses.
  • Logs : 7 à 30 jours suffisent dans la grande majorité des cas. C'est le poste le plus coûteux, donc le plus important à limiter.
  • Traces : 3 à 7 jours. On les consulte presque toujours immédiatement après un incident.
  • Exception : les logs d'audit et de conformité peuvent exiger plusieurs années — stockez-les séparément, dans un stockage d'archive bon marché.
4. Faut-il instrumenter manuellement ou automatiquement ?

Commencez par l'instrumentation automatique. OpenTelemetry propose des agents qui instrumentent automatiquement les bibliothèques courantes (serveurs HTTP, clients de base de données, clients HTTP) sans modifier votre code. Vous obtenez immédiatement les traces et les métriques de base.

Ajoutez de l'instrumentation manuelle pour ce qui a du sens métier : « durée du calcul de remise », « nombre d'articles dans le panier ». C'est là que réside la vraie valeur, car aucun agent automatique ne connaît votre métier.

5. Comment gérer l'astreinte sans épuiser l'équipe ?

Cinq principes qui font une réelle différence :

  1. Peu d'alertes, mais toutes pertinentes. Une astreinte devrait être réveillée rarement. Si c'est chaque nuit, le problème est la conception des alertes.
  2. Une procédure écrite pour chaque alerte. Voir la leçon 6.
  3. Une rotation équitable, connue à l'avance, avec compensation.
  4. Le droit de ne pas résoudre à 3 h du matin : rétablir le service suffit, comprendre attendra le lendemain.
  5. Chaque réveil nocturne génère une action corrective pour qu'il ne se reproduise pas. Sinon vous acceptez implicitement que ce soit normal.
6. SRE, DevOps, ingénieur plateforme : quelle différence ?
  • DevOps — une culture et un ensemble de pratiques : responsabilité partagée, automatisation, boucles de retour rapides. Ce n'est pas un métier à l'origine, même si le titre existe partout.
  • SRE — l'implémentation concrète du DevOps telle que définie par Google, avec ses outils propres : SLO, budget d'erreur, règle des 50 %, réduction du travail ingrat.
  • Ingénieur plateforme — construit une plateforme interne que les équipes produit consomment en libre-service. Se concentre sur l'expérience développeur.

Formule utile : « le DevOps est le but, le SRE est une méthode pour l'atteindre, la plateforme est un moyen de l'industrialiser ».

7. Comment mesurer l'expérience réelle des utilisateurs ?

Le serveur peut répondre en 40 ms et l'utilisateur attendre 4 secondes — à cause du réseau, du navigateur, du JavaScript. Deux approches complémentaires :

RUM (Real User Monitoring) — vous mesurez depuis le navigateur des vrais utilisateurs. Les Core Web Vitals de Google sont le standard : LCP (temps d'affichage du contenu principal), INP (réactivité aux interactions), CLS (stabilité visuelle de la mise en page).

Surveillance synthétique — un robot simule un parcours utilisateur toutes les X minutes, depuis plusieurs régions du monde. Utile pour détecter les pannes même sans trafic réel, la nuit par exemple.

Les deux sont utiles : le RUM dit ce que vivent vos utilisateurs, le synthétique détecte les pannes de façon proactive.

8. Que faire quand tous les indicateurs sont verts mais que ça ne marche pas ?

C'est le signe classique que vous mesurez les causes au lieu des symptômes. Trois vérifications :

  1. Mesurez-vous le taux d'erreur du point de vue de l'utilisateur ou seulement l'état des machines ?
  2. Avez-vous des métriques métier ? Si le nombre de commandes s'effondre alors que tout est vert, il y a un problème — souvent côté client (JavaScript cassé, bouton invisible).
  3. Vos sondes vérifient-elles quelque chose de réel ? Une sonde qui renvoie systématiquement « OK » sans vérifier la base de données ne prouve rien.

Le cas d'école : votre base de données est injoignable, donc vos serveurs web ne travaillent presque plus, donc leur charge est basse et tous vos voyants machine sont verts.

9. Faut-il un outil différent par pilier ?

Non, et c'est plutôt déconseillé. Le point critique est la corrélation : pouvoir passer d'une métrique à une trace puis aux logs correspondants en un clic.

Trois approches viables :

  • Une pile cohérente : Prometheus + Loki + Tempo + Grafana. Corrélation native, tout open source.
  • Une solution commerciale unifiée : Datadog, New Relic, Grafana Cloud.
  • Outils séparés mais reliés par OpenTelemetry — possible, mais la corrélation demande du travail.

À éviter : trois outils indépendants sans identifiant de trace commun. Vos ingénieurs passeront leur temps à comparer des horodatages à la main.

10. Comment convaincre ma direction d'investir dans l'observabilité ?

Parlez en durée d'incident et en euros :

  • « Notre dernier incident a duré 2 heures, dont 1h20 uniquement à chercher la cause. »
  • « Avec de l'observabilité, ce diagnostic prendrait 10 minutes. »
  • Chiffrez le coût d'une heure d'indisponibilité pour votre activité.
  • Multipliez par le nombre d'incidents de l'an dernier.
  • Comparez au coût annuel de l'outillage — l'écart est généralement considérable.

Argument complémentaire souvent décisif : « nous découvrons nos pannes par nos clients ». Aucune direction n'aime entendre cela deux fois.

11. L'observabilité est-elle utile en développement, ou seulement en production ?

Principalement en production, mais elle apporte aussi en développement :

  • Un traçage local révèle immédiatement les problèmes de requêtes en cascade (le problème « N+1 ») avant même la mise en production.
  • Un profilage identifie les fonctions coûteuses pendant le développement.
  • Instrumenter tôt évite d'avoir à le faire en urgence pendant un incident.

Le vrai bénéfice de commencer tôt : l'instrumentation devient une habitude d'écriture de code, au lieu d'un chantier ajouté après coup.

12. Comment observer un système Kubernetes ?

Kubernetes ajoute une couche à surveiller, en plus de vos applications :

  • Métriques du cluster : nœuds, pods en attente, pods non planifiables, ressources demandées contre réellement utilisées.
  • Redémarrages de pods — un pod qui redémarre en boucle (CrashLoopBackOff) est le symptôme numéro un.
  • Sondes de vivacité et de disponibilité en échec.
  • Limites atteintes : un conteneur tué pour dépassement mémoire (OOMKilled) est très fréquent et souvent silencieux.
  • Événements Kubernetes — une source d'information très riche et sous-exploitée.

L'outillage standard : kube-prometheus-stack, une distribution qui installe Prometheus, Grafana, Alertmanager et des tableaux de bord Kubernetes préconfigurés. Voir notre cours Kubernetes.

13. Quels salaires dans le domaine ?

Ordres de grandeur en France, très variables selon la région et le secteur :

  • Débutant DevOps avec bases d'observabilité : entre 35 000 et 45 000 euros brut annuels.
  • SRE ou DevOps confirmé (3 à 5 ans) : entre 50 000 et 70 000 euros.
  • SRE senior : entre 70 000 et 90 000 euros.
  • Ingénieur plateforme senior ou spécialiste observabilité : au-delà, notamment en région parisienne, en conseil ou dans les entreprises produit.

Les compétences les mieux valorisées : Prometheus et PromQL, OpenTelemetry, définition de SLO, Kubernetes, et la capacité à réduire concrètement les durées d'incident.

14. Par où commencer concrètement demain matin ?

Plan sur cinq jours, applicable à un vrai projet :

  1. Jour 1 — Mettez en place une surveillance externe de votre page d'accueil, toutes les 60 secondes, avec alerte SMS. Quinze minutes. Bénéfice immédiat.
  2. Jour 2 — Instrumentez le taux d'erreur de vos trois points d'entrée principaux. Créez une seule alerte dessus.
  3. Jour 3 — Ajoutez la latence en centiles (p50, p99) sur ces mêmes points. Regardez le p99 — il vous surprendra probablement.
  4. Jour 4 — Passez vos logs en format structuré avec un identifiant de requête. Centralisez-les.
  5. Jour 5 — Écrivez une procédure pour votre alerte du jour 2 : que faire, quoi vérifier, qui contacter.

Semaine suivante : définissez un seul SLO sur votre parcours le plus critique, et validez-le avec le métier.

Le principe : chaque jour apporte un bénéfice utilisable. Ne planifiez pas six mois de chantier.

7. Ce que vous avez appris dans ce cours​

8. Votre prochaine étape​

Piste 1 · Compléter votre culture technique​

Piste 2 · Passer à la pratique​

Piste 3 · Lire les références du domaine​

  • « Site Reliability Engineering » (Google, 2016) — disponible gratuitement en ligne, la référence absolue.
  • « The SRE Workbook » (Google, 2018) — la suite, orientée mise en pratique des SLO.
  • « Observability Engineering » (Charity Majors et al., 2022) — la vision moderne de l'observabilité.

9. Un dernier conseil​

Faites la chose la plus simple, aujourd'hui.

N'attendez pas d'avoir le budget pour Datadog, ni le temps d'installer une pile Prometheus complète. Mettez en place, cette semaine, une surveillance externe de votre page d'accueil avec une alerte SMS. Quinze minutes de travail.

À partir de cet instant, vous ne découvrirez plus vos pannes par vos clients. Et c'est déjà la moitié du bénéfice de l'observabilité, pour presque rien.

Le reste — les métriques, les traces, les SLO — viendra ensuite, une brique à la fois.

Retenir en 30 secondes​

  • Google a inventé le SRE en 2003 en confiant l'exploitation à des développeurs, pour qu'ils l'automatisent.
  • La règle des 50 % limite le travail répétitif et crée une pression saine sur la fiabilité.
  • Le livre « Site Reliability Engineering » est gratuit en ligne — la meilleure lecture du domaine.
  • Le même incident prend 2 heures sans observabilité et 10 minutes avec. La différence est l'instrumentation, pas le talent.
  • Post-mortem sans blâme : remplacez « qui a fait l'erreur ? » par « comment notre système l'a-t-il permise ? ».
  • Une PME peut tout transformer en 8 jours-homme et moins de 100 euros par mois.
  • L'observabilité coûte cher si on ne la gère pas : niveau DEBUG en production, traces à 100 %, conservation excessive.
  • L'action la plus rentable : une surveillance externe de votre page d'accueil. Quinze minutes.
  • Repère : au-delà de 10 à 15 % du coût de votre infrastructure, auditez votre observabilité.
  • Commencez petit, aujourd'hui. Ne planifiez pas six mois de chantier.

Merci d'avoir suivi ce cours découverte observabilité ! 🎉

Envie de continuer ? Retour à la table des matières ou passer au cours Premium Monitoring et Logs.

Dernière étape : passez le quiz de fin de cours — cinq questions corrigées et expliquées, trois minutes, pour vérifier que l'essentiel est acquis.