Alternative GitHub Copilot avec modèle local : 6 choix en 2026

Chercher une alternative GitHub Copilot capable d'utiliser un modèle local n'implique plus forcément de quitter VS Code. Depuis juin 2026, la donne locale autour de GitHub Copilot a changé : l'éditeur exécute le chat et les workflows d'agents hors ligne, sans compte GitHub ni abonnement Copilot. En revanche, ses suggestions inline standard ne fonctionnent toujours pas avec des modèles locaux. Il ne reste donc que trois vraies raisons de changer : obtenir une complétion locale avec Tab, centraliser l'auto-hébergement ou adopter un workflow d'agent plus performant. Et pour une équipe de 10 personnes, l'alternative payante la moins chère ne fait économiser que $480 par an, avant le matériel et l'administration.

En bref : Zed est la meilleure alternative GitHub Copilot entièrement locale

Zed est la meilleure alternative à GitHub Copilot si l'agent de code et les suggestions inline doivent tous deux tourner sur une infrastructure que vous contrôlez. Kilo Code convient mieux si changer d'éditeur est exclu. Cline est l'agent local spécialisé le plus solide dans VS Code, Tabby s'impose pour déployer un serveur de complétion administré de façon centralisée, Aider offre l'approche terminal la plus nette autour de Git, tandis qu'OpenCode couvre le plus d'interfaces.

Une septième réponse reste possible : ne rien changer. Si un chat et un agent locaux suffisent, la version actuelle de VS Code se connecte déjà à Ollama et à d'autres fournisseurs locaux. Une alternative ne se justifie que si elle comble un manque précis.

Les prix, limites, modalités d'essai et capacités ci-dessous ont été vérifiés sur les pages en ligne de chaque éditeur le 25 août 2026. Le « prix de départ » désigne le coût du logiciel ou de la plateforme. Un modèle local peut toujours entraîner des dépenses de matériel, d'électricité, d'installation et de maintenance.

Avant de changer, sachez ce que VS Code exécute déjà en local

VS Code est désormais un hôte crédible pour les modèles locaux, mais uniquement sur une moitié de l'expérience Copilot. Avec la mise à jour BYOK de juin 2026 de Microsoft, VS Code peut relier Ollama, Foundry Local et des fournisseurs de modèles compatibles au chat et aux workflows d'agents pris en charge. Le tout fonctionne sans connexion à GitHub ni abonnement Copilot, y compris entièrement hors ligne.

GitHub Copilot ne devient pas pour autant un produit hébergé localement. C'est VS Code qui sert de couche applicative : l'éditeur fournit au modèle des outils, du contexte et une boucle d'interaction. Le modèle peut s'exécuter en local tandis que VS Code fournit l'interface de chat et d'agent.

Quatre définitions évitent de fausser la comparaison :

• Modèle local : l'inférence s'exécute sur votre ordinateur ou sur un équipement que vous contrôlez.
• Modèle auto-hébergé : l'endpoint se trouve dans une infrastructure sous votre contrôle. Il peut être installé sur une autre machine ou dans votre cloud privé, et non sur le poste du développeur.
• Agent : le modèle peut examiner des fichiers, en modifier plusieurs et utiliser des outils comme un terminal, dans le cadre du système d'autorisations de l'application.
• Complétion inline : le texte fantôme ou la suggestion multiligne qui apparaît pendant la saisie et que l'on accepte généralement avec Tab.

Le manque se situe sur ce dernier point. D'après la documentation actuelle de Microsoft sur les modèles de langage, le BYOK s'applique au chat et aux tâches utilitaires, mais pas aux suggestions inline standard. La recherche sémantique et les fonctions reposant sur des embeddings continuent également de dépendre de GitHub ou de Copilot. VS Code expose bien une API d'extension grâce à laquelle d'autres produits peuvent proposer leur propre complétion, mais son chemin natif vers les modèles locaux n'envoie pas les suggestions inline à Ollama.

L'ancienne question « quelle alternative locale à Copilot ? » se décompose donc en deux questions plus précises :

1. Voulez-vous qu'un modèle local planifie et modifie le code dans une boucle d'agent visible ?
2. Voulez-vous aussi que chaque suggestion affichée pendant la saisie soit générée localement ?

Si vous répondez non à la seconde, ajouter une extension risque de compliquer l'environnement sans renforcer la confidentialité. Configurez l'éditeur Language Models, connectez le fournisseur local, sélectionnez le modèle pour le chat ou les tâches d'agent prises en charge, et conservez votre éditeur. Si vous répondez oui, Zed, Kilo Code ou Tabby deviennent pertinents, car chacun documente un chemin de complétion locale.

Cette nuance vaut également pour les promesses de fonctionnement hors ligne. Un chat local peut fonctionner sans Internet alors qu'une recherche dans le dépôt, une mise à jour d'extension, une opération distante de gestion de versions ou un service d'embeddings hébergé communique encore avec l'extérieur. « Le modèle est local » et « tout l'environnement de développement est isolé du réseau » ne sont pas des promesses équivalentes.

Le prix de Copilot que vous cherchez à remplacer

Les offres individuelles actuelles de GitHub sont Free, Student, Pro à $10 par mois, Pro+ à $39 par mois et Max à $100 par mois. Free comprend jusqu'à 2,000 complétions inline par mois, tandis que Student est gratuit pour les étudiants dont le statut est vérifié. Pour les organisations, Business coûte $19 par siège attribué et par mois, et Enterprise $39 par siège attribué et par mois.

