Neuf agents de code face à votre machine : ce qu'ils font vraiment en local
- Un développeur a passé neuf coding harnesses (Claude Code, Codex CLI, Gemini CLI, Aider, Cline & consorts) au banc d'essai sur un simple laptop, en regardant non pas la qualité du code produit mais ce que chaque outil s'autorise à faire sur le poste : lecture de fichiers hors du projet, exécution de commandes shell, sorties réseau, modèles de permission et qualité réelle du sandbox. Le constat est peu flatteur : les garde-fous varient énormément d'un outil à l'autre, beaucoup reposent sur la bonne volonté de l'utilisateur qui clique « approuver », et le mode permissif ( « YOLO » ) est devenu la norme de fait parce que les confirmations permanentes tuent la productivité. Le comparatif sert surtout de cartographie des compromis : plus l'agent est autonome, plus il a les mains dans votre système de fichiers et vos identifiants.
Ce que dit la source
Personne ne sait précisément quels droits s'octroient les agents de code en local : accès disque hors périmètre projet, exécution de commandes, appels réseau, télémétrie. L'article met ces comportements côte à côte pour neuf outils au lieu de se fier aux promesses marketing.
- Le vrai différenciateur entre les harnesses n'est pas le modèle sous-jacent mais le modèle de permissions et la qualité de l'isolation.
- L'ergonomie pousse au désarmement : la fatigue des confirmations amène presque tous les utilisateurs à activer le mode permissif, annulant les garde-fous annoncés.
- Le périmètre de lecture déborde souvent du dossier de travail — dotfiles, historiques shell, variables d'environnement, credentials cloud sont à portée d'un agent bavard.
- Tester sur un laptop, c'est tester le pire des environnements : pas de segmentation, secrets partout, droits administrateur fréquents.
- La conclusion opérationnelle est sobre : faire tourner ces agents dans un conteneur ou une VM éphémère règle 80 % du risque sans négocier avec l'éditeur.
- La comparaison a une durée de vie courte : ces outils publient plusieurs versions par mois et les comportements changent.
Dans les commentaires
Utile mais déjà périmé : intérêt réel, scepticisme méthodologique
- Le benchmark vieillit en quelques semaines : les harnesses évoluent trop vite pour qu'un tableau comparatif reste valide.
- Échantillon trop mince — une machine, un jeu de tâches — pour en tirer des conclusions générales sur la sécurité ou la performance.
- Plusieurs commentateurs rappellent que le vrai coût (tokens consommés, allers-retours inutiles) n'est pas mesuré, alors que c'est le critère qui tranche en entreprise.
- Le débat dérive vite sur les préférences personnelles d'outillage plutôt que sur la méthodologie, signe que le sujet reste dominé par l'anecdote.
- Reproche récurrent : tester en local sans isolation revient à documenter un problème que tout le monde connaît déjà et que personne ne corrige.
Alternatives citées : Claude Code, Codex CLI (OpenAI), Gemini CLI, Aider, Cline / Roo Code, OpenCode, Amp, Cursor en mode agent, ainsi que l'exécution en devcontainer ou VM jetable comme contournement des modèles de permission natifs.
Notre lecture
Si vos développeurs utilisent ces outils sur des postes qui portent des clés SSH, des tokens cloud et du code client, vous avez déjà un problème de gouvernance. Le vrai sujet n'est pas « quel agent code le mieux » mais « quel agent tourne dans un conteneur jetable avec des secrets cloisonnés et une sortie réseau filtrée ». Exigez une politique explicite : pas de mode auto-approbation sur un poste avec accès production, exécution en devcontainer ou VM par défaut, et inventaire des outils réellement installés (le shadow AI est massif sur ce segment).