OpenHands : une plateforme ouverte pour les agents logiciels d'IA et son impact sur l'automatisation de la finance

Je rencontre de plus en plus souvent OpenHands comme couche d'échafaudage sous-jacente à TheAgentCompany, InvestorBench et une liste croissante de documents d'évaluation — pourtant, je n'avais pas encore lu l'article de recherche principal. C'est l'infrastructure sur laquelle le reste du domaine s'appuie discrètement ; comprendre ce qu'elle apporte réellement, et là où elle échoue, importe donc plus que n'importe quel résultat de benchmark isolé construit par-dessus.

L'article

OpenHands (Wang et al., 2024 ; ICLR 2025) est une plateforme open-source pour la création et l'évaluation d'agents LLM agissant comme des développeurs logiciels généralistes. Mené par Xingyao Wang et Graham Neubig au sein d'une équipe de 24 auteurs, l'article affirme que la plupart des frameworks d'agents existants sont soit trop restreints à la recherche (boucles de tâches codées en dur), soit trop restreints à la production (source fermée ou à but unique) pour servir de base partagée à la communauté de recherche. OpenHands tente de corriger cela en fournissant un environnement d'exécution standardisé, une abstraction d'agent propre et 15 benchmarks d'évaluation intégrés sous un seul dépôt sous licence MIT.

L'environnement d'exécution (runtime) est un environnement isolé par Docker contenant un shell bash, un serveur Jupyter IPython et un navigateur Chromium contrôlé par Playwright. Les agents interagissent via trois types d'actions principaux : IPythonRunCellAction pour Python, CmdRunAction pour les commandes shell, et BrowserInteractiveAction pour la navigation web. Une primitive de coordination multi-agents, AgentDelegateAction, permet à un agent principal de générer des sous-agents spécialisés. La structure de base par défaut est CodeAct — initialement publié comme un article autonome soutenant que le code est l'espace d'action unifié idéal pour les agents LLM — et la plateforme propose plusieurs implémentations d'agents, dont un CodeActAgent généraliste et un BrowsingAgent spécialisé.

Idées clés

