OpenCode / OpenHands (anciennement OpenDevin)

1. Vue d’ensemble du concept et problématique systémique

L’émergence d’« AI Software Engineers » autonomes commerciaux (à l’instar de Devin) a préfiguré l’avenir du développement, où les modèles clôturent le backlog de manière autonome. Toutefois, les services propriétaires présentent des risques majeurs : coûts élevés (abonnements à partir de 500 $/mois), opacité des algorithmes internes, impossibilité totale d’adapter le comportement à la stack interne spécifique de l’entreprise, et risque de fuite de secrets commerciaux vers les clouds fermés des éditeurs.

OpenHands (anciennement OpenDevin) a été conçu comme une alternative libre, modulaire et sécurisée. Il s’agit d’un framework agentique complet capable de cloner un dépôt en autonomie, d’analyser la documentation, de reproduire des bugs via l’écriture de tests, de modifier la base de code et de pousser des Pull Requests. La sécurité est assurée par une isolation stricte : chaque session d’agent s’exécute dans son propre environnement Docker éphémère (Sandboxing).

2. Taxonomie architecturale et modèle mental

Le modèle architectural d’OpenHands repose sur un bus d’événements (Event Stream) et une exécution isolée :

┌─────────────────────────────────────────────────────────────┐
│                   ARCHITECTURE OPENHANDS                    │
├─────────────────────────────────────────────────────────────┤
│ 1. Noyau EventStream (EventController & AgentController)    │
│    Bus central de communication des événements Action ➔ Observation │
├─────────────────────────────────────────────────────────────┤
│ 2. Couche de raisonnement de l'agent (ReAct / CodeAct / Planner) │
│    Prise en charge de Claude 3.7 Sonnet, DeepSeek R1, OpenAI o1/o3 │
├─────────────────────────────────────────────────────────────┤
│ 3. Environnement d'exécution isolé (Docker / MicroVM / gVisor) │
│    • Exécution : Shell Bash avec suivi des processus en arrière-plan │
│    • Système de fichiers : Éditeurs basés sur AST & montage d'espace de travail │
│    • Navigateur sans interface graphique : Chromium pour les tests UI et la documentation │
│    • Jupyter / IPython : REPL interactif pour l'analyse de données │
├─────────────────────────────────────────────────────────────┤
│ 4. Intégrations Git & CI/CD : Application GitHub, Automatisation des PR │
└─────────────────────────────────────────────────────────────┘

1. Bus d’événements (EventStream Architecture) :
   • Toutes les communications dans le système sont typées sous forme de chaîne « Action ➔ Observation » (Action ➔ Observation).
   • Chaque étape de l’agent (exécution d’une commande bash, modification d’un fichier, ouverture d’une URL dans le navigateur) est enregistrée comme une action, tandis que la réponse du système (sorties standard, erreurs, captures d’écran) est enregistrée comme une observation.
2. Stratégies de raisonnement agentiques (Agent Framework) :
   • Prend en charge la paradigme CodeAct — une approche où l’agent génère directement du code exécutable Python ou Bash plutôt que des structures JSON complexes, ce qui améliore considérablement la précision des opérations multi-étapes complexes.
3. Environnement isolé (Docker Sandboxing) :
   • Garantit l’isolation physique du code. Le dépôt utilisateur est monté comme un volume de travail (Volume), tandis que tous les binaires système, dépendances et serveurs s’exécutent à l’intérieur du conteneur.

3. Pipeline technique et mécanique interne

Le cycle de vie de la résolution d’une tâche d’ingénierie dans OpenHands :

1. Initialisation et déploiement de l’environnement : La plateforme reçoit la tâche (par exemple, un lien vers une GitHub Issue). OpenHands crée un nouveau conteneur Docker avec un environnement projet préconfiguré (Node.js, Python, Rust) et clone la branche cible du dépôt.
2. Exploration et reproduction du défaut (Repro Test Phase) :
   • L’agent effectue une recherche sémantique de fichiers à l’aide de ripgrep.
   • Avant d’apporter des corrections, l’agent crée un fichier de test distinct (Reproduction Script) qui échoue sur le bug existant.
3. Boucle de modification autonome (CodeAct Loop) :
   • L’agent apporte des modifications à la logique métier.
   • Exécute les tests dans le terminal du conteneur.
   • Récupère le résultat : si le test échoue à nouveau, il analyse la stack trace et formule une nouvelle action.
4. Vérification via navigateur (Optional UI Inspection) : Si la tâche concerne l’interface web, l’agent démarre un serveur dev local, ouvre la page via Chromium headless et vérifie le rendu visuel.
5. Génération de PR et nettoyage des ressources : Une fois tous les tests passés, l’agent effectue un git commit, pousse une nouvelle branche sur GitHub, ouvre une Pull Request avec une description détaillée du travail effectué et arrête le conteneur.

4. Scénarios d’ingénierie pratiques en production

01. Worker nocturne automatisé pour le backlog (Automated Bug Triaging)

Intégration d’OpenHands au dépôt via GitHub Actions / Webhooks :

• Lors de l’attribution du label needs-ai-fix à un ticket, la plateforme déploie un conteneur et assigne la résolution de la tâche à l’agent.
• Au matin, l’équipe reçoit 5 Pull Requests prêtes, avec tests validés, en attente d’une revue finale humaine.

02. Test sécurisé de code externe non fiable

Audit de sécurité de bibliothèques open-source tierces ou de scripts suspects :

• L’agent explore le dépôt, lance des analyseurs statiques et des tests de charge.
• Grâce à la sandbox Docker, toute tentative du code tiers de se connecter au système hôte ou de télécharger des logiciels malveillants est entièrement bloquée.

03. Mise à jour en masse des microservices de l’entreprise

Nécessité de mettre à jour la configuration des Dockerfiles ou des Helm charts sur 40 microservices :

• OpenHands déploie séquentiellement un environnement isolé pour chaque microservice, applique les modifications, vérifie la réussite du build local du conteneur et publie une PR dans le dépôt correspondant.

5. Pièges courants, erreurs typiques et sécurité

• Danger lié au montage du socket Docker hôte : Lors du déploiement d’OpenHands, il est extrêmement risqué de passer le socket /var/run/docker.sock à l’intérieur du conteneur sans protection supplémentaire (Docker-out-of-Docker). Cela donne à l’agent un accès root à la machine hôte et annule l’isolation de la sandbox.
• Exigences en ressources de calcul : L’exécution parallèle de plusieurs agents dans Docker nécessite une grande quantité de mémoire vive (de 16 à 32 Go de RAM) et un processeur puissant, sinon le système peut subir des crashs dus à l’OOM (Out Of Memory).
• Consommation infinie de tokens en cas de défaillance de l’environnement : Si le compilateur système est absent du conteneur ou si le réseau est rompu, l’agent peut consommer des centaines de milliers de tokens dans des tentatives vaines d’installer un paquet manquant. Configurez toujours des timeouts de session.
• Conteneurs « orphelins » résiduels : En cas d’arrêt brutal du processus principal de la plateforme, les conteneurs temporaires et les volumes créés peuvent persister dans le système, saturant progressivement l’espace disque du serveur.