Outils pour agents : IDE, boîtes de réception et runtimes se partagent le terrain

Les trois propositions ne visent pas le même acheteur. Hyperlane se présente comme un IDE et un ADE qui exécute des agents IA en parallèle et fusionne leurs worktrees avec des outils natifs. Pizza Bot, publié sur GitHub par pizza-bot-app, est une boîte de réception locale pour agents à exécution longue, construite avec DeepAgents et LangGraph. Soma, documenté sur docs.trysoma.ai, est un runtime d'agents et de workflows open source et auto-hébergeable, livré sous forme d'un binaire unique.

Les trois s'adressent aux développeurs. Aucun n'est un service hébergé au sens où l'entend le cycle d'actualité actuel sur les agents en entreprise.

Ce que chacun revendique réellement

Le README de Pizza Bot est le plus précis des trois. L'outil a été développé chez Amazon et publié sous licence Apache 2.0. Le runtime est une pile avec état DeepAgents et LangGraph qui sert le même front end React dans Electron et dans le navigateur. L'application de bureau, l'application web et le CLI terminal communiquent tous avec un api-server via HTTP et des server-sent events.

Les agents continuent de travailler quand l'utilisateur quitte la page ou se déconnecte, précise le README, et seul le processus api-server doit rester actif. Le travail terminé arrive dans une file Unread et les demandes d'approbation dans Action. Les exécutions sont checkpointées et survivent aux déconnexions du client. Des déclencheurs cron ou webhook peuvent lancer du travail sans conversation ouverte.

Côté modèles, Pizza Bot prend en charge Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter et Ollama. Bedrock accepte un profil AWS, des clés d'accès AWS ou une clé API Bedrock, avec un remplacement de région en option, sinon AWS_REGION ou us-west-2 est utilisé. Le bureau protège les secrets saisis avec Electron safeStorage, et la configuration serveur ne conserve que des références à des variables d'environnement.

L'accès local est opt-in. Les administrateurs ajoutent des dossiers individuels en lecture seule ou inscriptibles dans Settings, Files, et le README indique que Pizza Bot ne reçoit aucun accès par défaut au répertoire personnel. L'api-server écoute sur 127.0.0.1, et une écoute hors loopback exige une authentification. Des installateurs sont joints à chaque release avec un fichier SHA256SUMS. Les builds macOS sont signés et notariés, Windows fournit un exécutable d'installation, et les paquets Linux .deb et .rpm ne sont pas signés.

Soma descend plus bas dans la pile

La documentation de Soma présente le projet comme le bas de la pyramide : des blocs de construction de base plus l'expérience développeur, la logique d'agent restant à la charge de l'utilisateur. Les agents et les fonctions MCP se définissent dans du code ordinaire, avec TypeScript pris en charge et Python annoncé comme à venir. Les utilisateurs peuvent apporter leurs propres frameworks, et la documentation cite LangChain et le Vercel AI SDK en exemple.

Le runtime revendique la tolérance aux pannes et la reprise : une exécution peut planter ou être suspendue à n'importe quel point et reprendre là où elle s'est arrêtée. Il génère aussi des endpoints A2A (Agent2Agent) et annonce des endpoints compatibles avec le streaming OpenAI comme à venir, avec une gestion fine des accès par clé API pour restreindre l'accès à un agent donné.

La gouvernance est le différenciateur sur lequel Soma insiste le plus. La documentation liste un serveur MCP pré-intégré à des fournisseurs SaaS tiers qui gère le chiffrement et la rotation des identifiants, une passerelle IA sortante pour intercepter les requêtes des agents vers les fournisseurs de modèles, et un chiffrement KMS local, AWS ou GCP à venir pour les identifiants MCP, les clés API et les secrets d'agents.

La prise en charge des plateformes est inégale. TypeScript est marqué disponible sur macOS x86 et ARM, Linux GNU x86 et ARM, Windows n'étant pas pris en charge. Python affiche les mêmes quatre plateformes vertes. Rust n'est encore disponible sur aucune plateforme listée, et la documentation attribue cet écart à l'usage par le projet de sockets de domaine Unix en Rust.

Hyperlane vend le worktree

