Observabilité d'une app buildée à l'IA : la stack LGTM sur un VPS à 5 €

Un utilisateur signale que son avatar « saute » à l’écran. Un autre dit que le son coupe par moments. Tu ouvres le code, tu lances l’application en local : tout fonctionne parfaitement.

Ce bug-là ne se reproduit pas sur ta machine. Il n’existe qu’en production, avec de vrais utilisateurs, une vraie latence réseau et des conditions que tu ne peux pas simuler. Sans traces exploitables, tu ne le corrigeras pas, et ton agent encore moins, parce qu’il ne dispose de rien d’autre que ce que tu lui donnes à lire.

TL;DR

• Un agent ne peut déboguer que ce qu’il peut lire. Sans logs structurés, il propose des hypothèses plausibles au lieu de diagnostics.
• La stack LGTM (Loki pour les logs, Grafana pour la visualisation, Tempo pour les traces, Mimir pour les métriques) tourne sans difficulté sur un petit VPS à quelques euros par mois.
• Le log utile n’est pas le log verbeux : il est structuré, corrélé par un identifiant, et il contient l’état, pas seulement l’événement.
• Un agent de surveillance qui lit les traces et remonte les anomalies transforme la production en source de diagnostic plutôt qu’en boîte noire.

Pourquoi l’observabilité compte plus quand on développe avec de l’IA

Un développeur qui connaît son application par cœur compense un manque de logs par son intuition. Il sait où ça casse d’habitude, quelle zone est fragile, quel enchaînement est suspect.

Un agent n’a aucune de ces ressources. Il n’a que le texte que tu lui fournis. Et devant un problème mal documenté, un modèle probabiliste fait ce pour quoi il est conçu : il produit l’explication la plus plausible, pas la plus vraie.

Concrètement, sans traces exploitables, tu obtiens une liste de causes possibles génériques (« c’est peut-être un problème de synchronisation », « vérifiez la latence réseau ») qui te fait perdre des heures.

Avec une trace complète de l’incident, l’agent lit ce qui s’est réellement passé et propose une correction sur des faits. L’observabilité n’est pas un confort d’exploitation : c’est le carburant du débogage assisté par IA.

Ce que la stack LGTM apporte, et pourquoi elle tient sur un petit serveur

LGTM est l’acronyme des quatre briques de la suite Grafana :

• Loki, la collecte et la recherche de logs.
• Grafana, la visualisation et les alertes.
• Tempo, les traces distribuées : le chemin complet d’une requête à travers les composants.
• Mimir, les métriques : compteurs, latences, taux d’erreur dans le temps.

L’ensemble est documenté sur le site officiel de Grafana, et la totalité de ces briques est utilisable sans licence.

Le point important pour un projet de taille modeste : cette stack a la réputation d’être « pour les grosses infrastructures ». C’est faux à cette échelle. Un VPS à quelques euros par mois (de l’ordre de 5 €) suffit largement pour héberger l’observabilité d’une application avec un trafic réel mais modéré. La configuration prend une soirée, et le retour sur investissement est immédiat au premier bug de production.

Les quatre briques n’ont pas la même urgence. Si tu dois commencer par une seule, commence par les logs : ils règlent la majorité des cas. Les traces deviennent indispensables dès que plusieurs services communiquent entre eux. Les métriques servent surtout à détecter les dégradations progressives, celles que personne ne signale.

Le log utile : structuré, corrélé, contextualisé

C’est ici que se joue la différence entre une observabilité décorative et une observabilité qui sert.

1. Structuré plutôt que textuel

Un message libre du type « Erreur lors de la synchronisation » n’est pas exploitable : impossible de le filtrer, de le compter, de le corréler.

Un log structuré porte des champs nommés : un événement, un identifiant d’utilisateur, un identifiant de session, une durée, un état. Il devient alors requêtable, « montre-moi toutes les désynchronisations de plus de 500 ms pour les sessions de plus de trois participants ». C’est cette requête qui trouve le bug, pas la lecture d’un fichier texte.

