OpenHands Agent Canvas : vos agents de code auto-hébergés

En mars 2024, une démo de Devin, « le premier ingénieur logiciel IA », faisait le tour des réseaux. Quelques jours plus tard naissait OpenDevin, sa réponse open source. Le projet a pris le nom d'OpenHands, puis a gagné des dizaines de milliers d'étoiles en promettant un agent qui écrit du code, lance des commandes et navigue sur le web dans un bac à sable.

Ouvrez le dépôt aujourd'hui, et le titre a changé : « Agent Canvas ». OpenHands n'est plus seulement un agent. C'est un centre de contrôle auto-hébergé pour agents de code, qui fait tourner son propre agent mais aussi Claude Code, Codex, Gemini CLI ou OpenCode, et qui les lance tout seul, sur planning ou quand un événement arrive dans GitHub, Slack ou Linear.

Du clone de Devin au centre de contrôle

Le dépôt OpenHands/OpenHands dépasse les 90 000 étoiles et les 12 000 forks mi-octobre 2026, sous licence MIT. Il est porté par l'entreprise derrière openhands.dev, qui vend en parallèle OpenHands Cloud et une offre Enterprise.

Le virage date de juin 2026. Agent Canvas est présenté le 16 juin comme « l'interface principale d'OpenHands », dans un dépôt séparé. Fin juillet, son code et son historique de versions sont migrés dans le dépôt principal, qui devient une application TypeScript. La logique de l'agent, elle, vit désormais dans le software-agent-sdk, en Python.

Le système est donc réparti sur plusieurs dépôts :

Si vous avez suivi le projet en 2024 ou 2025, oubliez l'ancienne interface et ses commandes docker run de plusieurs lignes. Les tutoriels de cette époque ne s'appliquent plus.

Un frontend, plusieurs backends

L'idée centrale tient en une phrase : l'interface et l'endroit où tourne l'agent sont séparés. Agent Canvas est le frontend. L'Agent Server est une API REST qui exécute les agents sur une machine. On peut en brancher plusieurs et passer de l'un à l'autre depuis la même fenêtre.

Agent Canvas (navigateur)
├── Local          → votre portable
├── Docker         → un conteneur par conversation
├── VM d'équipe    → un serveur partagé pour la revue de code
└── OpenHands Cloud → l'offre commerciale

Le cas d'usage cité par le README est parlant : un Agent Server partagé avec l'équipe pour les revues de code et les mises à jour de dépendances, et vos agents personnels sur votre portable. Un serveur distant a un autre avantage : les automatisations continuent de tourner quand vous fermez l'écran.

Claude Code, Codex et les autres via ACP

Agent Canvas fait tourner l'agent OpenHands par défaut, avec le modèle de votre choix : Claude, GPT, Gemini ou un modèle ouvert comme ceux de NVIDIA, avec lesquels l'éditeur a noué des partenariats. Les « profils LLM » permettent de réserver un modèle bon marché aux tâches simples et un modèle plus cher au travail difficile.

L'autre option est d'utiliser un agent tiers. Claude Code, Codex, Gemini CLI, Pi et OpenCode se branchent via l'Agent Client Protocol (ACP), un protocole qui standardise la conversation entre une interface et un agent de code. C'est ce qui rend l'outil intéressant pour ceux qui ont déjà leurs habitudes : vous gardez votre agent, avec ses réglages et ses sous-agents spécialisés comme ceux d'agency-agents, et Agent Canvas ajoute les backends et les automatisations par-dessus.

Installer : quatre options, une seule recommandable

Il faut Node.js 24 ou plus et uv, le gestionnaire Python d'Astral, qui lance l'Agent Server. La voie la plus courte :

npm install -g @openhands/agent-canvas
agent-canvas

L'interface s'ouvre sur http://localhost:8000. Mais le README prévient en gras : dans ce mode, l'agent tourne directement sur votre machine, avec un accès complet à votre système de fichiers. Un agent qui peut exécuter rm -rf, lire ~/.ssh et appeler le réseau n'a rien à faire en dehors d'un bac à sable.

Je recommande le conteneur Docker, qui limite l'agent aux projets que vous montez :

export PROJECTS_PATH="$HOME/projects"
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"
 
docker run -it --rm \
  -p 127.0.0.1:8000:8000 \
  -e AGENT_CANVAS_ALLOW_LAN_SESSION_KEY=true \
  -v "$HOME/.openhands:/home/openhands/.openhands" \
  -v "${PROJECTS_PATH}:/projects" \
  ghcr.io/openhands/agent-canvas:1.27.1

