Kilo Code : notre avis sur l’agent IA, ses usages et ses prix

Kilo Code, qu’est-ce que c’est ?

Kilo Code, aussi appelé Kilo, est un agent qui lit le contexte d’un projet et utilise des outils pour aider à écrire, modifier et relire du code. C’est le logiciel qui entoure le modèle de langage, pas le modèle lui-même. Ses clients open source permettent de travailler dans Visual Studio Code, les environnements de développement intégrés (IDE) JetBrains et le terminal. Ses services hébergés ajoutent Cloud Agents, la revue de pull requests et une passerelle d’accès aux modèles. La distinction compte : pouvoir examiner le code source de l’agent ne vous donne pas la maîtrise de l’infrastructure ni du modèle qui traite une requête hébergée. Le catalogue annoncé offre un choix de moteurs ; il ne prouve pas qu’ils sauront tous intervenir aussi bien sur votre dépôt.

Informations vérifiées le 31 octobre 2026 sur les pages produit, la documentation et les tarifs en ligne de Kilo. Les affirmations concernant les autres produits ont été vérifiées le même jour auprès de leurs éditeurs. Cette évaluation repose sur la documentation publique, des workflows proposés et des exemples de calcul, sans test de performances réalisé depuis un compte connecté. Notre verdict s’appuie sur la continuité du workflow, la maîtrise des modèles, la lisibilité de la facturation et les limites de la revue de code.

À qui recommander Kilo, et qui peut s’en passer ?

Kilo est surtout pertinent pour un développeur ou une petite équipe qui veut conserver son éditeur, choisir ses modèles et prolonger le travail local dans un environnement hébergé. Son intérêt est moindre si vous disposez déjà d’un agent fiable et ne voyez aucune tâche précise que Kilo rendrait plus pratique.

La comparaison porte sur ce que vous gagnez à changer d’outil. Une longue liste de fonctionnalités ne garantit pas de meilleurs correctifs, et cet avis ne prétend pas que Kilo surpasse ces alternatives sur votre propre code.

Kilo Code vs Cline : faut-il changer de workflow ?

Cline est un agent open source doté d’interfaces dans l’éditeur et le terminal. Il permet de choisir son fournisseur de modèles, prend en charge les modèles locaux et propose un workflow Plan/Act qui sépare la discussion d’une modification de son exécution. Son site actuel documente aussi les skills, les intégrations et le travail avec plusieurs agents. Ces capacités ne constituent donc pas des raisons propres à Kilo de le choisir. Fonctionnalités actuelles de Cline.

Choisissez Kilo si vous voulez précisément réunir ses Cloud Agents, le routage des modèles, les revues hébergées et la facturation partagée dans un même environnement de travail. Une petite agence qui entretient plusieurs dépôts pourrait utiliser l’éditeur pour des corrections interactives, confier un nettoyage bien délimité au cloud, puis appliquer les consignes de revue du dépôt avant qu’un humain ne fusionne le résultat.

Choisissez Cline si votre configuration des fournisseurs, vos autorisations et vos règles de projet vous conviennent déjà. Remplacer un workflow local qui fonctionne pour gagner un sélecteur de modèles supplémentaire apporte peu. Cline mérite aussi d’être envisagé si vous souhaitez construire votre solution autour de son moteur d’exécution d’agent plutôt qu’adopter les services hébergés de Kilo.

Pour approfondir ces deux autres workflows, consultez Cline vs Claude Code. Une précision pour les utilisateurs de JetBrains : la page tarifaire actuelle de Cline réserve son extension JetBrains à l’offre Enterprise. Ne supposez donc pas que son offre individuelle couvre les mêmes éditeurs que celle de Kilo.

Kilo Code vs Claude Code : quel intérêt à multiplier les modèles ?

Claude Code est l’agent de code d’Anthropic, accessible dans le terminal, les IDE, une application de bureau et le navigateur. Ses intégrations au terminal et à l’éditeur proposent aussi des configurations documentées avec des fournisseurs tiers. La différence ne tient donc pas à une présence exclusive dans le terminal ni à une facturation limitée à un abonnement personnel. Présentation de Claude Code.

