Microsoft détaille le routage local et le bac à sable de Copilot

Le 8 octobre 2026, Microsoft a détaillé les modèles locaux et les outils isolés de GitHub Copilot. Le mode Auto annoncé doit répartir certaines tâches entre l’inférence sur l’appareil et le cloud dans Copilot CLI, l’application Copilot et Visual Studio Code ; Microsoft vise la fin du mois pour son arrivée. Ce suivi entre dans le détail du volet Copilot après notre précédent article sur l’IA locale et le cloud dans Windows.

Microsoft présente les options de modèles locaux et les outils isolés comme étant en cours de déploiement. Auto doit choisir entre calcul local et cloud selon le contexte de la tâche et l’état du cache au fil d’une session. La sélection manuelle d’un modèle local reste une option distincte. L’annonce détaille ainsi deux décisions différentes : où le modèle traite la demande, et quelles limites s’appliquent aux outils utilisés par l’agent.

BYOK et Auto : deux façons de choisir le modèle

BYOK, pour « Bring Your Own Key », permet à l’utilisateur de configurer un fournisseur ou de choisir un modèle. Dans Copilot CLI, les types de fournisseurs pris en charge sont openai (par défaut), azure et anthropic. Le type openai englobe notamment Ollama, vLLM, Foundry Local et d’autres services compatibles avec l’API OpenAI Chat Completions.

Microsoft décrit Auto comme un mode qui doit choisir entre l’inférence locale et le cloud. Il concerne Copilot CLI, l’application Copilot et Visual Studio Code. Pour les modèles sélectionnés manuellement, l’annonce cite MAI Code 1.1 Flash via Windows ML, ainsi que des modèles proposés par des points de terminaison locaux compatibles avec l’API OpenAI.

Pour utiliser un modèle local compatible avec Copilot CLI, GitHub indique de renseigner COPILOT_PROVIDER_BASE_URL et COPILOT_MODEL. L’exemple Ollama utilise http://localhost:11434 ; un service local sans authentification n’a pas besoin de clé API. Le modèle doit prendre en charge l’appel d’outils et le streaming. Une fenêtre de contexte d’au moins 128 000 jetons est recommandée pour obtenir de meilleurs résultats, sans être présentée comme une exigence absolue.

Dans Visual Studio Code, l’ajout d’un fournisseur ou d’un point de terminaison personnalisé passe par le sélecteur de modèles, puis par Manage Language Models. Pour Ollama, Visual Studio Code recommande l’extension officielle : son fournisseur Ollama intégré est déprécié. Les modèles utilisés par les agents doivent prendre en charge l’appel d’outils.

Un modèle local ne suffit pas à tout faire hors ligne

Dans Visual Studio Code, le chat BYOK avec un modèle local peut fonctionner entièrement hors ligne, sans compte GitHub ni abonnement Copilot. Cette possibilité concerne le chat : la recherche sémantique, les suggestions de code et les fonctions qui reposent sur des embeddings nécessitent encore un compte GitHub.

Copilot CLI dispose de son propre réglage, COPILOT_OFFLINE=true, qui empêche le client de contacter GitHub. Si le fournisseur configuré est distant, il reçoit toujours les invites et le contexte de code. Pour isoler aussi ces échanges, le fournisseur doit être local ou fonctionner dans le même environnement isolé. Auto, qui prévoit une sélection entre modèles locaux et cloud, n’est pas un mode hors ligne en soi.

Ce que le bac à sable protège

Microsoft décrit le bac à sable (sandbox) comme un contrôle distinct du choix du modèle. Les commandes shell et, par défaut, les serveurs locaux Model Context Protocol (MCP) et de langage s’exécutent à l’intérieur de la frontière de processus.

Les outils de fichiers intégrés suivent une autre voie : les règles sont vérifiées par le mécanisme de contrôle de l’agent, sans isolation de processus enfant imposée par le système d’exploitation. Les serveurs MCP distants, eux, restent hors du bac à sable local. Un modèle exécuté sur l’appareil et les permissions accordées aux outils ne sont donc pas une seule et même protection.

Les mécanismes diffèrent selon le système

Microsoft cite Microsoft Execution Containers (MXC), avec le niveau BaseContainer de ProcessContainer, pour Windows. Sur macOS, le mécanisme nommé est Seatbelt ; sur Linux, bubblewrap. Selon Microsoft, ces mécanismes ne nécessitent ni machine virtuelle séparée ni image de conteneur.