TypeError: Cannot read properties of undefined (reading 'id'). Ce message, aussi familier que frustrant pour n’importe quel développeur JavaScript, atterrit plusieurs fois par semaine dans le canal d’alertes du studio Pixerelle, accompagné d’un lien vers l’événement correspondant dans Sentry. Ouvrir ce lien, chercher la ligne fautive dans la stack trace, remonter le contexte : ce rituel prenait quelques minutes à chaque fois, avant qu’un assistant interne ne vienne le raccourcir.
L’assistant en question n’est pas un simple résumeur de texte : il s’appuie sur le function calling pour aller chercher lui-même, via l’API Sentry, les détails de l’erreur signalée, avant de produire un résumé en français destiné au développeur d’astreinte. Le principe distingue nettement cette approche d’un simple copier-coller de la trace dans un prompt générique.
Le principe du function calling appliqué à Sentry
Le function calling consiste à décrire au modèle, sous forme d’un schéma structuré, les fonctions qu’il peut appeler et les paramètres qu’elles attendent. Face à un message contenant un identifiant d’événement Sentry, le modèle choisit d’invoquer la fonction getSentryEvent, dont l’exécution réelle est déclenchée côté serveur, pas par le modèle lui-même, qui ne fait que demander l’appel.
const tools = [{
name: 'getSentryEvent',
description: 'Recupere les details d une erreur Sentry par son ID',
parameters: {
type: 'object',
properties: { eventId: { type: 'string' } },
required: ['eventId']
}
}];Une fois la fonction exécutée côté serveur et son résultat renvoyé au modèle, celui-ci dispose de la stack trace complète, des tags associés (environnement, navigateur, version déployée) et du nombre d’occurrences de cette erreur sur les dernières vingt-quatre heures, pour produire un résumé qui va au-delà du simple message d’erreur.
Le résumé produit, en pratique
Sur l’erreur citée plus haut, le résumé généré indiquait que l’erreur survenait dans le composant d’affichage du panier, déclenchée quand un produit était retiré du panier après expiration de sa disponibilité en stock, avec une fréquence de douze occurrences dans les dernières vingt-quatre heures, concentrées sur les utilisateurs du navigateur Safari mobile. Ce niveau de détail, disponible en quelques secondes, aurait demandé une lecture attentive de la stack trace complète pour être reconstitué manuellement.
Le développeur d’astreinte reçoit ce résumé directement dans le canal d’alertes, avec un lien conservé vers l’événement Sentry original pour les cas où il souhaite creuser davantage. Le résumé ne remplace jamais ce lien, il ne fait que réduire le nombre de fois où l’ouvrir s’avère nécessaire pour une simple prise de connaissance.
Les limites observées
- Sur les erreurs rares, sans occurrence répétée, le résumé manque de contexte statistique et reste proche d’une simple traduction de la stack trace.
- Sur les erreurs liées à une régression introduite le jour même, le modèle ne dispose d’aucune information sur le commit en cause, qu’un développeur doit encore chercher manuellement.
- Le résumé peut occasionnellement mal interpréter un nom de variable technique ambigu, d’où l’intérêt de toujours garder le lien vers la source.
Le piège du prompt trop détaillé
Une première version du prompt demandait au modèle d’inclure systématiquement la stack trace complète dans sa réponse, en plus du résumé, dans l’idée de « tout donner » au développeur. Le résultat produisait des messages si longs que personne ne les lisait intégralement, l’information utile se noyant dans le rappel technique déjà disponible via le lien Sentry.
Un résumé qui répète la donnée brute qu’il est censé synthétiser n’est pas un résumé : c’est un contournement du travail que l’on attend du modèle.
La version corrigée du prompt impose une limite stricte de trois phrases, avec obligation d’indiquer la fréquence d’occurrence et l’environnement concerné, sans jamais reproduire la trace technique déjà accessible en un clic.
Ce que ce dispositif ne couvre pas
La configuration initiale de Sentry, ses règles de regroupement d’erreurs et ses seuils d’alerte restent entièrement gérés en dehors de ce projet, qui se contente de consommer les données une fois l’erreur déjà remontée par l’outil de suivi.
En résumé
Quarante-cinq secondes gagnées par erreur traitée peuvent sembler modestes, mais elles s’accumulent sur plusieurs dizaines d’erreurs par semaine, sans compter le confort d’un résumé en français directement lisible dans le canal de discussion. Le function calling n’a rien changé à la nature du travail de débogage, il en a simplement accéléré la première étape de compréhension.
