Bien choisir son environnement de développement logiciel avec l’IA

La question « Quel environnement d’IA code le mieux ? » perd de sa valeur. GitHub Copilot, Google Antigravity, JetBrains Air, Kiro, Zed et Zenflow peuvent placer des modèles de codage performants derrière un prompt de développeur. La question la plus difficile est de savoir dans quelle mesure une équipe peut exercer un contrôle pendant que ces modèles planifient, modifient, testent et, parfois, fonctionnent de manière autonome.

L’ampleur de l’outillage montre ce basculement. GitHub Copilot prend en charge environ deux douzaines de modèles d’IA, y compris des modèles d’OpenAI, d’Anthropic et de Google. Une installation particulière de Visual Studio Code a exposé 346 outils aux agents Copilot via des intégrations par défaut, des serveurs Model Context Protocol (MCP) et des plug-ins. Ce chiffre décrit une installation donnée plutôt qu’une configuration Copilot standard.

Les équipes doivent donc évaluer l’autonomie, le contexte, les autorisations, la structure des workflows, l’isolation et la vérification. Une petite modification de code peut nécessiter peu de processus, tandis qu’une fonctionnalité plus large peut exiger des exigences explicites et des vérifications répétées. Un environnement qui prend en charge les deux donne aux équipes la latitude d’adapter les contrôles au travail à réaliser.

La décision en matière de codage par IA a dépassé la simple génération de code

L’assistance au codage est passée de la complétion de mots à la complétion de lignes, de fonctions, puis à la génération de programmes sur une période d’environ dix ans. Les systèmes agentiques vont plus loin. Un agent peut inspecter une base de code existante, proposer des modifications, éditer des fichiers, compiler le résultat, exécuter des tests, réagir aux échecs et itérer.

Cela déplace une partie du travail du développeur vers l’orientation et la vérification des modifications générées par la machine. Le développeur décide du contexte qu’un agent reçoit, du degré d’indépendance avec lequel il peut opérer, des outils qu’il peut invoquer et des preuves requises avant d’accepter son résultat.

GitHub Copilot illustre cette portée élargie. D’abord proposé comme plug-in pour Visual Studio Code en 2021, Copilot fonctionne désormais dans VS Code, Visual Studio, Vim, Neovim, la suite d’IDE JetBrains, la ligne de commande via GitHub Copilot CLI et une extension GitHub CLI, ainsi que dans GitHub lui-même.

Visual Studio Code peut également ajouter des modèles au-delà de ceux inclus par défaut avec un abonnement Copilot. Les options incluent Foundry Local via AI Toolkit, GitHub Models via AI Toolkit, Microsoft Foundry via AI Toolkit et des modèles locaux via Ollama. Les modèles Ollama locaux ne sont pas décomptés d’un forfait Copilot, bien qu’ils consomment du GPU local ou de la mémoire unifiée. Ces capacités s’inscrivent dans l’écosystème Microsoft et GitHub, dont les fournisseurs tirent un bénéfice commercial d’une adoption plus large de leurs outils de développement.

Les environnements cités se recoupent sur certaines familles de modèles. L’accès aux modèles n’est qu’un élément de la décision. Les règles qui régissent la manière dont un modèle fonctionne à l’intérieur d’un environnement en sont un autre.

Les IDE deviennent des environnements d’orchestration

Un agent d’IA est un système capable d’inspecter son environnement de travail, de sélectionner et d’exécuter des actions, puis d’ajuster son plan à mesure que de nouvelles informations apparaissent. En développement, cela peut signifier décomposer une demande en étapes, lire les fichiers d’un dépôt, modifier du code, invoquer des outils, exécuter des tests et réagir aux résultats.

L’environnement de développement devient une couche d’orchestration : l’endroit où modèles, outils, contexte, autorisations et workflows sont coordonnés.

