Copilot dans JetBrains exporte ses traces : l’agent devient enfin observable

Le 27 juillet, GitHub a ajouté l’export OpenTelemetry aux workflows agentiques de GitHub Copilot dans les IDE de JetBrains. L’annonce tient en quelques lignes, mais elle marque un changement utile : un agent de code commence à pouvoir être traité comme n’importe quel autre service logiciel, avec des traces à inspecter plutôt qu’une simple fenêtre de chat à croire sur parole.

## Voir ce que fait réellement l’agent

Dans la nouvelle version du plugin, l’export se configure depuis Settings > Tools > GitHub Copilot > Chat. La même mise à jour permet de fixer maxInputToken et maxOutputToken pour les modèles BYOK et les endpoints personnalisés, d’activer ou désactiver les modèles intégrés et d’utiliser des serveurs MCP ou des agents personnalisés dans certains workflows. GitHub présente ces réglages comme des outils d’observabilité, de maîtrise des coûts et de gouvernance.

Ce qui m’intéresse surtout, c’est l’export OpenTelemetry. Une trace représente le parcours d’une opération, découpé en unités appelées spans. Chaque span peut contenir une durée, un statut, une hiérarchie et des attributs structurés. C’est le même mécanisme qui permet déjà de suivre une requête entre une API, une base de données et plusieurs services, comme l’explique la documentation officielle sur les traces.

Appliqué à un agent de code, cela peut répondre à des questions beaucoup plus concrètes que « Copilot semble lent aujourd’hui » :

combien de temps dure une session agentique ;
quelle étape concentre la latence ;
combien d’appels à des outils sont effectués ;
quel modèle est sollicité ;
où une exécution échoue ou boucle ;
comment deux configurations se comparent sur une même tâche.

GitHub ne publie toutefois pas encore, dans cette annonce, le schéma exhaustif des spans et attributs exportés. Il faudra donc inspecter les premières traces avant de construire des tableaux de bord ou des alertes autour de champs supposés stables.

## Une architecture simple sur un VPS

OpenTelemetry est un standard ouvert et indépendant d’un fournisseur. L’IDE peut envoyer sa télémétrie en OTLP vers un OpenTelemetry Collector, qui la traite puis la transmet vers un ou plusieurs backends.

Pour une installation auto-hébergée, le chemin peut rester lisible :

text

IDE JetBrains
    -> endpoint OTLP privé
    -> OpenTelemetry Collector
    -> Grafana Tempo
    -> Grafana

Le Collector reçoit, transforme et transmet traces, métriques ou logs. Il peut notamment assurer la mise en lots, les nouvelles tentatives et le filtrage avant stockage. Grafana Tempo fournit ensuite un backend open source consacré aux traces et intégré à Grafana.

Je ne commencerais pas par un gros dashboard. Une première vue avec la durée des sessions, leur statut, le modèle sélectionné et le nombre d’étapes serait déjà suffisante pour distinguer un modèle lent, un outil externe défaillant et une tâche simplement trop large.

## Les limites de tokens ne remplacent pas les traces

Les nouveaux champs maxInputToken et maxOutputToken apportent un garde-fou côté requête. Ils peuvent éviter qu’un endpoint personnalisé accepte un contexte démesuré ou produise une réponse inutilement longue. Ils ne disent cependant pas si l’agent a passé dix appels successifs pour atteindre son résultat.

C’est la différence entre limiter une opération et observer un workflow complet. GitHub dispose par ailleurs de budgets capables de plafonner la consommation individuelle ou collective de crédits IA, avec différents niveaux d’application documentés dans son guide de facturation. Les limites de tokens, les budgets et les traces répondent donc à trois problèmes distincts : encadrer une requête, stopper une dépense et comprendre son origine.

## Attention à ce qui quitte l’IDE

Une trace d’agent peut être plus sensible qu’une trace HTTP classique. Les conventions OpenTelemetry consacrées à l’IA générative préviennent que les arguments et résultats d’appels d’outils peuvent contenir des informations confidentielles. Cette réserve apparaît directement dans le registre des attributs GenAI.

Avant d’activer l’export pour toute une équipe, il faut donc vérifier les données réellement émises, réduire leur durée de conservation et filtrer les attributs inutiles. Sur un VPS, l’endpoint OTLP ne devrait pas être exposé sans contrôle d’accès : le projet recommande de limiter les adresses accessibles, d’activer l’authentification et de protéger les échanges avec TLS ou mTLS dans ses bonnes pratiques de sécurité.

Cette mise à jour ne rend pas automatiquement Copilot transparent. Elle fournit néanmoins la plomberie nécessaire pour passer d’un agent utilisé à l’aveugle à un composant mesurable, comparable et débogable. Pour un outil capable de modifier un dépôt entier, ce n’est pas un détail d’administration : c’est le début d’une vraie exploitation en production.

## Pour aller plus loin

Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.

Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.