Sentry, traces, logs et évaluations : qui répond à quelle question ?

Lorsqu'une fonctionnalité IA échoue, les équipes ouvrent souvent cinq outils et ne trouvent toujours pas la cause. Ce n'est pas nécessairement un manque de données : les signaux n'ont pas été conçus pour répondre à des questions distinctes. Erreurs, traces, logs, évaluations et événements métier ont chacun un rôle.

Erreurs applicatives : le logiciel a-t-il cassé ?

Un outil comme Sentry aide à repérer exceptions, régressions, versions concernées, environnement et parcours utilisateur. Il répond bien à « quelle erreur de code s'est produite, où et pour combien de personnes ? »

Il répond moins bien à « la réponse était-elle correcte ? » Une fonction peut s'exécuter sans exception et produire une recommandation médiocre.

Traces : comment l'exécution s'est-elle déroulée ?

Une trace relie les étapes d'une requête : récupération de contexte, appel de modèle, outil externe, nouvelle tentative, politique et réponse. Elle permet de localiser latence, échec et dépendance.

Pour l'IA, ajoutez les versions, le mode de délégation et des références aux sources. Évitez de dupliquer automatiquement les contenus sensibles.

Logs : quel fait technique faut-il expliquer ?

Un log décrit un événement ponctuel utile au diagnostic. Il doit être structuré, limité et relié à la trace. Les messages libres accumulés sans niveau, durée ou propriétaire deviennent une archive coûteuse.

Ne confondez pas journalisation et mémoire métier. Le log sert à opérer ; la mémoire conserve une décision, sa raison et son résultat.

Évaluations : la sortie répond-elle aux critères ?

Une évaluation teste exactitude, complétude, conformité, ancrage dans les sources, ton ou respect d'une règle. Elle peut s'exécuter hors ligne sur un jeu de cas ou en production sur un échantillon.

Les évaluateurs automatiques doivent eux-mêmes être calibrés avec des revues humaines. Un score global masque souvent une dégradation sur un segment important.

Événements métier : l'utilisateur a-t-il obtenu le résultat ?

Acceptation, correction, envoi, résolution, abandon ou recours relient la qualité technique à la valeur. Sans eux, l'équipe optimise une note ou une latence sans savoir si le produit aide réellement.

Le diagramme de diagnostic

Commencez par la plainte observable :

1. Écran cassé ou exception ? Consultez erreurs et version.
2. Réponse lente ou outil manquant ? Suivez la trace distribuée.
3. État interne inattendu ? Inspectez les logs structurés.
4. Sortie fluide mais fausse ? Lancez les évaluations et examinez les sources.
5. Sortie correcte mais sans valeur ? Analysez le parcours et le résultat métier.
6. Incident sensible ? Reliez trace, autorité, décision, recours et impact.

Un identifiant de corrélation commun évite de chercher manuellement entre les couches.

L'instrumentation minimale

Pour une première fonction IA, instrumentez : version de déploiement, durée, statut des dépendances, version du modèle et de la règle, identifiant de trace, évaluation sur les critères critiques, correction utilisateur et résultat métier. Ajoutez les signaux supplémentaires uniquement lorsqu'ils éclairent une décision.

Fait, inférence et hypothèse

Fait direct : absence d'exception ne signifie pas qualité sémantique, et qualité sémantique ne signifie pas résultat métier.

Inférence : séparer les couches réduit le bruit et accélère l'attribution d'un incident.

Hypothèse à tester : un diagramme partagé réduit le temps de diagnostic davantage que l'ajout d'un nouvel outil.

FAQ

Faut-il centraliser tous les signaux ?

Non. Il faut surtout pouvoir les corréler, connaître leur source de vérité et appliquer des accès et durées adaptés.

Un outil d'observabilité IA remplace-t-il Sentry ?

Pas nécessairement. Il peut compléter les erreurs applicatives avec traces de modèle et évaluations, mais vérifiez le chevauchement réel.

Peut-on conserver tous les prompts pour déboguer ?

Pas par défaut. Utilisez références, catégories, empreintes ou échantillons protégés selon une finalité explicite.

Prochaine étape

Utilisez le diagramme de diagnostic sur les trois derniers incidents et notez le signal qui manquait réellement. Pour une revue de votre architecture d'observabilité, écrivez à contact@yumea.fr avec l'objet « DIAGNOSTIC IA ».