Si vous choisissez la surveillance légère : dashboards et alertes classiques
Vous installez Prometheus avec Grafana. Vous configurez des métriques d'infrastructure : CPU, mémoire, latence P95 par endpoint. Trois ingénieurs passent une semaine à créer des dashboards par service. Vous ajoutez des alertes sur les seuils critiques. Le coût initial reste minimal : aucune modification du code applicatif, pas de bibliothèques de tracing à intégrer, pas de stockage massif de spans. Pendant le premier mois, l'équipe apprécie la visibilité nouvelle sur les pics de charge et les anomalies réseau.
Au troisième mois, un incident majeur survient. Une requête utilisateur prend 12 secondes au lieu de 200 millisecondes. Vos dashboards montrent que le service de paiement est lent, mais impossible de savoir pourquoi. Vous consultez les logs applicatifs : rien d'anormal dans les lignes capturées. L'équipe ouvre un terminal, active le mode debug sur un pod de staging, tente de reproduire. Deux heures passent. Le problème disparaît seul. Vous ne saurez jamais quelle combinaison de cache froid, de noisy neighbour sur le cluster, ou de queue depth excessive a causé la dégradation. Votre deprecation memo mentionne "incident non résolu, surveillance insuffisante."
À six mois, votre équipe passe 40% de son temps d'astreinte à corréler manuellement des logs éparpillés dans trois systèmes. Les runbooks accumulent des notes manuscrites du type "si le dashboard X monte pendant que Y reste stable, vérifier manuellement le service Z". Votre NRR stagne parce que les clients enterprise demandent des SLA que vous ne pouvez garantir sans visibilité sur la propagation des erreurs. Le tail latency reste un mystère : vous savez que 1% des requêtes échouent, mais lesquelles, dans quel contexte, avec quelle donnée ? Impossible à dire.
Si vous optez pour l'instrumentation complète : tracing distribué et logging structuré
Vous choisissez Loki pour les logs structurés et Backstage pour centraliser les traces. Chaque service reçoit une instrumentation OpenTelemetry. Les spans capturent chaque appel de base de données, chaque requête inter-services, chaque échec de cache. L'équipe passe trois semaines à modifier le code : ajout de context propagation, enrichissement des métadonnées, configuration des samplers pour éviter un thundering herd sur le backend de stockage. Le coût initial grimpe : licence de stockage, formation des ingénieurs, migration progressive par service.
Au troisième mois, le même incident survient. Une requête prend 12 secondes. Cette fois, vous ouvrez la trace complète dans l'interface. Vous voyez immédiatement : le service de paiement attend 11 secondes sur un appel à l'API bancaire tierce. Le span montre que le cache était vide (cold start documenté), et que l'API bancaire a subi un pic de latence ce jour-là. En cinq minutes, vous identifiez la cause racine, ouvrez un ticket chez le fournisseur avec les preuves exactes, et ajoutez un circuit-breaker pour éviter le blocage futur. Votre north-star definition inclut désormais "résolution d'incident sous 10 minutes avec traces complètes."
À six mois, votre équipe diagnostique les incidents en temps réel pendant les déploiements. Le tracing révèle des patterns invisibles auparavant : certaines requêtes déclenchent un fan-out excessif, d'autres souffrent de schema drift entre staging et production. Vous utilisez les traces pour optimiser les chemins critiques : un refactoring ciblé réduit la latence P99 de 800ms à 120ms. Les clients enterprise signent parce que vous démontrez, preuves à l'appui, une capacité de graceful degradation en cas de panne partielle. Votre quarter-106 retention passe de 78% à 91% grâce à la confiance technique instaurée.
Anatomie de la bifurcation : ce qui différencie vraiment les deux chemins
La surveillance légère repose sur l'hypothèse que les métriques agrégées suffisent. Vous observez les symptômes : "le service X est lent". Mais vous manquez la causalité. Chaque incident devient une enquête artisanale. Les ingénieurs développent un savoir-faire oral, transmis dans les couloirs : "la semaine dernière, ce même dashboard indiquait un souci de base de données, mais c'était en réalité un load shedding mal configuré". Cette connaissance ne se documente pas, ne se scale pas, et disparaît quand l'ingénieur part. Votre noisy on-call rotation past 2am devient insoutenable.
L'observabilité profonde ne vous dit pas seulement que le système est cassé ; elle vous montre la séquence exacte d'événements qui a mené à la casse.
L'instrumentation complète inverse la logique. Vous capturez le contexte de chaque requête individuelle. Quand un utilisateur signale un bug, vous retrouvez sa trace unique, suivez son parcours à travers 14 microservices, identifiez le span qui a échoué, voyez les paramètres exacts passés. Ce changement transforme la culture d'équipe : au lieu de spéculer, vous consultez les faits. Les post-mortems deviennent factuels, les corrections ciblées. PostHog montre que vos temps de résolution moyens passent de 4 heures à 22 minutes après six mois d'instrumentation.
Qui devrait emprunter quel chemin : critères de décision concrets
La surveillance légère convient aux équipes avec moins de cinq services, un traffic prévisible, et des clients tolérants aux incidents occasionnels. Si votre architecture reste monolithique ou composée de deux microservices simples, le coût d'instrumentation dépasse le bénéfice. Vous pouvez diagnostiquer manuellement avec des logs textuels et quelques dashboards. Votre priorité est ailleurs : construire des fonctionnalités, valider le marché, itérer vite. L'observabilité profonde serait du gold-plating.
Signaux que l'instrumentation devient nécessaire
Certains indicateurs annoncent le moment de basculer. Si votre équipe passe plus de temps à enquêter sur des incidents qu'à livrer des fonctionnalités, vous avez franchi le seuil. Si vos clients enterprise exigent des SLA avec pénalités financières, la surveillance basique ne suffit plus. Si vous subissez des incidents en cascade où un service dégradé en bloque trois autres, et que vous ne pouvez tracer la propagation, l'instrumentation devient rentable sous 60 jours.
- Plus de huit microservices en production avec des dépendances inter-services complexes
- Incidents récurrents dont la cause racine reste inconnue après deux heures d'investigation
- Contrats SLA avec clients imposant des temps de résolution inférieurs à une heure
- Équipe d'astreinte qui escalade systématiquement vers l'architecte ou le CTO faute de visibilité
- Back-fill de données ou migrations nécessitant une traçabilité précise des opérations effectuées
- Métriques de tail latency inexpliquées malgré des dashboards détaillés sur les moyennes
Ces signaux révèlent que votre architecture a dépassé la capacité cognitive d'une surveillance manuelle. Vous gérez désormais un système distribué où les interactions entre composants génèrent des comportements émergents. Sans traces, vous pilotez à l'aveugle. L'investissement initial dans l'instrumentation se rentabilise dès le deuxième incident majeur évité grâce à un diagnostic rapide et factuel.
Mise en œuvre progressive : comment instrumenter sans tout casser
L'erreur classique consiste à vouloir tout instrumenter en une fois. Vous bloquez les livraisons pendant un mois, l'équipe perd en vélocité, et la direction panique. La stratégie gagnante consiste à instrumenter par couches, en commençant par les services critiques. Identifiez votre BFF (backend-for-frontend) principal, celui qui orchestre les autres. Ajoutez-y le tracing complet, déployez, observez. Puis étendez aux services appelés en aval.
Séquence d'implémentation recommandée
Chaque phase dure deux à trois semaines. Vous avancez par incrément, validez les gains, ajustez avant de continuer. Cette approche limite les risques et démontre la valeur rapidement, ce qui sécurise le soutien managérial. Snowflake peut stocker vos spans agrégés pour analyse ultérieure, tandis que dbt transforme les données de tracing en métriques métier exploitables par les équipes produit.
- Installer le backend de tracing (Jaeger, Tempo, ou équivalent) et configurer les samplers à 1% pour éviter la surcharge initiale du système
- Instrumenter le service gateway ou BFF principal avec propagation du context vers les appels sortants, en capturant les erreurs HTTP et les latences réseau
- Ajouter le logging structuré sur ce même service avec corrélation trace_id dans chaque ligne de log pour relier traces et événements textuels
- Étendre l'instrumentation aux trois services les plus appelés en aval, en documentant les span tags utilisés pour maintenir la cohérence
- Former l'équipe d'astreinte à lire et interpréter les traces, en organisant des sessions de debug réel sur des incidents passés avec traces disponibles
- Augmenter progressivement le taux de sampling à 10% puis 100% en surveillant le coût de stockage et en ajustant les politiques de rétention
Coûts cachés et retours d'expérience terrain
Le coût de stockage des traces dépasse souvent les prévisions initiales. Un service qui traite 50 000 requêtes par minute génère environ 2TB de spans par jour si vous samplez à 100%. Heureusement, vous n'avez pas besoin de tout garder. Une politique de rétention intelligente conserve 100% des traces d'erreur, 10% des traces lentes (P95+), et 1% des traces normales. Cela réduit le volume de 85% sans perdre les signaux critiques. Prévoyez quand même un budget de 800€ à 2 500€ par mois pour un système de taille moyenne.
Le coût humain est plus subtil. L'équipe doit apprendre un nouveau vocabulaire : spans, traces, context propagation, sampling strategies. Les développeurs juniors confondent souvent metrics et traces. Vous devez documenter les conventions : quels tags ajouter, comment nommer les spans, quelle granularité capturer. Sans standardisation, chaque équipe instrumente différemment, et les traces deviennent inexploitables. Allouez 20% du temps d'un ingénieur senior pendant trois mois pour établir les guidelines et reviewer les pull requests.
En revanche, les gains dépassent largement les coûts. Une équipe cliente a réduit son MTTR (mean time to resolution) de 3,5 heures à 18 minutes en six mois. Une autre a identifié un bug de missing ownership sur un service critique grâce aux traces : aucune équipe ne surveillait un worker asynchrone qui accumulait du retard. Sans tracing, ce problème serait resté invisible jusqu'à l'explosion de la file d'attente. Le GRR (gross revenue retention) s'est amélioré de 7 points de pourcentage l'année suivante, directement attribuable à moins de downtime client.
Comment trancher : la grille de décision pour votre contexte
Posez-vous ces questions. Si vous répondez oui à trois ou plus, l'instrumentation complète devient rentable sous six mois. Première question : votre équipe passe-t-elle plus de six heures par semaine à corréler manuellement des logs pour diagnostiquer des incidents ? Deuxième : avez-vous perdu un client ou raté un renouvellement à cause d'incidents répétés que vous ne pouviez expliquer précisément ? Troisième : votre architecture compte-t-elle plus de cinq services avec des appels synchrones en chaîne ? Quatrième : les ingénieurs seniors partent-ils en emportant la connaissance tribale sur "comment débugger le système" ? Cinquième : vos incidents en production se reproduisent-ils malgré des correctifs, parce que vous n'avez jamais identifié la vraie cause ?
Si vous répondez non à la majorité, restez sur la surveillance légère encore six mois. Investissez plutôt dans la stabilisation de votre architecture, la réduction de la dette technique, ou la migration vers des patterns plus simples. L'observabilité profonde ne compense pas une architecture mal conçue. Elle éclaire les problèmes, mais ne les résout pas. Assurez-vous d'abord que votre système mérite l'instrumentation. Un monolithe bien architecturé avec un load balancer et trois instances n'a pas besoin de tracing distribué. Concentrez vos efforts sur la livraison de valeur métier.
Le moment idéal pour instrumenter se situe juste avant que la complexité vous échappe, pas après. Si vous attendez la crise, vous instrumenterez dans l'urgence, mal, et vous en tirerez peu de bénéfices. Si vous instrumentez trop tôt, vous gaspillez du temps sur une infrastructure qui changera radicalement dans trois mois. Surveillez les signaux faibles : quand les incidents commencent à prendre plus d'une heure à diagnostiquer, quand les réunions post-mortem tournent en débats spéculatifs faute de données, quand l'équipe évite l'astreinte par peur de passer la nuit à chercher une aiguille dans une botte de logs. C'est le moment.