Devin, OpenHands, Scion : quel environnement d'exécution pour vos agents en 2026 ?

Dans l'article du 5 juillet sur le harness engineering en pratique, on a posé le harness comme la couche qui détermine 90% du comportement d'un agent. Aujourd'hui, la question qui suit logiquement : où cet agent s'exécute-t-il ? Sur quelle infrastructure ? Avec quelles garanties d'isolation ?

Le réflexe contre-intuitif à corriger d'entrée : la plupart des équipes évaluent ces trois outils sur leur niveau d'autonomie perçu, alors que le critère qui détermine réellement l'adoption en production est l'auditabilité. Un agent plus autonome mais opaque se heurte systématiquement à la conformité ; un agent moins spectaculaire mais dont chaque action est traçable passe la revue de sécurité du premier coup.

Ce n'est pas un détail opérationnel. C'est une décision d'architecture qui conditionne la sécurité, les coûts et la capacité à passer à l'échelle. Et en 2026, trois approches distinctes se sont imposées comme références : Devin, OpenHands et Scion.

Ce que fait concrètement un environnement d'exécution

Un environnement d'exécution pour agents IA, c'est la couche qui prend en charge tout ce que le modèle de langage ne peut pas faire seul : lancer un terminal, accéder à un système de fichiers, exécuter du code, naviguer sur le web, appeler des APIs, et surtout isoler ces actions du reste de l'infrastructure.

Sans cette couche, un agent opère en aveugle ou, pire, avec des accès non bornés à votre système. Les incidents de sécurité les plus documentés sur les agents en production viennent rarement du modèle lui-même : ils viennent d'un environnement d'exécution mal configuré ou absent.

Trois critères dominent le choix d'un environnement en entreprise : le niveau d'isolation (sandbox), le support multi-agents, et la maturité pour un déploiement en production.

Devin : le pionnier propriétaire

Lancé par Cognition AI en mars 2024, Devin a popularisé l'idée d'un "software engineer autonome". L'agent s'appuie sur une infrastructure cloud propriétaire, avec un sandbox dédié par session, un accès à un navigateur et un terminal, et la capacité de travailler de façon asynchrone sur des tâches longues.

Ce qui le distingue : la persistance de contexte entre sessions. Devin maintient une forme de mémoire de travail sur les projets, ce qui lui permet de reprendre une tâche là où il l'a laissée sans re-contextualisation manuelle.

Ce qui le limite : la boîte noire. L'environnement d'exécution est entièrement géré par Cognition AI, sans accès aux logs internes ni possibilité de personnaliser l'isolation. Pour les équipes qui ont des exigences de conformité strictes sur la localisation des données, c'est un point de blocage.

Coût : environ 500 dollars par mois pour un accès équipe. Pas d'option self-hosted.

OpenHands : le leader open source

Anciennement OpenDevin, OpenHands est aujourd'hui l'un des environnements d'exécution open source les plus visibles et adoptés pour les agents codeurs : plus de 70 000 étoiles sur GitHub et plus de 490 contributeurs actifs selon son dépôt public, licence MIT, et une architecture conçue dès le départ pour la flexibilité.

Le principe est simple : chaque session agent tourne dans un conteneur Docker isolé. L'agent a accès à un terminal, un éditeur, un navigateur et peut appeler n'importe quel LLM via une interface unifiée (Claude, GPT-4o, Gemini, Llama). Le choix du modèle est découplé de l'environnement.

Ce qui le distingue : le contrôle total. Les équipes peuvent auditer le code, personnaliser les permissions par conteneur, intégrer l'environnement dans leur CI/CD via API, et ne dépendent d'aucun fournisseur pour l'exécution. Le coût d'infrastructure se limite aux tokens LLM et au compute conteneur.

Ce qui le limite : la charge opérationnelle. Déployer OpenHands en production demande de gérer l'orchestration des conteneurs, les limites de ressources, la persistance des sessions. Pour une petite équipe sans DevOps dédié, c'est une vraie friction.

L'architecture CodeAct d'OpenHands mérite une mention : plutôt que d'appeler des outils via des fonctions JSON, l'agent génère et exécute du code Python directement pour interagir avec son environnement. Ce choix rend les actions auditables et reproductibles.

Scion : l'approche Google Cloud

Scion est un projet open source de Google Cloud, porté par l'équipe infrastructure agents de Google. Son positionnement est différent des deux précédents : ce n'est pas un agent, c'est un orchestrateur d'agents.

La métaphore utilisée par l'équipe Google est parlante : Scion est un "hyperviseur pour agents". Comme un hyperviseur gère plusieurs machines virtuelles sur un même hôte, Scion gère plusieurs agents dans des conteneurs GCP distincts, avec un protocole de communication standardisé entre eux.

L'environnement est harness-agnostic : Scion ne dicte pas comment l'agent est construit, il fournit le substrat d'exécution et la couche de coordination. Un agent Claude Code, un agent LangGraph et un agent personnalisé peuvent cohabiter dans la même orchestration.

