hariri.ch
Prenez contact

Outils & Logiciels

JetBrains rapproche observabilité et agents IA dans l’IDE avec OpenTelemetry et MCP

7 min de lecture

Illustration abstraite montrant un IDE relié à des flux de télémétrie et à des agents logiciels externes dans un environnement technique bleu et violet.

Ce qui change concrètement dans les IDE JetBrains

Avec la version 2026.2, JetBrains rend son plugin OpenTelemetry disponible dans IntelliJ IDEA, GoLand, PyCharm et WebStorm. Le plugin continue aussi de fonctionner dans Rider. Pour les équipes qui développent sur plusieurs langages, c’est un point important : la même approche d’observabilité locale s’étend désormais à plusieurs environnements de travail de la gamme JetBrains.

Le principe est simple : le plugin fait remonter dans l’IDE les logs, les metrics, les traces et une service map issus d’applications locales. L’intérêt immédiat est de pouvoir inspecter cette télémétrie sans déployer un backend d’observabilité local séparé. Pour un développeur, cela réduit la friction quand il veut vérifier rapidement ce qu’émet son application instrumentée pendant une session de développement.

Il faut toutefois bien comprendre le périmètre du plugin : il n’ajoute ni bibliothèques OpenTelemetry ni agents à l’application. Il se contente de configurer la destination des données d’une application déjà instrumentée. Autrement dit, si votre service n’émet rien, le plugin ne crée pas cette instrumentation à votre place.

Comment les données arrivent dans le plugin

JetBrains indique que les configurations d’exécution prises en charge peuvent transmettre des variables d’environnement OTLP à des applications instrumentées en Java, Python, Go ou .NET. Ces variables pointent vers le récepteur intégré du plugin. Cela permet de lancer l’application depuis l’IDE et de récupérer directement sa télémétrie dans les vues prévues.

Le même mécanisme s’applique aussi aux nouvelles sessions du terminal intégré : les variables d’environnement OTLP y sont également passées. C’est utile pour les workflows où l’application n’est pas démarrée via un bouton Run classique, mais via une commande dans le terminal.

Le plugin n’impose pas non plus un seul mode d’intégration. Une application peut être configurée pour envoyer directement ses données vers l’endpoint OTLP affiché par le plugin. Et si une équipe utilise déjà un OpenTelemetry Collector local, elle peut ajouter le plugin comme destination OTLP tout en conservant le reste de son pipeline. En pratique, cela facilite l’adoption progressive : on peut brancher l’IDE sur une chaîne existante au lieu de la remplacer.

Il y a aussi une limite fonctionnelle à garder en tête : si l’application n’exporte que des traces, les vues Logs et Metrics resteront vides. Le plugin reflète ce qui est réellement émis, il ne reconstitue pas les signaux manquants.

Pourquoi le lien avec MCP change la donne

Le point le plus intéressant n’est pas seulement l’affichage de la télémétrie dans l’IDE, mais son exposition potentielle à des agents externes. Le plugin OpenTelemetry dispose d’un support MCP expérimental via le serveur MCP de JetBrains. Un agent de code compatible peut interroger la télémétrie collectée dans l’IDE avec les outils get_log_records, get_spans, get_services et get_service_map.

Cette capacité s’inscrit dans une évolution plus large d’IntelliJ IDEA. Depuis la version 2025.2, l’IDE intègre un serveur MCP. Celui-ci permet à des clients externes comme Claude Code, Codex ou VS Code d’accéder à des outils fournis par l’IDE. Le plugin MCP Server est inclus et activé par défaut dans IntelliJ IDEA.

Pour les clients détectés automatiquement, JetBrains cite notamment Junie, VS Code, Claude Code, Codex, Air et GitHub Copilot CLI. L’IDE peut écrire la configuration de connexion directement dans le projet courant, ce qui limite la disponibilité du serveur MCP à la durée de travail sur ce projet. IntelliJ IDEA peut aussi copier une configuration manuelle pour des connexions SSE, Stdio ou HTTP Stream.

Autrement dit, JetBrains ne se contente pas d’ajouter un panneau d’observabilité. L’éditeur construit un pont entre le contexte d’exécution local et des assistants externes capables d’exploiter ce contexte.

Quels outils les agents peuvent réellement utiliser

Le serveur MCP d’IntelliJ IDEA expose des outils permettant à des clients externes d’analyser du code, modifier des fichiers, lancer des configurations d’exécution ou exécuter des commandes terminal. Les administrateurs ou les développeurs gardent toutefois un certain contrôle : chaque outil peut être activé ou désactivé individuellement dans les réglages, et certains peuvent être marqués Router-only. Dans ce mode, ils n’apparaissent pas dans la liste directe des outils MCP et restent accessibles uniquement via l’outil routeur dédié.

