Pourquoi l'EDI est déjà un facteur déterminant pour la qualité de vos processus IA

Par JetBrains

L'EDI est déjà un facteur déterminant pour la qualité de l'IA. En avez-vous tenu compte dans votre feuille de route en matière d'IA ? par JetBrains

La qualité des outils d'IA des développeurs dépend de ce qu'ils savent dès le départ. Lorsque ces outils fonctionnent sur le bon EDI, cela peut leur donner une longueur d'avance : une vue d'ensemble du code que les outils devraient autrement reconstituer eux-mêmes. Cela signifie que les choix de votre équipe en matière d'EDI doivent figurer dans votre programme d'IA, au même titre que les politiques que vous définissez concernant les données des passerelles et les décisions relatives aux modèles de langage (LLM).

Le plafond des passerelles d'IA

Les passerelles d'IA sont désormais des composants essentiels de l'infrastructure de gestion. Gartner prévoit que 70 % des équipes d’ingénierie logicielle développant des applications multimodales en auront mis en place d’ici 2028.

Les passerelles vous offrent deux types de leviers de gestion de l’IA :

- Les contrôles en cours de pipeline. Pensez au routage des modèles, à la limitation de débit et à la répartition des coûts : les contrôles en cours de pipeline vous offrent une visibilité solide et des garde-fous sur les dépenses liées à l’IA, mais ils s’appliquent à des requêtes déjà formulées.

- Les politiques en amont du pipeline. Pensez aux listes de modèles approuvés, aux directives de saisie et aux programmes de formation. En théorie, ces politiques façonnent le comportement des développeurs. Une enquête Stack Overflow de 2024 a révélé que 73 % des développeurs ne savaient pas si leur entreprise disposait d’une politique en matière d’IA.

Et pourtant, la question de savoir comment relier l’utilisation de l’IA aux résultats techniques reste en suspens. « Nous travaillons à trouver cette réponse », a déclaré GitHub lors du lancement de son tableau de bord Copilot au niveau de l'organisation en février 2026.

Les passerelles sont un élément indispensable de la réponse. Mais elles n'offrent pas de levier architectural sur les outils d'IA disponibles avant même qu'une requête ne soit formulée. Les informations auxquelles elles ont accès font la différence – peu importe à quel point les collaborateurs respectent les directives de saisie ou à quel point vous surveillez de près les statistiques des passerelles.

Un outil familier, un levier IA négligé

L’un des cadres les mieux étayés pour boucler la boucle de mesure entre l’utilisation de l’IA et ses résultats se trouve dans le rapport DORA 2025 « State of AI-Assisted Software Development ». Il identifie sept capacités que les dirigeants doivent privilégier :

- Deux sont d’ordre organisationnel : une attention portée aux utilisateurs finaux de l’IA et une politique IA claire et communiquée. C’est là que votre passerelle IA entre en jeu.

- Deux sont procédurales : des pratiques rigoureuses de contrôle de version et le travail par petits lots.

- Trois sont techniques : un écosystème de données sain, des données internes accessibles à l’IA et une plateforme interne de haute qualité.

Dans le domaine des capacités de données, DORA précise ce qui détermine la performance : le contexte, c’est-à-dire ce qu’un modèle reçoit avant de générer un résultat. Un meilleur contexte signifie des avantages plus importants. Ce sur quoi DORA ne s'attarde pas, c'est ce qui détermine la qualité du contexte au moment de sa création. Cela dépend de qui ou de quoi le crée et comment.

À propos de l'IA : le contexte

Les passerelles ne montrent peut-être pas encore qui ou quoi crée le contexte, mais il existe trois cas de figure de base :

1. Directement par le développeur. Un développeur interagit directement avec l'IA via un navigateur ou une interface de chat. Le contexte correspond à tout ce qui est collé.

2. Directement par un agent. Un agent autonome opère directement sur la base de code. Le contexte correspond à ce que l'agent sélectionne.

3. Par l'intermédiaire d'un EDI. Un assistant IA ou un agent de codage s'exécute dans l'environnement de développement. Le contexte inclut toutes les connaissances structurelles de la base de code fournies par l'EDI – automatiquement pour les assistants, par configuration pour les agents.

Ces trois cas s'accompagnent de leviers de politique, notamment le choix des modèles à financer, des agents à autoriser, et la manière de suivre les coûts et les volumes.

Mais le cas via l’EDI introduit également une décision concernant l’environnement dans lequel les outils d’IA opèrent, et non les outils eux-mêmes. Lorsque la majeure partie du code est générée par l’IA au sein d’outils basés sur un EDI – chez Uber, cette part est de 65 % à 72 % –, cette décision a un poids réel.

Contexte, assemblez-vous !

