Visual Studio passe au multi-modèle pour ses agents IA

Microsoft vient d’ajouter une nouvelle brique à Visual Studio qui paraît, au premier regard, assez simple : Bring Your Own Model, ou BYOM. Dans Visual Studio 18.10 Insiders, il devient possible de connecter son propre modèle d’IA au nouvel Agent en Preview, via Microsoft Foundry, OpenAI, Anthropic ou Ollama.

Le changement peut sembler surtout pratique : choisir Claude pour une tâche, GPT pour une autre, ou un modèle local lorsqu’on veut garder certaines données sur sa propre infrastructure.

Mais l’évolution raconte quelque chose de plus large. Microsoft commence à traiter Visual Studio non plus comme un IDE lié à un assistant ou à un modèle précis, mais comme une couche capable d’accueillir plusieurs moteurs IA dans le même workflow de développement.

Ce que Microsoft ajoute exactement

BYOM est disponible en Preview dans Visual Studio 18.10 Insiders, sur les éditions Community, Professional et Enterprise.

Depuis le sélecteur de modèles du Chat, le développeur peut ajouter un fournisseur puis utiliser le modèle choisi dans le nouvel Agent Mode. Les fournisseurs officiellement pris en charge dans cette Preview sont :

• Microsoft Foundry ;
• OpenAI ;
• Anthropic ;
• Ollama.

Microsoft prend également en charge les URL personnalisées pour OpenAI et Ollama.

Le point important est que ces modèles ne sont plus seulement utilisés comme une alternative dans une fenêtre de chat. Ils peuvent désormais alimenter le nouvel Agent de Visual Studio, construit sur un harnessCadre d’évaluation / d’exécution qui mesure, contraint et observe un modèle ou un agent (jeux de tests, métriques, logs). basé sur le GitHub Copilot SDKSoftware Development Kit : bibliothèques et outils pour intégrer un service dans une application..

Et l’utilisation du BYOM ne dépend pas d’une connexion à GitHub : Microsoft précise que l’on peut connecter un modèle dans Agent Mode avec ou sans authentification GitHub.

Ce n’est pas la première ouverture de Visual Studio

Microsoft avait déjà introduit une première forme de Bring Your Own Model dans Visual Studio en 2025.

À l’époque, il était possible de connecter des clés OpenAI, Anthropic ou Google dans le Chat de Visual Studio. Mais la portée était plus limitée : le BYOM ne concernait pas les complétions, les messages de commit ou plusieurs autres fonctions IA, et certaines briques comme l’indexationInclusion d’une URL dans l’index d’un moteur, condition nécessaire (mais non suffisante) pour ranker. du dépôt continuaient à passer par les APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). de Copilot. Cette version n’était par ailleurs pas disponible pour les utilisateurs Copilot Business ou Copilot Enterprise, ce qui limitait fortement sa portée en entreprise.

La Preview 2026 n’est donc pas une simple extension de ce dispositif. Microsoft précise que l’ancienne expérience BYOM des modes Ask et Agent n’est plus prise en charge : les modèles déjà ajoutés doivent être configurés à nouveau après la mise à jour. Il s’agit bien d’un breaking change, avec une nouvelle implémentation centrée sur le nouvel Agent.

La liste des fournisseurs a elle aussi évolué : Google, présent dans le BYOM 2025, n’apparaît plus dans la Preview 2026. Il n’y a donc pas, à ce stade, de support direct de Gemini dans cette nouvelle expérience.

C’est ce changement d’architecture qui rend l’annonce plus intéressante qu’un simple nouveau sélecteur de modèles.

Visual Studio devient une couche d’orchestration

Depuis deux ans, l’environnement d’un développeur utilisant intensivement l’IA peut vite devenir chargé.

Une équipe peut utiliser GitHub Copilot pour les complétions et certaines fonctions intégrées à l’IDE, Claude Code pour des tâches agentiques plus longues, puis un autre outil ou un modèle local pour des contraintes spécifiques de confidentialité ou de coût.

BYOM ouvre une autre possibilité : conserver Visual Studio comme environnement principal et changer de modèle à l’intérieur de cet environnement.

Microsoft décrit lui-même le problème en expliquant que les développeurs ne travaillent plus dans un monde où un seul modèle suffit à tous les usages. Certaines équipes veulent un modèle pour le développement quotidien, un autre pour une tâche spécialisée et un troisième approuvé par leur organisation.

Dans cette logique, le modèle devient progressivement une ressource sélectionnable, au même titre qu’un runtime ou un environnement d’exécution.

On peut alors imaginer choisir un modèle selon le contexte : performance, coût, capacités de raisonnement, politique de l’entreprise ou hébergement local, sans changer complètement d’outil.

