Découvrez comment Skyscanner a étendu les capacités de Codex CLI d’OpenAI en l’intégrant aux IDE de JetBrains. Son assistant IA dispose ainsi des mêmes outils de débogage et de test que les développeurs.
Chez Skyscanner, nous cherchons toujours à accélérer le développement sans compromettre la qualité. Depuis quelques mois, j’expérimente la programmation en binôme avec Codex d’OpenAI dans mon travail quotidien.
Ce qui change la donne ? J’ai connecté Codex CLI aux IDE de JetBrains grâce au serveur Model Context Protocol (MCP) de JetBrains. L’IA peut ainsi découvrir les fonctionnalités de l’IDE et les utiliser. Cette intégration a changé ma façon de travailler. Dans cet article, je vais montrer comment l’accès aux outils de JetBrains aide Codex à mieux résoudre les problèmes et nous permet de développer plus vite.
Donner à Codex accès au contexte de l’IDE
Grâce au serveur MCP de JetBrains, Codex a désormais accès à une multitude d’informations sur mon environnement de développement qu’il ne « verrait » pas d’ordinaire.
Le serveur MCP de JetBrains permet à Codex d’interroger l’IDE pour obtenir davantage de contexte. Codex peut par exemple :
- Repérer les problèmes dans un fichier : les inspections d’IntelliJ analysent le fichier et indiquent précisément les erreurs et les avertissements, avec les messages et les emplacements correspondants.
- Lancer des configurations d’exécution : Codex peut lancer des configurations prédéfinies pour les tests unitaires, l’analyse statique ou le formatage, puis récupérer les codes de sortie et la sortie des commandes.
En pratique, le gain est considérable. Codex reçoit les mêmes retours de l’IDE que les développeurs lorsqu’ils écrivent, compilent et testent leur code. Il peut ainsi vérifier plus efficacement le code qu’il produit, ce qui raccourcit chaque itération.
Repérer les erreurs plus vite : un cas concret
J’écrivais des tests unitaires pour vérifier la gestion des erreurs dans notre code qui utilise le SDK Java de Databricks. J’ai demandé à Codex de m’aider à simuler une exception. Il m’a proposé sans hésiter une ligne de Java qui ressemblait à ceci :
var stubError = new NotFound("dummy error");À première vue, la ligne paraît correcte : on cherche bien à simuler une erreur NotFound. Quelques instants plus tard, pourtant, IntelliJ la soulignait en rouge.
Le problème, c’est que la classe d’exception NotFound du SDK Databricks ne possède aucun constructeur qui prenne une chaîne de caractères comme unique argument. On peut le vérifier dans le code source du SDK Databricks, dans NotFound.java. Le code proposé par Codex ne pouvait donc pas compiler.
Par défaut, Codex n’aurait pas eu connaissance de cette erreur. Il aurait pu ne la découvrir qu’au moment de lancer les tests. Grâce à l’intégration avec le serveur MCP de JetBrains, il l’a repérée immédiatement. En coulisses, Codex a appelé l’outil get_file_problems de l’IDE pour inspecter le fichier. L’outil lui a aussitôt signalé l’erreur de compilation : aucun constructeur ne correspondait à cet appel.
Sans MCP, Codex aurait probablement suivi ces étapes :
- Générer le code
- Déterminer comment lancer les tests unitaires
- Lancer les tests unitaires, en demandant au besoin à l’utilisateur d’autoriser l’exécution des commandes
- Lire et analyser le message d’erreur
- Tenter de corriger l’erreur
Avec le serveur MCP de JetBrains, le processus est bien plus court :
- Générer le code
- Demander à l’IDE de JetBrains quels problèmes il a repérés dans le fichier
- Corriger l’erreur précise signalée par IntelliJ
J’ai gagné du temps et Codex a eu besoin de moins de contexte. J’avais vraiment l’impression de programmer en binôme avec un collègue qui me disait aussitôt : « Ah, cette classe n’a pas de constructeur qui accepte cet argument. Il lui faut autre chose. Je te corrige ça tout de suite. »
Des configurations prédéfinies pour les tests et le formatage
Autre avantage que j’apprécie : Codex peut utiliser nos outils de build et de test directement depuis l’IDE. Pour la plupart de nos projets, j’y ai déjà défini des configurations d’exécution locales pour lancer les tests, formater le code ou effectuer l’analyse statique. 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. Il peut ainsi se concentrer sur le problème initial. Depuis ce changement, j’ai constaté qu’il lance les tests, le formatage et l’analyse statique sans difficulté.
Dans mes instructions personnalisées pour l’agent, je demande donc à Codex de lancer les tests après chaque modification. Je lui demande aussi d’exécuter chacune des commandes de formatage et d’analyse statique si elle est disponible.
## 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 availableJe constate que Codex résout désormais souvent les problèmes de lui-même, sans que j’aie à intervenir. Pour moi, en tant que développeur, le gain est considérable :
- Je n’ai plus à lancer manuellement les tests, l’analyse statique et le formatage chaque fois que Codex modifie quelque chose.
- Je n’ai plus à copier-coller les messages d’erreur dans la discussion.
- Codex sait rapidement et précisément si ses modifications fonctionnent, ce qui réduit le nombre d’allers-retours.
J’ai ainsi plus de temps à consacrer à ma tâche : livrer un logiciel de qualité qui fonctionne.
Ce qui change dans notre façon de développer
Depuis que nous avons intégré Codex au serveur MCP de JetBrains, notre assistant IA est nettement plus efficace et plus fiable au quotidien. Voici quelques avantages que nous avons constatés :
- Des retours plus rapides : l’IDE signale immédiatement à Codex les erreurs de compilation et les tests qui échouent.
- Moins d’allers-retours dans la discussion : Codex peut interroger directement l’IDE sans avoir systématiquement à attendre que je lance une commande et que je colle le message d’erreur.
- Des suggestions de meilleure qualité : comme Codex a accès aux mêmes informations que l’IDE, le code qu’il propose pour corriger une erreur a plus de chances de compiler et de passer les tests du premier coup.
- Une meilleure intégration à nos workflows : Codex utilise nos outils existants au lieu d’inventer les siens.
Auparavant, nous utilisions Codex comme un outil à part. Il fait désormais partie intégrante de notre environnement de développement.
En résumé
Chez Skyscanner, nous en avons tiré un enseignement simple : le contexte est déterminant. Codex est déjà performant à lui seul, mais il est bien plus efficace lorsqu’il a accès aux informations de l’IDE. Grâce à ce contexte, il comprend mieux les problèmes et propose plus vite des correctifs précis. Cela renforce ma confiance dans le code qu’il produit.
Nous espérons que notre expérience donnera à d’autres l’envie d’essayer ces intégrations. J’ai de moins en moins l’impression d’utiliser un outil et de plus en plus celle de programmer en binôme avec une IA qui voit ce que nous voyons.