Un développeur de Domklik apprend à OpenCode à se configurer lui-même : MCP, skills et permissions en quelques soirées

Vladimir Bandov, développeur backend chez Domklik, a publié sur Habr un retour d'expérience sur la configuration d'un agent de code dans OpenCode Desktop. La première demi-heure de configuration s'est déroulée sans problème, puis le chaos s'est installé : skills, serveurs MCP, permissions et plusieurs fichiers de réglages. Trouver une méthode qui fonctionne lui a pris quelques soirées libres. L'auteur qualifie le résultat de « paresseux » : cette approche consomme peut-être plus de tokens, mais l'agent aide à se configurer lui-même et ne part pas en roue libre.

Où la configuration dérape

Selon Bandov, le ticket d'entrée s'est révélé plus élevé que dans les vidéos de formation. Installer l'agent prend quelques minutes. Le faire travailler de façon prévisible est plus difficile. L'auteur identifie trois problèmes.

Premier problème : trop d'entités. Les skills, les MCP, les permissions et les différents niveaux de configuration doivent être gardés en tête simultanément. À un moment, il ne se souvenait plus de l'utilité de chaque skill.

Deuxième problème : l'ordre des actions. Il fallait répéter sans cesse à l'agent qu'il lui faut d'abord un plan, puis les accès et les configurations, et seulement ensuite le lancement de commandes dans le terminal.

Troisième problème : l'hyperinitiative. L'agent faisait des étapes superflues, inventait et implémentait des choses qui ne faisaient pas partie de la tâche. Pour un dépôt de travail, c'est le principal risque : il faut relire et annuler le code en trop.

L'approche paresseuse : l'agent se configure lui-même

L'idée annoncée dans le titre de l'article est la suivante : gérer la configuration « par les mains de l'agent lui-même ». Plutôt que de modifier les fichiers à la main et de retenir la syntaxe, le développeur pose la tâche, et l'agent propose un plan puis applique les changements : il connecte les MCP, ajoute les skills, renseigne les permissions. L'auteur détaille les étapes complètes et les prompts dans l'article original ; l'annonce ne les contient pas.

Un peu de contexte pour ceux qui n'ont pas suivi. MCP (Model Context Protocol) est un protocole ouvert qu'Anthropic a présenté en novembre 2024 pour connecter des outils externes et des sources de données aux modèles. OpenCode est un agent de code open source qui fonctionne dans le terminal et dans un client de bureau. Les droits d'action y sont définis par la configuration selon le schéma « autoriser, demander, interdire ». Quand les serveurs MCP se multiplient et que chacun expose des dizaines d'outils, l'administration manuelle devient vite une corvée.

Le cadre d'usage compte aussi. Bandov ne délègue pas à l'agent le rôle de développeur à part entière. Pour lui, l'agent est un assistant : il prépare le plan, exécute les étapes évidentes et pose des questions là où un contrôle s'impose. Ce mode de fonctionnement explique aussi sa disposition à payer en tokens des itérations de planification supplémentaires.

Ce que l'on sait d'après l'annonce

• Outil : OpenCode Desktop.
• Auteur : Vladimir Bandov, développeur backend chez Domklik.
• Durée : environ 30 minutes avant que la configuration manuelle ne devienne pénible ; encore quelques soirées pour arriver à un schéma qui fonctionne.
• Composants : skills, MCP, permissions, plusieurs configurations.
• Problème principal : l'agent effectue un travail qu'on ne lui a pas demandé.
• Prix de la solution : peut-être une consommation de tokens plus élevée.
• L'annonce ne contient aucune mesure du gain de temps ni du coût.

Comment l'appliquer chez soi

L'article permet de retenir quelques règles pratiques, indépendantes du client utilisé.

Commencez par le plan. Si l'agent doit d'abord décrire ses étapes et seulement ensuite obtenir l'accès aux commandes, inscrivez-le dans les règles du projet pour ne pas le répéter à chaque conversation.

Mieux vaut définir des permissions strictes par défaut. La lecture de fichiers peut être autorisée ; l'écriture et les commandes shell doivent exiger une confirmation. Mieux vaut assouplir les restrictions au cas par cas, pour une tâche précise.

Connectez les MCP un par un et regardez quels outils chacun ajoute au contexte. Chaque serveur consomme des tokens pour ses descriptions et élargit la surface d'erreurs possibles.

Gardez dans git les configurations que l'agent modifie et relisez-les via le diff. S'il change ses propres droits, il faut le voir avant le commit.

Enfin, mesurez. Si le schéma « paresseux » coûte réellement plus de tokens, évaluez-le sur des tâches réelles pendant une semaine et comparez-le au temps que vous ne passez plus à la configuration manuelle.