La page des offres en vigueur de GitHub précise aussi que les nouvelles souscriptions Business en libre-service des organisations sur GitHub Free et GitHub Team sont temporairement suspendues depuis le 22 avril 2026. Cela ne modifie pas la base de comparaison de $19, mais peut changer le parcours d'achat. Une décision de remplacement doit partir de l'offre que l'organisation peut réellement acquérir, pas d'un tunnel de commande dont elle se souvient.

Comment ces alternatives à GitHub Copilot ont été retenues

Un produit n'a été retenu que si sa documentation actuelle décrivait un chemin officiellement pris en charge vers un modèle local pour un workflow de développement. Un dépôt que l'on pourrait théoriquement adapter pour appeler un endpoint local ne suffisait pas. Même exclusion pour un assistant cloud doté de solides garanties de confidentialité si l'inférence passe toujours par son propre service.

Les six produits ont été évalués selon cinq critères :

1. Couverture : les modèles locaux fonctionnent-ils pour l'agent, la complétion inline ou les deux ?
2. Clarté du déploiement : l'éditeur documente-t-il Ollama, LM Studio, llama.cpp, un endpoint compatible avec OpenAI ou un serveur auto-hébergé ?
3. Adéquation au workflow : le produit vit-il dans un éditeur, un terminal, une application desktop ou un service central ?
4. Premier mur opérationnel : quelle est la première contrainte rencontrée dans un déploiement sérieux — migration d'éditeur, modèle de complétion imposé, configuration matérielle minimale, limite à un GPU ou absence de contrôles d'identité ?
5. Coût total : quel est le prix de chaque offre logicielle publique, auquel s'ajoute le calcul ou l'inférence facturé hors plateforme ?

Aucun test pratique de performance n'est revendiqué ici. Latence et qualité en local dépendent trop de la taille du modèle, de sa quantification, de la longueur de contexte, de la mémoire GPU, de la structure du dépôt et de la tâche pour faire d'un résultat obtenu sur un portable une vérité générale. Le classement repose plutôt sur les capacités actuellement prises en charge, les prix exacts, les limites documentées et une analyse normalisée des coûts.

Cette méthode écarte aussi plusieurs noms connus. Un assistant de code uniquement cloud n'est pas une alternative avec modèle local sous prétexte que son offre gratuite est généreuse. Continue a été retiré du classement : sa page d'accueil indique désormais son acquisition par Cursor et présente le code open source restant comme une fondation, non comme un produit indépendant encore pris en charge pour un nouveau déploiement. Ce seul changement rend obsolètes plusieurs anciens comparatifs d'alternatives locales à Copilot.

Pour une vue plus large des solutions cloud et locales, le comparatif des meilleurs assistants de code IA en 2026 couvre davantage d'outils. Cette sélection reste volontairement stricte : chaque produit classé dispose d'un chemin documenté vers l'inférence locale.

1. Zed : la meilleure alternative locale complète à Copilot

Zed constitue le remplacement complet le plus convaincant, car l'éditeur documente l'usage de modèles locaux à la fois pour son Agent et pour son système Edit Prediction. Edit Prediction est la couche de complétion inline de Zed, avec des suggestions sur une ou plusieurs lignes. Cette double couverture est rare et lève l'ambiguïté qui entoure bien des promesses de « prise en charge d'Ollama ».

Il s'agit d'un éditeur de code complet, et non d'une extension VS Code. Pour Agent, Inline Assistant et les fonctions d'IA associées, les modèles locaux peuvent passer par Ollama, LM Studio, llama.cpp ou un serveur local compatible. Une configuration locale distincte pour Edit Prediction prend en charge Ollama, vLLM, le serveur llama.cpp, LocalAI et d'autres serveurs qui implémentent l'API de complétion OpenAI.

Cette architecture fait de Zed la réponse la plus simple pour un développeur indépendant qui veut localiser les deux flux et accepte de changer d'éditeur. C'est aussi la mutation de workflow la plus importante de ce comparatif. Extensions, raccourcis, habitudes de développement distant, fonctions de débogage et conventions d'équipe doivent tous être vérifiés avant une migration.

Idéal pour : les développeurs qui veulent réunir agent local et complétion inline locale dans un même éditeur.
Point fort : des chemins locaux documentés pour Agent comme pour Edit Prediction.
Tarifs : Personal à $0 pour toujours ; Pro à $10 par mois ; Business à $30 par siège et par mois ; au-delà des $5 inclus avec Pro, l'usage hébergé est facturé au tarif catalogue de l'API, majoré de 10%.
Essai gratuit : Pro pendant deux semaines ou jusqu'à épuisement de $20 de crédits de tokens d'essai ; aucun essai gratuit pour Business.

Tarifs de Zed : la limite que le prix masque

Zed Personal coûte $0 pour toujours et comprend 2,000 prédictions de modification hébergées acceptées, plus un usage illimité avec vos propres clés API ou des agents externes. Zed Pro coûte $10 par mois, inclut un nombre illimité de prédictions de modification et $5 de tokens hébergés, puis facture cet usage au tarif catalogue de l'API majoré de 10%. Zed Business coûte $30 par siège et par mois pour des politiques de modèles à l'échelle de l'organisation, des contrôles de données, une vue unifiée des dépenses, des prédictions de modification illimitées et un contrôle d'accès fondé sur les rôles.

Le mot « Business » peut induire de mauvaises attentes. L'offre ne comporte ni enveloppe fixe de crédits LLM, ni essai gratuit, ni prise en charge actuelle de SSO, SAML ou SCIM. Aucun minimum de sièges n'est imposé, même si les bons de commande commencent à 25 sièges. Dans une entreprise fortement contrainte par la gestion des identités, l'absence de cette famille de fonctions SSO peut peser davantage que l'exhaustivité de Zed sur les modèles locaux.

