Découvrez comment Skyscanner a dopé Codex CLI d’OpenAI en l’intégrant aux IDE JetBrains, donnant ainsi à son assistant IA les mêmes outils de débogage et de test que ceux des développeurs humains.
Chez Skyscanner, nous cherchons toujours à accélérer le développement sans compromettre la qualité. Ces derniers mois, j’ai expérimenté la programmation en binôme avec Codex d’OpenAI dans mon travail quotidien.
La particularité de cette expérience ? J’ai connecté Codex CLI aux IDE JetBrains via leur serveur Model Context Protocol (MCP), permettant ainsi à l’IA de découvrir et d’utiliser les fonctionnalités de l’IDE. Cette intégration a changé la donne. Dans cet article, je vais expliquer comment l’accès aux outils JetBrains a amélioré la capacité de Codex à résoudre des problèmes et accéléré notre développement.
Donner à Codex accès au contexte d’un IDE
Grâce au serveur MCP de JetBrains, Codex peut désormais exploiter toute la richesse du contexte de mon environnement de développement, notamment des éléments que l’IA ne « verrait » pas habituellement.
Grâce au serveur MCP de JetBrains, Codex peut demander à l’IDE des informations contextuelles supplémentaires, par exemple :
- Détection des problèmes d’un fichier : analyse d’un fichier à l’aide des inspections IntelliJ pour détecter les erreurs et les avertissements, puis restitution des problèmes précis, avec leurs messages d’erreur et leurs emplacements.
- Lancement des configurations d’exécution : lancement de configurations d’exécution prédéfinies, comme des tests unitaires, des linters ou des outils de formatage, puis récupération des codes de sortie et de la sortie produite.
Cette approche s’est révélée extrêmement efficace. En s’appuyant sur les mêmes boucles de retour que les développeurs humains lorsqu’ils écrivent, compilent et testent du code, Codex peut utiliser le contexte de l’IDE pour mieux contrôler et vérifier ce qu’il produit, ce qui réduit le temps nécessaire à chaque itération.
Détecter les erreurs plus vite : un exemple concret
Alors que j’écrivais des tests unitaires pour la gestion des erreurs dans notre code utilisant le SDK Java de Databricks, j’ai demandé à Codex de m’aider à simuler un scénario d’exception. Il a produit avec assurance une ligne de code Java qui ressemblait à ceci :
var stubError = new NotFound("dummy error");À première vue, cela semble raisonnable : nous voulons simuler une erreur NotFound. Mais quelques instants plus tard, IntelliJ a souligné cette ligne d’un gros trait rouge.
Le problème : la classe d’exception NotFound du SDK Databricks ne possède pas de constructeur acceptant une chaîne de caractères comme unique argument (vous pouvez le vérifier dans le code source du SDK Databricks : NotFound.java). Autrement dit, le code suggéré par Codex ne pouvait tout simplement pas compiler.
Par défaut, Codex n’aurait pas connaissance de cette erreur. Il pourrait ne découvrir le problème que plus tard, en essayant de lancer les tests. Mais grâce à l’intégration du serveur MCP de JetBrains, Codex a immédiatement détecté l’erreur. En coulisses, il a appelé l’outil get_file_problems de l’IDE pour inspecter le fichier. L’outil a aussitôt signalé le problème de compilation : aucun constructeur correspondant.
Sans MCP, les étapes auraient probablement été les suivantes :
- Génération du code
- Recherche de la méthode à suivre pour lancer les tests unitaires
- Exécution des tests unitaires (avec éventuellement une demande d’approbation à l’utilisateur pour certaines commandes)
- Lecture et analyse du message d’échec
- Tentative de correction de l’erreur
Avec le serveur MCP de JetBrains, ce cycle est beaucoup plus court :
- Génération du code
- Demande à JetBrains de la liste des problèmes détectés dans le fichier
- Correction de l’erreur précise signalée par IntelliJ
Cela a permis de gagner du temps et d’économiser du contexte. J’avais vraiment l’impression de programmer en binôme avec un ingénieur qui me disait immédiatement : « Ah, cette classe n’a pas de constructeur de ce type, elle attend autre chose. Je corrige ça tout de suite. »
Configurations prédéfinies pour les tests et le formatage
Autre avantage que j’ai apprécié : laisser Codex piloter nos outils de build et de test existants directement depuis l’IDE. Pour la plupart de nos projets, j’ai déjà défini dans mon IDE des configurations d’exécution locales, notamment pour les tests, le formatage et le linting. Grâce au serveur MCP de JetBrains, Codex peut découvrir ces configurations et les lancer à la demande.
En pratique, Codex a besoin de moins de temps et de contexte pour déterminer comment lancer ces opérations, ce qui l’aide à rester concentré sur le problème initial. Depuis ce changement, j’ai constaté qu’il ne bute plus sur l’exécution des tests, du formatage ou du linting.
Dans mes instructions personnalisées pour l’agent, je demande donc à Codex de lancer les tests, le linting et le formatage après chaque modification.
## Code edit instructions
After you've finished editing
- Use the jetbrains mcp (if available) to find any problems
- Run format command if available
- Run lint command if availableJ’ai remarqué que Codex résout désormais souvent les problèmes tout seul, sans que j’aie à intervenir. En tant que développeur, c’est un gain considérable :
- Je n’ai pas à lancer manuellement les tests, le linting et le formatage chaque fois que Codex modifie quelque chose.
- Je n’ai pas à copier-coller les messages d’erreur dans la discussion.
- Codex reçoit des retours rapides et précis sur le bon fonctionnement de ses modifications, ce qui réduit le nombre de cycles de retour.
Cela me laisse davantage de temps pour me concentrer sur ma tâche : livrer des logiciels de qualité qui fonctionnent.
Ce que cela change dans notre façon de développer
L’intégration de Codex au serveur MCP de JetBrains a rendu notre assistant IA nettement plus performant et plus fiable dans notre processus de développement. Voici quelques-uns des avantages concrets que nous avons constatés :
- Des boucles de retour plus rapides : l’IDE signale immédiatement à Codex les erreurs de compilation et les tests qui échouent.
- Moins d’allers-retours par prompts : Codex n’a pas toujours besoin d’attendre que je lance une opération et que je colle un message d’erreur. Il peut interroger directement l’IDE.
- Des suggestions de meilleure qualité : comme Codex voit ce que voit l’IDE, le code qu’il corrige a plus de chances de compiler et de réussir les tests dès le premier essai.
- Une meilleure intégration aux workflows existants : Codex utilise nos outils existants au lieu d’inventer les siens.
Dans l’ensemble, Codex est passé du statut d’outil indépendant à celui de composant mieux intégré à notre écosystème de développement.
Résumé
Chez Skyscanner, nous en avons tiré une leçon simple : le contexte est essentiel. Codex est puissant à lui seul, mais il est bien plus efficace lorsqu’il dispose des informations de l’IDE. Ce contexte lui permet de mieux comprendre les problèmes et de produire plus rapidement des corrections justes, ce qui renforce encore ma confiance dans ses résultats.
Nous espérons que notre expérience donnera à d’autres l’envie d’essayer ces intégrations. On a vraiment moins l’impression d’utiliser un outil que de programmer en binôme avec une IA qui voit ce que nous voyons.