Pentest autonome par agents IA : promesses, limites et approche encadrée

Par Sébastien De Coninck, fondateur de HackHeart. Mis à jour le 9 novembre 2026.

Comment fonctionne un agent de pentest IA

Un agent est une boucle : il observe (résultat d'un outil, réponse HTTP, fichier), raisonne avec un modèle de langage, choisit une action (lancer un outil, envoyer une requête, lire un document), puis observe le résultat de cette action. Une architecture multi-agents répartit le travail entre plusieurs rôles qui se transmettent leurs découvertes :

1. Orchestrateur : il découpe le périmètre autorisé en objectifs et attribue les tâches.
2. Agent de reconnaissance : énumération des actifs, des technologies et des points d'entrée.
3. Agents d'analyse : un par famille de failles (contrôle d'accès, injections, authentification, configuration).
4. Agent de qualification adversariale : il essaie de prouver que chaque constat est faux. Seuls les constats qui résistent passent à l'étape suivante.
5. Agent de rédaction : il produit preuves, reproduction, criticité et remédiation.

C'est l'architecture retenue par HackHeart pour Umbra, développée en interne : plus d'une centaine d'agents spécialisés, utilisés sur des missions réelles. Leur fonctionnement, les outils employés et un exemple de rapport sont détaillés dans la présentation technique d'Umbra.

Toutes les offres vendues sous l'étiquette « IA » ne se valent pas : certaines ne sont que des scanners repeints. Notre panorama 2026 du pentest agentique distingue quatre catégories de solutions et propose dix questions pour évaluer sérieusement une plateforme.

Ce que les agents font mieux qu'un humain

• Ne jamais se lasser d'une énumération de plusieurs milliers d'endpoints.
• Lire intégralement un bundle JavaScript minifié à la recherche de routes cachées ou de clés exposées.
• Tester méthodiquement chaque objet de l'API avec chaque rôle utilisateur (failles IDOR et BOLA).
• Documenter chaque étape au fil de l'eau, ce qui rend le rapport plus complet et reproductible.

Les limites réelles du pentest 100 % autonome

Hallucinations et faux positifs

Un modèle de langage peut affirmer qu'une injection SQL fonctionne alors que la réponse du serveur ne le prouve pas. Sans vérification indépendante, le client reçoit un rapport qui l'alarme pour rien, ou pire, qui le rassure à tort.

Risque pour la production

Un agent qui « essaie des choses » peut supprimer des données, verrouiller des comptes ou saturer un service. Il faut des garde-fous techniques stricts : liste blanche d'actions, interdiction des méthodes destructrices, limites de débit, comptes de test dédiés.

Logique métier et contexte

Savoir qu'un utilisateur ne devrait pas pouvoir valider sa propre note de frais, ou qu'une remise ne doit pas se cumuler, demande de comprendre le métier du client. Les agents trouvent des pistes ; l'humain décide si c'est une faille.

Confidentialité des données

Envoyer les données d'un client à un modèle hébergé par un tiers pose une vraie question de confidentialité. Chez HackHeart, une passerelle de confidentialité (le Privacy Gateway d'Umbra) remplace localement les IP, URL et identifiants par des jetons avant tout envoi au modèle, puis réinjecte les vraies valeurs uniquement au moment d'exécuter l'outil. Avec un modèle local, aucune donnée ne quitte l'infrastructure.

Cadre légal

Un agent autonome n'est pas une personne : la responsabilité d'un test hors périmètre retombe sur le prestataire. Le périmètre autorisé doit donc être appliqué techniquement, et non simplement « demandé » à l'IA.

L'approche HackHeart : autonomie encadrée

Nos agents travaillent en autonomie sur les tâches où ils excellent, dans un bac à sable dont ils ne peuvent pas sortir. Le pentesteur pilote la mission, oriente les agents vers les zones sensibles, exploite manuellement les chaînes d'attaque complexes et reproduit chaque vulnérabilité avant qu'elle n'entre dans le rapport. Vous bénéficiez de la vitesse de l'automatisation et de la fiabilité d'un audit humain.