Choisissez Claude Code si vous voulez un workflow centré sur Claude et que le quota de votre abonnement actuel couvre largement votre travail. Ajouter une passerelle pour accéder à un modèle que vous utilisez déjà présente alors moins d’intérêt. Le point à surveiller ici est le quota partagé : l’utilisation interactive de Claude et celle de Claude Code puisent dans la même réserve.

Choisissez Kilo si vous passez régulièrement d’une famille de modèles à une autre, utilisez vos propres clés fournisseur ou combinez les workflows locaux et hébergés de Kilo. Il peut aussi compléter Claude Code : réservez Kilo aux tâches qui nécessitent un autre routage ou un autre environnement, puis comparez le correctif obtenu et l’effort total avant de lui confier davantage de travail. Utiliser un modèle Claude dans Kilo ne transforme pas ce client en Claude Code.

Kilo Code vs Cursor : conserver son éditeur ou son environnement intégré ?

Cursor est un environnement de développement intégré qui propose des workflows avec agent, terminal et cloud. Gardez-le si c’est l’éditeur lui-même qui vous plaît et que vous ne voulez pas gérer une configuration d’agent séparée. Choisissez Kilo si conserver votre éditeur préféré et maîtriser le routage des modèles de l’agent compte davantage. La page d’installation de Kilo mentionne aussi Cursor parmi les éditeurs compatibles avec son extension : ajouter Kilo n’oblige donc pas à abandonner Cursor immédiatement. Cursor, options d’installation de Kilo.

Kilo Code vs OpenCode : une base commune, des services différents

OpenCode est un agent de code open source avec des interfaces dans le terminal, l’éditeur et une application de bureau, ainsi qu’un choix de fournisseurs. La CLI actuelle de Kilo et son extension VS Code reconstruite reposent sur OpenCode. Choisissez OpenCode si son workflow vous convient déjà ; choisissez Kilo si ce sont les services qu’il ajoute autour qui motivent votre recherche. Une base commune ne garantit ni un comportement identique, ni le même rythme de publication, ni les mêmes fonctionnalités hébergées. OpenCode, base technique de la CLI Kilo.

Kilo Code vs Roo Code : raisonner en migration

Roo Code ne doit pas figurer dans une nouvelle sélection comme un produit équivalent encore maintenu. Son dépôt officiel est archivé et son README indique que l’extension a cessé de fonctionner. Si vous l’utilisiez et envisagez Kilo, traitez ce changement comme une migration de vos consignes et de vos workflows. Ne partez pas du principe que les anciens réglages se transfèrent tels quels. Dépôt de Roo Code.

Si aucune de ces façons de travailler ne vous convient, la sélection plus large d’alternatives à Claude Code peut vous aider.

Travailler dans l’éditeur et le terminal avec le même agent

Le premier atout concret de Kilo est de garder l’agent près du code tout en séparant le travail en modifications faciles à relire. Son offre actuelle dans l’éditeur comprend les sessions parallèles, les worktrees et la revue des diffs. Elle ne se limite pas à un panneau de chat qui suggère des fragments de code.

VS Code : séparer l’investigation du correctif

L’extension VS Code de Kilo partage un cœur portable avec sa CLI. Elle prend en charge les agents parallèles, les worktrees et les commentaires ligne par ligne sur les diffs. Un worktree est une autre copie de travail du dépôt, sur sa propre branche. Une tâche peut ainsi modifier des fichiers sans perturber immédiatement votre copie de travail principale. L’extension peut aussi renvoyer vos commentaires de revue dans la conversation de l’agent. Kilo pour VS Code.

Prenons un bug de remboursement dans une petite application de commerce. Une tâche cherche où le statut du remboursement change ; une autre prépare un correctif limité, accompagné d’un test qui reproduit le bug. Attribuez un worktree distinct à la tâche qui écrit le code. Demandez à la tâche d’investigation d’expliquer le comportement concerné avant que l’un ou l’autre agent n’élargisse la modification.

Les critères d’acceptation doivent décrire le résultat attendu : un webhook répété, c’est-à-dire une notification d’événement reçue à nouveau, ne doit pas créer un second remboursement ; le parcours qui fonctionne déjà doit rester opérationnel ; le code de paiement sans rapport avec le problème doit rester intact. Ce point de départ est bien plus utile qu’une demande générale d’amélioration du système de paiement.

