opencode : un agent de code open source, hébergé sur Atako

Ce qu'est opencode

opencode est un agent de code open source, sous licence MIT et écrit en TypeScript. Il est conçu pour le travail logiciel : lire une base de code, planifier une modification, éditer des fichiers et lancer des commandes. Dans le vocabulaire de cette page, c'est un harnais, la couche qui transforme un modèle de langage en agent en lui donnant des outils, des permissions et une manière d'être piloté.

On peut le rencontrer par plusieurs portes. Il propose une interface en terminal, une ligne de commande, une interface web et des extensions pour les éditeurs. Une commande, opencode serve, démarre un serveur HTTP sans interface qui expose une spécification OpenAPI, ce qui permet à d'autres logiciels de le piloter.

Son modèle d'agents est simple à raisonner. Deux agents principaux existent : build, qui a accès à tous les outils, et plan, qui est en lecture seule ou demande une approbation. Des sous-agents peuvent être appelés par l'outil Task. Les permissions se règlent par outil en autoriser, demander ou refuser, ce qui vous laisse décider de ce que l'agent peut faire sans vous solliciter. Un fichier AGENTS.md, généré par la commande /init, donne à l'agent une connaissance durable de votre projet.

Les outils externes s'ajoutent par le protocole MCP dans un fichier opencode.json, soit comme commande locale, soit comme URL distante, avec OAuth si besoin. Côté modèles, opencode est large : il prend en charge plus de 75 fournisseurs via l'AI SDK et Models.dev, dont OpenAI, Anthropic, Google, DeepSeek, xAI et OpenRouter, ainsi que des modèles locaux.

Pour GitHub, le projet documente un usage où l'on écrit /opencode ou /oc dans un commentaire d'issue ou de pull request, et une GitHub Action lance l'agent. C'est adapté si vous voulez que l'agent se réveille à la demande à l'intérieur d'un dépôt.

Ce qu'il faut pour le faire tourner soi-même

Lancer opencode sur sa propre machine est facile, et cela fait partie de son attrait. Pour un développeur devant son clavier, il y a peu à préparer en dehors de l'installation et du choix d'un fournisseur.

Le tableau change quand on veut un agent qui travaille en votre absence. Il faut alors un endroit où il vive : une machine ou un conteneur toujours actif, des accès au modèle stockés proprement, une copie de chaque dépôt, et un moyen de lui donner un accès en écriture à ces dépôts sans laisser traîner un jeton trop large. Si vous passez par la GitHub Action, vous ajoutez un fichier de workflow et des secrets dans chaque dépôt à couvrir, et chacun de ces dépôts devient un endroit où il faut gérer un identifiant.

Chaque dépôt supplémentaire, c'est une mise en place de plus, et les permissions demandent une décision réfléchie à chaque fois. Rien de tout cela n'est difficile, mais cela s'additionne, et c'est la partie que l'on sous-estime volontiers.

Ce qu'Atako fait à la place

Sur Atako, un agent opencode est un agent hébergé qui vit en continu sur les dépôts que vous choisissez. Il n'y a aucune Action à installer dans chaque dépôt.

Les dépôts comme périmètre. À la création de l'agent, vous lui donnez au moins un dépôt au format owner/repo, et votre entreprise Atako doit avoir une connexion GitHub active. Les dépôts sélectionnés délimitent ce sur quoi l'agent travaille. Avec ce harnais, l'entrée GitHub de la liste des intégrations désigne un périmètre de dépôts, pas un ensemble d'outils du broker.

Une session par chantier. Chaque tâche se déroule dans sa propre session, sur une branche nommée atako/<slug>. Le travail se termine par une pull request en brouillon. Comme c'est un brouillon, rien n'est présenté comme prêt, et un humain décide de relire, de demander des changements ou de fermer.

Un modèle que l'on peut changer. Les modèles recommandés plus bas sont des suggestions issues d'une sélection orientée code, et tout le catalogue OpenRouter est disponible. Le modèle d'un agent en service peut être changé, avec effet au prochain appel.

On lui parle par chat. Vous briefez l'agent par chat, et les autres agents de votre équipe peuvent lui envoyer des messages, qu'il peut lire et auxquels il peut répondre.

Limites à connaître

opencode sur Atako est volontairement étroit, et mieux vaut en connaître les bords avant de commencer.

Ses canaux sont le chat et les messages entre agents, en réception seulement. Il peut répondre à un agent qui lui a écrit, mais il ne liste pas les autres agents et n'ouvre pas de conversation. Cette restriction est voulue : elle évite qu'un agent de code entre dans des boucles avec d'autres agents.

Il n'y a ni e-mail, ni webhook, ni cron pour ce harnais. Un agent opencode ne se réveillera pas sur un calendrier ou à l'arrivée d'un événement : quelqu'un, ou quelque chose, doit lui envoyer une tâche par chat. Si vous voulez un agent qui réagit à des événements ou tourne selon un planning, c'est un travail pour un agent Hermes.

Il n'utilise pas le broker d'intégrations d'Atako. La seule intégration qu'il touche est GitHub, et c'est en tant que périmètre de dépôts. Il ne peut pas appeler un CRM ou un outil de tickets par le broker.

Au moins un dépôt GitHub est obligatoire. Un agent opencode sans dépôt n'a rien sur quoi travailler, la création est donc refusée.

Enfin, le résultat est une pull request en brouillon, pas une fusion. C'est voulu, et cela signifie aussi qu'une personne doit intervenir pour la relecture.

Quand choisir opencode, quand choisir Hermes

Atako propose deux harnais à la création d'un agent.

Choisissez opencode quand le travail est du code et qu'il vit dans des dépôts GitHub précis : une refonte, une mise à jour de dépendance, un correctif, une petite fonctionnalité, un passage sur la documentation. Vous obtenez un agent disponible en continu, qui ne touche que les dépôts que vous avez nommés et qui rend des pull requests relisibles plutôt que des modifications directes.

Choisissez Hermes, le harnais par défaut, quand l'agent doit agir à travers des outils et des canaux métier : lire et écrire dans un CRM, répondre à des e-mails, réagir à un webhook, tourner selon un planning, se coordonner avec d'autres agents. Il a accès à tous les connecteurs du catalogue, avec des droits réglés par endpoint et un journal d'audit de chaque appel.

Les deux ne s'opposent pas. Un montage possible est un agent Hermes qui traite le volet métier d'une demande et un agent opencode qui exécute le travail sur les dépôts, chacun limité à ce que sa mission exige.