L’assemblage du contexte est le processus consistant à sélectionner ce qu’il faut envoyer à un modèle d’IA. La méthode utilisée affecte de manière mesurable la qualité du résultat :

- Une étude de 2026 a révélé qu’une méthode basée sur le traçage des liens entre les fichiers de code – par opposition à une méthode basée sur la correspondance de code d’apparence similaire – produisait une couverture de test 213 % plus complète pour Java et 174 % pour Go.

- Une étude de 2024 a comparé une méthode différente, basée sur le code d’apparence similaire, à une méthode d’analyse statique pour extraire les dépendances de code et les informations de type. La méthode basée sur l'extraction a produit des complétions de code 62 % plus précises.

Pour les outils d'IA fonctionnant dans un environnement de développement, c'est l'environnement qui détermine les connaissances structurelles dont dispose leur méthode d'assemblage de contexte.

La décision relative à l'EDI, repensée

Le choix de l'EDI à utiliser a toujours relevé de la décision du développeur. Les meilleurs indicateurs dont vous disposiez à ce sujet comprenaient les coûts de licence et les scores de satisfaction des développeurs. Les passerelles d'IA commencent à changer la donne.

Pensez aux données de passerelle que vous surveillez peut-être déjà, telles que le volume d'appels aux modèles, la taille de la charge utile contextuelle ou l'utilisation des jetons. Ce que les IDE de votre équipe mettent à la disposition de leurs outils d'IA peut influencer tous ces indicateurs.

Aucun cadre de gestion de l'IA établi n'a encore formalisé le rôle de l'EDI dans ce contexte. L'infrastructure de mesure est encore en cours de développement. Le tableau de bord Copilot de GitHub peut vous indiquer d'où provient le trafic Copilot. Aucune passerelle multi-outils n'offre actuellement d'équivalent prêt à l'emploi pour l'ensemble des outils de codage IA. En attendant, vous pouvez faire deux choses pour garder une longueur d'avance :

Comprenez ce dont vous disposez

Que vous disposiez ou non d’une passerelle, commencez par comprendre quels EDI les développeurs utilisent et pourquoi. Si vous disposez d’une passerelle, allez plus loin : demandez aux ingénieurs ce qu’il faudrait pour classer les appels de modèles par type d’interaction – via l’EDI, directement par l’agent ou directement par le développeur. L’effort varie selon la configuration, mais les données brutes sont probablement déjà disponibles. Établir une base de référence dès maintenant vous donne un point de repère à mesure que les outils évoluent.

Évaluez ce qui vous attend

Certains EDI laissent les outils d'IA déchiffrer le code par eux-mêmes. C'est exactement ce que font par défaut les agents de codage actuels.

D'autres EDI mettent à la disposition des outils d'IA qui les exploitent un modèle structurel de l'ensemble de la base de code. Le protocole ACP (Agent Client Protocol) permet à des agents externes de s'exécuter au sein des EDI JetBrains. Une fois connectés, ils peuvent appeler des outils côté EDI via le protocole MCP (Model Context Protocol).

À mesure que le travail de codage par agents devient plus complexe et autonome, cet avantage structurel qu’un EDI peut offrir prend de l’importance. Les mécanismes sont suffisamment récents pour que les données probantes soient encore limitées, mais les premiers résultats d’un benchmark publié par Sourcegraph ont montré que les agents utilisant des outils MCP accomplissent leurs tâches 38 % plus rapidement et localisent les fichiers pertinents 70 % plus souvent sur des bases de code volumineuses à plusieurs dépôts.

Les développeurs savent ce que leurs EDI leur offrent et comment leurs agents sont configurés. C'est à vous de décider si cela suffit pour l'avenir du développement assisté par l'IA.

Des EDI pour les défis à venir

Lorsque le choix des EDI de votre équipe figure à l'ordre du jour de votre stratégie IA, JetBrains vous propose des variables architecturales à ajuster.

Les EDI JetBrains maintiennent une représentation structurelle continue de l’ensemble de la base de code, ce qui rationalise la construction du contexte IA. Tout cela est automatiquement transmis à l’Assistant IA, l’interface native des EDI qui prend en charge pratiquement n’importe quel LLM avec les propres clés ou l’IA JetBrains.

Pour plus de 25 agents de codage compatibles ACP, les EDI JetBrains fournissent des outils qui exposent directement cette même représentation. La plupart des agents doivent être orientés vers ces outils ; lorsqu’ils le sont, la boucle de construction du contexte peut être raccourcie, selon au moins une équipe d’ingénieurs.

La dynamique est encore en train de se mettre en place, et les résultats varieront certainement, mais les leviers sont là pour que vous puissiez les actionner.

Découvrez les outils de JetBrains pour les entreprises