GitHub Copilot expose trois modes de fonctionnement par défaut. Plan étudie un problème et esquisse une approche en plusieurs étapes. Ask permet la conversation sans modifier les fichiers. Agent peut modifier les fichiers dans l’espace de travail. Des modes personnalisés peuvent étendre ces choix via des plug-ins ou une configuration utilisateur ; l’installation mentionnée plus haut contenait 16 modes personnalisés.

Les agents Copilot disposent également de neuf catégories d’outils par défaut, avec potentiellement de nombreux outils dans chaque catégorie. Les serveurs MCP et les plug-ins peuvent en ajouter davantage. Certaines tâches d’agent peuvent s’exécuter pendant des heures avec seulement quelques demandes d’autorisation.

Google Antigravity adopte une approche différente. Google a présenté le Google Antigravity d’origine en novembre 2025 comme une plateforme de développement agentique construite à partir de l’IDE VS Code « Code – OSS » utilisé en interne par Google. Le mono-dépôt logiciel de Google exige une infrastructure spécialisée, y compris son outil interne de contrôle de version Piper plutôt que Git.

Le 19 mai 2026, Antigravity est devenu la base d’un écosystème plus large. Google Antigravity 2.0 est une application desktop autonome, centrée sur les agents, issue de l’Agent Manager. Google Antigravity IDE est un téléchargement d’IDE distinct. Google Antigravity CLI permet aux développeurs d’invoquer, de surveiller et d’interagir avec des agents depuis un terminal, tandis que le Google Antigravity SDK prend en charge le développement d’agents personnalisés. Google a un intérêt commercial dans l’adoption de cet écosystème et de ses modèles Gemini.

Antigravity permet aux développeurs de modifier le comportement des agents via des contrôles de workflow. Son contrôle « + » ajoute des médias, des mentions, des actions et, dans Antigravity 2.0, un accès au navigateur. Le sous-agent navigateur peut cliquer, faire défiler, saisir du texte, inspecter les logs de console, capturer le DOM, prendre des captures d’écran et enregistrer des vidéos, avec une intégration MCP native de Chrome DevTools.

Les commandes slash modifient le degré d’indépendance avec lequel un agent opère. /goal indique à l’agent de continuer jusqu’à ce qu’une tâche soit terminée sans demander d’entrée intermédiaire. /grill-me lui indique de poser des questions avant l’implémentation, tandis que /schedule crée des Scheduled Tasks ponctuelles ou récurrentes. Les skills au niveau de l’espace de travail et au niveau global utilisent un fichier SKILL.md avec un frontmatter YAML, ainsi que des scripts, exemples et ressources facultatifs ; la description YAML aide un agent à reconnaître quand un skill s’applique.

Le choix du modèle s’inscrit dans ces contrôles. Google Gemini 3.6 Flash est le modèle par défaut d’Antigravity et peut fonctionner avec un effort faible, moyen ou élevé. Google le décrit comme son modèle agentique et de codage le plus performant à ce jour et affirme qu’il est plus rapide que d’autres modèles frontier sur Antigravity. Ces affirmations de performance proviennent de Google, qui fournit Gemini et bénéficie de son utilisation. Antigravity prend également en charge Gemini 3.5 avec un effort faible, moyen et élevé ; Gemini 3.1 Pro à deux niveaux d’effort ; Claude Sonnet 4.6 et Opus 4.6 d’Anthropic avec le mode thinking activé ; et GPT-OSS-120B avec un effort moyen. Google recommande de sélectionner le niveau d’effort le plus bas suffisant pour la tâche afin de réduire la consommation de tokens.

JetBrains Air fait des limites d’exécution une partie de son modèle de contrôle. Une tâche peut s’exécuter dans un espace de travail local, un Git worktree, un conteneur Docker isolé ou, une fois configurée, dans le cloud depuis une machine locale ou un navigateur. Il prend en charge quatre fournisseurs d’agents : OpenAI Codex, Anthropic Claude, Google Gemini et le propre Junie de JetBrains. Les développeurs peuvent fournir des abonnements ou des clés API pour OpenAI, Anthropic et Google, ou utiliser l’hébergement JetBrains via un abonnement. JetBrains a un intérêt commercial dans l’adoption d’Air et de son service d’hébergement.