Une fois le correctif reçu, lisez les fichiers modifiés, examinez l’assertion du test et commentez précisément la ligne à reprendre. Le parallélisme n’est utile que s’il réduit l’attente sans augmenter le temps passé à réconcilier des modifications incompatibles. Deux agents qui écrivent dans la même copie de travail peuvent toujours se gêner.

JetBrains : un plugin natif, avec des particularités liées aux worktrees

Kilo fournit un plugin JetBrains natif pour des IDE comme IntelliJ IDEA, PyCharm et WebStorm, sans nécessiter Node.js. Installez-le via Settings → Plugins → Marketplace, puis configurez-le dans Settings → Tools → Kilo Code. Les réglages partagés de l’agent utilisent kilo.jsonc, tandis que les paramètres propres à l’IDE restent dans le plugin. Documentation JetBrains.

Pour un développeur backend, le test pratique consiste à vérifier si l’agent sait travailler dans la structure du projet et avec le système de build déjà en place. Demandez-lui de suivre un contrôleur jusqu’à sa couche de service et de persistance, puis de proposer une modification ciblée. Évaluez ensuite le résultat avec vos inspections et vos tests habituels dans l’IDE.

L’intégration présente des limites précises. Par défaut, les worktrees des agents sont exclus de l’index du projet qui les contient. Leurs fichiers peuvent donc ne pas bénéficier de la résolution du code ou des inspections habituelles. Ouvrez le worktree comme un projet à part entière lorsque vous avez besoin d’une indexation complète. Par ailleurs, un script de préparation du worktree peut démarrer sans que l’agent attende la fin de son exécution. Attendez que les dépendances soient installées et les fichiers générés avant de lui demander de les utiliser. Ces contraintes relèvent du workflow ; elles ne prouvent pas que le modèle a mal compris le code.

CLI : une option pratique pour travailler dans le terminal

L’interface en ligne de commande de Kilo permet d’utiliser l’agent depuis le répertoire d’un projet, avec un compte Kilo ou vos propres clés fournisseur. Voici l’installation via npm indiquée dans sa documentation : CLI Kilo.

npm install -g @kilocode/cli
kilo

Lancez la seconde commande depuis le dépôt sur lequel vous voulez travailler. Pour une première tâche, demandez une explication du test qui échoue et une proposition de correctif avant d’autoriser les modifications. Une petite réparation facile à examiner vous en apprendra davantage qu’une demande de modernisation globale du dépôt.

Kilo documente aussi /sandbox, qui limite l’exécution des outils au niveau du système d’exploitation. Les contrôles annoncés comprennent des écritures limitées à l’espace de travail, des métadonnées Git en lecture seule et des restrictions réseau facultatives. Les autorisations déterminent si une action peut s’exécuter ; les règles de la sandbox déterminent ce à quoi elle peut accéder. Configurez les deux en fonction de la tâche, sans considérer l’approbation automatique comme un substitut à ces limites.

Modèles Kilo Code : choisir le modèle, mais aussi son mode d’accès

La souplesse de Kilo prend tout son sens lorsqu’on distingue le moteur du service qui achemine la requête. La passerelle Gateway fournit un accès hébergé ; l’utilisation de votre propre clé (BYOK) fait passer l’inférence, c’est-à-dire le traitement de votre requête par le modèle, par votre compte chez un fournisseur ; la prise en charge des modèles locaux permet de faire tourner un modèle sur votre machine avec un logiciel comme Ollama ou LM Studio. Une clé fournisseur donne accès à une API. Elle ne transfère pas automatiquement l’abonnement d’une autre application. Options d’inférence de Kilo, Gateway.

Il y a donc deux décisions à prendre : quel modèle doit tenter de résoudre la tâche, et quel compte et quelle infrastructure doivent la traiter. Les distinguer clairement permet ensuite de comparer les coûts de façon pertinente.

Kilo Auto Model propose les modes de routage Efficient, Frontier et Free. Efficient classe la tâche et choisit une stratégie de modèles adaptée à sa difficulté ; Frontier utilise des modèles payants destinés aux tâches exigeantes ; Free s’appuie sur les modèles gratuits disponibles. Vous pouvez aussi sélectionner vous-même un modèle précis. Auto Model.