L'interface est alors sur http://localhost:8000/canvas. Notez le 127.0.0.1 dans la publication du port : la clé de session est injectée dans la page, et ce réglage l'empêche de fuiter sur le réseau local. Si vous publiez le port ailleurs, retirez AGENT_CANVAS_ALLOW_LAN_SESSION_KEY et saisissez la clé à la main.

Pour lancer plusieurs agents en parallèle, une troisième option isole chaque conversation dans son propre conteneur :

OH_CONVERSATION_RUNTIME=docker agent-canvas

Attention à la nuance : seule l'exécution des conversations est isolée, pas Agent Canvas ni le service d'automatisation. Et deux conversations sur le même dossier partagent les mêmes fichiers. Utilisez des dossiers ou des worktrees git séparés.

Les automatisations

C'est le cœur de la nouvelle version, et ce que montre l'image en tête de cet article, tirée du dépôt. Une automatisation, c'est un prompt, un dépôt, un déclencheur et un profil de modèle. Le déclencheur est un planning (« en semaine à 9 h ») ou un webhook (« à chaque push », « à chaque incident »).

Les modèles proposés donnent une idée de l'usage visé :

Chaque exécution affiche son état et son coût en tokens, et un tableau de bord suit les échecs et les durées. Les définitions peuvent être synchronisées dans un dépôt git privé, ce qui permet de relire leur historique comme du code. Les modèles peuvent aussi installer des scripts pour la partie déterministe, comme le dédoublonnage ou l'interrogation d'une API, et laisser à l'agent ce qui demande du jugement.

Ce dernier point est le bon réflexe. Une automatisation qui doit toujours faire la même chose relève d'une pipeline GitHub Actions ou d'un workflow n8n, moins chers et prévisibles. L'agent n'a de sens que là où il faut lire, interpréter et rédiger : résumer une PR, trier un ticket mal écrit, expliquer un incident.

Exposer Agent Canvas sur un serveur

Le guide d'auto-hébergement est l'un des plus francs que j'aie lus. Il commence par ceci : quiconque peut parler à l'Agent Server peut lire et écrire sur la machine, exécuter des commandes et accéder au réseau. Il faut traiter la VM comme une machine qui détient des identifiants de production.

La procédure recommandée suit cette logique. D'abord, fermer tout le trafic entrant sauf SSH, depuis votre IP, au niveau du fournisseur cloud, avec un pare-feu comme UFW en seconde ligne. Ensuite, lancer en mode public avec une clé forte :

export LOCAL_BACKEND_API_KEY="$(openssl rand -base64 32)"
npx @openhands/agent-canvas --public

En mode public, la clé n'est pas intégrée au frontend : l'interface la demande à la connexion. On accède ensuite au service par un tunnel SSH, ou par nginx avec TLS en limitant le port 443 à une liste d'IP.

Deux mises en garde du projet méritent d'être répétées. L'éditeur OpenVSCode intégré partage l'origine du navigateur avec Agent Canvas : un script qui s'y exécute peut lire le localStorage, où sont stockées les clés de session de tous les backends enregistrés. Le problème est suivi dans le ticket #16492. Les « Canvas Apps », des extensions apparues en août, exécutent elles aussi leur JavaScript dans le même contexte que l'interface, sans iframe. Elles s'installent désactivées pour qu'on puisse relire leur code avant de les activer, et c'est exactement ce qu'il faut faire.

Ce qui freine encore

Le projet est officiellement en bêta, et ça se voit au rythme : une version 1.20 mi-septembre, une 1.27 mi-octobre. Chaque mise à jour peut changer l'interface ou une option. Pour un usage d'équipe, épinglez la version de l'image Docker plutôt que de suivre latest.

L'architecture en quatre dépôts complique aussi la lecture. Pour comprendre un comportement, il faut souvent aller voir le SDK Python, alors que le dépôt le plus visible est une application TypeScript.

Enfin, l'outil ne paie pas les tokens à votre place. Une automatisation quotidienne sur un gros dépôt, avec un modèle haut de gamme, finit par coûter. Le coût par exécution est affiché, et les profils de modèles servent justement à ne pas lancer le modèle le plus cher pour résumer un canal Slack.

OpenHands a fait un pari lucide. Le marché des agents de code s'est rempli de concurrents solides, et plutôt que de lutter agent contre agent, le projet est devenu l'endroit où on les fait tourner : sur sa machine, dans Docker ou sur un serveur d'équipe, avec des déclencheurs, des coûts visibles et un historique. Si vous utilisez déjà Claude Code ou Codex à la main, Agent Canvas est la façon la plus simple de tester ce que donne un agent qui travaille sans qu'on le lui demande. Commencez par une seule automatisation de lecture, comme le résumé quotidien des PR, dans un conteneur, et donnez-lui le droit d'écrire seulement quand elle a fait ses preuves.