2. Corrélé par un identifiant unique

Chaque action utilisateur reçoit un identifiant qui la suit à travers tous les composants traversés. Sans lui, tu as des morceaux d’histoires mélangées ; avec lui, tu peux reconstituer exactement le parcours d’un incident.

C’est l’élément le plus utile à donner à un agent : une trace complète corrélée raconte une histoire cohérente, du clic initial jusqu’à l’erreur finale.

3. Contextualisé : l’état, pas seulement l’événement

Un log qui dit « la position a été rejetée » est insuffisant. Un log qui dit « position rejetée : reçue (x=340, y=112), dernière position connue (x=180, y=95), écart 162 px, seuil 100 px, latence 780 ms » contient le diagnostic.

La règle : au moment où tu écris le log, demande-toi de quoi tu aurais besoin pour comprendre l’incident sans accès à la machine. C’est exactement ce dont l’agent aura besoin.

4. Ce qu’il ne faut jamais logguer

Les données personnelles, les jetons d’authentification, les mots de passe, le contenu des messages. Un journal est conservé, dupliqué, parfois exporté, et un secret dans un log est un secret compromis. Les identifiants techniques (anonymes) suffisent au diagnostic.

L’agent de surveillance : de la boîte noire au diagnostic continu

Une fois les traces disponibles, une possibilité s’ouvre : un agent dont le rôle est de les lire.

Son travail n’est ni de corriger ni de déployer. Il observe et il rapporte :

• Un taux d’erreur qui monte anormalement sur un composant.
• Un motif d’erreur inédit, jamais vu jusqu’ici.
• Une latence qui se dégrade progressivement, sans franchir aucun seuil d’alerte.
• Un enchaînement inhabituel dans les traces.

Ce qu’un agent apporte par rapport à une alerte classique : une alerte se déclenche sur un seuil défini à l’avance, donc sur un problème que tu avais anticipé. Un agent qui lit des traces peut signaler ce que tu n’avais pas prévu, « depuis le déploiement de mardi, un type d’erreur qui n’existait pas avant apparaît trois fois par heure ».

La règle de séparation, non négociable : l’agent de surveillance observe et alerte. Il ne modifie rien en production. Un agent qui pourrait à la fois diagnostiquer et corriger sur un système en production est un risque, pas un gain : c’est exactement la séparation des rôles qui structure une organisation d’agents inspirée des boucles ITIL, où détecter, décider et changer sont trois responsabilités distinctes.

Et parce que ce travail consiste à lire beaucoup pour produire peu, une synthèse courte, il correspond exactement au profil des tâches à confier à un sous-agent en fan-out.

Les bugs que seule la production révèle

Certaines catégories de défauts n’apparaissent jamais en local. Ce sont précisément celles qui rendent l’observabilité indispensable.

Les problèmes de synchronisation temps réel. Deux utilisateurs, deux latences différentes, un état partagé : la divergence est invisible seul sur sa machine. Elle demande des traces horodatées côté serveur pour être comprise.

Les défauts de média temps réel. Une coupure audio dépend du réseau, du navigateur, du matériel de l’utilisateur. Reproduire est illusoire ; instrumenter est la seule voie.

Les effets de concurrence. Deux actions simultanées sur la même ressource produisent un état incohérent une fois sur mille. Sans corrélation par identifiant, ce bug est indétectable.

Les dégradations progressives. Une fuite mémoire ou une requête qui ralentit à mesure que les données s’accumulent ne déclenche aucune alerte, jusqu’au jour où tout s’arrête. Seules les métriques dans la durée les révèlent.

Par où commencer, dans l’ordre

