Savoir avant que le client n'appelle

Vendredi, 16 h 40. Un client écrit que votre application est « lente depuis ce matin ». Vous ouvrez le tableau de bord : tout est vert. Le processeur plafonne à 30 %, la mémoire est stable, la sonde de disponibilité répond 200 depuis trois semaines sans interruption. Vous n'avez rien vu, et pourtant le client a raison. Une heure plus tard, vous découvrez que 4 % des requêtes mettent plus de dix secondes, toutes sur le même point d'entrée, toutes pour les clients dont le compte contient plus de dix mille lignes. Aucune de vos sondes ne pouvait le voir : elles vérifiaient que le service répondait, pas qu'il répondait correctement à tout le monde.

Ce décalage n'est pas un défaut d'outillage, c'est un défaut de méthode. Une sonde vérifie une hypothèse que vous avez formulée à l'avance : « le processus est-il vivant », « le disque est-il plein ». Elle est excellente pour les pannes que vous avez déjà rencontrées, et aveugle à toutes les autres. Or en production, les incidents qui coûtent cher sont presque toujours ceux que personne n'avait anticipés : une dépendance qui ralentit sans tomber, un cache qui se vide, une requête SQL dont le plan d'exécution change après une montée de version. La question utile n'est donc pas « ai-je assez de sondes », mais « quand un incident inédit arrive, mes données me permettent-elles de comprendre sans déployer de code ». C'est exactement ce que désigne le mot observabilité, et c'est un critère mesurable, pas un slogan de fournisseur.