Est-ce la fin de l’empilement des assistants IA ?

Pas encore.

Il serait tentant de conclure qu’avec Claude ou GPT directement disponibles dans l’Agent de Visual Studio, un développeur n’aura bientôt plus besoin d’installer plusieurs assistants complémentaires.

C’est une possibilité, pas une conséquence acquise.

Claude Code, GitHub Copilot et les autres outils ne sont pas de simples enveloppes autour d’un modèle. Ils apportent aussi leur propre manière de collecter le contexte, d’utiliser le terminal, de modifier plusieurs fichiers, d’exécuter des commandes, de travailler avec Git ou d’enchaîner des tâches agentiques.

Donner accès au même modèle ne signifie donc pas reproduire automatiquement le même produit.

En revanche, plus Visual Studio enrichira son Agent, plus cette distinction pourra devenir importante. Si l’IDE fournit lui-même suffisamment de contexte, d’outils et de capacités d’action, alors l’intérêt d’installer un assistant différent uniquement pour accéder à un autre modèle peut diminuer.

C’est probablement là que BYOM devient stratégique : Microsoft ne promet pas de remplacer tous les assistants, mais commence à rendre leur modèle sous-jacent interchangeable dans un environnement commun.

Un enjeu important — et un risque immédiat — pour les entreprises

L’entreprise est évidemment l’une des cibles de BYOM. Microsoft met en avant des besoins bien réels : modèles approuvés derrière des endpoints privés, contraintes sur les flux de données, identité, conformité, coûts ou performances.

À terme, une organisation pourra par exemple s’appuyer sur Microsoft Foundry pour exposer à ses développeurs des modèles approuvés et centraliser davantage la configuration.

Mais la Preview actuelle prend de l’avance sur la gouvernance. BYOM est activé par défaut sur Community, Professional et Enterprise, alors que les contrôles administrateurs permettant à une organisation de le désactiver ne sont pas encore disponibles. Microsoft prévoit une policy ADMX pour la disponibilité générale de Visual Studio 18.10, destinée aux éditions Professional et Enterprise.

Concrètement, pendant cette phase Preview, une entreprise ne dispose donc pas encore du verrou central permettant d’empêcher un développeur de connecter un fournisseur externe depuis Visual Studio. Pour les organisations soumises à des règles strictes de conformité ou de gestion des données, c’est un risque à encadrer, pas encore une réponse complète au problème de gouvernance.

Microsoft prévoit ensuite, pour Professional et Enterprise, une configuration centralisée des modèles, ainsi que des réglages plus fins sur la taille du contexte, les appels d’outils ou l’effort de raisonnement, et un support plus large des fournisseurs.

Autrement dit, l’intérêt de BYOM pour les grandes organisations est réel, mais la couche de contrôle administratif arrive après l’ouverture technique.

Une Preview avec encore beaucoup de limites

Microsoft insiste d’ailleurs sur le caractère précoce de la fonctionnalité.

Tous les modèles ne supportent pas toutes les capacités de l’Agent. L’entreprise ne certifie pas encore toutes les combinaisons modèle-fournisseur, et certaines fonctions peuvent être indisponibles si le modèle choisi ne possède pas les capacités nécessaires.

Ce point est essentiel : multi-modèle ne veut pas encore dire interchangeable à 100 %.

Un modèle capable de répondre à une question ou de générer du code n’est pas nécessairement capable d’utiliser correctement les outils de l’Agent, de gérer un contexte très large ou de suivre un workflow complexe sur un dépôt.

Microsoft travaille justement sur une meilleure détection de compatibilité entre modèles et fonctionnalités.

Le modèle devient une pièce remplaçable de l’IDE

Cette évolution rejoint une tendance déjà visible dans les outils de développement IA : le modèle compte toujours énormément, mais il n’est plus forcément le produit entier.

La couche qui entoure le modèle — contexte du projet, outils, permissions, mémoire, terminal, Git, orchestration — prend une importance croissante.

Avec BYOM dans Agent Mode, Visual Studio avance dans cette direction. Le développeur peut commencer à dissocier l’environnement dans lequel il travaille du modèle qui raisonne derrière l’Agent.

À court terme, cela donnera surtout davantage de choix aux utilisateurs avancés et aux entreprises qui ont déjà leurs propres modèles ou contraintes d’infrastructure.

À plus long terme, la conséquence pourrait être plus structurante : plutôt que d’accumuler un assistant par fournisseur de modèle, les développeurs pourraient progressivement travailler dans un même environnement agentique capable de changer de moteur selon le besoin.

Visual Studio n’en est pas encore là. Mais avec cette nouvelle Preview, Microsoft vient clairement de poser une brique dans cette direction.