Human-on-the-loop

Ce que ça veut dire

Human-on-the-loop décrit la répartition du travail entre un agent et une personne. L'agent assure l'ampleur — explorer la surface d'attaque, muter des paramètres, rejouer des flux, valider ce qui est exploitable — et un chercheur prend les décisions qui exigent une responsabilité humaine avant que l'exécution n'aille plus loin.

Il faut le distinguer de deux voisins. Le human-in-the-loop place une personne sur le chemin de chaque étape, ce qui ne passe pas à l'échelle. L'autonomie totale retire la personne, ce qui n'est pas sûr sur les systèmes qui comptent. Le « on-the-loop » se situe entre les deux : l'agent tourne en continu, et l'humain est présent aux décisions qui requièrent un humain, pas à chaque frappe.

Pourquoi l'automatisation a stagné

Durant l'essentiel de son histoire, le pentest a été défini par des chercheurs individuels. Les failles difficiles — l'IDOR enfoui à trois workflows de profondeur, le contournement d'authentification qui n'apparaît qu'après une séquence précise de requêtes, la condition de course qui exige un timing précis — viennent de gens qui raisonnent sur la façon dont une application se comporte, pas seulement sur les entrées qu'elle accepte.

La plupart des outils ont traité l'automatisation comme un multiplicateur de techniques connues : on lui donne une cible, il lance ses vérifications, il rend un rapport. Parfait pour la couverture de surface — brute-force de répertoires, vérifications de CVE connues, analyse d'en-têtes — et inutile pour le travail qui compte. Les scanners ne raisonnent pas sur les frontières de confiance ni sur les comportements chaînés entre workflows ; ils trouvent ce qu'on leur dit de trouver. Le modèle n'a jamais changé : le chercheur faisait tout le raisonnement, et l'outil ne faisait qu'exécuter des instructions.

Une autre répartition du travail

Un agent n'est pas un scanner mieux emballé. La différence qui compte, c'est qu'il interagit avec une application comme le fait un chercheur — en l'explorant, en observant ses réponses, et en s'ajustant selon ce qu'il trouve. Il peut rejouer des flux authentifiés, muter des entrées systématiquement et tester des variations entre endpoints, et, quand l'application change après un déploiement, revisiter ces chemins de lui-même.

Surtout, il peut valider les failles, pas seulement les signaler, et il conserve la trace d'exécution complète : quels endpoints ont été touchés, comment les entrées ont été modifiées, quelle condition a fait surgir un signal. Le travail du chercheur cesse donc d'être « refaire le travail de l'agent pour le confirmer ». La preuve est déjà là, à inspecter. Son travail devient les décisions : quels chemins valent la peine d'être poursuivis, et quelles actions sont autorisées à continuer.

Pourquoi l'humain le rend déployable

Garder une personne dans la boucle n'est pas de la nostalgie, c'est ce que la sécurité offensive pleinement autonome ne peut faire sans danger. Un outil qui exécute sans supervision crée un risque concret : des actions qui dépassent les règles d'engagement, des failles qu'on ne peut rattacher à une décision claire, des pistes d'audit qui ne tiennent pas là où on les examine. Sur un système de production, « c'est l'agent qui l'a fait » n'est pas une réponse acceptable.

Le human-on-the-loop n'est donc pas une faiblesse du modèle, c'est ce qui permet de le faire tourner tout court. Quand un agent atteint un garde-fou — pour protéger la stabilité, rester dans le périmètre ou satisfaire une exigence de conformité — il fait remonter la décision à une personne, qui décide de la suite. Cette responsabilité est délibérée. C'est la ligne entre un système auquel une organisation peut vraiment se fier et un système auquel elle ne le peut pas.

Des garde-fous plus fins, pas moins nombreux

À mesure que les agents s'améliorent et que les limites s'affinent à l'usage, les moments qui exigent un humain deviennent plus rares et plus précis. C'est la trajectoire honnête, et il faut en parler avec soin : les garde-fous ne disparaissent pas. Ils s'améliorent. Moins d'interruptions parce que l'agent a appris où sont les vraies décisions, non parce que les décisions auraient cessé de compter.

Il y a aussi un effet cumulatif. À mesure que le chercheur dirige l'investigation et confirme ce qui est pertinent, la couverture continue se met à refléter ce jugement accumulé, plutôt qu'un playbook générique lancé selon un calendrier. L'humain ne relit pas la sortie après coup ; il façonne la direction du test.

Ce que cela change pour le chercheur

Le rôle du pentesteur ne disparaît pas, il évolue. Les chercheurs deviennent la couche de responsabilité qui fixe jusqu'où les agents peuvent aller : non pas diriger chaque action, mais débloquer celles qui exigent d'abord une décision humaine. Moins de temps à redécouvrir la même surface ; davantage au jugement, à la validation et aux décisions qui doivent être assumées par une personne.

C'est tout le propos, et il est modeste. Pour qui accepte de travailler ainsi, ce n'est pas une perte de métier, c'est un déplacement de là où le métier s'exerce — loin de l'ampleur répétitive qu'une machine gère bien, vers le raisonnement et la responsabilité qu'une machine ne devrait pas assumer.

CyberStrike est une plateforme de tests d'intrusion augmentés par l'IA, actuellement en accès anticipé. Envie de voir comment les agents et l'humain s'articulent ? Découvrez les agents ou rejoignez la liste d'attente.