Comment évaluer une plateforme de pentest autonome : plan de pilote et grille de notation

La plupart des évaluations ratées échouent ici : le pilote démarre avant que quiconque se soit mis d'accord sur ce qu'est un bon résultat.

1. 1Choisissez un périmètre représentatif. Un ou deux segments internes avec de vraies charges de travail, un domaine Active Directory si vous en avez un, et une partie du périmètre externe. Un laboratoire propre masque exactement les problèmes que l'outil doit trouver.
2. 2Rédigez les règles d'engagement. Hôtes et plages exclus, fenêtres de test, actions jamais autorisées en production, qui peut arrêter le test et comment le joindre.
3. 3Implantez des faiblesses connues. Dans un segment de test, mettez en place quelques problèmes que votre équipe connaît déjà : un mot de passe administrateur local réutilisé, un service non corrigé, un partage trop permissif. Ils vous donnent une réponse connue pour mesurer les oublis.
4. 4Définissez la réussite par écrit. Par exemple : aucune action hors périmètre, chaque vulnérabilité prouvée, résultats invalides sous un seuil que vous fixez, la plupart des faiblesses implantées trouvées, re-test fonctionnel sur les problèmes corrigés.
5. 5Définissez les conditions d'arrêt. Toute action hors périmètre, toute interruption de service non approuvée ou toute donnée quittant l'environnement met fin au pilote.
6. 6Nommez les personnes. Un responsable de votre côté, les approbateurs des actions soumises à validation et les analystes qui examineront les résultats.

Testez d'abord la sécurité : une plateforme qu'on ne peut pas contrôler ne peut pas être lancée souvent, et la fréquence est précisément la raison de l'acheter.

• Périmètre strict. Placez un hôte exclu à l'intérieur d'une plage incluse et vérifiez que l'agent n'y touche jamais, et que la tentative éventuelle est journalisée. Le périmètre doit être imposé par la plateforme, pas laissé au jugement du modèle.
• Arrêt d'urgence. Déclenchez-le en pleine exécution. Chaque action en cours doit s'arrêter, et le journal doit indiquer quand.
• Points d'approbation. Demandez quelles actions s'exécutent seules, lesquelles attendent un humain, et si vous pouvez modifier cela par campagne. Chaque approbation doit enregistrer qui a approuvé quoi, et quand. Voir les tests de sécurité par IA avec human-in-the-loop.
• Limites de débit et d'impact. Vérifiez comment la plateforme limite la charge, les verrouillages de comptes et les techniques perturbatrices sur les systèmes fragiles comme l'OT, les imprimantes ou les serveurs anciens.
• Journal complet des actions. Vous devez pouvoir reconstituer chaque commande exécutée par l'agent, sur quel hôte, et pourquoi.

Un agent autonome peut décrire une vulnérabilité qu'une chaîne de version ne fait que suggérer, ou croire qu'un exploit a réussi alors que non. La preuve est ce qui distingue une vulnérabilité d'une supposition.

• Pour chaque vulnérabilité, exigez : la requête ou la technique exacte utilisée, la réponse de la cible et ce que l'agent a pu faire après l'accès, horodatés.
• Vérifiez que les preuves ne peuvent pas être modifiées a posteriori. Des enregistrements signés et chaînés permettent à un auditeur de confirmer que le rapport correspond à ce qui s'est passé.
• Choisissez trois vulnérabilités et reproduisez-les avec votre propre équipe à partir des seules preuves. Si elle n'y parvient pas, les preuves ne sont pas suffisantes pour la remédiation ni pour un auditeur.
• Vérifiez ce que contiennent les preuves. Les identifiants capturés et les échantillons de données sont sensibles : demandez où ils sont stockés, qui peut les voir et comment ils sont supprimés à la fin.

Comptez ce que vos analystes acceptent, pas ce qu'affiche le tableau de bord.

• Résultats invalides. Faites marquer par vos analystes chaque résultat comme valide, invalide ou doublon. La part d'invalides est le coût que vous paierez en qualification chaque semaine. Dans la comparaison ICLR 2026 entre agents IA et pentesters professionnels, même le meilleur agent a vu environ une soumission sur cinq rejetée : demandez à chaque fournisseur comment il mesure la sienne.
• Oublis. Comparez les résultats aux faiblesses que vous avez implantées. Un outil qui signale beaucoup mais manque vos problèmes connus est bruyant, pas exhaustif.
• Criticité en contexte. Vérifiez que la criticité reflète ce qu'un attaquant pourrait atteindre à partir de la vulnérabilité dans votre parc, et pas seulement le score CVSS.
• Doublons et bruit. Une même cause racine doit donner une seule vulnérabilité avec plusieurs hôtes affectés, pas cinquante tickets.

• Des chemins d'attaque, pas des listes

  La valeur d'une red team autonome est l'enchaînement : un identifiant faible vers un serveur, vers un administrateur de domaine, vers un système cible. Demandez au moins un chemin présenté étape par étape.

• Interne et externe

  Vérifiez les deux, et si l'agent peut partir d'une position de compromission supposée (assumed breach) sur un poste de travail ordinaire.

• Identité

  Les erreurs de configuration d'Active Directory et des identités cloud sont le terrain où se déplacent les vraies attaques. Regardez ce que l'agent y teste et comment il le prouve.

• Boîte noire et boîte grise

  Lancez une exécution sans identifiants et une autre avec un compte utilisateur standard ; la différence montre à quel point l'agent dépend de ce que vous lui fournissez.

• Ce qu'il ne teste pas

  La logique métier des applications sur mesure, l'ingénierie sociale et l'accès physique restent généralement l'affaire d'humains. Un fournisseur qui prétend tout couvrir est un signal d'alerte.

