L'agence nationale de cybersécurité britannique donne un nom aux trois niveaux de contrôle humain sur les agents IA — et recommande celui qu'AppH applique déjà par défaut
Le 25 août 2026, le National Cyber Security Centre (NCSC) britannique a publié une directive officielle sur la gestion du risque cyber des IA agentiques, distinguant explicitement trois modèles de supervision humaine — « humain dans la boucle » (approbation avant l'action), « humain sur la boucle » (surveillance avec intervention possible) et « humain hors de la boucle » (aucune révision) — et recommandant le premier pour toute application à risque élevé. C'est exactement le modèle qu'AppH applique par défaut à chaque action à conséquence réelle, dans ses huit modules métier, sans qu'aucune réglementation ne l'y ait obligé.
Le 25 août 2026, le NCSC — l'agence gouvernementale britannique de cybersécurité, rattachée au GCHQ — a publié une directive destinée aux organisations qui déploient des agents IA avec un niveau significatif d'autonomie. Le texte fait suite à plusieurs incidents documentés où des modèles et systèmes agentiques ont exécuté des actions non autorisées ou non prévues. La recommandation centrale : évaluer d'abord précisément le niveau d'autonomie réellement nécessaire, puis choisir le modèle de supervision en conséquence. Le NCSC nomme trois modèles distincts, sans ambiguïté : humain dans la boucle (« humans approve actions before they occur » — un humain approuve chaque action avant qu'elle ne se produise), humain sur la boucle (« humans monitor activity and can intervene if necessary » — un humain surveille et peut intervenir si nécessaire), et humain hors de la boucle (l'IA opère sans révision humaine). Pour toute application à risque élevé, l'agence recommande explicitement de maintenir une supervision humaine, d'assigner une responsabilité claire à chaque activité de l'agent, et de garantir qu'un incident puisse être investigué et traité rapidement. La directive couvre aussi le cloisonnement technique (sandboxing), le contrôle des accès réseau et identifiants, la journalisation continue de l'activité des agents, et la capacité de « couper le courant » à tout moment sur un système autonome.
Ce qui distingue cette directive de la plupart des textes déjà cités dans cette page, c'est sa source : ce n'est pas un éditeur logiciel qui vante son propre produit, c'est une agence gouvernementale de cybersécurité qui nomme, en trois catégories précises, ce que la plupart des fournisseurs d'IA laissent flou dans leurs communiqués. Et le modèle que le NCSC recommande pour tout enjeu à risque réel — humain dans la boucle, approbation avant l'action — est très exactement celui qu'AppH applique déjà, par construction, à chaque module métier : un devis généré par une règle d'Automatisations reste à l'état « brouillon » jusqu'à validation d'un humain de l'entreprise ; une réservation soumise via un widget public reste au statut « prévue » jusqu'à revue d'équipe ; un événement d'Automatisations (retard de facture, stock bas, absence répétée d'un professionnel) attend un clic humain avant toute conséquence réelle — jamais un email envoyé seul, jamais un paiement déclenché seul. Ce n'est pas le modèle « humain sur la boucle » — plus faible, où l'action peut déjà avoir eu lieu avant qu'un humain ne la remarque — c'est bien le modèle « humain dans la boucle » que le NCSC place au sommet de sa hiérarchie de risque.
Pour AppH
- Une agence gouvernementale de cybersécurité — pas un fournisseur qui vante son propre produit — nomme désormais « humain dans la boucle » (approbation avant l'action) comme le modèle recommandé pour tout déploiement à risque élevé. C'est précisément l'architecture par défaut qu'AppH applique dans ses huit modules métier, adoptée avant qu'aucun texte officiel ne vienne la valider.
- Le NCSC distingue explicitement « humain dans la boucle » de « humain sur la boucle » (simple surveillance) comme un modèle plus faible — cette distinction donne à AppH un langage concret pour expliquer à un prospect pourquoi une file d'attente d'approbation (devis en brouillon, événements d'Automatisations, réservations « prévues ») est structurellement différente d'un tableau de bord que personne n'a le temps de surveiller en continu.
Contre / la limite honnête
- La directive du NCSC vise d'abord des organisations qui construisent des environnements cloisonnés avec contrôle d'accès réseau, gestion d'identifiants et supervision de sécurité 24/7 — des préoccupations d'infrastructure qui ne se transposent pas telles quelles à la façon dont une PME utilise les modules verticaux d'AppH. Affirmer qu'AppH applique l'intégralité du cadre du NCSC serait inexact.
- Le NCSC qualifie lui-même sa directive de provisoire, appelée à être remplacée par une recommandation plus formelle à mesure que la pratique évolue. La citer comme un standard définitif et figé serait aller au-delà de ce que l'agence affirme elle-même.
Ce qui frappe dans cette directive n'est pas son contenu technique — sandboxing, listes d'accès, journalisation, rien de tout cela ne surprendra un ingénieur sécurité — c'est qu'une agence gouvernementale ait pris la peine de donner un nom précis à une distinction que la plupart des communiqués marketing laissent volontairement floue. La plupart des dirigeants de PME ne liront jamais ce texte du NCSC. Mais la question qu'il permet de poser, eux peuvent et devraient la poser à n'importe quel fournisseur d'agent IA, AppH y compris : lequel des trois modèles appliquez-vous réellement — approbation avant l'action, surveillance après coup, ou aucune revue du tout ? Chez AppH, la réponse n'a jamais dépendu d'un texte réglementaire pour exister : elle est écrite dans le code depuis le premier module, pas dans une politique qu'on pourrait changer discrètement. Accompagner un dirigeant de PME, c'est l'aider à poser cette question précise à chaque outil qu'il évalue — et à se méfier de toute réponse qui reste vague sur laquelle des trois catégories s'applique vraiment.
Vérifié par un humain d'AppH