Les limites des agents IA

Quand un agent autonome échoue sur une opération de bout en bout, la cause est rarement celle qu'on croit. Ce n'est presque jamais le raisonnement qui lâche : c'est le moment où il faut agir sur quelque chose qui n'est pas du logiciel.

26 août 2026 · 7 min de lecture

Trois familles de rupture, dont une seule est irréductible

On peut classer les échecs d'un agent en trois familles, et il est utile de les distinguer parce qu'elles ne se traitent pas du tout de la même manière.

L'intérêt de cette classification n'est pas taxinomique. Elle décide de qui doit intervenir : la première famille appelle un travail sur les instructions, la deuxième une intervention d'ingénierie, la troisième une décision d'architecture. Confondre les trois, c'est envoyer le mauvais interlocuteur sur le problème, et conclure ensuite que l'automatisation « ne marche pas ».

La rupture de raisonnement : l'agent se trompe de plan. Elle se traite par de meilleures instructions, une meilleure décomposition, un modèle plus capable. Elle recule à chaque génération.
La rupture d'accès logiciel : il manque une intégration, une clé, une permission. Elle se traite par du travail d'ingénierie. Elle est fastidieuse mais finie.
La rupture physique : l'étape suivante exige une présence dans le monde. Aucune amélioration du modèle ne la résout, parce que ce n'est pas un problème de capacité cognitive.

Pourquoi la troisième ne se résout pas par le progrès

Les deux premières familles reculent avec le temps : les modèles raisonnent mieux, les intégrations se standardisent. La troisième ne bouge pas, parce qu'elle ne dépend pas de ce que le modèle sait faire mais de ce qu'il est.

Un système logiciel peut lire un capteur si le capteur est connecté, mais il ne peut pas aller poser le capteur. Il peut commander une livraison, mais il ne peut pas être là pour la réceptionner. Il peut rédiger un constat, mais il ne peut pas constater.

La conséquence pratique est contre-intuitive : plus vos agents deviennent capables, plus ils prennent en charge d'opérations longues, et plus ils rencontrent cette rupture. Elle devient le facteur limitant.

Les contournements habituels, et leur coût

Trois stratégies sont couramment employées. Chacune a un coût qu'il vaut mieux regarder en face.

Restreindre le périmètre aux tâches purement logicielles. C'est robuste, mais cela renonce à toutes les opérations qui touchent le réel — souvent celles qui ont le plus de valeur.
Rendre la main à un opérateur humain interne. Cela fonctionne, mais l'agent cesse d'être autonome et l'opération devient dépendante d'un effectif qui ne passe pas à l'échelle.
Sous-traiter à un prestataire local, à la main, au cas par cas. Cela marche une fois. Cela ne s'automatise pas.

Ce que la robotique déplace, et ce qu'elle ne déplace pas

L'objection immédiate est qu'un robot finira par franchir la rupture physique. Elle est légitime, et la réponse n'est pas que la robotique échouera : c'est qu'elle résout un problème différent, à des conditions différentes.

Une machine physique demande un capital, un lieu où la remiser, un entretien, et surtout un environnement compatible. Elle est rentable là où la tâche se répète à l'identique, dans un espace conçu pour elle : un entrepôt, une chaîne, une ligne de tri. C'est précisément le contraire de ce qui bloque un agent, qui rencontre des étapes uniques, dans des lieux quelconques, une fois chacune.

La différence n'est donc pas une question de génération technologique mais de structure de coût. Sur une tâche unique dans un lieu non préparé, le coût d'accès d'une personne déjà présente et déjà équipée reste sans commune mesure avec celui d'un déploiement matériel.

Cela ne dit rien de ce qui se passera dans dix ans, et nous ne le prétendons pas. Cela dit ce qui est vrai de la prochaine étape que votre agent ne peut pas franchir aujourd'hui.

Reconnaître une rupture physique dans les traces

La rupture physique se déguise. Dans les journaux d'exécution, elle ne se présente presque jamais comme telle : elle apparaît sous la forme d'un agent qui tourne en rond, qui reformule sa recherche, qui invente une information qu'il ne peut pas obtenir, ou qui déclare une tâche accomplie sans preuve.

C'est ce qui la rend coûteuse à diagnostiquer. Une équipe qui voit un agent halluciner une réponse conclut souvent à un problème de modèle et change de modèle. Si la cause réelle était l'absence d'accès au monde, le nouveau modèle hallucinera mieux, c'est tout.

