Une équipe intègre un agent IA au développement et instaure deux étapes de revue

L’agent a rapidement écrit le code. Quelqu’un doit maintenant vérifier qu’il a modifié le bon service, interrogé la bonne base de données et évité de bloquer l’interface avec une opération longue. Dans un article publié sur Habr, une équipe explique comment elle a traité ces problèmes dans son propre agent pour IntelliJ IDEA. L’une des principales mesures consiste à faire valider les spécifications dans une pull request distincte avant de commencer l’implémentation. Cette organisation peut aussi être essayée avec un agent déjà installé.

L’histoire commence en 2024 avec un plugin de génération de tests. Un chat apparaît ensuite dans l’IDE, puis, après avoir découvert Windsurf en janvier 2025, l’équipe entreprend de développer un agent complet : recherche dans le projet, modification de fichiers et exécution de vérifications. À l’usage, elle découvre quelles tâches nécessitent des explications répétées et où l’outil doit être encadré.

Contexte du projet : trouver le code et choisir la bonne base de données

Pour la recherche, l’équipe utilise les index d’IntelliJ IDEA et PSI, la représentation structurée du code au sein de l’IDE. Les index permettent de trouver les classes, les méthodes et les fichiers, tandis que PSI expose les éléments du programme et leurs relations. L’agent transmet ces informations au modèle de langage.

Imaginons une tâche : modifier le traitement d’une commande. Il est utile de repérer la méthode concernée, ses appels et les classes associées avant de modifier le premier fichier qui semble convenir. Cet exemple illustre l’approche ; les auteurs ne fournissent aucune mesure précise de la qualité de cette recherche.

Pour les sources externes, l’équipe a ajouté MCP, qui permet de connecter des serveurs fournissant des outils à l’agent. Ceux-ci permettent de récupérer des tâches sur GitHub, d’interroger une base de données ou de vérifier une application web dans un navigateur. Les actions disponibles dépendent du serveur concerné et des autorisations accordées.

Mais connecter une base de données n’a pas suffi à résoudre le problème du contexte. Selon les auteurs, une requête a un jour été envoyée au mauvais environnement et a renvoyé un résultat convaincant, mais erroné. L’agent confondait également les noms de colonnes. Les développeurs devaient répéter leurs explications, surtout après l’ouverture d’un nouveau chat.

L’équipe a formalisé les procédures récurrentes sous forme de skills : des instructions précisant l’ordre des actions et les conditions de vérification. Elle a également ajouté une mémoire locale du projet pour conserver les contraintes et les solutions trouvées. Les règles interdisent d’y enregistrer des identifiants de connexion, mais le texte fourni ne détaille pas les mécanismes techniques de protection de cette mémoire.

Vérifier d’abord la tâche, puis l’implémentation

Le travail sur une fonctionnalité commence désormais par des spécifications. Le développeur les rédige avec l’agent et ouvre une pull request distincte. Un collègue examine le document, puis l’implémentation commence après validation. Les décisions et les précisions restent dans le dépôt pour permettre au prochain intervenant de reconstituer le contexte.

Prenons une modification d’API. Avant la génération du code, l’équipe peut s’accorder sur les champs de la réponse, la gestion des erreurs et le comportement attendu du client. Le développeur frontend reçoit une description déjà examinée par un collègue. Cela crée un point de contrôle précoce : une erreur dans les exigences peut être repérée avant de se propager à plusieurs fichiers.

Pour la revue de code, les auteurs se sont appuyés sur leurs propres remarques issues de précédentes pull requests. Lors du développement du plugin, ils rencontraient fréquemment des opérations longues exécutées sur le thread d’interface EDT et des appels à l’API IntelliJ sans la read action nécessaire. Ils ont transformé ces cas en instructions destinées à l’agent chargé de la revue.

La revue a ensuite été répartie entre plusieurs sous-agents aux rôles différents. Leurs résultats sont réunis dans un rapport commun, à partir duquel le développeur choisit les corrections à apporter. Les auteurs affirment que les erreurs déjà connues sont devenues moins fréquentes, mais ne présentent ni statistiques, ni échantillon témoin, ni coût des vérifications. L’article ne permet donc pas de mesurer l’ampleur de l’effet.

Ce que votre équipe peut reprendre

L’élément le plus directement applicable de ce retour d’expérience est le contrôle des actions au niveau du plugin. Un outil peut être désactivé ou son appel soumis à confirmation. C’est la couche logicielle qui décide de son exécution. Le développeur dispose ainsi d’un point de contrôle concret pour les commandes et les services externes.

L’équipe a également séparé la logique de l’agent de l’interface et publié une CLI. D’après sa description, la version en terminal conserve la prise en charge des fichiers, des skills, des modèles et de MCP. Cependant, l’extrait fourni s’interrompt : il ne donne ni le nom du produit, ni ses conditions d’accès, ni une vue complète de son utilisation en pratique.

Pour lancer une expérimentation concrète, vous pouvez partir d’une erreur récurrente de votre équipe : décrire une règle de vérification, ajouter une validation des exigences et comparer les résultats sur les tâches suivantes. Les indicateurs à suivre sont le délai jusqu’à l’acceptation d’une modification, le nombre de retours en correction après revue et les défauts constatés après fusion. Ce sont précisément ces mesures qui manquent encore à ce retour d’expérience pour juger de la rentabilité d’un agent développé en interne.