Pour préparer la structure de tests courants, essayez un routage économique en décrivant précisément le comportement attendu. Pour une panne qui touche plusieurs services, fournissez les traces utiles et demandez à l’agent plusieurs explications possibles avant d’autoriser un correctif. Vérifiez s’il identifie le bon code et propose un moyen d’invalider son hypothèse. Un modèle plus cher n’a d’intérêt que s’il réduit le travail total nécessaire pour obtenir un résultat acceptable.

Le routage automatique est une commodité, pas un paramètre expérimental figé. La documentation de Kilo précise que les modèles sous-jacents peuvent changer côté serveur et que le sélecteur déplié affiche les modèles choisis et leur coût. Si vous comparez des outils sur une même tâche, notez le modèle et le routage réellement utilisés, pas seulement la mention Auto. Documentation d’Auto Model.

Skills Kilo Code : formaliser les tâches récurrentes

Kilo prend en charge les skills : des dossiers contenant un fichier SKILL.md qui rassemble les consignes d’une tâche répétable. Les skills de projet se trouvent actuellement dans .kilo/skills/. L’agent découvre leurs métadonnées et charge les instructions pertinentes au besoin. C’est un moyen de lui fournir une procédure documentée, sans garantie qu’il exécutera correctement chaque consigne. Documentation des skills.

Dans notre exemple de remboursement, un skill de projet pourrait indiquer où se trouvent les jeux de données de test des paiements, quelle commande teste les nouvelles tentatives et comment distinguer un webhook reçu en double d’un second remboursement légitime. Sa description doit être assez précise pour que l’agent reconnaisse les situations où il s’applique. Versionnez la procédure afin que le prochain développeur puisse aussi l’examiner.

Le bénéfice est de moins répéter les consignes. La limite est qu’elles dépendent toujours d’un environnement fonctionnel et d’une revue humaine. Une procédure de test parfaitement rédigée ne compense pas l’absence d’installation des dépendances dans une copie de travail cloud.

Cloud Agents : déléguer une tâche reproductible

Kilo Cloud Agents est utile lorsqu’une tâche peut s’exécuter dans un environnement hébergé sans dépendre de votre ordinateur portable. Kilo documente les connexions aux dépôts, un environnement Linux distant, la création de branches et de worktrees ainsi que des profils d’environnement réutilisables. Ces profils contiennent les commandes de préparation, les variables d’environnement et les secrets. Cloud Agents.

Pour une première délégation, choisissez un refactoring limité avec un contrôle d’acceptation exécutable : par exemple, remplacer une fonction utilitaire obsolète dans un module précis tout en conservant ses tests. À l’inverse, une tâche qui dépend de services locaux non documentés et d’identifiants présents uniquement dans l’historique de votre shell se prête mal à cet exercice.

La limite de portabilité est très concrète : Cloud Agents ne détecte et n’exécute pas automatiquement .kilo/setup-script. Si ce script prépare le dépôt, appelez-le explicitement dans les Setup Commands du profil cloud. Les skills de projet peuvent accompagner le dépôt ; les skills globaux de l’utilisateur, stockés dans son répertoire personnel, ne le suivent pas. Documentation de Cloud Agent.

Il faut aussi distinguer les conversations séparées des environnements d’exécution séparés. Les conversations cloud partagent un conteneur, et celles qui utilisent le même worktree voient leurs modifications respectives. Des worktrees distincts aident à séparer les changements ; ils n’impliquent pas des machines indépendantes. Cette différence compte si vos tâches installent des dépendances différentes, lancent des services sur le même port ou supposent un accès exclusif à des fichiers générés.

Code Reviews : faire passer les règles du dépôt avant les commentaires génériques

Kilo Code Reviewer peut commenter les pull requests GitHub et les merge requests GitLab configurées, avec le modèle et les axes de revue de votre choix. Il permet aussi une revue locale avant le commit. La question utile est de savoir si ses commentaires identifient des risques concrets sur lesquels agir dans votre code, pas s’il sait produire une longue liste de suggestions. Kilo Code Reviewer.

