Kilo Code ou Cline : méthodes de travail, coûts et permissions

Choisissez d'abord le lieu d'exécution

Évaluez Kilo Code si vous voulez des agents spécialisés et des permissions par outil. Évaluez Cline si vous préférez discuter des changements dans Plan, puis passer à Act. Les deux proposent désormais des méthodes de travail dans l'éditeur, le terminal et le cloud. Cette seule distinction ne suffit donc pas à choisir.

Nous avons consulté la documentation officielle liée le 23 octobre 2026. Ce guide de sélection repose sur cette documentation. Nous n'avons exécuté cet exercice avec aucun des produits, ni audité leur trafic réseau, ni mesuré leur vitesse, taux de réussite ou coût comparés.

Lieu d'exécution	Kilo Code	Cline
Espace de travail de l'éditeur	Clients VS Code et JetBrains	Clients VS Code et JetBrains
Terminal	CLI interactive et commandes d'automatisation	CLI interactive et automatisation sans interface
Environnement hébergé	Cloud Agent avec intégration de dépôts	Cloud Agents avec intégration GitHub

La CLI de Kilo et la CLI de Cline fonctionnent hors de l'éditeur. Une CLI s'exécute sur la machine où vous la lancez, qu'il s'agisse de votre portable, d'un hôte distant ou de la CI. Choisir un modèle cloud ne déplace pas votre shell dans un environnement isolé hébergé.

Évaluez le cloud séparément. Kilo Cloud Agent documente une validation automatique toujours active et des frais distincts pour le calcul et l'inférence. BYOK reste soumis aux frais de calcul. La page mentionne un onglet MCP, mais indique aussi que sa prise en charge est à venir. Nous n'avons pas pu résoudre cette contradiction à partir de cette page. Ne supposez pas que votre configuration MCP locale y fonctionne.

Cline Cloud Agents permet les tâches GitHub, mais ne charge actuellement ni règles, ni compétences, ni serveurs MCP, ni connecteurs. Cette limite compte si votre tâche dépend de ces instructions ou intégrations locales. Une liste de fonctions locales ne prouve pas leur disponibilité dans le cloud.

Comparez la méthode et les permissions effectives

Les agents intégrés de Kilo comprennent code, ask, plan et debug. Ask bloque les écritures. Plan peut modifier les fichiers de planification dans .kilo/plans/. Orchestrator est obsolète. Les anciennes comparaisons centrées sur ce mode peuvent donc induire en erreur.

Plan et Act de Cline séparent l'exploration de l'implémentation. Plan inspecte le code sans modifier les fichiers ni exécuter de commandes. Act conserve le contexte de la conversation et permet l'implémentation. Vous pouvez attribuer un modèle différent à chaque mode.

Le nom du mode ne décrit pas toutes les validations :

• Les permissions de Kilo utilisent allow, ask et deny par outil. La plupart ont des valeurs initiales permissives, avec des exceptions documentées. Rechargez le client après avoir modifié les règles de permissions du projet pendant une session.
• Auto Approve de Cline contrôle des catégories telles que les modifications et les commandes. YOLO valide toutes les actions. La classification des commandes sûres dépend du champ requires_approval renseigné par le modèle, pas d'une liste fixe de commandes autorisées.

Pour une première comparaison dans l'éditeur, exigez une validation des modifications, commandes et appels MCP. Vérifiez les paramètres effectifs de la version installée. La CLI de Cline documente une autre valeur initiale pour la validation automatique globale. Vérifiez-la lors du passage à un script. Le nombre de clics reflète les réglages autant que le comportement de l'agent.

Distinguez l'accès aux modèles du coût de la tâche

Les deux proposent des fournisseurs en dehors de leur propre facturation. Le répertoire de Kilo couvre les fournisseurs directs, les passerelles et les moteurs locaux. La configuration compatible OpenAI de Cline permet de définir le point d'accès, l'identifiant et les capacités du modèle. Comparez le même point d'accès et le modèle exact, pas seulement un nom tel que "Sonnet".

La facturation Kilo Gateway applique les tarifs d'inférence du fournisseur sans majoration et facture séparément 5% à l'achat de crédits. Exemple hypothétique, acheter 20 dollars de crédits coûte 21 dollars hors taxes et finance 20 dollars d'utilisation. Gateway BYOK passe toujours par Kilo. Le fournisseur facture l'inférence selon votre contrat.

