Nous connaissons notre code en détail, mais beaucoup moins son comportement réel une fois en production.
Quand une application ralentit, consomme plus de mémoire ou se comporte différemment, une question revient toujours : est-ce normal ?
Face à ces situations, nous réagissons souvent de la même manière : ajouter des logs, augmenter les ressources, redéployer, tester des hypothèses. Pourtant, avant de corriger un problème, encore faut-il comprendre ce qui se passe réellement. C’est précisément le rôle de l’observabilité : rendre visible le comportement interne d’un système à partir de ce qu’il expose, pour passer de l’intuition à la compréhension.
Mais une métrique seule ne dit rien. Une latence à 300 ms, est-ce inquiétant ? Sans référence, impossible de distinguer une anomalie d’un comportement attendu. Cette référence transforme un signal brut en information exploitable. Et elle ne se construit pas au moment où un incident survient : elle s’apprend progressivement, dès les premières phases de développement, de test et de recette.
Plus tôt l’observabilité devient accessible, plus il devient possible de comprendre le comportement nominal avant que les problèmes apparaissent.
Dans ce retour d’expérience chez Atol CD, nous verrons ce qui a été mis en place pour rendre cette compréhension disponible par défaut dans un contexte bien réel : multi-équipes, multi-technologies, nombreux projets, le tout avec des composants open source auto-hébergés.
L’objectif n’est pas de produire davantage de données, mais de construire une baseline fiable et la rendre disponible en supprimant au maximum la friction côté développeur.
Au-delà des outils, nous reviendrons sur les choix structurants et les difficultés rencontrées : comment standardiser des données provenant de technologies différentes, éviter les dashboards jetables, construire des conventions qui tiennent dans le temps ou encore rendre une stack mutualisée réellement simple à adopter.
Avec démonstrations et exemples concrets à l’appui, nous verrons autant ce qui a fonctionné que ce qui ne s’improvise pas.
Parce que le vrai défi n’est pas de produire plus de données d’observabilité. C’est d’arrêter de deviner.