Dans une petite équipe, utilisez-le pour une passe supplémentaire avant la revue humaine. Demandez-lui de se concentrer sur les comportements importants pour le dépôt : les autorisations d’un portail client, le traitement sûr des événements répétés dans la facturation ou la compatibilité des migrations dans un service partagé. Laissez les questions de formatage aux outils qui l’imposent déjà.

Le réglage le plus utile repose sur REVIEW.md, un fichier de règles de revue propre au dépôt. Commitez-le dans la branche de base et activez Use REVIEW.md dans les paramètres de Code Reviews. Kilo lit les règles de cette branche de base, pas celles de la modification proposée. Sans cela, une pull request pourrait modifier les instructions servant à l’évaluer. Documentation de Code Reviews.

Pour un service de remboursement, ces règles pourraient demander de vérifier le traitement des événements reçus en double, les autorisations entre tenants et les assertions portant sur les échecs d’appels externes. Pour chaque problème soulevé, demandez le chemin du fichier concerné, une explication et des éléments probants. Ce sont des critères de revue proposés, pas l’affirmation que l’agent a détecté ces défauts lors d’un test réalisé ici.

En local, /review examine les modifications non commitées ; /review branch compare la branche à sa base. Une séquence utile consiste à lancer la revue locale, apporter les corrections ciblées, puis ouvrir une pull request pour suivre le processus habituel de l’équipe. Surveillez si les exécutions successives apportent de nouveaux éléments ou se contentent de reformuler le même problème.

La limite est importante : les revues hébergées ignorent par défaut les pull requests créées par des bots, y compris les bots de mise à jour des dépendances. Elles se concentrent aussi sur les fichiers modifiés et imposent des limites d’exécution et de concurrence. Si votre principale difficulté est de relire les mises à jour automatiques des dépendances, ne supposez pas que l’activation de Code Reviews couvre cette file d’attente. Vérifiez le fonctionnement attendu avant d’en faire une étape obligatoire de votre processus.

Combien coûte Kilo pour un développeur solo ou une petite équipe ?

Kilo distingue l’accès à la plateforme, l’inférence des modèles et le calcul hébergé. Commencez par l’offre individuelle, sauf si vous avez besoin d’une administration partagée. Voici les offres actuelles et les frais à prévoir :

• Free & Open Source : aucun coût d’accès à la plateforme ; usage facturé séparément.
• Teams : $15/utilisateur/mois pour partager la facturation, les clés et les agents, et suivre les usages. Enterprise : tarif sur devis pour les fonctions de gouvernance, comme les restrictions de fournisseurs ou de modèles, l’authentification unique et les journaux d’audit.
• Inférence : usage de Gateway aux tarifs des fournisseurs, avec 5% de frais de traitement à l’achat de crédits, indiqués séparément. En BYOK, l’inférence est facturée par votre fournisseur. L’option Kilo Pass démarre à $19/mois pour des crédits sur abonnement ; elle ne donne ni un usage illimité ni un siège Teams.
• Calcul : Code Review $0.33/heure ; Cloud Agent Docker/Small $0.60/heure ; Standard $1.20/heure, avec décompte à la seconde, en supplément de l’inférence. Tarifs Kilo.

Un espace Teams pour trois personnes démarre donc à $45/mois hors usage (3 × $15). Au tarif de calcul annoncé pour la revue, une revue de dix minutes prise comme exemple consommerait $0.055 de calcul (10 ÷ 60 × $0.33), auxquels s’ajoutent l’inférence et les frais applicables. Il s’agit d’un calcul, pas d’une durée observée ni du prix total d’une revue. Le raisonnement du modèle et les nouvelles tentatives déterminent encore une grande partie de la facture finale.

Le cloud exige aussi un solde de $5 pour démarrer. C’est un solde requis, pas un supplément facturé ; le BYOK ne supprime pas les frais de calcul. Détails de la facturation cloud. Si vous envisagez Pass, ne comptez que les crédits bonus que vous utiliserez : ils expirent chaque mois. Conditions de Kilo Pass.

