Lorsqu’un pilote d’agents n’atteint pas la production, la cause est rarement le modèle. C’est le harness : la couche d’encadrement qui entoure le modèle et détermine quels outils il peut utiliser, avec quelles permissions, ce qu’il retient d’une étape à l’autre, ce qui se passe en cas d’échec et combien il peut dépenser avant que quelqu’un ne l’arrête.
Le modèle est un composant que l’on peut remplacer en un après-midi. Le harness, c’est le produit.
Ce que contient un harness
La définition des outils. Chaque action que l’agent peut exécuter — interroger l’ERP, créer une commande, envoyer un e-mail — est décrite avec précision : ce qu’elle fait, quels paramètres elle accepte, ce qu’elle renvoie et quels effets elle produit. Une description ambiguë donne un agent qui utilise le mauvais outil, et avec assurance.
Les permissions et le périmètre. Lecture et écriture séparées, identifiants limités au strict nécessaire et liste explicite de ce que l’agent ne peut pas toucher. Le principe est le même que pour tout nouveau collaborateur : accès au système, oui ; accès à tout le système, non.
La mémoire et le contexte. Ce qui est transmis au modèle à chaque étape, ce qui est résumé, ce qui est conservé d’une exécution à l’autre et ce qui est écarté. Un agent qui traîne tout l’historique devient coûteux et confus ; un agent qui ne retient rien refait le travail et perd le fil.
Les relances et la reprise. Ce qui se passe quand un outil renvoie une erreur, quand le modèle produit une réponse inexploitable ou quand un appel externe échoue : nouvelle tentative avec délai croissant, chemin alternatif ou transmission à une personne.
Les points de validation humaine. Les actions irréversibles — payer, supprimer, communiquer avec un client — s’arrêtent et attendent une confirmation. Le reste s’enchaîne. Bien tracer cette frontière est une décision métier, pas technique.
Les plafonds de dépenses et d’étapes. Un plafond par exécution et un autre par jour. Sans eux, une boucle que personne n’avait prévue consomme le budget d’un trimestre en une nuit.
Les traces. Chaque exécution consigne ce que l’agent a décidé, avec quelles informations et pour quel résultat. Sans traces, pas de débogage possible ni de défense en cas d’audit.
Pourquoi tout se joue dans le harness
Un agent sans harness fonctionne en démonstration parce que la démonstration est menée par celui qui l’a construit. En production, il rencontre des données de mauvaise qualité, des systèmes qui répondent lentement, des cas que personne n’avait envisagés et des utilisateurs aux demandes inattendues. Tout cela, soit le harness l’absorbe, soit personne ne l’absorbe.
C’est aussi ce qui permet de changer de modèle sans refaire le projet. Avec une architecture bien construite, remplacer le modèle sous-jacent se résume à une ligne de configuration et à une campagne d’évaluation ; sans elle, il faut repartir de zéro.
Quand investir dans un harness propre, et quand ne pas le faire
C’est pertinent lorsque :
- L’agent doit exécuter des actions réelles sur les systèmes de l’entreprise, et pas seulement rédiger du texte
- Plusieurs cas d’usage sont prévus : le harness est rentabilisé dès le deuxième agent
- Le processus touche des données sensibles ou des décisions aux conséquences financières
- L’entreprise veut garder la liberté de changer de fournisseur de modèle
Ce n’est pas pertinent lorsque :
- Le cas d’usage se règle avec une automatisation classique ou un flux n8n
- Il s’agit d’une preuve de concept destinée à décider s’il vaut la peine de continuer : on valide d’abord la valeur, on industrialise ensuite
- Personne ne pourra maintenir le système par la suite : un harness sans responsable se dégrade en quelques mois
Notre approche
Nous commençons par l’inventaire des actions que l’agent devra exécuter et par la frontière de risque : ce qu’il peut faire seul et ce qui exige une validation humaine. Nous définissons à partir de là l’ensemble des outils, les permissions, les plafonds de dépenses et le protocole de gestion des erreurs. L’évaluation est mise en place avant l’agent, pas après : sans moyen de mesurer s’il fonctionne, impossible de savoir si une modification améliore ou dégrade les choses.
En tant que laboratoire indépendant, nous ne revendons pas de plateformes d’agents. Si le cas se règle avec un outil du marché, nous le disons.
Questions fréquentes
Un harness est-il la même chose qu’un framework d’agents ? Non. Un framework fournit des briques ; le harness est la manière de les assembler pour un cas précis : quels outils existent, quelles permissions ils ont, où l’agent s’arrête et combien il peut dépenser. Il peut se construire sur un framework ou sans.
Peut-on le réutiliser d’un agent à l’autre ? C’est tout l’intérêt. Le coût élevé est celui du premier ; dès le deuxième agent, on réutilise les outils, les permissions, les traces et les plafonds.
Quel surcoût représente-t-il pour le projet ? Il représente l’essentiel du travail réel d’un projet d’agents. Le présenter comme une option facultative est précisément ce qui conduit aux pilotes qui ne dépassent jamais le stade de la démonstration.