SolutionsReview le dit sans détour le 3 septembre 2026 : un bouton d'approbation ne suffit pas — ce que le clic d'AppH construit derrière lui
Le 3 septembre 2026, SolutionsReview a publié « Why 'Human-in-the-Loop' Fails Agentic AI, and How to Build Institution-Level Safeguards » : la thèse est directe — un simple bouton « valider » posé devant un agent n'est pas une garantie de sécurité, c'est du théâtre de sécurité, si rien derrière ce clic n'audite, ne limite le périmètre ou ne trace ce qui s'est passé. C'est la première pièce qu'on couvre qui critique le HITL superficiel en tant que tel, plutôt que l'enforcement réglementaire (Uber/CNIL) ou la validation de marché (VentureBeat). L'occasion de montrer, en détail, ce qu'il y a réellement derrière le clic d'approbation d'AppManager.
L'argument de SolutionsReview part d'un constat simple : dans la ruée vers les agents IA en entreprise, « human-in-the-loop » est devenu une case à cocher plutôt qu'une architecture. Un humain qui clique « approuver » sans savoir précisément ce qu'il approuve, sans historique consultable de ce que l'agent a déjà fait, sans limite claire de ce à quoi l'agent peut toucher, ne réduit pas le risque — il donne juste à l'organisation l'impression fausse qu'elle est couverte. La pièce distingue le HITL « théâtre » du HITL « institutionnel » : ce dernier suppose trois piliers qui existent indépendamment du clic lui-même — un journal d'audit qui survit à la décision (pas seulement au moment où elle est prise), un périmètre d'action borné par rôle et par système (l'agent ne peut physiquement pas dépasser certaines limites, humain ou pas), et une traçabilité qui permet de reconstruire après coup pourquoi une action a eu lieu. Sans ces trois piliers, prévient SolutionsReview, le bouton d'approbation est une façade — l'organisation croit avoir un garde-fou, elle a un point de friction cosmétique.
Chez AppH, le clic d'approbation existe depuis le premier module — mais la question honnête que pose cette pièce, c'est : qu'est-ce qui existe AUTOUR de ce clic ? Trois réponses concrètes, pas trois promesses. Premièrement, le clic bloque réellement l'action, il ne se contente pas de la signaler : une facture au-delà du seuil, un remboursement, l'envoi d'une communication externe restent en attente tant qu'un humain n'a pas validé — l'agent ne peut pas « quand même » exécuter si personne ne répond, contrairement à un simple avertissement qu'on peut ignorer. Deuxièmement, chaque décision (approuvée, rejetée, ou l'action automatique qui n'a jamais eu besoin d'approbation) laisse une entrée dans le même journal d'audit que les actions humaines, avec l'identité de qui a approuvé et quand — consultable module par module, pas un fichier de log technique que seul un ingénieur peut lire. Troisièmement, le périmètre de chaque agent est borné à son propre module dès la conception : un agent qui gère la facturation n'a pas accès aux dossiers cliniques, un agent qui répond aux messages n'a pas accès aux virements — ce n'est pas une règle qu'on demande à l'agent de respecter, c'est une frontière que le code ne permet pas de franchir.
Pour AppH
- Les trois piliers que SolutionsReview pose comme définition du HITL « institutionnel » — blocage réel, journal d'audit persistant, périmètre borné par conception — correspondent à ce qu'AppH a construit dès le départ, pas à un chantier de mise en conformité lancé après coup pour répondre à cette pièce.
- Le blocage réel de l'action (pas juste un avertissement ignorable) est la différence la plus concrète entre le HITL « théâtre » que critique SolutionsReview et ce que fait AppH — une facture qui reste bloquée sans validation n'est pas une fonctionnalité qu'on peut contourner par accident.
Contre / la limite honnête
- AppH n'a pas de certification tierce (SOC 2, ISO 27001 ou équivalent) qui validerait ces trois piliers de façon indépendante et publique — la pièce de SolutionsReview s'adresse d'abord à de grandes entreprises qui exigent ce type d'audit externe, un terrain où AppH n'a aujourd'hui que sa propre parole à offrir.
- Le périmètre de ce qui déclenche une approbation obligatoire reste un choix de configuration fait avec chaque client, pas une règle universelle gravée dans le produit — un client qui configure ce seuil trop haut affaiblit le garde-fou sans qu'AppH ne puisse l'en empêcher techniquement.
Ce qui nous a arrêtés dans cette pièce, ce n'est pas la nouveauté du problème — le risque d'un HITL cosmétique est documenté depuis longtemps en sécurité informatique — c'est la précision de la définition qu'elle propose. « Human-in-the-loop » n'est ni bon ni mauvais en soi ; ce qui compte, c'est ce qu'il y a derrière le clic. On aurait pu écrire une pièce qui se contente de dire « nous, on a un bouton d'approbation » — ça n'aurait rien prouvé. La question honnête que pose SolutionsReview, et à laquelle on essaie de répondre ici avec des détails vérifiables plutôt que des adjectifs, c'est : votre clic bloque-t-il vraiment quelque chose, ou est-ce un pas de plus avant que tout continue comme prévu ? Chez AppH, la réponse tient dans le fait qu'une action à conséquence réelle reste réellement en attente jusqu'à ce qu'un humain regarde et décide — pas dans une case cochée quelque part.
Vérifié par un humain d'AppH