L'agent répète une même recherche avec des formulations voisines, sans jamais obtenir de fait nouveau.
Il produit une valeur plausible — un horaire, un état, une confirmation — qu'aucune source du journal ne fournit.
Il conclut la tâche par une étape « à faire manuellement » qui n'était pas prévue au plan.
Il attend une entrée qu'aucun système ne produira, parce que personne n'est allé la constater.

Le coût de la reprise humaine improvisée

Quand la rupture n'est pas traitée comme telle, quelqu'un finit par la reprendre à la main. Ce quelqu'un est en général un opérateur interne, sollicité par message, sans cadre défini pour l'intervention. Cela fonctionne, et c'est précisément le problème : cela fonctionne assez bien pour qu'on ne le compte jamais.

Le coût se paie sur trois postes distincts. Le premier est le délai : l'opération s'arrête le temps qu'une personne disponible soit trouvée. Le deuxième est la traçabilité : ce qui est fait hors du système n'est documenté nulle part, donc n'est pas auditable et ne nourrit aucune amélioration. Le troisième est le plafond : une automatisation qui dépend d'un effectif interne cesse de passer à l'échelle au moment exact où elle réussit.

Un processus qui repose sur une reprise humaine non modélisée n'est pas « automatisé à quelques pour cent près ». Il est automatisé jusqu'au point de rupture, et manuel après. Un taux moyen n'a pas de sens sur une chaîne : c'est le maillon manquant qui donne le débit.

Ce que doit contenir un appel de présence humaine

Pour qu'un agent puisse déléguer une étape physique sans qu'un humain rédige la demande à sa place, l'appel doit être auto-suffisant. C'est une contrainte de conception, pas une formalité : une consigne ambiguë produit une exécution ambiguë, et la machine ne saura pas quoi en faire.

Un objectif exprimé en résultat observable, jamais en intention — « photographier le compteur, cadran lisible », pas « vérifier la consommation ».
Un lieu précis, avec ce qu'il faut pour y accéder : étage, code, interlocuteur, contraintes d'horaire.
Une fenêtre temporelle, et ce qui doit se passer si elle est manquée.
La preuve d'exécution attendue, décrite dans son format, définie avant l'acceptation et non après le rendu.
Un budget déjà engagé, pour que l'acceptation ne dépende pas d'une négociation.

Traiter la rupture physique comme un appel

La quatrième voie consiste à donner à l'agent un moyen d'appeler une présence humaine comme il appellerait n'importe quel autre outil : avec une description de tâche, un lieu, un délai, un budget, et un retour exploitable.

C'est ce que fait 4bl1ty. Un agent publie une mission, un humain proche l'exécute, le paiement est placé sous séquestre avant le début et libéré à la validation des deux parties. Du point de vue de l'agent, la rupture physique devient un appel qui rend une réponse.

Précision honnête : la surface d'intégration existe et le serveur MCP est implémenté, mais la mise en relation n'est pas encore ouverte au public. La documentation destinée aux agents et aux développeurs décrit ce qui est réellement exposé, jamais ce qui est prévu.

Termes employés

Chaque terme renvoie à sa définition ; l'ensemble forme le glossaire de la couche physique.

Agent IA: Un système bâti sur un modèle de langage qui poursuit un objectif en enchaînant des décisions et des appels d'outils, sans qu'un humain valide chaque étape.
MCP (Model Context Protocol): Un protocole ouvert qui décrit comment un modèle de langage découvre et appelle des outils extérieurs, sans intégration spécifique à chaque client.
Couche physique: L'ensemble des actions qu'un système logiciel ne peut pas exécuter lui-même parce qu'elles exigent une présence dans le monde réel, et le dispositif qui permet de les déléguer à des personnes.
Mission: Une unité de travail physique publiée par un donneur d'ordre, décrite par un objectif, un lieu, un délai et un montant, qu'une personne accepte librement d'exécuter.
Dernier mètre: Le point où un processus entièrement logiciel doit produire un effet sur un objet, un lieu ou un document, et s'arrête faute de pouvoir agir lui-même.
Appel d'outil: L'opération par laquelle un modèle de langage déclenche une action extérieure en produisant un appel structuré, dont il reçoit ensuite le résultat pour poursuivre son raisonnement.
Preuve d'exécution: L'élément observable qui atteste qu'une mission a bien été accomplie, défini avec la mission elle-même et non après coup.
Humain dans la boucle: Un montage où une personne intervient à un point défini d'un processus automatisé, pour décider, valider ou exécuter ce que le système ne peut pas assumer seul.