OpenHands : un agent développeur sur modèle local

#Ce qu'il fait, concrètement

Vous décrivez une tâche en français. Il inspecte le dépôt, se fait un plan, puis agit en boucle : lancer une commande, lire le résultat, modifier un fichier, relancer les tests, lire l'échec, corriger. Cette boucle est le produit. On est plus près d'un stagiaire avec un terminal que d'une complétion automatique.

Les conséquences suivent. Chaque itération est une génération complète sur un contexte qui grossit : une tâche en dix étapes coûte dix longs prompts. Et comme l'agent agit au lieu de suggérer, son rayon d'action est tout ce qu'il peut atteindre — ce qui explique pourquoi le bac à sable fait partie de la conception et non des réglages.

#Le projet en 2026 : Agent Canvas

OpenHands s'appelait OpenDevin à son lancement, avant de prendre son nom actuel. Le dépôt, maintenu par All Hands AI, est publié sous licence MIT et dépasse 89 000 étoiles sur GitHub à l'été 2026. Le projet s'est aussi élargi : il ne se présente plus seulement comme un agent autonome isolé mais comme « le centre de contrôle auto-hébergé pour les agents de code et les automatisations », capable de piloter aussi bien OpenHands que Claude Code, Codex ou Gemini depuis une seule interface.

