Les discussions sur les LLM pour le code tournent encore trop autour du dernier modele, de la taille du contexte et des benchmarks. Ces sujets comptent, mais ils n'expliquent pas a eux seuls pourquoi une demo semble brillante alors qu'un systeme en production reste fragile. Si une equipe veut une meilleure IA pour le code, la couche manquante est l'observabilite : voir, mesurer et piloter ce que fait vraiment le systeme sur toute la stack, et pas seulement lire la reponse du modele sur un tour de chat.
Une meilleure IA pour le code commence par l'observabilite
Une reponse conversationnelle est un seul saut. Les agents de code et workflows de livraison assistee par IA sont des chaines completes : etat du repository, outils, sandboxes, CI, APIs, retries, corrections humaines et garde-fous de policy. La performance se joue sur le parcours de bout en bout. Latence et fiabilite de tout le run, cout par resultat utile (PR mergee, build verte, incident corrige), qualite de ce qui est deploye, et comportement lorsque dependances ou prompts changent.
Rien de cela n'est visible dans un dashboard fournisseur qui montre seulement les tokens par requete. Il faut une telemetrie correlee : traces, logs structures et metriques relies a une identite de session ou de requete stable, avec assez de contexte pour filtrer par repo, branche, outil, version de modele et client.
Le probleme de l'agregation des logs
Un seul run d'agent peut traverser une gateway, l'authentification, la recherche vectorielle, le stockage objet, l'API du modele, une sandbox, des linters, des tests et des webhooks. Chaque couche a son format, son horloge, sa retention et ses regles d'echantillonnage. Sans un correlation id ou trace id propage partout, impossible de reconstruire un run logique unique. Les contraintes PII et secrets imposent souvent de redacter ou de separer des flux, ce qui fragmente l'analyse. Et l'echantillonnage agressif sur les services bruyants masque souvent la queue longue qui genere le plus de cout et de latence.
Meme les petits projets generent deja un volume massif
Les equipes sous-estiment souvent le volume produit par une stack "petite". Un seul produit avec une API, un worker, une file, une base et un frontend peut deja emettre chaque jour :
- logs d'acces API et edge : 300k a 1.5M evenements par jour
- logs applicatifs (backend + worker) : 100k a 600k evenements par jour
- logs de cycle de vie des files et jobs : 50k a 300k evenements par jour
- logs SQL lents et connexions base : 20k a 150k evenements par jour
- erreurs client et telemetrie frontend : 10k a 120k evenements par jour
Beaucoup de petits projets se retrouvent donc autour de 500k a 2.5M d'evenements par jour. Avec 14 jours de retention, on arrive vite a 7M a 35M d'evenements. En prenant une moyenne grossiere de 800 bytes a 2 KB par evenement indexe (payload + metadata + overhead d'index), cela represente facilement 10 GB a plus de 70 GB de donnees interrogeables sur une fenetre courte.
Pourquoi la recherche devient difficile dans ces donnees
A cette echelle, la recherche devient un probleme de fiabilite et de cout a part entiere. Les approches type grep texte brut ne tiennent plus. Les plateformes de logs aident, mais en incident on se heurte encore a :
- des resultats trop larges avec des filtres generiques ("errors last 30 minutes")
- des signaux rates quand les filtres sont trop stricts ou les champs incoherents
- des requetes lentes sur des dimensions a forte cardinalite (user id, request id, tags dynamiques)
- des scans couteux quand index et partitionnement ne correspondent pas aux patterns de requete
Le probleme pratique n'est pas seulement le volume. C'est la precision de la requete sous pression. En incident, si les correlation ids manquent, si les noms de champs changent selon les services, ou si les timestamps ne sont pas alignes, retrouver un chemin en echec peut prendre plus de temps que corriger le bug lui-meme.
Centraliser les logs dans un index unique n'est que le debut. Le vrai sujet est de rendre les signaux composables : unites comparables (temps mur, dollars, tokens), identifiants coherents, et vues qui aident vraiment a decider.
L'observabilite complete etait deja difficile avant les LLM
Le besoin de visibilite production n'est pas ne avec les LLM. C'est justement ce qui a pousse la croissance d'ecosystemes autour de Prometheus, Grafana, OpenTelemetry et des APM heberges : les equipes devaient deja relier metriques, logs et traces sur des systemes distribues pour repondre a des questions simples sous pression.
Une stack serieuse n'est jamais un seul service. On cumule base de donnees, replicas et migrations, cache, files de messages et workers, un ou plusieurs backends, API gateway, auth, stockage objet, taches planifiees, et erreurs client-side web ou mobile, souvent avec CDN edge et bruit Kubernetes par-dessus. Chaque couche emet ses propres signaux, avec ses propres proprietaires et modes de panne. Mettre en place collecte, retention, alerting et dashboards est un vrai travail d'ingenierie, et garder cardinalite et cout sous controle reste une discipline continue.
Un outil ne remplace pas cette discipline. Une bonne plateforme d'observabilite apporte stockage, langage de requete et visualisation. Elle ne decide ni les frontieres de service, ni les SLI, ni la politique de sampling, ni les champs indispensables pour debugguer un incident. L'expertise reste decisive : comprendre comment la production casse, quoi correler, et quelles actions appliquer quand les courbes bougent.
Lidless : observabilite pour les agents de code chez AI2H
Chez AI2H, nous accompagnons des clients qui exploitent des workflows de code assistes par LLM en production. Lidless est notre capacite interne d'observabilite dediee aux agents de code. C'est l'outil que nous utilisons pour rassembler le contexte le plus riche possible sur ces workflows : ce qui a tourne, dans quel ordre, a quel cout, avec quel resultat, afin d'eviter de recoller l'histoire a la main dans plusieurs interfaces. A partir de cette base, on peut visualiser et mesurer le comportement en production, puis optimiser les couts, les latences, la qualite des sorties et le comportement des agents en charge reelle, sans se limiter a des metriques fournisseurs isolees. Nous presentons Lidless dans notre page automatisation et outils.
Lidless ne remplace pas l'expertise. Il reduit l'ecart entre telemetrie brute et comprehension exploitable sur les parcours de code les plus complexes. Le modele reste un composant parmi d'autres. La livraison et l'exploitation exigent instrumentation et jugement. Si vous faites face aux couts tokens et aux risques autour du code assiste par IA, nos articles sur les couts caches et risques de securite du vibe coding et sur comment reprendre le controle quand les boucles IA derapent completent cette analyse.
Conclusion
Le prochain saut de performance des LLM pour le code depend moins du modele en tete de benchmark que de votre capacite a observer et piloter tout le cycle de vie des agents. Tant que chaque dependance ne contribue pas a une vision coherente et correlee, vous laissez de la vitesse, de la qualite et de la marge sur la table. L'observabilite n'est pas un bonus. C'est la couche de performance.