Kilo Code — retour d'expérience 2 mois (équipe, usage quotidien)
L'outil le plus riche out-of-the-box pour les workflows IDE. Le marketplace de modes et l'intégration native VS Code en font le choix naturel pour les équipes qui ne sont pas terminal-first. La qualité est au niveau d'OpenCode, l'expérience initiale est meilleure.
Points forts
- + Intégration VS Code native : lit les diagnostics LSP en temps réel, comprend le contexte de l'éditeur sans configuration
- + Marketplace de modes prêts à l'emploi (Architect, Coder, Debugger, Reviewer) — opérationnel sans investissement initial
- + MCP servers supportés nativement avec interface graphique de configuration — pas besoin de toucher au JSON
- + Multi-provider complet : même liberté qu'OpenCode pour router selon la tâche et le coût
- + Open-source Apache 2.0 — code auditable, pas de lock-in outil
- + Partage des configurations d'équipe via Git (.kilocode/ dans le repo)
- + Interface de diff visuelle avant application des modifications — feedback clair sur ce qui va changer
Limites
- − Dépendance VS Code stricte : pas d'usage terminal pur, pas de setup remote/SSH sans VS Code Server
- − Les modes du marketplace ne sont pas tous de qualité équivalente — certains sont peu maintenus, il faut trier
- − Plus lent à démarrer qu'OpenCode sur des machines moins puissantes à cause de l'overhead VS Code
- − L'interface graphique peut être contre-productive pour les profils qui préfèrent tout contrôler en CLI
Contexte de test
Version testée : Kilo Code 2.x (décembre 2025 → février 2026). Déployé sur l’équipe (4 devs) après comparaison avec OpenCode. Stack : PHP/Symfony 7 + TypeScript/React, VS Code comme éditeur partagé en équipe. Mon outil personnel a changé depuis (OpenCode à l’époque, Claude Code aujourd’hui), mais Kilo Code VS Code reste l’outil de l’équipe mi-2026 — ce test reflète les deux perspectives, et le déploiement a tenu.
Ce que Kilo Code fait réellement
Kilo Code est une extension VS Code qui transforme l’éditeur en interface pour un agent de coding. Son architecture est similaire à OpenCode (client LLM avec accès aux outils de l’environnement), mais l’intégration est conçue pour tirer parti de l’API VS Code plutôt que d’être indépendante de l’IDE.
Ce que ça change concrètement : l’agent voit ce que tu vois. Il connaît le fichier actif, lit les erreurs dans le panneau Problems, comprend la structure du workspace. Il n’a pas besoin qu’on lui dise où sont les problèmes — il les voit.
Les modes sont la fonctionnalité distinctive. Chaque mode est un profil avec des instructions système, des permissions d’action, et des outils disponibles pré-configurés. Le mode Architect ne peut pas modifier de fichiers par défaut — il est limité à l’analyse et la proposition. Le mode Coder a plein accès. C’est une façon propre de structurer la délégation.
Ce qui fonctionne
L’intégration LSP est la vraie différence. Quand il y a une erreur TypeScript dans le code, Kilo Code la voit directement dans son contexte sans qu’on ait à la copier-coller. En pratique, le cycle “modifier → voir l’erreur → corriger” est plus court que sur OpenCode où il faut lancer les tests ou communiquer l’erreur manuellement.
Le marketplace réduit l’investissement initial. Avec OpenCode, il faut 2-3 heures pour construire des custom commands qui couvrent les workflows récurrents. Avec Kilo Code, les modes Architect et Coder font le travail pour commencer. Sur l’équipe, l’onboarding a pris 30 minutes contre 3h estimées pour OpenCode.
La diff visuelle rassure les profils moins confiants. Avant chaque application de modifications, Kilo Code affiche un diff. Pour des devs qui découvrent les agents, voir exactement ce qui va changer réduit l’anxiété de délégation. Les profils expérimentés le désactivent rapidement, mais c’est un bon garde-fou initial.
Ce qui ne fonctionne pas
La dépendance VS Code est structurelle. Notre workflow de dev principal est Mac → SSH → Ubuntu en remote. VS Code Server fonctionne mais c’est plus lourd que de lancer opencode directement côté serveur. Pour les sessions rapides en SSH, on revient à OpenCode.
Le marketplace est inégal. Sur les ~50 modes disponibles, 10-15 sont vraiment bien faits et maintenus. Les autres sont des variations génériques sans valeur ajoutée réelle. Il faut investir du temps pour trier, ce qui atténue l’avantage “prêt à l’emploi”.
Pour qui ?
Le profil Kilo Code est l’équipe ou le dev dont VS Code est l’environnement de travail central. L’intégration LSP, le marketplace de modes, et l’interface graphique de configuration MCP en font l’outil le plus accessible pour des équipes qui veulent adopter les agents sans investissement de configuration initiale important.
Pour les workflows terminal-first ou les setups SSH intensifs, OpenCode reste plus adapté.
Recommandé pour
- ✓Équipes utilisant VS Code comme éditeur principal
- ✓Onboarding rapide — modes préconfigurés, pas besoin de construire ses workflows from scratch
- ✓Projets nécessitant une intégration MCP riche (bases de données, APIs externes)
- ✓Développeurs venant de Cursor qui veulent garder l'expérience IDE mais avec la liberté du multi-provider
Déconseillé pour
- ✗Workflow terminal-first ou remote/SSH sans VS Code Server
- ✗Profils qui veulent tout contrôler en CLI sans interface graphique
- ✗Machines avec peu de ressources où l'overhead VS Code est problématique
Questions fréquentes
- Kilo Code vs OpenCode : comment choisir ?
- La réponse courte : VS Code quotidiennement → Kilo Code. Terminal/Neovim/SSH → OpenCode. Les deux sont multi-provider, open-source, et de qualité comparable. Kilo Code gagne sur l'intégration IDE et les workflows prêts à l'emploi. OpenCode gagne sur la légèreté, le remote, et le contrôle total via CLI. Ce n'est pas forcément un choix exclusif — certains utilisent Kilo Code en journée dans VS Code et OpenCode pour des sessions SSH en dehors.
- Le marketplace de modes est-il vraiment utile ?
- Pour commencer, oui. Les modes Architect et Coder couvrent 80% des cas d'usage sans configuration. Après quelques semaines, on finit généralement par personnaliser ou créer ses propres modes adaptés au projet. Le marketplace est un bon point de départ, pas une fin en soi.
- Comment partager les configurations Kilo Code en équipe ?
- Le dossier .kilocode/ à la racine du projet se versionne dans Git. Il contient les modes custom, les instructions projet (équivalent du CLAUDE.md pour OpenCode), et les configurations MCP. Un nouveau dev qui clone le repo hérite automatiquement des workflows de l'équipe.
- Kilo Code fonctionne-t-il avec Ollama pour les modèles locaux ?
- Oui. Ollama est supporté nativement comme provider. La configuration se fait directement dans l'interface VS Code — URL du serveur Ollama local, sélection du modèle. Utile pour les tâches sur du code sensible qu'on ne veut pas envoyer dans le cloud.