Concrètement, l'offre s'est structurée en plusieurs briques : Agent Canvas (l'interface de pilotage), un Software Agent SDK pour construire ses propres agents, un Agent Server, et un serveur d'automatisation pour les tâches planifiées. L'ancienne interface locale autonome a été dépréciée au profit de cette architecture modulaire ; le principe reste le même pour l'usage local décrit ici — un agent qui agit dans un bac à sable conteneurisé — mais les noms de composants et la commande de lancement peuvent différer d'une ancienne documentation à l'autre, y compris celle que vous trouverez encore parfois indexée sous le nom OpenDevin.

#L'exigence de modèle, sans détour

Deux capacités comptent plus que les scores de benchmark : l'appel d'outils dans le format exact attendu, et la stabilité sur contexte long, puisque l'agent relit un historique croissant à chaque étape. Un modèle excellent pour écrire une fonction à partir d'un prompt peut être inutilisable en boucle. Les modèles orientés code battent en général les modèles de discussion de même taille sur cet exercice.

La documentation officielle du projet a changé de conseil courant 2026 : elle recommande désormais Qwen3.6-35B-A3B comme premier modèle local à essayer, un modèle MoE (mélange d'experts) conçu pour le codage agentique, avec un contexte large et disponible via LM Studio, Ollama, vLLM et SGLang. L'intérêt d'un MoE ici est direct : seuls 3 milliards de paramètres sont activés par jeton malgré les 35 milliards de poids totaux, ce qui rend la génération nettement plus rapide qu'un modèle dense de taille comparable, pour une VRAM plus proche de celle d'un modèle 14B que d'un 35B dense.

#Le faire tourner en local

1. 01
   Servir un modèle

   Sur un point d'accès compatible OpenAI, avec la variable OLLAMA_CONTEXT_LENGTH remontée à 22 000 au minimum (32 768 conseillé) si vous passez par Ollama. C'est l'étape qu'on saute, et elle produit des agents qui oublient leur propre plan.
2. 02
   Démarrer l'application dans sa configuration conteneurisée

   Elle a besoin d'un moteur de conteneurs (Docker Desktop ou Docker Engine) : le shell de l'agent vit là, pas sur votre hôte.
3. 03
   Le pointer vers votre point d'accès local

   Avec une clé d'API factice (par exemple local-llm) et une URL de base atteignable depuis le conteneur — sous Docker Desktop, http://host.docker.internal:PORT/v1 plutôt que localhost, qui désignerait le conteneur lui-même. Ne déclarez la prise en charge des appels d'outils que si le modèle en est réellement capable.
4. 04
   Monter un seul dépôt

   Idéalement un clone jetable, sur une branche que vous pouvez supprimer sans regret.
5. 05
   Commencer par une tâche petite et vérifiable

   Corrige ce test qui échoue, ajoute ce paramètre, mets à jour cette configuration. Puis relisez le diff.

• Servir un modèle avec un contexte long
• Faire relire du code par un modèle local
• Cline : l'agent de code intégré à l'éditeur
• Le kit QuelLLM pour monter un agent local
• Documentation officielle : modèles locaux avec OpenHands
• Dépôt officiel OpenHands sur GitHub
• Revue indépendante d'OpenHands (2026)

#Le coût réel d'une tâche

Une tâche agentique ne coûte pas un appel au modèle mais une suite d'appels, chacun sur un contexte plus long que le précédent puisque l'historique s'accumule. Pour une tâche qui prend dix itérations, si chaque étape ajoute en moyenne 800 tokens à l'historique, le dixième appel relit déjà plusieurs milliers de tokens de contexte avant même de produire sa réponse. Sur du calcul local, le temps de lecture du prompt (le « prefill ») s'ajoute au temps de génération à chaque tour, ce qui explique pourquoi un agent local sur un modèle de 32 milliards de paramètres se compte en minutes par tâche, et non en secondes comme une complétion classique.

C'est la contrepartie de ne pas payer de facture d'API : le coût ne disparaît pas, il se déplace vers votre carte graphique et votre temps d'attente. Sur une tâche mal spécifiée qui déclenche vingt itérations parce que l'agent tourne en rond, ce déplacement de coût devient vite plus cher, en électricité et en temps, qu'un appel API équivalent.

#Un exemple concret, pour fixer les idées

Prenons une tâche réaliste : « le test test_export_csv échoue depuis le dernier commit, corrige-le ». Sur un modèle de la classe 32 milliards, le déroulé typique tient en cinq à huit itérations : lecture du test et du message d'échec, ouverture du fichier source concerné, hypothèse sur la cause, modification, relance du test, lecture du nouveau résultat, ajustement si besoin. Chaque itération relit l'historique complet des précédentes, ce qui rend la fenêtre de contexte décisive : avec 8 000 tokens seulement, l'agent perd le fil au bout de trois ou quatre étapes et recommence des hypothèses déjà écartées.

Sur un modèle de 7 à 8 milliards de paramètres, la même tâche échoue le plus souvent différemment : le test est bien identifié, mais la commande de relance est mal formée, ou le modèle édite un fichier voisin qui porte un nom proche. Ce ne sont pas des erreurs de réglage — c'est la limite de capacité du modèle sur le format strict qu'exige la boucle outil-résultat-décision, quelle que soit la qualité du prompt système. C'est aussi pour cette raison que les scores publiés sur des benchmarks de complétion de code ne prédisent pas grand-chose ici : un modèle noté haut sur la génération d'une fonction isolée peut rester incapable d'enchaîner dix appels d'outils cohérents sans dérailler, parce que ces deux compétences ne sont pas corrélées de la même façon selon la façon dont le modèle a été entraîné.

#La sécurité n'est pas optionnelle

Aucun secret dans l'environnement

L'agent lit son propre environnement et peut l'afficher.

Une branche jetable et un clone de travail

Jamais votre copie de travail avec des modifications non validées.

Accès réseau restreint

Un agent qui peut joindre n'importe quoi peut exfiltrer tout ce qu'il a lu.

Tout contenu récupéré est hostile par défaut

La description d'un ticket ou un fichier README peuvent contenir des instructions destinées à l'agent : le mécanisme est détaillé dans notre guide sur l'injection de prompt.

Relire chaque diff

« Les tests passent » signifie que les tests passent, pas que la modification est correcte.

#Quand un assistant vaut mieux qu'un agent

En résumé, OpenHands en local n'est ni un gadget ni un remplaçant universel : c'est un outil à réserver aux machines qui peuvent réellement loger un modèle de 27 milliards de paramètres ou plus avec un contexte de 32 000 tokens, et aux tâches assez étroites pour qu'un test automatisé ou une relecture rapide suffise à juger le résultat. En dessous de ce seuil de matériel, un assistant conversationnel classique avec le fichier ouvert reste plus rapide et plus fiable qu'un agent qui boucle sans jamais converger.

#FAQ