Ce qui le distingue : la vision multi-agents native. Là où Devin et OpenHands sont pensés pour un agent unique par tâche, Scion est conçu pour des workflows où plusieurs agents spécialisés collaborent en parallèle ou en séquence.

Ce qui le limite : le niveau de maturité. Scion est explicitement présenté comme un testbed expérimental. Il n'existe pas de documentation de production stabilisée, et l'API peut évoluer entre versions. À date, Scion convient aux équipes qui expérimentent l'architecture multi-agents, pas à celles qui ont besoin d'un déploiement fiable en semaine.

Comparaison sur cinq dimensions

Quel profil pour quel outil

Devin correspond aux équipes qui veulent une solution clé en main, sans friction de déploiement, et dont les cas d'usage sont des tâches d'ingénierie autonomes bien délimitées (résolution de tickets, génération de PR, maintenance de documentation). La contrepartie est la dépendance complète à Cognition AI et l'impossibilité d'auditer l'exécution.

OpenHands est le choix des équipes techniques qui veulent le contrôle : choix du modèle, audit des actions, intégration dans un pipeline CI existant, conformité sur la localisation des données. La communauté active (contributions quotidiennes sur GitHub) garantit une évolution rapide. C'est l'environnement le plus utilisé en production parmi les trois, avec des déploiements documentés dans des équipes de 5 à 500 ingénieurs.

Scion est à réserver aux équipes qui explorent l'architecture multi-agents et qui ont une appétence pour les technologies Google Cloud. Son intérêt principal en 2026 est expérimental : tester des workflows agents-à-agents avant que les standards du secteur ne se stabilisent.

Une note pratique : OpenHands et Scion ne sont pas mutuellement exclusifs. Plusieurs équipes utilisent OpenHands comme environnement d'exécution pour les agents individuels, et expérimentent Scion comme couche d'orchestration au-dessus. Le harness défini dans l'article du 5 juillet s'applique à chaque agent individuel, indépendamment de l'orchestrateur.

Ce que ça change pour votre roadmap

Le choix de l'environnement d'exécution n'est pas un choix technique isolé. Il conditionne ce que vous pouvez auditer, ce que vous pouvez certifier auprès d'un auditeur réglementaire, et ce que vous pouvez réutiliser quand vous ajoutez un deuxième ou troisième agent.

En 2026, la tendance est claire : les équipes qui ont commencé avec Devin pour sa simplicité migrent progressivement vers OpenHands quand les exigences de conformité ou de coût deviennent contraignantes. Les équipes qui anticipent des architectures multi-agents regardent Scion de près, sans encore le déployer en production.

La question n'est pas quel outil est le meilleur. C'est lequel correspond à l'état actuel de votre équipe et à la maturité agents que vous visez dans 12 mois.

À mettre en route cette semaine

Listez vos cas d'usage agents actuels ou prévus et classez-les selon deux axes : besoin d'audit réglementaire et besoin de multi-agents. Un agent unique sans exigence de conformité stricte peut démarrer sur Devin. Un cas d'usage soumis à audit ou nécessitant l'intégration dans un pipeline CI existant pointe vers OpenHands.

Si vous démarrez sur Devin pour la rapidité de mise en route, documentez dès maintenant le critère qui déclencherait une migration vers OpenHands : seuil de coût mensuel, exigence de localisation des données, ou besoin d'audit des actions de l'agent.

Si vous anticipez des workflows multi-agents dans les 12 prochains mois, testez Scion en environnement de développement dès maintenant, sans attendre sa stabilisation en production. L'objectif est de comprendre le modèle de coordination avant d'en avoir besoin en urgence.

Vérifiez que le harness défini pour vos agents (article du 5 juillet) reste portable d'un environnement d'exécution à l'autre. Un harness trop couplé à l'infrastructure Devin, par exemple, complique une migration future vers OpenHands.

Conclusion

Devin, OpenHands et Scion répondent à trois besoins différents plutôt qu'à trois façons de résoudre le même problème : la rapidité de mise en route sans exigence d'audit pour Devin, le contrôle et la conformité pour OpenHands, l'expérimentation multi-agents pour Scion. Le critère qui décide n'est pas la puissance perçue de l'outil, c'est l'auditabilité dont votre organisation a besoin aujourd'hui et la trajectoire multi-agents que vous anticipez à 12 mois.

Sources : As of July 2026

• [Primary] — OpenHands GitHub Repository (70k+ stars, 490+ contributeurs, MIT license) — GoogleCloudPlatform / All-Hands-AI — 2026 — https://github.com/All-Hands-AI/OpenHands
• [Secondary] — Google Open Sources Experimental Multi-Agent Orchestration Testbed Scion — InfoQ — avril 2026 — https://www.infoq.com/news/2026/04/google-agent-testbed-scion/
• [Primary] — Scion Overview — Google Cloud Platform — 2026 — https://googlecloudplatform.github.io/scion/overview/
• [Secondary] — OpenHands Review 2026: 70K Stars — VibeCoding — 2026 — https://vibecoding.app/blog/openhands-review