Agent BB-LOG — Quand l'IA surveille les logs à ma place
Partie 1 — Le problème des erreurs en production
Les erreurs existent. La question c’est comment on les traite.
Dans toute application en production, des erreurs se produisent. C’est inévitable. La vraie question, c’est : est-ce qu’on les voit ? Est-ce qu’on les comprend ? Est-ce qu’on agit dessus dans un délai raisonnable ?
Sentry, l’outil de monitoring d’erreurs que j’utilise sur mes projets, envoie un email hebdomadaire de résumé. C’est utile. Mais c’est un résumé de haut niveau : les erreurs les plus fréquentes, leur nombre d’occurrences, leur première apparition. Pas vraiment de quoi prendre une décision éclairée sur ce qui mérite une correction prioritaire.
Pour vraiment comprendre une erreur Sentry, il faut aller dedans : lire la stack trace, regarder quand elle a commencé à apparaître, comprendre combien d’utilisateurs sont touchés, croiser avec le code source pour identifier la cause probable. C’est un travail de titan quand on a plusieurs erreurs à traiter sur plusieurs projets.
L’accumulation silencieuse
Le vrai problème, ce n’est pas l’erreur isolée. C’est l’accumulation progressive d’erreurs non traitées qui finit par peser sur la qualité du produit et la confiance des utilisateurs. On ne les traite pas parce que c’est long, parce qu’on ne sait pas par où commencer, parce qu’il n’y a pas de processus clair.
J’avais besoin d’un processus automatisé qui transforme la surveillance des erreurs en actions concrètes dans GitHub.
Partie 2 — Ce que fait l’agent BB-LOG
Un audit hebdomadaire profond des erreurs Sentry
L’agent BB-LOG tourne une fois par semaine. Sa mission : passer en revue toutes les erreurs actives dans Sentry, les analyser en profondeur, et produire un rapport actionnable.
Ce n’est pas une simple copie du résumé Sentry. L’agent effectue une analyse réelle :
| Critère d’analyse | Ce que l’agent évalue |
|---|---|
| Fréquence | Nombre d’occurrences sur la période |
| Impact utilisateur | Nombre d’utilisateurs distincts touchés |
| Gravité | Blocage complet, dégradation, ou comportement inattendu ? |
| Évolution | L’erreur est-elle nouvelle, en hausse, stable ou en baisse ? |
| Récidive | A-t-elle déjà été signalée dans une session précédente ? |
Pour chaque erreur significative, l’agent va plus loin que les métadonnées Sentry. Il lit la stack trace, retrouve le fichier source concerné, et produit une pré-analyse des causes possibles.
La connexion MCP Sentry
L’accès à Sentry se fait via le protocole MCP (Model Context Protocol). Cela permet à l’agent de fouiller les issues Sentry en profondeur : lire les breadcrumbs, accéder aux détails de l’environnement au moment de l’erreur, voir les sessions utilisateurs affectées, naviguer dans l’historique d’une issue.
C’est cette profondeur d’accès qui fait la différence. L’agent ne lit pas un résumé — il explore, exactement comme un développeur qui irait manuellement faire le tour des erreurs.
Partie 3 — Du rapport Sentry aux tickets GitHub
Un CRON et Claude Code en mode CLI
L’agent BB-LOG est appelé via une tache CRON, que j’ai programmée chaque semaine. Ensuite, j’utilise Claude Code en mode CLI avec le mode autonome activé. Cela me permet d’utiliser mon forfait Claude directement — pas besoin de tokens API supplémentaires.
Un rapport docx structuré
Le premier livrable de l’agent, c’est un rapport au format docx. Pourquoi docx plutôt qu’un simple texte ? Parce que ce rapport est destiné à être partagé — avec un client, avec l’équipe, en réunion. Un document structuré avec une mise en page claire est bien plus efficace qu’un dump de terminal.
Le rapport inclut pour chaque erreur :
- Un résumé de l’erreur en langage clair
- Le contexte technique (fichier, fonction, ligne)
- L’impact estimé (fréquence, utilisateurs touchés)
- La ou les causes probables identifiées par l’analyse du code
- La recommandation de traitement
La création automatique de tickets GitHub
Le rapport, c’est la vision. Les tickets, c’est l’action. Après avoir produit le rapport, l’agent crée dans GitHub un ticket pour chaque erreur qui mérite un correctif.
Ce n’est pas une création mécanique. L’agent :
- Vérifie si le ticket existe déjà — si l’erreur a déjà été remontée la semaine précédente et que le ticket n’a pas été traité, il met à jour le ticket existant plutôt que d’en créer un doublon.
- Rédige un titre clair — pas le message d’erreur brut, mais une description compréhensible de ce qui se passe.
- Documente le ticket — description, contexte, lien vers l’issue Sentry, pré-analyse des causes, suggestion de correction.
- Place le ticket en backlog — les tickets créés arrivent en backlog, pas directement dans le sprint.
La boucle avec l’agent BB-DEV
Une fois les tickets créés par BB-LOG, c’est moi qui décide lesquels méritent d’être traités en priorité. Si le correctif me semble simple et bien balisé, je le tague BB-DEV — et l’agent de développement BB-DEV s’en charge dès qu’il le peut.
Les agents travaillent ensemble. BB-LOG détecte et documente, BB-DEV corrige. Je reste le point de décision entre les deux.
Partie 4 — Ce que ça change sur la gestion des erreurs
Passer de la réaction à la prévention
Avant l’agent BB-LOG, je traitais les erreurs de manière réactive : quand un utilisateur signalait un problème, ou quand je tombais par hasard sur quelque chose dans Sentry. La couverture était partielle, le délai de traitement variable.
Avec BB-LOG, le cycle est devenu proactif. Chaque semaine, j’ai une vue complète des problèmes actifs, classée par impact. Je ne découvre plus un bug critique deux semaines après son apparition.
Un rapport bien plus riche que l’email Sentry
L’email hebdomadaire de Sentry vous dit qu’il y a 47 occurrences d’une erreur TypeError: cannot read property 'id' of undefined. L’agent BB-LOG vous dit que cette erreur touche 23 utilisateurs distincts depuis mardi, qu’elle se produit dans la fonction processOrder du fichier orders.service.ts à la ligne 142, que la cause probable est un cas non géré quand la commande n’a pas encore de ligne de produit, et que la correction probable est un guard de 3 lignes avant l’accès à la propriété.
Ce n’est pas la même information. C’est la différence entre une alerte et une analyse.
L’investissement en temps
Un audit hebdomadaire manuel des erreurs Sentry sur plusieurs projets prendrait facilement 2 à 3 heures. C’est du temps de développeur senior utilisé à une tâche de collecte et de mise en forme. Avec BB-LOG, ces 2 à 3 heures se passent sans moi. Ce que je reçois, c’est directement la synthèse sur laquelle je peux décider.
Vous voulez passer d’un monitoring passif à un traitement actif des erreurs ?
Chez Citios, j’aide les équipes à mettre en place des dispositifs de surveillance et de traitement automatisé : intégration Sentry, création de tickets, workflows de correction. Des systèmes qui font avancer la qualité sans attendre un incident critique.
Prendre contact — Sébastien Quéré, CTO à la demande
Vous cherchez un CTO à la demande pour votre startup ou votre PME ?
Discutons de votre projet →