Agent IA autonome ou simple wrapper : la différence est architecturale
Tous les produits IA appellent les mêmes modèles. Ce qui sépare celui qui termine le travail de celui qui en parle, c'est le harnais autour du modèle.
Publié le 2026-08-02
Tout le monde loue le même moteur
Il existe peut-être cinq modèles de pointe sur lesquels construire un produit, et chaque éditeur d'IA que vous évaluez en appelle un par API. Celui qui fait la démo impressionnante n'a pas de modèle secret. Il loue le même que celui qui fait la démo décevante.
Donc quand deux produits IA se comportent radicalement différemment sur la même tâche, le modèle n'explique presque rien de l'écart. Ce qui l'explique, c'est le logiciel autour du modèle : combien de fois il a le droit d'agir, ce qu'il a le droit de toucher, ce qu'il retient, et ce qui se passe quand l'étape 3 échoue.
Ce logiciel a un nom : le harnais. C'est lui, le vrai produit. Le modèle en est un composant, comme une base de données est un composant de votre CRM.
Un wrapper, c'est quoi exactement
Ce n'est pas une insulte, c'est une description :
- Prendre le message de l'utilisateur.
- Ajouter un prompt système devant.
- Appeler un modèle, une fois.
- Poster la réponse à un endroit fixe — une bulle de chat, un brouillon d'e-mail, un message Slack.
Un appel en entrée, une réponse en sortie. Rien ne persiste d'une exécution à l'autre. Il ne peut rien ouvrir qu'on ne lui a pas donné, rien exécuter, et surtout pas vérifier si ce qu'il vient de produire est vrai.
Pour toute une catégorie de tâches, c'est la bonne ingénierie. Résumer ceci. Traduire cela. Répondre à une question de support à partir d'une base de connaissances. Rédiger un brouillon. Si la tâche tient vraiment en une étape et que l'information tient vraiment dans le message, un harnais est du gaspillage : le wrapper gagne sur le coût et sur la latence.
Le problème n'est pas que les wrappers existent. C'est qu'aucun process d'entreprise ne tient en une étape, et qu'on les vend comme si tous y tenaient. C'est ce décalage qui explique pourquoi ajouter des outils IA a rendu votre équipe plus occupée.
Le calcul qui ne figure sur aucune page de tarifs
Prenez une tâche en plusieurs étapes, et supposez que le modèle réussit chaque étape prise isolément 9 fois sur 10 — un chiffre généreux dès qu'il s'agit de vos données.
En un seul coup, les étapes se multiplient :
Étapes dans la tâche — Probabilité que l'ensemble soit juste
3 — 73%
5 — 59%
10 — 35%
20 — 12%
Ce n'est pas une critique du modèle. C'est une multiplication. Et c'est pour ça que les démos d'IA ressemblent à de la magie pendant que l'IA en production paraît instable : une démo tient en une étape, votre mardi non.
Les échecs sont en plus silencieux. Un wrapper qui s'est trompé à l'étape 4 ne s'arrête pas. Il rédige les étapes suivantes avec la même assurance, et vous le découvrez vendredi.
La seule sortie, c'est d'arrêter de multiplier : vérifier chaque étape contre la réalité avant de prendre la suivante. Un appel API unique, par construction, ne peut pas faire ça.
La boucle
Un harnais fait tourner le modèle en boucle : proposer une action, l'exécuter pour de vrai, lire ce qui revient, décider de la suivante.
Ça paraît banal. C'est toute la différence, parce que ça remplace la prédiction par l'observation. Au lieu de prédire ce que l'export contient probablement, l'employé l'ouvre et le lit. Au lieu de supposer que la mise à jour est passée, il vérifie. Le jour où une colonne de votre CSV est renommée, un wrapper produit une magnifique synthèse des mauvais chiffres ; un employé en boucle le remarque, s'adapte, termine, et vous dit ce qu'il a changé.
Les erreurs cessent de se composer et commencent à être rattrapées. Tout est là.
Ce que le harnais ajoute par-dessus
La boucle est la fondation. Tout ce qui a une valeur commerciale se construit dessus.
Les outils : le déterministe fait par du code déterministe. L'employé ne se souvient pas du fichier, il l'ouvre. N'estime pas le total, il le calcule. Ne suppose pas que la facture est payée, il interroge. Chaque étape confiée à du vrai logiciel est une étape qu'il ne peut pas halluciner — et son intelligence est dépensée sur le jugement plutôt que sur la mémoire.
La gestion du contexte. Une grande fenêtre de contexte est une ressource, pas une solution : ce qui compte, c'est ce qu'on y met. Le harnais décide — charger ce fichier maintenant, chercher plutôt que tout aspirer, compresser le début d'une longue tâche pour que la partie utile reste nette. Deux produits sur le même modèle, l'un chargeant les 5 000 bons mots et l'autre 100 000 mauvais, ne rendent pas le même service.
Une mémoire qui survit à la session. Le modèle ne retient rien d'un appel à l'autre. La persistance est une fonction du harnais, et elle s'écrit en fichiers : qui est l'employé, qui vous êtes, comment votre entreprise fait cette chose-là précisément. SOUL.md, USER.md et AGENTS.md, c'est notre version.
La délégation. Une grosse tâche se découpe entre des sous-agents qui travaillent chacun dans leur propre contexte et ne rendent qu'une conclusion. Ce n'est pas qu'une question de vitesse : une recherche qui aurait noyé le contexte principal sous deux cents pages en rend une demi-page, et l'employé finit le travail avec les idées encore claires.
La vérification. Le harnais peut donner au modèle un oracle : un test qui passe ou qui échoue, un schéma, un total qui doit tomber juste. Un employé capable de contrôler sa propre sortie a le droit de se tromper en privé et de corriger avant que vous ne voyiez quoi que ce soit. C'est ça, la fiabilité en pratique — personne n'a raison du premier jet.
Les permissions et la piste d'audit. Tout ce qui peut agir peut mal agir : un harnais livre donc les freins avec le moteur. Ce qui exige une validation, ce qui est interdit, un arrêt d'urgence, et un journal de chaque action. Les garde-fous sont précisément ce qui rend l'autonomie possible — personne ne laisse tourner un système sans surveillance sur ses données de production sans ça. Voici comment le nôtre fonctionne.
Six questions qui révèlent ce que vous achetez
Toutes les plaquettes disent « agent IA autonome ». Ces questions-là se moquent de la plaquette :
- Peut-il ouvrir un document que je n'ai pas collé dans le chat ?
- Peut-il exécuter quelque chose — un script, une requête, un calcul — et se servir du résultat ?
- Montrez-moi ce qui se passe à l'étape 3 quand l'export revient vide.
- Sait-il ce qu'il a fait mardi dernier, et où est-ce écrit ?
- Puis-je ajouter une procédure que vous n'avez jamais vue, sans attendre votre prochaine version ?
- Où est le journal de ce qu'il a réellement fait, action par action ?
Un wrapper répond non aux deux premières, et à la troisième par un paragraphe sur la puissance du modèle sous-jacent. C'est le signe qui ne trompe pas : quand un produit ne peut pas vous montrer un échec, c'est en général que l'échec n'est pas un état qu'il connaît. Il renvoie du texte, puis s'arrête.
Les limites, honnêtement
Un harnais n'est pas gratuit, et prétendre le contraire est le meilleur moyen d'être déçu deux fois.
Il coûte plus cher par tâche, parce qu'un travail, c'est beaucoup d'appels au modèle au lieu d'un seul. Il est plus lent, parce qu'une boucle qui vérifie son travail prend plus de temps qu'une qui ne le fait pas. Il exige des garde-fous, et les garde-fous sont du travail. Et il exige que la procédure soit écrite : un harnais sans rien de spécifique dedans n'est qu'un wrapper cher, puisqu'une boucle n'aide que s'il y a un vrai objectif vers lequel itérer.
C'est pour ça que la mise en place prend une semaine ou deux et pas un après-midi. Et c'est pour ça qu'un catalogue figé de neuf agents est le bon achat pour un process réellement standard. Si la tâche tient vraiment en une étape, achetez le produit à une étape.
Ce qu'on fait tourner
Les employés OpenLabor tournent sur un harnais agentique. Chacun a un espace de travail qu'il lit et écrit, un shell qu'il peut exécuter, des connecteurs vers vos outils, des skills que vous définissez pour les procédures qui n'existent nulle part ailleurs, des fichiers d'organisation que chaque employé lit avant d'agir, et un journal par employé de chaque action.
On a changé le modèle en dessous plus d'une fois. Les employés ont continué à faire leur travail, parce que le modèle n'a jamais été le produit. C'est la même raison pour laquelle « faites votre propre GPT personnalisé » cale au stade de la démo : le prompt non plus n'a jamais été la partie difficile.
La question à poser à un éditeur
Pas « quel modèle utilisez-vous ».
« Combien de fois votre modèle a-t-il le droit de se tromper avant que je voie la réponse ? »
La réponse d'un wrapper est zéro. Un seul coup, et ce qui sort est ce que vous obtenez. La réponse d'un harnais, c'est autant de fois qu'il le faut, en privé, jusqu'à ce que le travail soit réellement fait.
Accédez à votre espace, ou réservez un appel et décrivez le process qui ne tient jamais en une étape.
Tous les articles du blog OpenLabor