Le passage de Free à Teams répond à un besoin de gestion partagée. Le passage de Teams à Enterprise répond à un besoin de gouvernance. Achetez les contrôles dont vous avez besoin, puis prévoyez un budget d’usage distinct.

Les limites qui peuvent faire pencher la décision

La souplesse de Kilo implique des choix de configuration qu’une petite équipe doit assumer. Voici les limites les plus susceptibles de changer la recommandation.

Auto Free ne convient pas au travail confidentiel sans vérification du parcours des données. La documentation Auto Model de Kilo indique que les modes gratuits peuvent recourir à des fournisseurs qui enregistrent les prompts et les réponses et les utilisent pour améliorer leurs services. Elle déconseille explicitement d’y soumettre des données personnelles ou confidentielles. Le caractère open source du client n’annule pas les pratiques du fournisseur retenu. Pour du code privé, utilisez un routage approuvé. Traitement des données avec Auto Free.

La préparation locale ne se transpose pas automatiquement dans le cloud. L’absence d’exécution automatique de .kilo/setup-script et des skills du répertoire personnel peut faire produire des résultats différents à une même instruction à distance. Versionnez les consignes nécessaires au projet et définissez explicitement la préparation cloud. Sinon, vous comparez autant les environnements que les agents.

La revue hébergée ne garantit pas la qualité de l’ensemble du dépôt. L’examen des seuls fichiers modifiés, l’exclusion des bots et les limites d’exécution laissent des angles morts. Une mise à jour proposée par un bot de dépendances ou un comportement situé hors du diff peut toujours nécessiter une attention distincte. L’absence de remarques ne prouve pas qu’une version peut être publiée sans risque.

Les tarifs publics de la revue se contredisent. La page de la fonctionnalité annonce des revues gratuites avec des modèles gratuits ; la documentation de revue décrit un calcul gratuit pendant une bêta limitée. Les pages dédiées aux tarifs et au cloud affichent, elles, un coût de calcul. Cet avis retient la page tarifaire dédiée pour établir le budget. Confirmez toute exonération liée à la bêta ou à votre compte avant de promettre à l’équipe des revues hébergées sans frais. Cette contradiction ne permet pas de présenter le tarif affiché comme un montant effectivement facturé sur un compte qui n’a pas été testé.

L’offre d’équipe n’inclut pas tous les contrôles de gouvernance. Si vous devez restreindre de manière centralisée les modèles ou fournisseurs autorisés à recevoir du code, la page tarifaire réserve ce contrôle à Enterprise. La facturation partagée ne fournit pas cette même règle de contrôle. Ce point peut déterminer l’achat avant même que la qualité des modèles n’entre en jeu.

Notre avis sur Kilo Code : changer pour un workflow que vous utiliserez vraiment

Kilo mérite sa place dans une sélection si vous voulez un agent dont le code est consultable, le choix des modèles et des services locaux, cloud et de revue reliés entre eux. Son meilleur argument d’achat est le travail que cette combinaison permet d’organiser. La taille du catalogue, à elle seule, justifie mal une migration.

Choisissez Kilo si vous pouvez nommer une tâche récurrente qui bénéficie du passage entre environnements, du routage des modèles ou de la configuration des revues du dépôt, et si vous êtes prêt à gérer la facture d’usage associée. Choisissez Cline si votre configuration actuelle d’agent open source gère déjà correctement votre travail local. Choisissez Claude Code si vous recherchez une expérience centrée sur Claude et que votre quota convient. Garder Kilo à côté de l’un ou l’autre reste pertinent tant que sa valeur ajoutée répond à un besoin précis.

La semaine prochaine, choisissez une petite tâche réversible dans un dépôt. Notez le routage du modèle, le travail de préparation, l’usage facturé, les corrections humaines et la réussite ou non de votre propre contrôle d’acceptation par le correctif final. Ne répétez l’exercice que si le résultat permet de trancher une vraie question d’achat. Confiez davantage de travail à Kilo lorsqu’il réduit l’effort nécessaire pour obtenir une modification validée, pas simplement lorsqu’il génère plus de code.

Questions fréquentes

Utilisez la checklist d’audit des workflows IA en entreprise pour préciser la tâche, la personne responsable de la revue et le contrôle d’acceptation avant d’étendre votre configuration d’agents.