Air propose quatre niveaux d’autorisation allant de plan first à full access. Les développeurs peuvent sélectionner un agent au démarrage d’une tâche, changer de modèle au sein de cet agent, définir le niveau d’effort pour certains agents et fournir du contexte à partir de fichiers, dossiers, documentation, branches Git et autres sources. Dans un test, Claude Sonnet 4.6 (fenêtre de contexte de 1M) a fonctionné avec un effort élevé et des autorisations Ask pour optimiser localement un calculateur de pi en C++.

Ces conceptions rendent la question centrale concrète : qui décide de ce qu’un agent peut voir et faire, et à quel moment un humain doit-il intervenir ?

Une plus grande autonomie accroît la valeur d’une structure explicite

L’autonomie soulève une deuxième question : quelles informations doivent gouverner les décisions d’un agent tout au long d’une tâche ?

Kiro traite ce point au moyen de spécifications et d’un steering persistant. Développé par « une petite équipe aux convictions affirmées au sein d’AWS », Kiro est proposé comme un IDE basé sur Code OSS et comme Kiro CLI (kiro-cli). Le CLI dispose actuellement d’un agent planificateur et du steering d’agent, mais ne gère pas les specs. Kiro IDE (kiro) prend explicitement en charge à la fois le vibe coding et le développement piloté par les spécifications (SDD). AWS a un intérêt commercial dans l’adoption de Kiro.

Les exigences EARS utilisent la forme WHEN [condition/event] THE SYSTEM SHALL [expected behavior]. Cela rend les exigences suffisamment explicites pour être testées. Kiro peut générer des tests basés sur les propriétés (PBT) à partir d’exigences formatées selon EARS. Le PBT vérifie des propriétés sur des entrées générées au lieu de s’appuyer uniquement sur des exemples sélectionnés manuellement.

Le steering fournit un autre contrôle. Kiro peut générer product.md pour l’objectif, les utilisateurs cibles, les fonctionnalités clés et les objectifs métier ; tech.md pour les frameworks, bibliothèques, outils de développement et contraintes techniques ; et structure.md pour l’organisation des fichiers, les conventions de nommage, les modèles d’import et les décisions d’architecture. Ces fichiers conservent des informations sur l’espace de travail qui peuvent guider les interactions ultérieures avec l’agent.

Kiro peut également importer et réviser des spécifications et générer une spécification après une session de vibe coding. Il prend en charge plus d’une douzaine de fournisseurs de contexte de chat, dont #codebase, #spec et #code, ainsi que des skills suivant le standard ouvert Agent Skills et des serveurs MCP.

Sa configuration de modèles ajoute une autre dimension. Dans le forfait gratuit décrit, Kiro IDE prenait en charge Anthropic Claude Sonnet 4.5 et Sonnet 4.0 ainsi que cinq modèles open-weight, avec une sélection automatique du modèle disponible. Sa documentation mentionnait également GPT-5.6 Sol, Terra et Luna d’OpenAI ; Claude Opus 4.5, 4.6, 4.7, 4.8 et 5.0 ; ainsi que Claude Haiku 4.5, activable avec un forfait Pro (20 $/mois) ou supérieur.

Ces mécanismes résolvent des problèmes différents. Les autorisations limitent les actions, tandis que le contexte détermine quelles informations sont disponibles pour une demande. Le steering préserve les conventions du projet ; les exigences définissent le comportement attendu ; l’isolation limite l’endroit où l’exécution et les modifications ont lieu. À mesure qu’un agent prend davantage de décisions entre les points de contrôle humains, chacun de ces contrôles peut façonner le travail produit.

La rigueur maximale a un coût en effort