• Le code comme espace d'action universel : CodeAct consolide toutes les actions de l'agent (édition de fichiers, appels d'API, transformations de données) en Python ou bash, permettant au LLM de raisonner dans le support sur lequel il a été le plus intensément entraîné. Cela évite la fragilité liée aux schémas JSON qui handicape les agents basés sur l'appel de fonctions (function-calling).
• Environnement d'exécution Docker isolé : chaque agent s'exécute dans un conteneur isolé, de sorte que les agents peuvent exécuter librement du code arbitraire sans compromettre la machine hôte — un prérequis pour tout agent financier en production à qui l'on pourrait confier de véritables identifiants.
• 15 benchmarks dans un seul banc d'essai : SWE-Bench Lite (réparation de code), HumanEvalFix (correction de bugs), WebArena (navigation web), GPQA (raisonnement de niveau universitaire), GAIA (résolution de tâches générales), et dix autres. Cette colocalisation évite les évaluations sélectives (cherry-picked).
• CodeActAgent + claude-3.5-sonnet atteint 26 % sur SWE-Bench Lite et 79,3 % sur HumanEvalFix ; BrowsingAgent atteint 15,5 % sur WebArena — des résultats compétitifs en "zero-shot" sans aucun entraînement spécifique à la tâche.
• Performance GAIA : 32,1 % avec GPTSwarm, bien en dessous de la base de référence humaine de 92 % — ce qui est cohérent avec tous les autres benchmarks d'agents généraux montrant un écart de 60 à 70 points entre l'humain et l'agent.
• Échelle de la communauté : 71,4k étoiles sur GitHub et plus de 188 contributeurs au moment de la soumission à l'ICLR ; TheAgentCompany a adopté OpenHands comme banc d'essai d'évaluation, lui conférant un statut de fait d'infrastructure de référence.

Ce qui tient la route — et ce qui ne la tient pas

La conception de l'environnement d'exécution isolé est une ingénierie solide. Isoler l'exécution des agents dans Docker est le choix par défaut correct pour tout système qui pourrait plus tard recevoir un accès en écriture à de véritables grands livres financiers, et il est réellement utile que les benchmarks soient regroupés plutôt que dispersés dans des dépôts incompatibles.

La couverture des benchmarks est cependant plus aspirative que systématique. Les 15 benchmarks couvrent des types de tâches et des niveaux de difficulté radicalement différents sans cadre clair sur la manière dont les résultats devraient être agrégés ou comparés. Rapporter 26 % sur SWE-Bench Lite aux côtés de 79,3 % sur HumanEvalFix dans le même article risque de donner l'impression que le même agent est simultanément médiocre et excellent — les tâches ne sont tout simplement pas comparables. Les auteurs ne fournissent pas de méthodologie d'agrégation multi-benchmarks rigoureuse.

L'hypothèse CodeAct — selon laquelle le code est le bon format d'action universel — est contestée. Cela fonctionne bien pour les tâches de développement, mais impose une couche de médiation Python/bash pour chaque action, ce qui ajoute de la latence et échoue lorsque la sémantique de l'action ne correspond pas proprement au code (instructions utilisateur ambiguës, API uniquement en langage naturel). L'article n'effectue pas de benchmark par rapport à des espaces d'action non basés sur le code pour démontrer que l'avantage est réel plutôt que confondu par les capacités intrinsèques du LLM.

L'écart le plus important est peut-être la séparation entre évaluation et déploiement. Le chiffre de 26 % sur SWE-Bench provient d'un benchmark relativement propre et bien spécifié. Les rapports de la communauté et les fils de discussion GitHub décrivent systématiquement une fiabilité bien moindre sur des tâches réelles ambiguës ou à long horizon — le même mode d'échec que celui documenté par TheAgentCompany. L'article n'aborde pas la manière de mesurer ou d'améliorer la robustesse face au bruit des spécifications de tâches réalistes.

Pourquoi cela est important pour l'IA financière

OpenHands est ce qui se rapproche le plus d'un substrat d'agent partagé pour la communauté. Si Bean Labs construit une infrastructure d'évaluation pour les agents Beancount, l'architecture d'exécution ici — isolation Docker, actions Python/bash, backends LLM interchangeables — mérite d'être adoptée plutôt que reconstruite. La primitive AgentDelegateAction correspond naturellement à un pipeline d'agent financier où un orchestrateur de haut niveau délègue à des sous-agents spécialisés : un pour la lecture du grand livre, un pour le signalement d'anomalies, un pour une proposition d'écriture qu'un humain révise.

Les chiffres de SWE-Bench et de TheAgentCompany, lus ensemble, établissent un a priori lucide : même les meilleurs agents disponibles ne réalisent qu'environ 26 à 30 % des tâches logicielles réalistes et non ambiguës. L'automatisation des grands livres financiers est plus difficile — les transactions sont souvent ambiguës, le rayon d'impact des erreurs est réel et l'intention de l'utilisateur est fréquemment sous-spécifiée. La conclusion correcte n'est pas que les agents ne sont pas prêts, mais que les premiers déploiements productifs seront des flux de travail d'écriture unique strictement délimités (suggestions de catégorisation, signalement de rapprochements) plutôt que des modifications autonomes du grand livre en plusieurs étapes.

Que lire ensuite

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — associe un modèle peu coûteux à un modèle onéreux et ne délègue au modèle onéreux que lorsque l'incertitude est élevée ; aborde directement la manière dont un agent de type OpenHands devrait décider quand escalader une écriture Beancount à une révision humaine.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 séquences de tâches annotées par des experts à travers 34 scénarios financiers ; la méthodologie d'évaluation qui manque à OpenHands pour l'utilisation d'outils à long horizon spécifiques à la finance.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 échantillons à travers 65 outils financiers MCP réels, directement pertinent pour la manière dont un agent Beancount construit sur le runtime d'OpenHands serait évalué dans un déploiement MCP réel.