Pour 10 sièges, Zed Business revient à $3,600 par an avant l'usage des modèles ou le calcul local. Copilot Business coûte $2,280 pour le même nombre de sièges. Les seuls frais de plateforme de Zed sont donc supérieurs de $1,320. Choisissez-le pour la conception de l'éditeur et la maîtrise locale de bout en bout, pas pour réduire les licences.

Mini-tutoriel : utiliser Ollama pour Zed Agent et Edit Prediction

Zed documente séparément ses deux chemins locaux. Gardez cette séparation pendant la configuration : un agent opérationnel ne prouve pas que les prédictions inline sont elles aussi locales.

1. 1

   Démarrer le runtime local

   Installez Ollama, exécutez ollama pull mistral pour reprendre l'exemple Agent documenté par Zed, puis lancez ollama serve si le service ne démarre pas automatiquement. Zed devrait détecter les modèles Ollama téléchargés et les afficher dans son sélecteur de modèles.

2. 2

   Sélectionner le modèle de l'Agent

   Ouvrez le panneau Agent, choisissez le modèle Ollama détecté et commencez par une tâche circonscrite en lecture seule, par exemple l'explication d'un module. Vérifiez, à partir du fournisseur sélectionné et de l'activité du processus local, que la requête atteint bien Ollama.

3. 3

   Configurer Edit Prediction séparément

   Ouvrez les réglages edit_predictions de Zed. Dans l'exemple documenté par l'éditeur, le fournisseur est ollama, l'endpoint http://localhost:11434, le modèle qwen2.5-coder:7b-base, le format du prompt infer et le nombre maximal de tokens en sortie 512.

4. 4

   Valider les deux chemins

   Déconnectez le réseau sur une machine de test non critique. Envoyez un prompt à Agent, puis saisissez du code dans un fichier représentatif et confirmez qu'une prédiction Edit Prediction apparaît. Si le test Agent réussit mais que la complétion échoue, seule la moitié du déploiement est locale.

Le modèle précis doit correspondre à la machine et à la tâche. L'intérêt du tutoriel tient à la validation des deux chemins, pas au nom du modèle utilisé dans l'exemple. Un modèle local qui appelle mal les outils reste un mauvais choix pour Agent, même si sa complétion est satisfaisante.

2. Kilo Code : la meilleure option locale dans VS Code et JetBrains

Kilo Code est le meilleur choix lorsque l'éditeur ne doit pas changer, mais que l'agent et la complétion inline ont tous deux besoin d'un chemin local. Ses extensions open source couvrent VS Code et JetBrains, tandis que son CLI ajoute une interface dans le terminal. La migration est donc plus légère qu'avec Zed. Le produit documente Ollama en local pour l'agent, ainsi que Codestral en local via Ollama ou LM Studio pour l'autocomplétion.

Cette force s'accompagne de deux restrictions. Le modèle d'autocomplétion de Kilo est actuellement limité à Codestral : « complétion locale » ne signifie donc pas que n'importe quel modèle peut être sélectionné. Les recommandations pour l'agent fixent également un seuil matériel exigeant : au moins 24 GB de VRAM GPU, ou un Mac doté d'au moins 32 GB de mémoire unifiée, pour que les modèles locaux recommandés tournent à une vitesse convenable.

La documentation de Kilo se montre exceptionnellement franche sur la qualité. Elle recommande qwen3-coder:30b pour le travail d'agent, propose devstral:24b comme alternative et avertit que le modèle Qwen plus petit peut rater des appels d'outils, boucler ou produire davantage d'erreurs de syntaxe qu'un modèle cloud de pointe. Elle préconise une fenêtre de contexte d'au moins 32k et documente un délai d'expiration API par défaut de 10 minutes. Ce sont des exigences opérationnelles, pas des notes de bas de page.

Idéal pour : les utilisateurs de VS Code ou JetBrains qui veulent un agent local et un chemin de complétion locale pris en charge.
Point fort : la voie la moins disruptive vers ces deux workflows locaux dans des éditeurs familiers.
Tarifs : Individual à $0 ; Teams à $15 par utilisateur et par mois ; Enterprise sur devis ; inférence et calcul cloud facturés séparément.
Essai gratuit : offre Enterprise pendant 14 jours.

Tarifs de Kilo : trois factures, pas une

Les offres de plateforme de Kilo sont Individual à $0, Teams à $15 par utilisateur et par mois, et Enterprise sur devis. Teams ajoute les statistiques, les modes d'agent partagés, la facturation centralisée, le BYOK partagé, les contrôles de confidentialité et le support prioritaire. Enterprise ajoute SSO, OIDC, SCIM, les journaux d'audit, des limites par fournisseur, le BYOK via une passerelle privée, des engagements SLA et un support dédié. L'essai de 14 jours donne accès aux fonctions Enterprise ; le client choisit ensuite Teams ou Enterprise.

L'inférence constitue une décision séparée. Auto Free, BYOK ou l'exécution locale coûtent $0 par mois en frais d'inférence de plateforme Kilo. Kilo Gateway ne demande aucun abonnement et refacture les tarifs exacts des fournisseurs sans marge. Kilo Pass propose Starter à $19 par mois avec jusqu'à $26.60 de crédits mensuels, Pro à $49 avec jusqu'à $68.60, et Expert à $199 avec jusqu'à $278.60. L'achat de crédits supporte 5% de frais de traitement.

Les fonctions cloud créent une troisième facture. Code Review coûte $0.33 par heure. Cloud Agent Docker et Small coûtent chacun $0.60 par heure. Gas Town et Cloud Agent Standard coûtent chacun $1.20 par heure. La facturation se fait à la seconde et l'inférence du modèle reste séparée.