La fiche Hyperlane sur hyperlaneide.com positionne le produit comme un IDE complet qui exécute des agents IA en parallèle et fusionne les worktrees d'agents avec des outils natifs. C'est tout ce que le texte de la page permet d'affirmer de substantiel. Le reste du contenu récupéré relève du bruit de rendu plutôt que d'une documentation lisible.

L'isolation par worktree est la réponse naturelle à un vrai problème : deux agents qui modifient le même dépôt en même temps produisent des conflits difficiles à attribuer. Exécuter chaque agent dans son propre worktree et fusionner les résultats garde la branche principale propre jusqu'à ce qu'un humain décide quoi accepter. C'est une réponse centrée sur le code, et elle suppose que l'acheteur vit déjà dans un IDE.

Pizza Bot adopte la position inverse. Sa métaphore de boîte de réception suppose que l'utilisateur ne veut pas du tout regarder l'agent travailler. Le README propose de lancer ou de planifier une tâche, de partir, et de revenir au travail terminé. Les skills deviennent des sous-agents limités à des outils dont la progression apparaît dans un panneau Activity. Les approbations avec humain dans la boucle, la mémoire à long terme, les pièces jointes et les notifications de bureau sont intégrées au flux de travail.

Soma se situe sous les deux. Peu lui importe qu'un humain regarde, car son rôle est de maintenir l'exécution en vie et observable à travers les plantages, et de garder les identifiants et les appels aux modèles dans une frontière contrôlée.

La question de gouvernance que soulèvent ces outils

L'auto-hébergement est le fil conducteur. Les trois sont positionnés comme des logiciels qu'une organisation exécute sur sa propre infrastructure plutôt qu'un abonnement. Pizza Bot fournit Docker Compose et un Dockerfile. Soma est livré sous forme d'un binaire unique. Artifact Keeper, un autre projet Show HN, tient le même raisonnement pour les registres d'artefacts : un remplacement auto-hébergé de JFrog Artifactory et Sonatype Nexus sans séparation open-core, 45 formats de paquets ou plus, la signature GPG et PGP, l'authentification OIDC, LDAP et SAML 2.0, et le traçage OpenTelemetry. Ce n'est pas un outil d'agents, mais c'est le même acheteur qui fait le même calcul.

Ce calcul est le point où le marché des outils pour agents se fracture actuellement. Le cycle d'actualité autour des agents en entreprise est dominé par les plans de contrôle et la gouvernance des runtimes, mais les artefacts que les développeurs publient réellement sont plus petits et plus tranchés : une boîte de réception, un runtime, un IDE.

Aucun des trois ne publie de chiffres d'adoption. Le README de Pizza Bot liste une architecture et une feuille de route mais aucun nombre d'utilisateurs. La documentation de Soma liste la disponibilité par plateforme sans chiffres de téléchargement. La page d'Hyperlane n'offre aucune métrique dans le texte qui s'affiche. Pour une catégorie que les gros titres environnants valorisent en dizaines de millions de dollars, les preuves publiques ici restent des détails d'ingénierie plutôt qu'une traction.

Il y a aussi une tension non résolue dans la proposition locale. Une boîte de réception qui exécute de longues tâches en arrière-plan n'est utile que si le runtime reste actif, et Pizza Bot le dit exactement : seul le processus api-server doit rester en marche. Un ordinateur portable qui se met en veille, ou une application de bureau qu'on quitte, brise la promesse à moins de déplacer le backend quelque part de persistant. Le même README documente une voie backend autonome pour Electron à distance, les navigateurs, les conteneurs et les services Linux, ce qui est de toute façon la destination de la plupart des déploiements en entreprise.

Les options KMS de Soma pointent vers la même réalité. Le chiffrement local est pratique pour un développeur seul ; AWS KMS, avec GCP annoncé comme à venir, est ce qu'une organisation soumise à une obligation d'audit demandera. L'écart entre la démo et le déploiement est l'endroit où ces projets seront jugés.

Pour l'instant, le signal utile est ce que les auteurs ont choisi de construire en premier. L'un a choisi les worktrees parallèles. L'un a choisi une boîte de réception. L'un a choisi un plan de gouvernance autour d'un binaire unique. Ce sont trois paris différents sur l'endroit où le travail des agents casse réellement, et seul l'usage tranchera lequel avait raison.