Le vibe coding se situe près d’une extrémité de l’éventail des workflows. Un développeur dirige une IA principalement au moyen de prompts et laisse au modèle une marge importante dans l’implémentation. Cela peut alléger les prototypes rapides, mais donne au développeur moins d’exigences explicites pour vérifier l’implémentation.

Le SDD crée une surface de contrôle différente. Une spécification consigne les exigences avant que l’agent ne prenne une série de décisions d’implémentation. Le développeur dispose alors d’une base explicite pour vérifier si ces décisions restent alignées sur le comportement attendu.

Créer et maintenir cette spécification demande du travail. Une modification limitée avec une intention claire peut ne pas justifier des exigences, une documentation d’architecture, un plan d’implémentation et chaque étape de workflow associée. Il reste donc une zone intermédiaire entre des prompts peu structurés et un processus SDD complet.

Plusieurs approches de développement couvrent certaines parties de cette zone. Le behavior-driven development organise le travail autour du comportement attendu. « Facts first », une variante du test-driven development, utilise des faits définis comme des invariants exécutables qu’une machine peut tester. L’intent-driven software development (IDSD) développe l’ancienne pratique de l’intention, du contexte et des attentes (ICE). Ces approches offrent des moyens d’ancrer le travail sans en établir une comme globalement supérieure.

Zenflow fait de la profondeur du workflow un choix explicite. Développé par l’équipe Zencoder, Zenflow coordonne des agents de codage via des workflows orientés SDD et se décrit comme une couche d’orchestration. Les plug-ins Zencoder fonctionnent dans Zenflow, tandis que des fonctionnalités Zenflow telles que les guided workflows ont également été ajoutées à Zencoder. Zencoder bénéficie commercialement de l’adoption des deux produits ; ces descriptions sont donc des affirmations du fournisseur sur son propre outillage.

Andrew Filev, PDG de Zencoder, a déclaré que son équipe d’ingénieurs expérimentés utilisait Zenflow pour le développement de son propre produit depuis plus d’un an lorsqu’on l’a interrogé sur son niveau de préparation pour du code de production. Filev dirige l’entreprise à l’origine de Zenflow et bénéficie commercialement de la confiance accordée au produit.

Zenflow propose quatre workflows standard :

Les équipes peuvent également définir des workflows personnalisés pour les adapter à leurs standards.

La conception sépare le choix de l’agent du choix du workflow. L’agent de codage peut être Zencoder, Claude Code, Codex ou Gemini. Zencoder est aussi le nom de l’entreprise et le nom de son plug-in d’IDE d’IA ; le plug-in Zencoder propose environ neuf modèles.

Kiro fournit un autre exemple de structure de workflow variable grâce à sa prise en charge du vibe coding et du SDD. Ces exemples n’établissent pas de catégories de workflow universelles. Ils montrent deux approches fournisseurs qui donnent aux développeurs plus d’un niveau de processus autour du travail des agents.

La vérification devient une partie de l’environnement de développement

Le contrôle du workflow a une valeur limitée si les équipes ne peuvent pas vérifier ce qu’un agent a produit. La vérification doit donc faire partie de toute évaluation de l’orchestration des agents.

Les tests basés sur les propriétés de Kiro en sont un exemple. Les exigences EARS peuvent alimenter la génération de PBT, reliant le comportement attendu à des vérifications exécutables. Cela transforme les données de spécification en entrée de test.

Zed adopte une approche centrée sur la revue. L’équipe à l’origine de Zed a précédemment créé Atom, l’éditeur de texte hackable ; Electron, la plateforme d’applications desktop JavaScript ; et Tree-sitter, un framework d’analyse syntaxique désormais largement utilisé pour l’analyse de code et la coloration syntaxique. Atom a été abandonné, tandis qu’Electron et Tree-sitter restent actifs.