Pour 10 développeurs, Kilo Teams revient à $1,800 par an, contre $2,280 pour Copilot Business. L'écart de $480 représente le plafond local : dès que le matériel supplémentaire et l'administration dépassent ensemble $40 par mois, l'économie apparente sur la plateforme disparaît. Quelques heures consacrées par un ingénieur à la maintenance du service local peuvent suffire à le franchir.

3. Cline : le meilleur agent local transparent dans VS Code

Cline est le meilleur choix spécialisé pour utiliser dans VS Code un agent de code local soumis à validation. Il rend visibles les modifications de fichiers, les actions dans le terminal et le choix du fournisseur de modèles, sans abonnement individuel à la plateforme. Le chemin local est clairement documenté pour Ollama, LM Studio et Atomic Chat.

Cline ne remplace pas tous les usages de Copilot. Son cœur de produit est un agent, pas un substitut propriétaire à la complétion avec Tab. Si l'objectif est de générer localement le texte fantôme pendant la saisie, il faut l'associer à une extension de complétion distincte ou choisir Zed, Kilo Code ou Tabby. Ajouter une seconde extension peut rester une bonne architecture, mais impose alors deux politiques, deux circuits de mise à jour et, potentiellement, deux serveurs de modèles à administrer.

Le meilleur scénario pour Cline est celui d'un développeur qui confie une issue bien délimitée à un modèle local, inspecte chaque action proposée et conserve son environnement VS Code. Pensez « analyse ce test en échec et propose un correctif », plutôt que « prédis les six prochains tokens à chaque frappe ». L'interaction est plus lente et plus délibérée que la complétion Copilot, mais elle peut prendre en charge une plus grande part d'une tâche multifichier.

Idéal pour : les utilisateurs de VS Code qui veulent une boucle d'agent locale, visible et contrôlable.
Point fort : une interface d'agent individuelle gratuite, des runtimes locaux documentés et aucun abonnement obligatoire.
Tarifs : Open Source gratuit ; Enterprise sur devis ; inférence fournie séparément.
Essai gratuit : aucun essai Enterprise indiqué ; l'offre open source sert de parcours d'évaluation.

Tarifs de Cline et montée en gamme matérielle

Cline Open Source est gratuit pour les développeurs individuels. Il n'existe ni abonnement ni frais par siège, mais l'inférence hébergée reste facturée à l'usage, sauf si le développeur apporte sa clé ou exécute un modèle local. L'offre gratuite inclut l'extension VS Code et le CLI, une architecture cliente sécurisée, la marketplace MCP, les espaces de travail multiracines et le support communautaire.

Cline Enterprise est proposé sur devis. Il ajoute l'extension JetBrains, SSO, un SLA, un support dédié, la facturation centralisée, la gestion des configurations, le contrôle d'accès par rôles, les limites par fournisseur d'inférence, un tableau de bord d'équipe et les journaux d'authentification. Aucun essai gratuit Enterprise n'apparaît sur la page tarifaire en ligne.

Le guide matériel fixe une frontière plus utile que le prix de plateforme à $0. Cline associe 16 à 32 GB de RAM aux modèles petits ou quantifiés, 32 à 64 GB aux modèles intermédiaires, et 64 GB ou plus aux grands modèles et aux longues fenêtres de contexte. Ses endpoints locaux par défaut sont http://localhost:11434 pour Ollama et http://localhost:1234 pour LM Studio.

Cette échelle doit guider le pilote. Un portable de 16 GB peut valider la connexion tout en échouant sur le workflow visé à cause d'une génération trop lente, d'un contexte insuffisant ou d'un usage médiocre des outils. Le déploiement n'est prêt que lorsque le modèle cible peut lire une portion suffisante du dépôt et terminer la tâche représentative dans un délai acceptable pour l'équipe.

La place de Cline dans une configuration locale mixte

Une répartition pragmatique consiste à réserver Cline aux sessions d'agent explicites et à confier la fluidité de saisie à un fournisseur de complétion locale dédié. Cette architecture peut surpasser un modèle unique et polyvalent : un agent exige l'usage d'outils et un raisonnement sur un long contexte, alors que la complétion réclame une faible latence et un entraînement fill-in-the-middle. En contrepartie, l'exploitation se dédouble.

Pour un développeur indépendant, ce doublon peut se réduire à quelques réglages. Pour une entreprise, il implique deux modèles approuvés, deux politiques d'endpoints, deux audits de télémétrie et deux procédures de retour arrière. Le comparatif des agents de code pour l'entreprise approfondit la gouvernance, mais le choix immédiat de Cline reste simple : retenez-le si la transparence de l'agent compte davantage qu'une solution tout-en-un.

4. Tabby : le meilleur serveur de complétion auto-hébergé et centralisé

Tabby est le meilleur choix lorsque le besoin principal consiste à remplacer la complétion Copilot par un service auto-hébergé, exploité de façon centralisée. Cet assistant de code open source s'articule autour d'un serveur de complétion alimenté par un LLM et administré par l'équipe. Les développeurs s'y connectent au moyen d'extensions d'éditeur, tandis que l'organisation garde le contrôle du service.

Cette conception centrée sur le serveur appartient à une autre catégorie qu'un agent local installé sur un portable. Elle devient utile lorsque dix ou cinquante développeurs doivent partager des modèles approuvés, du contexte de dépôt, des contrôles d'accès et de l'observabilité, au lieu de faire tourner chacun leur propre Ollama. Elle transfère aussi à l'organisation la responsabilité de la disponibilité, des mises à niveau, de la capacité GPU, de l'authentification et de la réponse aux incidents.