1. Les logs structurés dans l’application. Avant tout serveur, avant tout tableau de bord. Sans logs exploitables, l’infrastructure ne sert à rien.
2. L’identifiant de corrélation. Généré à l’entrée, propagé partout. C’est un petit travail, et c’est le plus rentable de la liste.
3. La collecte centralisée. Un petit VPS, la stack déployée, les logs qui arrivent.
4. Trois tableaux de bord, pas trente. Taux d’erreur, latence, volume. Les tableaux de bord que personne ne regarde sont du bruit.
5. Les alertes sur ce qui est actionnable. Une alerte qui ne déclenche aucune action doit être supprimée, sinon elle apprend à l’équipe à ignorer les alertes.
6. L’agent de surveillance, en dernier, quand il y a de la matière à lire.

Checklist : rendre une application déboguable par un agent

• Les logs sont structurés en champs nommés, pas en texte libre.
• Chaque action utilisateur porte un identifiant de corrélation propagé de bout en bout.
• Les logs contiennent l’état au moment de l’erreur, pas seulement l’événement.
• Aucune donnée personnelle ni aucun secret ne figure dans les journaux.
• Les logs sont centralisés et requêtables, pas dispersés sur les machines.
• Trois tableaux de bord maximum, tous consultés réellement.
• Chaque alerte correspond à une action précise à mener.
• L’agent de surveillance observe et rapporte, sans droit de modification en production.
• Je peux extraire la trace complète d’un incident et la donner à lire à un agent.

FAQ

Faut-il vraiment une stack complète pour une petite application ?

Non, et il ne faut pas commencer par là. Des logs structurés écrits dans un fichier et consultables couvrent déjà l’essentiel des besoins d’un projet à faible trafic. La centralisation devient utile quand il y a plusieurs services, plusieurs machines, ou quand tu perds du temps à chercher où regarder. L’ordre correct est toujours : bien logguer d’abord, centraliser ensuite.

Combien coûte cette observabilité ?

Un petit VPS de l’ordre de 5 € par mois suffit pour un projet à trafic modéré, les briques logicielles étant utilisables sans licence. Le coût réel est ailleurs : le temps de mise en place initiale, et surtout la discipline d’instrumentation dans le code. La rétention est le principal facteur de dérive, garder trois mois de logs détaillés coûte bien plus cher en stockage que d’en garder sept jours, et n’apporte presque rien en pratique.

Comment donner efficacement des logs à un agent ?

Jamais en vrac. Extrais la trace complète d’un incident précis, filtrée par identifiant de corrélation, sur une fenêtre de temps courte. Un agent noyé sous dix mille lignes produit une synthèse vague ; le même agent avec quarante lignes cohérentes retraçant un incident produit un diagnostic précis. La qualité du filtrage compte plus que le volume fourni.

L’agent de surveillance peut-il générer trop de bruit ?

Oui, et c’est le principal risque à surveiller. Un agent qui signale tout ce qui sort légèrement de l’ordinaire sera ignoré au bout d’une semaine, exactement comme une alerte trop sensible. La bonne approche est de démarrer avec un périmètre volontairement étroit (un seul type d’anomalie, par exemple les motifs d’erreur inédits) et de n’élargir qu’après avoir vérifié que chaque remontée était justifiée.

Conclusion

Une application développée avec de l’IA n’est pas plus fragile qu’une autre. Elle est simplement plus difficile à déboguer sans instrumentation, parce que l’agent qui l’a écrite n’a aucune mémoire du projet et ne dispose que de ce que tu lui montres.

Des logs structurés, un identifiant de corrélation et une collecte centralisée sur un petit serveur : voilà le socle. À partir de là, un incident de production cesse d’être une énigme pour devenir une trace à lire, par toi, ou par un agent.

Si tu ne fais qu’une chose cette semaine : ajoute un identifiant de corrélation à tes requêtes. Tout le reste devient beaucoup plus simple ensuite.

Cette stack est montrée en fonctionnement dans le live Team Studio consacré aux bugs et à la refacto.