Parmi les outils documentés, analyze_calls construit l’arbre de hiérarchie d’appels de l’IDE pour une méthode, une fonction, un constructeur ou certains types pris en charge. build_project lance la compilation du projet ou de fichiers précis, attend la fin du traitement et renvoie les erreurs de build. get_file_problems et lint_files s’appuient sur les inspections IntelliJ pour remonter erreurs et avertissements. get_project_dependencies retourne la liste des dépendances définies dans le projet, tandis que get_project_modules renvoie les modules et leurs types. Enfin, get_symbol_info fournit les mêmes informations que la documentation rapide d’IntelliJ IDEA pour un symbole à une position donnée.

Vu sous l’angle de l’observabilité, l’intérêt est clair : un agent peut potentiellement croiser ce qu’il voit dans le code avec ce qu’il lit dans la télémétrie locale. Cela ne signifie pas qu’il résout automatiquement un incident, mais cela réduit la distance entre symptômes d’exécution et contexte source.

Débogage, base de données et garde-fous

JetBrains étend aussi MCP au débogage. Les outils de débogueur sont fournis par le plugin Debugger MCP toolset, inclus par défaut dans IntelliJ IDEA. Ils permettent à un client externe de définir, lister et supprimer des points d’arrêt, de démarrer une session de debug, d’avancer pas à pas et d’inspecter la pile d’appels, les threads et les valeurs de variables à l’exécution. Une limite est explicitement documentée : les événements d’erreur de breakpoint et la sortie des tracepoints ne sont actuellement remontés que par les débogueurs basés sur la JVM, comme Java et Kotlin.

Le volet base de données est plus sensible. Les fonctions MCP spécifiques aux bases nécessitent l’installation et l’activation du plugin Database Tools and SQL ainsi que du plugin JetBrains AI Assistant. JetBrains recommande, pour garantir un accès strictement en lecture seule à un agent IA, d’utiliser un utilisateur de base de données avec des privilèges restreints en lecture seule et de configurer la source de données avec cet utilisateur. C’est un rappel utile : l’exposition d’outils à un agent ne remplace pas les contrôles de privilèges au niveau de l’infrastructure.

Il existe aussi des restrictions de disponibilité. La fonctionnalité list_recent_sql_queries, par exemple, n’est pas proposée dans les offres gratuites.

Enfin, IntelliJ IDEA peut autoriser des clients externes connectés à exécuter des commandes terminal ou des configurations d’exécution sans demander une confirmation à chaque fois. C’est puissant pour l’automatisation, mais cela mérite une revue attentive des réglages exposés, surtout sur des projets sensibles. L’IDE peut également afficher une suggestion de configuration dans le terminal lorsque Codex ou Claude démarre sans configuration MCP correspondante.

Ce que cela signifie pour les équipes de développement

Pour les équipes, la nouveauté la plus tangible est la consolidation de plusieurs boucles de feedback dans un même environnement : exécution locale, télémétrie, inspection statique, build, debug et interaction avec des agents externes. Le plugin OpenTelemetry réduit le coût d’entrée pour observer une application déjà instrumentée. Le serveur MCP, lui, transforme l’IDE en fournisseur de capacités structurées pour des clients externes.

Le bénéfice potentiel est surtout opérationnel : moins de changements de contexte, moins d’outils intermédiaires à installer pour une inspection locale, et davantage de possibilités pour automatiser des tâches d’analyse ou de diagnostic. En contrepartie, cette convergence augmente l’importance de la gouvernance : quels outils sont exposés, à quels clients, dans quel projet, avec quels droits, et avec quel niveau d’autonomie pour l’exécution de commandes.

En résumé, JetBrains ne propose pas seulement une meilleure visualisation d’OpenTelemetry dans l’IDE. L’éditeur assemble progressivement une chaîne où l’IDE devient à la fois poste de développement, point d’observation local et surface d’intégration pour des agents capables d’agir sur le projet. Pour les développeurs et responsables d’outillage, c’est moins une simple fonctionnalité qu’un changement d’architecture du poste de travail.

À retenir

  • Le plugin OpenTelemetry est disponible depuis JetBrains 2026.2 dans IntelliJ IDEA, GoLand, PyCharm et WebStorm, et continue de fonctionner dans Rider.
  • Il affiche logs, métriques, traces et carte de services dans l’IDE sans nécessiter de backend local d’observabilité séparé.
  • Le plugin ne crée pas l’instrumentation OpenTelemetry : il redirige les données d’applications déjà instrumentées vers son récepteur OTLP intégré.
  • Le support MCP expérimental permet à des agents compatibles d’interroger la télémétrie collectée dans l’IDE.
  • IntelliJ IDEA intègre un serveur MCP depuis 2025.2, avec des outils pour analyser le code, lancer des builds, exécuter des commandes, déboguer et, sous conditions, accéder à des fonctions base de données.

Publié par :

Sources