Tabby convient surtout à une équipe d'ingénierie réglementée ou soucieuse de confidentialité, qui privilégie la complétion centralisée plutôt que le comportement autonome d'un agent. Answer Engine et la navigation dans le code élargissent le périmètre, mais la complétion reste la raison de le préférer à un agent centré sur le poste de travail. Un développeur seul peut exécuter Community, même si Aider, Cline, Kilo Code ou Zed demanderont généralement moins d'infrastructure.

Idéal pour : les équipes qui veulent un serveur de complétion unique, contrôlé et auto-hébergé.
Point fort : un déploiement centralisé conçu d'abord pour le local, avec extensions d'éditeur et offres pour les équipes.
Tarifs : Community à $0 par utilisateur et par mois ; Team à $19 par utilisateur et par mois ; Enterprise sur devis ; usage cloud Pochi séparé.
Essai gratuit : aucun essai Team ou Enterprise limité dans le temps n'est indiqué ; Community accepte jusqu'à 5 utilisateurs.

Tarifs de Tabby : la confidentialité sans réduction de licence

Tabby Community coûte $0 par utilisateur et par mois pour un maximum de 5 utilisateurs. Tabby Team coûte $19 par utilisateur et par mois pour un maximum de 50 utilisateurs. Tabby Enterprise, facturé annuellement sur devis, propose un nombre illimité d'utilisateurs, SSO, un déploiement sur mesure, un canal Slack dédié au support et une priorisation dans la roadmap.

Pochi, le service de Tabby Cloud, entraîne une facture distincte selon l'usage du modèle. La page tarifaire en ligne comprend $20 de crédits mensuels gratuits, déclenche une facturation automatique lorsque l'usage dépasse $10 — ou à la fin du mois pour les montants inférieurs — et indique que Tab Completion reste toujours gratuit et sans limite d'usage. Il ne faut pas confondre cette offre cloud avec le coût de calcul du serveur auto-hébergé.

Pour 10 sièges, Tabby Team et Copilot Business coûtent tous deux $2,280 par an en frais de plateforme. Tabby nécessite ensuite une infrastructure. Sa documentation estime à environ 8 GB la VRAM nécessaire pour CodeLlama-7B en mode int8 et précise qu'une instance ne prend en charge qu'un GPU. Le coût exact du serveur dépend du matériel déjà disponible, de son utilisation, de la redondance et du niveau de support attendu, mais le constat ne change pas : Tabby s'achète pour le contrôle, pas pour réduire le prix des licences.

Le mur du GPU unique

La limite d'un GPU par instance Tabby est le mur opérationnel à anticiper. Un seul GPU peut parfaitement convenir à une petite équipe, puis créer une file d'attente lors d'une période de développement simultané. La montée en charge passe alors par des instances supplémentaires et des décisions de routage, plutôt que par l'ajout de plusieurs GPU à une même instance.

Mesurez le délai jusqu'à la première complétion et le nombre de complétions acceptées lors des pics d'utilisation, pas sur un serveur inactif. Une moyenne rapide peut masquer un 95e percentile médiocre qui apprend aux développeurs à ignorer les suggestions. Testez aussi le rechargement des modèles, le comportement de repli des extensions et les conséquences d'une indisponibilité du service. La complétion doit une partie de sa valeur à son intégration invisible dans la frappe ; toute attente récurrente détruit cet avantage.

5. Aider : le meilleur workflow terminal natif pour Git

Aider est la meilleure alternative avec modèle local pour les développeurs qui veulent organiser la session d'agent autour du dépôt et de l'historique Git, plutôt qu'autour de l'interface d'un éditeur. Il s'exécute dans le terminal, construit une carte du code, modifie les fichiers, crée automatiquement des commits et peut lancer les linters et les tests. Ce logiciel sous licence Apache-2.0 ne demande aucun abonnement de plateforme.

Le workflow est concret : ouvrez un dépôt, ajoutez les fichiers pertinents ou laissez la carte du dépôt guider le contexte, demandez une modification, examinez le diff, puis utilisez Git pour la conserver ou l'annuler. Aider séduira donc les développeurs qui font déjà confiance au terminal et aux primitives de gestion de versions. Il sera moins naturel pour ceux qui attendent un agent en barre latérale, des points de contrôle visuels et une complétion en arrière-plan pendant la saisie.

Aider se connecte à presque tous les LLM cloud ou locaux, dont Ollama. Sa documentation Ollama recommande le préfixe de modèle ollama_chat/ et signale un piège discret : par défaut, Ollama utilise une fenêtre de contexte de 2k et supprime silencieusement ce qui la dépasse. Une session peut sembler fonctionnelle tout en perdant le contexte du dépôt, ce qui est pire qu'une erreur franche.

Idéal pour : les développeurs qui travaillent d'abord dans le terminal et veulent un agent local centré sur Git.
Point fort : carte du dépôt, commits automatiques, diffs, linting et tests réunis dans une boucle open source.
Tarifs : logiciel Apache-2.0 à $0 ; usage du modèle ou calcul local séparé ; aucune offre de plateforme payante.
Essai gratuit : sans objet, puisque le logiciel est gratuit et open source.

Tarifs d'Aider et plafond individuel de $120

Aider n'a aucune offre Personal, Pro, Team ou Enterprise. Le logiciel est gratuit sous licence Apache 2.0. La facture vient du fournisseur de modèles ou de la machine qui les exécute.