Cline propose une facturation à l'usage par crédits et un abonnement ClinePass distinct et facultatif. Un abonnement, un modèle gratuit promotionnel et une clé API directe correspondent à des modes de paiement différents. Vérifiez les conditions actuelles du modèle. Ne présumez pas qu'un abonnement couvre tous les modèles ou un travail illimité.

Le coût total comprend l'inférence, les nouvelles tentatives, la part attribuable des abonnements ou offres d'équipe, et le calcul hébergé lorsqu'il s'applique. Relevez séparément les entrées, sorties et usages du cache. Un prix par token inférieur peut produire une facture supérieure si davantage de tentatives sont nécessaires.

Kilo et Cline documentent l'inférence locale avec Ollama, LM Studio et Atomic Chat. Évaluez le matériel, la capacité de contexte et la fiabilité des appels d'outils. Kilo possède aussi des réglages de modèles auxiliaires, dont un repli du petit modèle vers sa passerelle authentifiée. Configurez ces chemins avant de considérer l'installation comme entièrement locale.

Vérifiez la migration des règles et du contexte

Les règles Kilo utilisent le tableau instructions dans kilo.jsonc pour référencer des fichiers ou motifs glob. L'ancien répertoire .kilocode/rules/ reste pris en charge. Les règles Cline acceptent .clinerules/, .cline/rules/ et AGENTS.md, avec des instructions globales et propres à l'espace de travail. Renommer un répertoire ne prouve pas que les mêmes règles ont été chargées.

Consultez le guide des règles Cline pour des exemples de configuration et une vérification du chargement.

Les mentions Kilo peuvent inclure des fichiers, la sortie du terminal et les changements Git. Le contexte Cline accepte les mentions de fichiers et dossiers. Fournissez les mêmes fichiers pertinents pour comparer. Joindre tout le dépôt à un outil et quelques fichiers à l'autre modifie les informations disponibles et la consommation.

Les deux documentent MCP pour Kilo et MCP pour Cline. Vérifiez le transport, l'authentification, les outils et les validations du serveur dans le client choisi. Une connexion MCP peut envoyer des données à un autre service que le fournisseur du modèle. Un modèle local ne rend pas locaux les outils distants.

Les règles indiquent au modèle ce que vous voulez. Les permissions limitent les outils. Retirez les fichiers confidentiels du dépôt de test. Une instruction écrite ne constitue pas une restriction d'accès.

Restaurer des fichiers ne révoque pas les actions externes

Les instantanés Kilo permettent un retour à un message utilisateur, pas au milieu d'une réponse de l'agent. Si les instantanés sont désactivés ou indisponibles, seul l'historique peut revenir en arrière, sans restaurer les fichiers. Vérifiez l'avertissement et le diff réel.

Les checkpoints Cline restaurent séparément les fichiers, l'historique de la tâche ou les deux. Restaurer seulement les fichiers conserve la discussion pour essayer une autre implémentation. Les grands dépôts peuvent accroître le stockage et le travail nécessaires aux checkpoints.

Les deux documentent un stockage des instantanés distinct de l'historique Git du projet. Conservez aussi un commit de référence. Restaurer des fichiers ou une conversation ne révoque ni un courriel envoyé, ni une écriture en base, ni un déploiement, ni des frais API. Cette limite vient de l'action externe, quelle que soit l'interface de restauration. Testez la récupération avec des fichiers locaux jetables avant d'autoriser des actions sur un autre service.

Précisez le besoin de collaboration

Les sessions Kilo proposent des liens facultatifs pour lire une session ou en créer une dérivée. Les offres Teams et Enterprise ajoutent des contrôles organisationnels et une facturation centralisée, achetés séparément des crédits de modèles.

Cline Kanban exécute des tâches parallèles dans des worktrees Git isolés et reste un aperçu de recherche. Cline Enterprise documente la gouvernance et l'observabilité. Partager une conversation, exécuter des agents en parallèle et appliquer une politique d'organisation répond à des besoins différents. Évaluez celui de votre équipe.

Reliez le choix à une tâche réelle

Ces critères découlent des limites documentées. Ils ne désignent aucun gagnant de test de performance :

• Pour explorer un module inconnu sans commande, essayez Cline Plan. Pour une inspection par shell en lecture seule, essayez Kilo ask.
• Pour une implémentation avec permissions et instructions par rôle, évaluez Kilo. Pour discuter puis implémenter, évaluez le passage de Plan à Act de Cline.
• Avec un contrat API ou un moteur local existant, les deux sont candidats. Comparez les chemins des requêtes, modèles auxiliaires, outils et facture finale.
• Pour le cloud sans surveillance, vérifiez séparément cet environnement. Une tâche dépendante de règles locales ou de MCP peut échouer aux exigences avant l'évaluation du code.