Zed lui-même est écrit en Rust et met l’accent sur la vitesse, avec un accès aux modèles de langage reposant largement sur une approche « bring your own key » ; les modèles hébergés par Zed nécessitent un abonnement. Zed a un intérêt commercial dans l’utilisation de son service payant de modèles hébergés. La version v1.13.2 comprenait une évolution plus large qui avait récemment ajouté Claude Opus 5 d’Anthropic, GPT-5.6 d’OpenAI, llama.cpp comme fournisseur de modèles et la compaction automatique du contexte d’agent, aux côtés de capacités déjà établies, notamment les skills, la collaboration et le développement à distance.

Dans un test de calcul de π en C++, le skill de revue de code de Zed a d’abord évalué le programme et proposé des modifications. Le développeur les a examinées avant d’autoriser l’implémentation et les tests avec Claude Sonnet 4.6. Le contrôle clé était un point de contrôle humain entre la recommandation de la machine et la modification par la machine.

Zenflow utilise un schéma de vérification différent. Zencoder affirme que ses workflows exécutent des tests automatisés et une revue de code inter-agents, les tests échoués déclenchant des corrections automatiques. Il affirme également que les tâches s’exécutent dans des Git worktrees isolés et que plusieurs tâches peuvent s’exécuter en parallèle dans des environnements isolés. Les projets sont divisés en tâches, sous-tâches et chats, avec un statut des tâches disponible via des tableaux Kanban ou des vues en liste empilée. Il s’agit d’affirmations du fournisseur qui vend le produit.

Pour un dirigeant qui évalue ces environnements, la qualité de génération n’est qu’une partie de la décision. Le workflow doit aussi produire des preuves avant que le code n’avance : résultats de compilation, tests automatisés, vérifications de propriétés, points de contrôle de revue, gestion des échecs et isolation de l’exécution.

Le suivi de l’usage peut faire de ces choix d’orchestration une question économique autant que technique. À compter du 1er juin 2026, GitHub a modifié la comptabilisation de l’usage de Copilot, passant des Premium Request Units à la consommation de tokens, tandis que les complétions de code et les suggestions de modification suivante sont exemptées des limites de tokens. GitHub contrôle les conditions commerciales de Copilot ; cette règle de comptabilisation doit donc être évaluée comme une politique fournisseur plutôt que comme une mesure indépendante de l’efficacité d’ingénierie.

La recommandation de Google d’exécuter les modèles Gemini au niveau d’effort le plus bas capable de mener la tâche à bien reflète la même préoccupation pratique au sein d’Antigravity : le niveau d’effort du modèle peut affecter la consommation de tokens. Google fournit les modèles et la plateforme et a donc un intérêt commercial dans la manière dont les clients les utilisent.

Points clés

Évaluez l’orchestration : Le choix du modèle devient moins différenciant à mesure que les environnements de développement IA gagnent en capacités agentiques. Les dirigeants devraient comparer la manière dont les plateformes gèrent l’autonomie, le contexte, les autorisations, les outils, les workflows et les limites d’exécution.
Faites correspondre l’autonomie à une structure explicite : À mesure que les agents prennent davantage de décisions de manière indépendante, les équipes ont besoin de contrôles plus solides sur les exigences, le contexte du projet, les autorisations et l’isolation. Choisissez des environnements capables de préserver ces contraintes tout au long du travail d’un agent.
Adaptez le processus à la tâche : Un développement entièrement piloté par les spécifications peut améliorer la rigueur, mais ajoute un effort qui n’a pas forcément de sens pour chaque modification. Les dirigeants devraient privilégier des environnements qui prennent en charge des workflows légers pour les tâches limitées et des processus plus structurés pour les travaux complexes ou à haut risque.
Faites de la vérification une partie du workflow : Le code généré par des agents a toujours besoin de preuves qu’il fonctionne comme prévu. Privilégiez les environnements qui intègrent les tests, les points de contrôle de revue, la gestion des échecs et l’exécution isolée plutôt que de traiter la vérification comme une étape finale distincte.