Remplacer un abonnement Copilot Pro à $10 par mois permet d'économiser au maximum $120 par an. C'est la version individuelle du plafond local. Si un nouveau GPU, de la mémoire supplémentaire, du temps d'installation ou des réponses plus lentes ne servent qu'à économiser cet abonnement, le calcul est rarement favorable. Si le matériel existe déjà et que la priorité porte sur la confidentialité, le hors-ligne ou le contrôle du modèle, ces $120 deviennent un avantage secondaire.

Le premier contrôle de configuration doit porter sur le contexte, pas sur l'art du prompt. Aider documente un exemple de serveur Ollama à 8k et ajuste le contexte pour limiter les troncatures silencieuses. Les grands dépôts peuvent exiger bien davantage. Quand un modèle local commence à oublier les exigences, à rouvrir plusieurs fois les mêmes fichiers ou à modifier le mauvais symbole, inspectez la fenêtre de contexte et la carte du dépôt avant de mettre en cause le format d'interaction.

6. OpenCode : le meilleur agent local sur plusieurs interfaces

OpenCode est la meilleure option pour disposer d'un même agent open source dans le terminal, via une extension d'IDE et dans une application desktop. Il prend en charge plus de 75 fournisseurs de modèles, y compris des modèles locaux, et son logiciel de base n'impose aucun abonnement payant. Cette souplesse d'interface constitue son avantage face à la conception d'Aider, centrée sur le terminal.

Ollama fonctionne en local grâce à un endpoint de fournisseur compatible avec OpenAI à l'adresse http://localhost:11434/v1. La documentation des fournisseurs expose la configuration au lieu de la masquer et suggère notamment de commencer avec une fenêtre de contexte d'environ 16k à 32k lorsque les appels d'outils échouent. C'est un avantage pour les équipes en quête d'un contrôle explicite, mais du travail supplémentaire pour les utilisateurs qui attendent une détection en un clic.

La proposition locale d'OpenCode concerne les sessions d'agent, pas le remplacement complet de la complétion inline de Copilot. L'outil peut fonctionner dans un IDE, mais son trait distinctif reste le même agent multiétape sur plusieurs interfaces. Choisissez-le pour la portabilité des interfaces et l'étendue des fournisseurs, pas pour les suggestions avec Tab.

Idéal pour : les développeurs qui veulent le même agent compatible avec le local dans le terminal, l'IDE et l'application desktop.
Point fort : plus de 75 fournisseurs et trois interfaces d'interaction.
Tarifs : cœur open source à $0 ; Go en option à $10 par mois ; Enterprise sur devis par siège.
Essai gratuit : pilote interne du produit open source avant une discussion commerciale Enterprise.

Tarifs d'OpenCode et traitement des données

Le cœur d'OpenCode est un logiciel open source gratuit ; l'utilisateur choisit un modèle local, BYOK, gratuit ou hébergé. OpenCode Zen est une passerelle facultative en paiement à l'usage, avec une tarification des modèles au token. OpenCode Go est un abonnement facultatif à $10 par mois pour des modèles de code ouverts et hébergés. Ses limites actuelles sont exprimées sous forme de plafonds de valeur : $12 par tranche de 5 heures, $30 par semaine et $60 par mois.

OpenCode Enterprise est tarifé sur devis par siège. Lorsqu'un client fournit sa propre passerelle LLM, OpenCode indique ne pas facturer les tokens utilisés. Le parcours d'évaluation commence par un essai interne du produit open source, puis une discussion commerciale sur la configuration centralisée, SSO, la passerelle interne et l'accompagnement à la mise en œuvre.

La déclaration par défaut sur les données est solide : OpenCode affirme ne stocker ni le code ni le contexte, et le traitement se déroule localement ou par des appels directs au fournisseur choisi. Le partage facultatif des conversations constitue l'exception, puisqu'il transmet les données de session à l'extérieur. La documentation Enterprise recommande de le désactiver pendant l'essai. L'examen de confidentialité doit confirmer le chemin par défaut et chacune des sorties facultatives.

Quel outil choisir selon le besoin ?

Identifiez la capacité manquante, puis acceptez le plus petit changement de workflow capable de l'apporter. L'enthousiasme pour un produit est un mauvais guide ici : chaque option déplace les coûts et la complexité vers une couche différente.

Rester sur VS Code si un agent local suffit

Le chemin natif de VS Code est la réponse la moins disruptive pour un développeur ou une équipe qui veut un chat, de la planification et des tâches d'agent prises en charge en local, mais peut conserver la complétion Copilot hébergée ou s'en passer. Extensions, habitudes de débogage, environnements distants et connaissances du support interne restent intacts. Le point de bascule est la complétion inline : si ces données doivent elles aussi rester locales, le chemin BYOK intégré s'arrête trop tôt.

Cette option est particulièrement sensée pour un petit pilote. Configurez un fournisseur local, masquez les modèles non approuvés, choisissez un modèle utilitaire si nécessaire et consignez les fonctions qui dépendent encore de GitHub. N'ajoutez pas une autre extension d'agent avant qu'une tâche représentative ne révèle un manque réel dans la configuration native.

Choisir Zed si l'exhaustivité prime sur la continuité de l'éditeur

Zed l'emporte pour un développeur technique indépendant ou une petite équipe produit prête à adopter un nouvel éditeur afin de réunir Agent et Edit Prediction dans un système local cohérent. La compatibilité de l'éditeur est le critère qui peut inverser le choix. Si une extension indispensable, un débogueur, un environnement distant ou un workflow d'accessibilité échoue, Kilo Code devient l'option la plus sûre.

Dans une grande organisation, la gestion des identités peut faire basculer la décision avant même la compatibilité de l'éditeur. L'offre Business actuelle inclut des politiques sur les modèles et les données, mais ni SSO, ni SAML, ni SCIM. Une entreprise qui exige ces contrôles ne doit pas prendre une promesse de roadmap pour une fonction de sécurité.