Exécutez une comparaison reproductible

L'expérience suivante est à exécuter vous-même. Nous ne l'avons pas réalisée. Elle isole un défaut pour examiner le correctif et les validations avant de traiter un grand dépôt.

Créez ports.py dans un dépôt Git jetable :

def parse_port(value):
    if not value:
        return 8080
    if not value.isascii() or not value.isdecimal():
        raise ValueError("invalid port")
    port = int(value)
    if not 1 <= port <= 65535:
        raise ValueError("invalid port")
    return port

Créez tests/test_ports.py :

import unittest
from ports import parse_port


class PortTests(unittest.TestCase):
    def test_valid(self):
        for value, expected in [(None, 8080), ("80", 80), ("65535", 65535)]:
            with self.subTest(value=value):
                self.assertEqual(parse_port(value), expected)

    def test_invalid(self):
        for value in ["", "0", "65536", "abc", "-1"]:
            with self.subTest(value=value):
                with self.assertRaises(ValueError):
                    parse_port(value)

Le cas de la chaîne vide doit échouer au départ. Le contrat d'entrée accepte None ou une chaîne décimale ASCII. Utilisez exactement le même prompt dans chaque nouvelle session :

Corrige parse_port pour que seul None sélectionne la valeur par défaut. Conserve les ports valides de 1 à 65535 et rejette les entrées invalides couvertes par les tests. Garde la signature publique et les dépendances inchangées. Exécute python3 -m unittest discover -s tests -v et explique le correctif. Ne crée aucun commit, ne pousse rien et n'utilise aucun service externe.

1. Exécutez les tests, puis créez un commit de cet exemple. Faites deux copies propres de ce même commit. Relevez les versions de Python, du client et du système.
2. Alignez fournisseur, modèle exact, réglage de raisonnement disponible et contexte. Désactivez le changement automatique de modèle et MCP. Notez les différences inévitables.
3. Alignez les validations et ouvrez des conversations neuves. Fixez les mêmes plafonds de coût et de durée. Par exemple, 2 dollars d'inférence et 10 minutes sont des limites hypothétiques, pas des prévisions de coût ou de délai. Arrêtez manuellement si le client ne sait pas les imposer.
4. Relancez vous-même les tests après chaque tentative. Acceptez uniquement une suite réussie, un contrat respecté, des dépendances inchangées et aucune modification sans rapport. Rejetez un correctif qui supprime des assertions. Gardez le prompt, le diff, la sortie des tests et les justificatifs de facturation.
5. Testez séparément la restauration d'un fichier jetable. Recommencez avec une tâche de votre dépôt et inversez l'ordre des outils. Un petit défaut ne détermine pas la qualité générale du code.

Utilisez le même relevé pour les deux outils :

Relevé	Éléments à conserver
Configuration	Commit, versions, fournisseur, modèle exact, contexte, permissions
Acceptation	Sortie des tests, vérification du contrat, changements sans rapport
Relecture	Validations demandées, prompts correctifs, modifications manuelles, minutes de relecture
Usage et coût	Tokens, cache, tentatives, facture du fournisseur, frais, calcul
Arrêt et récupération	Plafond atteint, motif d'échec, résultat de restauration, effets externes restants

Vérifiez ces points avant de migrer

1. Recensez règles du projet, règles globales, points d'accès, modèles auxiliaires et variables d'environnement. Reconfigurez les identifiants selon la procédure du nouvel outil.
2. Confirmez les instructions chargées. Demandez la commande de test et les restrictions d'édition, puis vérifiez la première action réelle.
3. Recréez les connexions MCP et les validations. Vérifiez un appel en lecture seule avant d'autoriser les écritures.
4. Créez un commit de référence propre et testez la restauration des fichiers. Ne supposez pas que l'historique ou les checkpoints passent d'un produit à l'autre.
5. Terminez une tâche représentative dans votre budget. Gardez le prompt, le correctif et la facture pour décider à partir d'un travail accepté.

Les fiches Kilo Code et Cline donnent accès aux produits. Les sources officielles liées à chaque comparaison ont été consultées le 23 octobre 2026. Revérifiez les comportements propres à votre version et au cloud avant d'en dépendre.