- ▸ 10 avril 2026 : un billet relance un débat tranché trop vite
- ▸ Thèse : la séparation est une décision de sécurité
- ▸ L'agent harness : pilier silencieux de la chaîne agentique
- ▸ Deux architectures : à l'intérieur ou à l'extérieur du sandbox
Un billet publié le 10 avril 2026 sur Mendral.com remet une question d’apparence technique au centre du débat IA : où doit tourner la boucle qui pilote un modèle de langage ? Le choix paraît anodin. Il dessine en réalité la frontière entre les credentials de l’utilisateur et le code que l’agent manipule. Les conséquences touchent la sécurité, la flexibilité et la capacité à servir plusieurs utilisateurs à la fois. Trois architectures, trois surfaces d’attaque, trois contraintes — ce dossier les démêle.
Points clés 1. L’agent harness est la boucle qui pilote un LLM ; sa localisation détermine la surface d’attaque du système. 2. Tourner le harness à l’extérieur du sandbox isole les clés API du code en cours d’exécution, selon l’analyse publiée le 10 avril 2026 sur Mendral.com. 3. Les architectures mono-utilisateur (style Claude Code local) et multi-utilisateur ne posent pas les mêmes contraintes de sécurité ni de scalabilité. 4. Les équipes multi-utilisateur héritent de problèmes que les builders mono-utilisateur n’ont jamais à traiter. 5. La flexibilité d’exécution des outils dépend directement de l’emplacement choisi pour la boucle agentique.
10 avril 2026 : un billet relance un débat tranché trop vite
Le 10 avril 2026, l’auteur du blog Mendral.com publie un texte intitulé The Agent Harness Belongs Outside the Sandbox. Le titre n’a rien d’une provocation. Il prend position dans une discussion devenue centrale à mesure que les agents de codage se généralisent : faut-il loger la boucle de contrôle d’un LLM à l’intérieur du conteneur qu’elle manipule, ou la maintenir à l’écart, sur le backend de l’opérateur ?
L’enjeu paraît étroit. Il ne l’est pas. Cette frontière conditionne la circulation des secrets, la capacité du système à servir plusieurs utilisateurs en même temps, et la marge de manœuvre laissée à l’agent pour invoquer des outils. La publication du billet intervient à un moment où les architectures convergent dans deux directions opposées, ce qui rend le choix particulièrement visible.
Thèse : la séparation est une décision de sécurité
L’argument central tient en une phrase. Quand le harness vit dans le même conteneur que le code sur lequel il travaille, tout ce qui transite par lui — clés API, tokens, données utilisateur — devient accessible à du code potentiellement malveillant exécuté dans le sandbox. Sortir le harness du sandbox rétablit un cloisonnement clair : la boucle pilote, le sandbox exécute, et les credentials ne franchissent jamais la frontière.
Cette thèse, défendue dans le billet du 10 avril 2026 sur Mendral.com, a une portée pratique immédiate pour toute équipe qui construit un produit agentique multi-utilisateur. Les enseignements qui suivent en déclinent les conséquences techniques.
L’agent harness : pilier silencieux de la chaîne agentique
Avant de débattre de son emplacement, il faut s’accorder sur ce qu’est un agent harness. Selon la formulation reprise dans le billet de Mendral.com daté du 10 avril 2026, un agent harness est la boucle qui pilote un LLM. Concrètement : un programme qui envoie une requête au modèle, lit la réponse, identifie les outils que le modèle veut invoquer, exécute ces outils, renvoie les résultats au modèle, recommence — jusqu’à ce que la tâche soit terminée.
Cette boucle est l’élément qui transforme un modèle de langage statique en agent. Elle gère le contexte, l’état, la mémoire de la conversation, la liste des outils disponibles, les permissions, parfois la facturation. Elle détient les clés API qui permettent d’appeler le modèle. Elle décide quand interrompre, relancer, ou clore une session. Sans elle, un LLM ne fait rien de plus que répondre à une requête isolée.
Architecture des agents IA : les briques essentielles — l’article de référence sur LagazetteIA détaille les composants standards d’une telle boucle.
Deux architectures : à l’intérieur ou à l’extérieur du sandbox
La question soulevée par le billet du 10 avril 2026 sur Mendral.com tient à la localisation physique de cette boucle. Deux choix dominent le marché.
Option 1 — Le harness vit dans le sandbox
Dans cette première architecture, la boucle vit dans le même conteneur que le code sur lequel elle travaille. Selon la description reprise dans le billet de Mendral.com, the loop lives in the same container as the code it’s working on. C’est un schéma logique : le harness a un accès direct au système de fichiers, peut lancer des commandes shell, lire la sortie sans aller-retour réseau. La latence est minimale. Le code de l’agent et le code utilisateur partagent le même environnement d’exécution.
C’est aussi le modèle implicite quand on lance un outil agentique en local sur sa propre machine. La frontière entre l’agent et le projet sur lequel il travaille est purement logique — il n’y a pas de cloisonnement matériel, pas de séparation réseau, pas d’isolement des secrets.
Option 2 — Le harness vit sur le backend
Dans la seconde architecture, the loop runs on your backend, comme le formule le billet du 10 avril 2026. Le sandbox devient un environnement d’exécution distant que le harness pilote à travers un canal RPC. Le harness reste sur l’infrastructure de l’opérateur. Le sandbox reçoit des instructions atomiques — exécute cette commande, écris ce fichier, lis cette sortie — et renvoie le résultat. Selon la description publiée le 10 avril 2026 sur Mendral.com, the sandbox runs the tool and returns the result.
Le coût est une latence supérieure et une plomberie réseau plus complexe. Le bénéfice est une frontière nette entre la boucle de contrôle et le terrain de jeu. Les credentials de l’utilisateur, les clés du modèle, les tokens d’authentification, n’entrent jamais dans le conteneur où s’exécute le code potentiellement instable ou hostile.
| Critère | Harness dans le sandbox | Harness sur le backend |
|---|---|---|
| Localisation des clés API | dans le conteneur | hors du conteneur |
| Latence d’exécution outil | très faible (in-process) | réseau RPC |
| Surface d’attaque | élevée | réduite |
| Multi-utilisateur natif | non | oui |
| Cas d’usage type | outil local mono-user | service hébergé |
| Exemple courant | exécution locale d’un coding agent | plateforme SaaS agentique |
Les deux choix coexistent aujourd’hui. Mais ils ne s’adressent pas au même type de produit, comme le détaille la suite.
Sécurité et gestion des données : le sandbox comme barrière, pas comme coffre-fort
Le sandbox n’est pas un coffre-fort. C’est une barrière. Sa fonction est d’empêcher le code qu’il exécute d’atteindre le système hôte, le réseau de l’opérateur, ou les données d’autres utilisateurs. Mettre les credentials à l’intérieur de cette barrière revient à confier ses clés au cambrioleur potentiel.
L’argument central du billet du 10 avril 2026 sur Mendral.com tient à cette image : your credentials stay out of the sandbox. Quand la boucle vit hors du conteneur, les clés API du modèle de langage, les tokens d’accès aux outils tiers, les secrets de l’utilisateur, restent côté backend. Le sandbox reçoit uniquement les instructions et les données strictement nécessaires à l’exécution d’une étape. Si un attaquant compromet le code en cours d’analyse — par exemple via une dépendance vérolée, un script malveillant injecté dans un fichier de test, ou une instruction cachée dans un README — il ne peut pas accéder aux secrets parce que ceux-ci ne sont jamais entrés dans son périmètre.
À l’inverse, dans une architecture où le harness vit dans le sandbox, la moindre exfiltration depuis le conteneur emporte potentiellement les clés. Les attaques par injection d’instructions dans des fichiers traités par l’agent — souvent appelées prompt injection dans la littérature, et que l’on peut traduire par injections d’instructions — deviennent un vecteur direct vers les secrets de l’opérateur. Le coût d’un seul incident peut dépasser largement le surcoût d’ingénierie qu’imposerait une architecture séparée.
Sécurité des agents IA : le risque d’injection d’instructions — un article de fond sur ce vecteur d’attaque, à consulter pour le contexte.
Cette logique vaut particulièrement pour tout opérateur qui héberge un service agentique pour des utilisateurs tiers. Les clés API d’OpenAI, d’Anthropic ou de Mistral ne peuvent pas se retrouver à portée du code que les utilisateurs soumettent. La séparation n’est pas un confort. C’est une obligation fonctionnelle, dès lors que l’opérateur n’a pas le contrôle absolu sur la nature du code traité.
Les contraintes des systèmes multi-utilisateurs
Le billet du 10 avril 2026 sur Mendral.com revendique une perspective explicite : we’re in the multi-user camp, which surfaces problems single-user builders don’t hit. La distinction est cruciale pour comprendre pourquoi les avis divergent dans la communauté.
Un builder mono-utilisateur — par exemple un développeur qui assemble un agent pour son propre usage local — n’a pas à se préoccuper de la fuite de clés vers le code analysé. Les clés sont les siennes. Le code aussi. La menace de fuite croisée entre utilisateurs n’existe pas. Loger le harness dans le sandbox simplifie l’architecture, accélère les outils, et n’a pas de coût visible. C’est la trajectoire naturelle d’un outil personnel.
Une plateforme multi-utilisateur hérite de problèmes que ce builder ne rencontre jamais. Les clés API du fournisseur de modèle servent l’ensemble des utilisateurs et ne peuvent pas être exposées à l’un d’entre eux. Les sandboxes doivent être isolés les uns des autres. La gestion d’état doit suivre des sessions parallèles. La facturation doit attribuer correctement la consommation. Le provisionnement de conteneurs à la demande devient un sujet d’infrastructure de premier plan. La latence acceptable est plus élevée parce que le réseau s’intercale partout.
Surtout, la surface d’attaque change de nature. Dans un système mono-utilisateur, l’attaquant et la cible sont confondus : l’utilisateur ne va pas s’auto-attaquer. Dans un système multi-utilisateur, un utilisateur malveillant peut chercher à compromettre les clés de l’opérateur, à accéder aux données d’autres utilisateurs, ou à pivoter vers l’infrastructure de la plateforme. Le sandbox devient une frontière de défense critique, et tout ce qui se trouve à l’intérieur doit être considéré comme potentiellement compromis.
L’impact des choix architecturaux sur la flexibilité d’exécution
Au-delà de la sécurité, la localisation du harness conditionne ce que l’agent peut faire. La règle décrite dans le billet du 10 avril 2026 sur Mendral.com — the sandbox runs the tool and returns the result — implique un découplage qui modifie la conception des outils.
Quand le harness vit hors du sandbox, chaque appel d’outil traverse une frontière. L’instruction part du backend, le sandbox l’exécute, le résultat revient. Cette discipline impose des outils dont l’interface est explicitement déclarée, dont les entrées et les sorties sont sérialisables, et dont les effets de bord sont bornés. Les outils deviennent des fonctions au sens strict : entrée → exécution → sortie. La traçabilité est totale, ce qui facilite l’audit, le rejeu, et la reproduction de bugs.
Quand le harness vit dans le sandbox, la frontière disparaît. Un outil peut consulter le système de fichiers, modifier l’état partagé, manipuler le contexte de l’agent directement. La simplicité de développement est réelle. Le coût est une perte de discipline : il devient difficile de savoir, après coup, quelles données ont transité, quelles modifications ont été apportées, et quels effets de bord ont été déclenchés. Pour un outil personnel, ce n’est pas un drame. Pour un service multi-utilisateur soumis à des exigences de conformité, cela devient un problème opérationnel majeur.
Cette discipline a aussi un effet sur l’extensibilité. Une architecture où le sandbox ne fait qu’exécuter des commandes atomiques se prête bien à l’ajout d’outils tiers, à la délégation à d’autres environnements (par exemple un conteneur dédié à un langage spécifique), ou à la composition entre plusieurs sandboxes. Une architecture où le harness vit dans le sandbox tend à coupler la boucle aux outils disponibles dans cet environnement précis, ce qui réduit la portabilité.
Contexte historique : d’où vient ce débat
Le débat sur la localisation du harness n’est pas neuf, même s’il prend une dimension nouvelle avec la généralisation des agents de codage. Trois étapes l’ont façonné.
Première étape, vers 2023-2024 : les premiers outils agentiques sont quasi-exclusivement mono-utilisateur. Ce sont des CLI installés en local, qui appellent un modèle distant et exécutent des commandes sur la machine de l’utilisateur. Le harness vit là où vit le code. La question de la séparation ne se pose pas, parce qu’il n’y a pas d’opérateur tiers à protéger.
Deuxième étape, fin 2024 et 2025 : les éditeurs de modèles et les startups de tooling commencent à proposer des agents hébergés. Les utilisateurs poussent du code vers une plateforme distante, l’agent travaille dans un sandbox géré par l’éditeur, le résultat revient. La question de l’isolation des credentials émerge mécaniquement, parce que l’opérateur a désormais des secrets à protéger contre les utilisateurs eux-mêmes.
Troisième étape, en cours en 2026 : la diversité des architectures se stabilise autour de deux pôles. D’un côté, les outils locaux qui assument leur position mono-utilisateur — dont Claude Code est l’archétype, comme le mentionne le billet du 10 avril 2026 sur Mendral.com en évoquant son adaptation à l’exécution locale. De l’autre, les plateformes multi-utilisateur qui adoptent l’architecture séparée pour des raisons de sécurité et de scalabilité. Le choix entre les deux n’est plus considéré comme une question de goût mais comme une décision produit qui découle directement de la cible utilisateur.
Cette évolution explique pourquoi le billet du 10 avril 2026 sur Mendral.com prend une position aussi tranchée : pour un opérateur multi-utilisateur, l’option n’est pas une opinion, c’est une contrainte.
Impact terrain : ce que cela change pour les équipes qui construisent des agents
Pour une équipe d’ingénierie qui démarre un produit agentique en 2026, la question doit être posée tôt et de façon explicite. Les implications dépassent le simple choix de hosting.
Côté sécurité, le choix de l’architecture détermine la nature du modèle de menace. Un harness dans le sandbox impose de traiter chaque fichier traité par l’agent comme une source potentielle d’injection d’instructions visant à exfiltrer les secrets. Un harness séparé restreint cette surface aux seules fuites depuis le sandbox vers l’extérieur, qui sont déjà l’objet du durcissement classique des conteneurs. Le coût d’audit, le coût d’assurance, et le coût de réponse à incident varient en conséquence.
Côté coûts d’infrastructure, l’architecture séparée impose une plomberie réseau, un système de provisionnement de sandboxes à la demande, une gestion d’état distribuée. Pour une jeune équipe sans budget infrastructure, c’est un investissement significatif. L’architecture intégrée simplifie le démarrage. Elle devient toutefois un piège si le produit grandit vers le multi-utilisateur sans qu’on ait planifié la migration : refondre la séparation a posteriori, alors que des clients utilisent déjà le service, est rarement indolore.
Côté expérience développeur, les deux architectures n’imposent pas la même discipline. La séparation oblige à concevoir des outils auto-contenus, sérialisables, idempotents quand c’est possible. Cette discipline a un coût initial, mais elle paie à mesure que la suite d’outils s’étoffe : les bugs deviennent plus simples à reproduire, l’audit plus simple à mener, l’intégration de nouveaux outils plus rapide. À l’inverse, un harness intégré laisse les ingénieurs prendre des libertés qui se paient en dette technique.
Côté conformité, enfin, certains secteurs réglementés (santé, finance, défense) ne peuvent tout simplement pas accepter qu’un code utilisateur tourne dans le même périmètre que les credentials d’un opérateur. La séparation n’est alors pas une option mais un prérequis contractuel.
Agents de codage : tour d’horizon des outils en 2026 — pour comparer les architectures retenues par les principaux acteurs.
Perspectives contradictoires : les arguments des défenseurs du harness intégré
L’argument du billet du 10 avril 2026 sur Mendral.com n’est pas universellement partagé. Plusieurs voix défendent l’option intégrée pour des raisons qui méritent d’être prises au sérieux.
Premier argument : la simplicité opérationnelle. Pour un outil mono-utilisateur, qui s’installe en local et tourne sur la machine du développeur, l’architecture séparée n’apporte pas de bénéfice de sécurité réel. L’utilisateur a déjà l’accès complet à sa machine, à ses fichiers, à ses clés. Imposer une plomberie de séparation ne fait qu’alourdir l’installation, allonger les temps de réponse et ajouter une surface de bugs supplémentaire sans réduire la surface d’attaque réelle. C’est précisément l’argument implicite qui justifie qu’un outil comme Claude Code soit conçu pour tourner localement sur la machine de l’utilisateur, comme le mentionne le billet de Mendral.com.
Deuxième argument : la performance. Chaque appel d’outil qui traverse une frontière réseau ajoute une latence de plusieurs dizaines de millisecondes au minimum. Multipliée par les centaines d’appels que peut comporter une session agentique complexe, cette latence se paie en secondes voire en dizaines de secondes par tâche. Pour des usages interactifs, où l’utilisateur attend une réponse, le surcoût n’est pas neutre.
Troisième argument : le coût d’ingénierie initial. Construire une architecture séparée robuste — avec sandboxes provisionnés à la demande, isolation réseau, gestion d’état distribuée, observabilité de bout en bout — représente plusieurs mois-ingénieur. Pour une startup qui doit valider son product-market fit avant tout, c’est un investissement difficile à justifier face à une architecture intégrée qui se met en place en quelques semaines.
Ces arguments sont solides dans leur périmètre. Ils n’invalident pas la thèse du billet du 10 avril 2026 sur Mendral.com, mais ils en délimitent le domaine de validité : la séparation est obligatoire en multi-utilisateur, elle reste une option en mono-utilisateur. Le débat n’oppose pas deux camps qui se disputent le même terrain, il décrit deux architectures adaptées à deux types de produit.
Prospective : vers une convergence ou une bifurcation durable
Plusieurs scénarios sont plausibles pour les prochains mois.
Premier scénario : la convergence vers le modèle séparé. À mesure que les agents quittent le terrain expérimental et entrent en production multi-utilisateur, la pression réglementaire et assurantielle pourrait imposer la séparation comme standard de fait. Les outils mono-utilisateur eux-mêmes pourraient adopter une architecture séparée par défaut, par cohérence avec leur version hébergée et pour faciliter la réutilisation des composants.
Deuxième scénario : la bifurcation durable entre deux écosystèmes. Les outils mono-utilisateur conservent leur architecture intégrée parce qu’elle convient à leur cas d’usage, et les plateformes multi-utilisateur restent sur l’architecture séparée. Les deux mondes coexistent sans converger, chacun optimisé pour son terrain. C’est le scénario le plus probable à court terme, comme le suggère implicitement le billet du 10 avril 2026 sur Mendral.com en revendiquant son appartenance au camp multi-utilisateur sans disqualifier l’autre approche.
Troisième scénario : l’émergence d’architectures hybrides. Certains produits pourraient exposer un harness séparé pour les fonctions sensibles (gestion des credentials, accès aux modèles tiers, journalisation) et un harness intégré pour les fonctions de bas niveau (exécution rapide d’outils sans secret). Le choix architectural deviendrait granulaire, par fonction plutôt que par produit.
Quel que soit le scénario qui s’imposera, le débat ouvert par le billet du 10 avril 2026 sur Mendral.com aura eu le mérite de rendre explicite une décision que beaucoup d’équipes prenaient implicitement, sans en mesurer les conséquences à long terme.
FAQ
Pourquoi l’agent harness ne doit-il pas être à l’intérieur du sandbox ?
Selon le billet publié le 10 avril 2026 sur Mendral.com, héberger la boucle de contrôle dans le sandbox expose les clés API et les tokens d’authentification au code en cours d’exécution. Une injection d’instructions ou une dépendance vérolée peut alors exfiltrer ces secrets. Tourner le harness à l’extérieur, sur le backend de l’opérateur, maintient les credentials hors du périmètre exécutoire et réduit drastiquement la surface d’attaque.
Quels sont les avantages d’une architecture multi-utilisateur ?
Une architecture multi-utilisateur permet de mutualiser les clés API du fournisseur de modèle, d’isoler les sessions des différents utilisateurs entre elles, et d’industrialiser la facturation comme la gestion d’état. Elle impose toutefois des contraintes techniques absentes d’un produit mono-utilisateur : provisionnement de sandboxes à la demande, plomberie RPC, gestion fine des sessions parallèles. C’est précisément ce que pointe le billet du 10 avril 2026 sur Mendral.com.
Une architecture séparée a-t-elle un coût en performance ?
Oui. Chaque appel d’outil qui traverse la frontière entre le harness et le sandbox ajoute une latence réseau de l’ordre de quelques dizaines de millisecondes par étape. Sur une session agentique complexe, le cumul peut représenter plusieurs secondes. Ce surcoût est généralement acceptable pour des plateformes hébergées, mais il explique en partie pourquoi les outils mono-utilisateur installés en local préfèrent l’architecture intégrée.
Quelle architecture choisir pour démarrer un produit agentique en 2026 ?
Le choix dépend du modèle de cible : mono-utilisateur installé en local ou multi-utilisateur hébergé. Selon la position défendue dans le billet du 10 avril 2026 sur Mendral.com, le second cas impose la séparation pour des raisons de sécurité non négociables. Le premier cas peut s’accommoder d’une architecture intégrée, plus simple à construire, à condition d’avoir conscience des limites en cas de bascule ultérieure vers le multi-utilisateur.
Sources
- The Agent Harness Belongs Outside the Sandbox, Mendral.com, 10 avril 2026 — https://www.mendral.com/blog/agent-harness-belongs-outside-sandbox