Choisir Kilo Code si VS Code ou JetBrains doit rester

Kilo Code gagne lorsque l'agent et l'autocomplétion doivent tous deux fonctionner en local dans l'éditeur existant. Les développeurs changent d'extension et de configuration de modèle, pas d'environnement de travail entier. Le choix cesse d'être pertinent si le modèle Codestral imposé pour l'autocomplétion est inacceptable ou si le matériel ne satisfait pas aux besoins de mémoire documentés de l'agent local.

C'est aussi l'argument financier le plus séduisant et le plus facile à exagérer. Dix sièges Teams économisent $480 par an face à Copilot Business, avant le calcul et le travail d'exploitation. Choisissez le produit parce que ses extensions et ses contrôles de fournisseurs conviennent ; considérez ensuite l'écart de prix comme une petite compensation.

Choisir Cline si l'agent doit rester explicite et supervisé

Cline l'emporte lorsque les développeurs veulent une boucle d'agent délibérée dans VS Code sans demander au même produit de générer les suggestions inline. Il convient aux tâches de la taille d'une issue, où lectures de fichiers, modifications, commandes et validations doivent rester visibles. Kilo ou Zed reprennent l'avantage si l'ajout d'un deuxième système de complétion locale crée trop de configuration.

Pour une équipe, l'écart de transparence tarifaire compte également. L'usage individuel est gratuit, mais Enterprise est proposé sur devis. Validez d'abord le workflow open source, puis ne sollicitez un devis qu'après avoir déterminé les besoins en SSO, limites de fournisseurs, tableau de bord et prise en charge de JetBrains.

Choisir Tabby si l'organisation exploite elle-même le service

Tabby l'emporte lorsqu'une équipe plateforme ou sécurité veut un service de complétion central plutôt qu'un runtime de modèle sur chaque portable. C'est le choix le plus clair pour partager un modèle approuvé et une interface prévisible via les extensions d'éditeur. La décision s'inverse si personne ne prend en charge la disponibilité, les mises à niveau, la capacité et l'assistance aux développeurs.

N'attribuez pas implicitement cette responsabilité à « l'équipe infrastructure ». Nommez la personne ou le groupe responsable, définissez un objectif de service et chiffrez le GPU avant le déploiement. Un service local sans exploitant devient une version moins fiable du produit cloud qu'il remplace.

Choisir Aider ou OpenCode si le terminal est central

Aider gagne lorsque les diffs Git et les commits automatiques forment la surface de contrôle naturelle. OpenCode gagne si le même agent doit circuler entre le terminal, l'IDE et l'application desktop, tout en conservant un large choix de fournisseurs. Aucun des deux ne répond directement au besoin de complétion inline locale.

La structure du workflow les départage. Choisissez Aider pour un dépôt, un fil dans le terminal et une boucle serrée de revue des diffs. Choisissez OpenCode pour multiplier les interfaces, les sessions et les configurations de fournisseurs. Le guide des alternatives à Claude Code est le comparatif voisin lorsque la décision porte surtout sur les agents dans le terminal, plutôt que sur une complétion à la Copilot.

Comparatif des coûts : calculez votre plafond local

Les modèles locaux permettent de maîtriser l'inférence, pas de faire disparaître les coûts. Pour 10 sièges, les frais annuels publics de plateforme sont les suivants :

• Kilo Teams : $1,800
• GitHub Copilot Business : $2,280
• Tabby Team : $2,280
• Zed Business : $3,600

Dans cette comparaison de quatre offres payantes pour une équipe, Kilo est la seule à générer une économie publique. Elle atteint $480 par an, soit $40 par mois. Cette somme représente le plafond local : le coût mensuel supplémentaire maximal que le déploiement peut absorber avant d'effacer l'économie réalisée sur la plateforme.

Ce plafond ne doit pas compter uniquement l'achat du GPU. Ajoutez l'amortissement annuel du matériel, l'électricité, l'hébergement ou l'espace en baie, le monitoring, les sauvegardes, le téléchargement des modèles, les correctifs, la sécurité des endpoints, la réponse aux incidents et le temps passé à aider les développeurs lorsque le service ralentit. Comptez aussi la pénalité de qualité si un modèle local plus petit exige davantage de tentatives ou de travail de revue.

Pour Tabby Team, le plafond local face à Copilot Business est nul, puisque les prix par siège sont identiques. Dès qu'on ajoute le calcul et l'administration, Tabby coûte davantage en trésorerie. Il peut néanmoins rester le bon choix si le bénéfice recherché est la maîtrise des données, un usage en réseau isolé, l'indépendance vis-à-vis des modèles ou une complétion homogène pour l'équipe.

Zed Business part avec un surcoût de $1,320 face à Copilot Business pour 10 sièges. L'éditeur et sa couche de contrôle doivent justifier cette prime. L'équation diffère pour un utilisateur individuel de Zed : Personal est gratuit et accepte les modèles locaux, tandis que Pro affiche le même prix de plateforme de $10 par mois que Copilot Pro, avec les fonctions hébergées de Zed en plus.

Aider, Cline Open Source, le cœur d'OpenCode, Kilo Individual, Zed Personal et Tabby Community peuvent tous ramener le poste logiciel à $0 dans leur périmètre respectif. Pour un utilisateur de Copilot Pro, l'économie d'abonnement maximale atteint $120 par an. Du matériel suffisamment puissant déjà disponible peut la rendre intéressante. Acheter une machine principalement pour récupérer $120 par an ne l'est pas.

Les solutions à éviter