Le pilote dure quelques semaines ; l'outil fonctionnera des années. Notez le travail qui l'entoure.

• Re-test. Corrigez deux vulnérabilités et demandez à la plateforme de les re-tester. Elle doit rejouer le chemin d'origine et montrer qu'il ne fonctionne plus.
• Transmission. Vérifiez l'export vers votre outil de ticketing et les recommandations de remédiation : sont-elles assez précises pour l'équipe propriétaire du système ?
• Rapports. Examinez séparément la synthèse pour la direction et le rapport technique, ainsi que la correspondance avec les référentiels sur lesquels vous rendez compte, comme NIS2, DORA, PCI DSS ou ISO 27001.
• Temps d'analyste. Mesurez la durée de qualification par vulnérabilité. Ce chiffre, multiplié par la fréquence d'exécution, est le vrai coût en personnel.
• Déploiement et données. Le lieu d'exécution des modèles, ce qui sort du réseau et le fonctionnement en air-gap sont traités dans la checklist acheteur on-premise en 15 questions.

• Pas de pilote sur votre réseau,

  seulement des démos dans le laboratoire du fournisseur ou sur un jeu de challenges public.

• Des scores de benchmark sans méthode

  Un score sur des challenges que le fournisseur a pu étudier à l'avance n'est pas en aveugle. Demandez qui a réalisé la mesure et sur quoi.

• Des vulnérabilités sans preuve,

  ou une preuve limitée à des captures d'écran et à la sortie d'un scanner.

• Un périmètre qui dépend du modèle

  et de sa capacité à suivre des instructions, plutôt qu'une limite imposée par la plateforme.

• Pas d'arrêt d'urgence que vous pouvez déclencher vous-même,

  ou un arrêt qui met des minutes à agir.

• Vos données quittent le réseau

  pour l'inférence ou l'analyse sans réponse claire et contractuelle sur leur destination.

• « Remplace entièrement vos pentesters. »

  Les tests encadrés par les régulateurs, comme le TLPT de DORA, exigent toujours des équipes humaines.

1. 1Semaine 0 : préparation. Convenez du périmètre, des règles d'engagement et des critères de réussite et d'arrêt ; implantez les faiblesses connues ; installez la plateforme et connectez les approbateurs.
2. 2Semaine 1 : tests de sécurité et première exécution. Testez délibérément le respect du périmètre et l'arrêt d'urgence, puis lancez une campagne en boîte noire sur le périmètre externe et un segment interne, au niveau d'autonomie le plus prudent.
3. 3Semaine 2 : profondeur. Lancez une campagne en boîte grise, en compromission supposée, avec un compte utilisateur standard. Examinez les chemins d'attaque et faites marquer chaque résultat par les analystes.
4. 4Semaine 3 : correction et re-test. Corrigez quelques vulnérabilités ainsi que les faiblesses implantées, puis re-testez. Reproduisez trois vulnérabilités à partir des seules preuves.
5. 5Semaine 4 : notation et décision. Remplissez la grille de notation, mesurez le temps d'analyste par vulnérabilité et comparez avec les critères rédigés en semaine 0.

Pour comprendre de bout en bout le fonctionnement du test d'intrusion autonome avant le pilote, commencez par le guide. Pour comparer d'abord les plateformes sur le papier, utilisez la comparaison des outils de pentest automatisé et l'OWASP Autonomous Penetration Testing Standard comme langage commun pour les exigences.

Combien de temps doit durer un pilote de pentest autonome ? Deux à quatre semaines suffisent généralement : une semaine pour les tests de sécurité et une première exécution, une pour une exécution plus approfondie en boîte grise, une pour corriger et re-tester, et le temps de noter. Les pilotes plus courts incluent rarement un re-test, là où de nombreux outils sont pris en défaut.

Est-il sûr de mener un pilote en production ? Uniquement avec un périmètre imposé par la plateforme, un arrêt d'urgence que vous contrôlez et une approbation humaine pour les actions perturbatrices. Commencez au niveau d'autonomie le plus prudent et sur des segments où une interruption serait tolérable.

Comment mesurer les faux positifs ? Faites marquer par vos analystes chaque résultat signalé comme valide, invalide ou doublon, et implantez des faiblesses connues pour mesurer les oublis. Les deux chiffres comptent : un faible taux de faux positifs assorti de nombreux oublis n'est pas un bon résultat.

Faut-il se fier aux scores de benchmark des fournisseurs ? Seulement si la mesure a été réalisée en aveugle et par quelqu'un d'autre que le fournisseur. Les résultats sur des jeux de challenges publics que le fournisseur a pu étudier ne sont pas en aveugle. Un pilote sur votre propre réseau est un meilleur guide.

Que doit prévoir le contrat après le pilote ? Le périmètre et les règles d'engagement, qui approuve les actions soumises à validation, où résident les données et les modèles, comment les preuves sont stockées et supprimées, et le processus de re-test. La checklist acheteur on-premise citée plus haut liste les questions relatives aux données et au déploiement.

Quelle est la place de Zero Hunt ? Zero Hunt est une red team IA autonome sur une appliance on-premise qui exécute ses propres modèles : les données de test restent dans votre réseau. Les limites de périmètre et l'arrêt d'urgence sont imposés par la plateforme, les opérateurs choisissent l'un des cinq niveaux d'autonomie qui déterminent quelles actions attendent une approbation, et chaque vulnérabilité est étayée par des preuves signées Ed25519 et chaînées par hachage. Zero Hunt ne publie pas encore de chiffres de benchmark ; sa méthodologie d'évaluation est en préparation, et la plateforme peut être évaluée selon le pilote décrit ici.