OpenCode sur un serveur : faire travailler un agent IA pendant que vous dormez

Une histoire bien connue : vous lancez un agent IA dans le terminal, il se fige au moment le plus intéressant, puis vous fermez votre ordinateur portable et toute la session disparaît. Claude Code et Codex sont fermés et conçus pour les modèles de leurs éditeurs. OpenCode, un harness open source, n'a pas cette limite : il fonctionne avec n'importe quel fournisseur et, surtout, il peut s'installer sur un serveur.

Pourquoi c'est possible

En interne, OpenCode repose sur un schéma client-serveur. La TUI communique avec un serveur HTTP local qui publie une spécification OpenAPI sur le point d'accès /doc. La commande opencode serve lance ce même serveur sans interface. Par défaut, il écoute sur 127.0.0.1:4096 ; l'adresse et le port se modifient avec les options --hostname et --port. On peut s'y connecter depuis la CI, depuis cron ou depuis un autre script, et le garder « chaud » pour ne pas payer le démarrage à froid de MCP et LSP.

Si le serveur est accessible ailleurs que depuis localhost, définissez impérativement OPENCODE_SERVER_PASSWORD. L'authentification HTTP basic est alors activée, avec opencode comme nom d'utilisateur par défaut. Un mot de passe ne suffit pas : placez le serveur derrière nginx ou Caddy avec HTTPS, faute de quoi le basic auth sur HTTP en clair ne protège que des scans fortuits.

Cas d'usage

Le scénario le plus simple est la CI/CD et la revue de pull requests. Avec l'application GitHub, il suffit de mentionner /opencode ou /oc dans un commentaire : l'agent démarre dans un runner GitHub Actions, lit le contexte et, si nécessaire, ouvre une PR avec un correctif. Sans l'application, on écrit dans le workflow une étape avec opencode run --standalone : en CI, aucune TUI n'est lancée, et la commande démarre elle-même un serveur privé pour la tâche. La sortie des modèles n'étant pas déterministe, il ne faut pas confier à l'agent des notations chiffrées, mais pour la revue il convient très bien.

Second scénario : les tâches nocturnes. Le plugin opencode-scheduler utilise launchd sous macOS et systemd sous Linux, avec cron en solution de repli. Un audit quotidien des dépendances ou un rapport sur git log se programme puis s'oublie. Troisième scénario : un serveur commun pour l'équipe. Plugins d'IDE, interface web ou pont Telegram se connectent à un seul processus et voient les mêmes sessions.

Systemd ou Docker

Sur un VPS vierge, une unité systemd avec la commande opencode serve suffit. Le piège principal est le PATH. Les services systemd n'héritent pas du PATH de votre shell : non seulement OpenCode reste introuvable, mais aussi tout ce que l'agent appelle via bash : git, node, rg, make. Définissez explicitement Environment=PATH=... et HOME.

Docker apporte l'isolation du système de fichiers et la reproductibilité. Fixez une version précise de l'image, montez le workspace dans un volume distinct, et les configs et sessions dans un autre. Mais c'est une assurance contre un rm accidentel, pas contre une évasion délibérée.

Droits, fournisseurs, sécurité

Le fournisseur se connecte via @ai-sdk/openai-compatible : tout point d'accès compatible convient, d'un Ollama local à une passerelle cloud. L'exemple de l'article utilise BotHub, sponsor du contenu. Mieux vaut ne pas stocker la clé API dans la config, mais l'enregistrer via opencode auth login. Pour les tâches annexes, comme les titres de session, définissez une small_model peu coûteuse.

Sur un serveur, il ne faut pas laisser la règle ask : opencode serve peut attendre pendant des heures une réponse qui ne viendra jamais. Utilisez des allow ciblés par-dessus deny, ou l'option --auto, qui transforme ask en allow tout en conservant deny.

Le plus important : SECURITY.md indique clairement qu'OpenCode n'est pas un bac à sable et que le système de permissions n'est qu'une question d'UX. Les serveurs MCP externes sont hors du périmètre de confiance, et un récent cas de MCP malveillant exécutant du code via OAuth l'a confirmé. Autre point douloureux : Bun lit de façon instable HTTP_PROXY, ne comprend pas socks5://, et sans NO_PROXY pour localhost, l'agent peut tourner en boucle sur ses propres requêtes.

Supervision et conclusion

Il existe un health-check /global/health, des logs dans journald ou Docker, et le plugin opencode-otel envoie des traces vers Jaeger, Grafana Tempo, Datadog ou Langfuse. Pour la CI, opencode run --format json est pratique. Surveillez la consommation de tokens : la nuit, l'agent travaille sans supervision.

Conclusion pratique : déployer un agent sur un serveur prend une soirée, mais le vrai travail commence après. Isolation, HTTPS, droits stricts et observabilité sont indispensables. Il est le plus efficace là où il est intégré à un processus : audits nocturnes, revue de PR. Mieux vaut ne pas lui donner accès à la production : qu'il prépare la PR, et c'est vous qui appuyez sur le bouton.