Continue est le produit le plus clairement à écarter pour un nouveau déploiement pris en charge dans cette catégorie. Sa page d'accueil indique que Continue a été acquis par Cursor et que son code open source reste disponible comme fondation. Une communauté existante peut y trouver une base à forker ou à maintenir, mais ce n'est pas l'équivalent d'un produit indépendant activement commercialisé avec un support et des tarifs à jour.

Les utilisateurs actuels de Continue n'ont aucune raison de paniquer. Figez les versions, auditez le dépôt et la licence, documentez les endpoints des modèles et désignez le responsable de la maintenance. En revanche, un nouvel acheteur ne doit pas le classer aux côtés de Zed, Kilo Code, Cline, Tabby, Aider et OpenCode sans tenir compte de cette évolution du support.

Écartez également tout assistant pensé d'abord pour le cloud dont la promesse « locale » se limite à l'indexation locale des fichiers, à une application desktop ou à un compte de cloud privé. La vraie question est de savoir où s'exécute l'inférence pour la fonction précise qui vous intéresse. Interrogez séparément le chat, les appels d'agent, la complétion inline, les embeddings, la télémétrie, les rapports de crash, les mises à jour et le partage facultatif.

Enfin, évitez le plus grand modèle local que votre machine arrive tout juste à charger. Un modèle qui occupe presque toute la mémoire disponible ne laisse guère de place au contexte, à l'éditeur, aux outils de build, aux conteneurs et au système d'exploitation. Un modèle plus petit, avec des appels d'outils réguliers et une latence acceptable, produit souvent davantage de travail terminé qu'un grand modèle qui utilise le swap, dépasse les délais d'attente ou perd le contexte.

Dès lundi : un pilote avec deux ingénieurs

Testez un dépôt avec deux ingénieurs pendant une semaine avant de modifier l'offre de toute une équipe. Il ne s'agit pas de sacrer un modèle à partir d'un prompt synthétique, mais d'identifier le premier mur opérationnel du workflow que vous envisagez d'acheter.

1. 1

   Nommer l'usage manquant de Copilot

   Choisissez une mission principale : traitement agentique d'une issue, complétion inline, auto-hébergement centralisé ou modifications pilotées depuis le terminal. Un pilote qui tente de remplacer toutes les fonctions de Copilot à la fois produira un verdict ambigu.

2. 2

   Choisir un dépôt représentatif

   Utilisez un dépôt doté du mélange habituel de langages, de tests, de temps de build, de structure de dépendances et de contraintes de sécurité. Confiez aux deux ingénieurs les trois mêmes tâches circonscrites : expliquer un module, réaliser une petite modification multifichier et réparer un test en échec.

3. 3

   Figer le déploiement

   Consignez la version de l'outil, le runtime local, le modèle et sa quantification, la fenêtre de contexte, l'endpoint, le matériel, l'état du réseau, le réglage de partage et tout repli hébergé. Sans ces données, impossible de reproduire un bon résultat ou de diagnostiquer un échec.

4. 4

   Mesurer le workflow, pas la sortie de tokens

   Suivez le délai jusqu'à la première réponse utile, le temps nécessaire pour obtenir un diff valide, les suggestions inline acceptées le cas échéant, les appels d'outils en échec, les interventions manuelles, les nouvelles tentatives et le temps de revue. Notez la latence maximale lorsque les deux ingénieurs utilisent le service simultanément.

5. 5

   Prendre la décision budgétaire

   Comparez le coût annuel de plateforme au calcul et au temps mensuel estimé pour l'exploitation. Ne gardez le chemin local que s'il répond au besoin de contrôle nommé et reste sous le plafond local, ou si ce contrôle justifie clairement de dépasser le plafond.

La décision du lundi doit rester modeste : conserver le chemin local existant de VS Code, prolonger le pilote avec l'une des alternatives classées, ou arrêter. N'achetez aucun siège, ne migrez aucun éditeur et ne provisionnez aucun GPU partagé tant que le pilote n'a pas montré quelle tâche précise de Copilot doit être remplacée.

Questions fréquentes

Peut-on utiliser GitHub Copilot en local ?

VS Code peut utiliser un modèle local pour le chat, les workflows d'agents pris en charge et les tâches utilitaires, sans compte GitHub ni abonnement Copilot. Les modèles hébergés de GitHub Copilot ne tournent pas en local et le chemin local intégré ne couvre pas les suggestions inline standard.

Comment exécuter Copilot en local ?

La réponse précise est que VS Code héberge le modèle local via le BYOK. Connectez un fournisseur comme Ollama, puis sélectionnez ce modèle pour le chat ou les tâches d'agent prises en charge. La complétion inline, la recherche sémantique et les fonctions reposant sur des embeddings conservent des dépendances distinctes.

Peut-on utiliser des modèles locaux avec VS Code Copilot ?

Oui pour le chat et les tâches d'agent prises en charge, grâce aux contrôles de modèles de VS Code. Non pour le modèle standard de suggestions inline à la Copilot. Kilo Code et Tabby peuvent ajouter une complétion locale dans VS Code, tandis que Cline y ajoute un agent local.

Existe-t-il une alternative gratuite à GitHub Copilot compatible avec les modèles locaux ?

Oui. Zed Personal, Kilo Individual, Cline Open Source, Tabby Community, Aider et le cœur d'OpenCode proposent tous un chemin logiciel à $0. Le matériel, l'inférence hébergée, la gouvernance d'équipe et la maintenance peuvent toutefois rester payants.

Recevez la checklist d'audit des workflows IA en entreprise et la prochaine analyse de build fondée sur les faits en vous inscrivant à la newsletter.