Un agent d'IA peut « réussir » sa tâche et produire quand même le mauvais résultat — la supervision classique ne le voit pas
Publié le 7 septembre 2026 par Callum Turner sur TheNextWeb (« AI agent reliability requires a new model of observability »), l'article rapporte les propos de Robert Hommes, fondateur de la startup d'observabilité Moyai : un agent peut faire une requête valide, recevoir une réponse valide, et produire malgré tout la mauvaise décision métier — l'infrastructure technique enregistre un succès pendant que l'entreprise subit un échec, un angle mort que les outils de supervision classiques, conçus pour des systèmes déterministes et des codes d'erreur connus, ne savent tout simplement pas voir.
Le point de départ de Hommes est concret, pas théorique : « Le cas le plus dangereux est un agent d'IA qui accomplit une tâche avec succès tout en produisant en réalité le mauvais résultat. » Il prend l'exemple d'un agent d'approvisionnement chargé d'acheter un type précis de grain de café — la requête part, la réponse revient, la tâche se ferme comme réussie, mais « du point de vue de l'entreprise, l'agent produit régulièrement le mauvais résultat ». Même logique dans l'exemple d'une compagnie aérienne cité dans l'article : un agent annonce à un passager que son vol a été re-réservé, la réservation sous-jacente n'aboutit en réalité jamais, et le passager ne le découvre qu'en arrivant à l'aéroport. « Nous n'avons pas de code d'erreur qui dise : "j'ai atteint le endpoint, je l'ai interrogé avec le mauvais paramètre, et j'ai reçu autre chose que ce dont j'avais besoin." Techniquement, rien n'échoue, mais ça ne fonctionne pas », résume Hommes — un code 200 peut donc masquer une décision invalide aussi bien qu'une décision correcte.
Le point le plus utile de l'article, pour nous, n'est pas la description du problème — c'est la limite honnête que Hommes pointe dans sa propre piste de solution. Il reconnaît la valeur des architectures human-in-the-loop, qui obligent un salarié à approuver une action aux conséquences réelles — exactement le principe sur lequel AppManager est construit depuis son premier module. Mais il ajoute une nuance qu'on ne peut pas ignorer : « Une fois que vous avez un impact matériel, vous le voyez, mais il est déjà trop tard [...] il a fallu que ça empire avant que vous ne le remarquiez. » Sa proposition — détecter d'abord ce qui est différent du comportement habituel, puis vérifier si c'est réellement un problème, plutôt que d'empiler une règle pour chaque nouvel échec déjà observé (ce qu'il appelle du « whack-a-mole ») — s'attaque à un problème distinct et plus difficile que la seule approbation humaine d'une action identifiée comme risquée.
Pour AppH
- L'article donne un nom précis à un principe qu'AppH applique déjà sans le nommer ainsi : un déroulement technique sans erreur ne garantit pas un résultat métier correct — c'est pour ça qu'une automatisation AppManager n'est jamais close sur elle-même, un humain confirme le résultat réel, pas seulement l'absence d'exception.
- Le clic d'approbation obligatoire d'AppManager avant toute action aux conséquences réelles est exactement le type d'architecture human-in-the-loop que Hommes cite comme une protection réelle et utile — validé ici par un expert du secteur qui n'a aucun lien avec AppH.
Contre / la limite honnête
- La propre critique de Hommes sur le human-in-the-loop s'applique en partie à AppH aussi : un écran d'approbation ne vaut que ce que vaut le résumé qu'une automatisation affiche avant le clic — AppH n'a pas aujourd'hui de couche dédiée de détection d'anomalies comportementales comme celle que Moyai propose, seulement une supervision humaine explicite sur les actions qu'on a nous-mêmes définies comme consequentes.
- Robert Hommes est fondateur de Moyai, une startup qui vend précisément la catégorie de produit d'observabilité qu'il décrit comme manquante — un argument crédible et bien sourcé, mais aussi celui d'un fondateur qui explique pourquoi le marché a besoin de ce que son entreprise vend.
Ce qui nous a arrêtés dans cette pièce, ce n'est pas la mise en garde générale sur les agents d'IA — on en lit beaucoup — c'est la phrase sur le code 200. Un système qui répond correctement à une requête mal posée ne signale rien d'anormal à qui le surveille de la manière classique. C'est exactement pour ça que, chez AppH, on n'accepte jamais qu'une automatisation se ferme sur elle-même sans un humain qui confirme le résultat réel. Cela dit, Hommes a raison de pointer que l'approbation humaine seule a sa propre limite — elle protège l'action qu'on a pensé à faire approuver, pas celle qu'on n'a pas identifiée comme risquée à temps. On ne prétend pas avoir résolu ce point : AppH n'a pas aujourd'hui de détection d'anomalies comportementales comme celle que Hommes décrit, seulement une supervision humaine explicite sur ce qu'on a nous-mêmes défini comme une action consequente. Le dire clairement nous semble plus utile que de laisser croire que le clic d'approbation règle tout, à lui seul, pour toujours.
Vérifié par un humain d'AppH