Pentest IA : ce qu'un test d'intrusion par intelligence artificielle fait vraiment

Introduction

Il y a dix-huit mois, « pentest IA » désignait surtout un chatbot qu'on consultait entre deux requêtes Burp. Aujourd'hui l'expression recouvre des produits qui envoient eux-mêmes des requêtes à votre production, enchaînent des constats et rédigent le rapport. Entre les deux, le marché a changé de nature, et le vocabulaire n'a pas suivi.

Nous construisons un de ces produits, et nous avons passé l'année à répondre à la même question en démonstration : « concrètement, qu'est-ce que l'IA fait de plus qu'un scanner ? ». Cet article est la réponse longue. Il définit ce qu'est un test d'intrusion par intelligence artificielle, explique comment fonctionne un agent de pentest, dit ce qu'il trouve et ce qu'il ne trouvera pas, et donne les questions à poser avant de signer.

Pour ceux qui n'iront pas plus loin : un pentest IA bien fait n'est pas un scanner plus bavard. C'est un moteur de détection classique, plus un agent qui tente l'exploitation comme le ferait un pentester, sur tout votre périmètre, tous les jours. Et il ne remplace toujours pas un humain sur la logique métier de votre application principale.

Trois choses qu'on appelle « pentest IA »

Avant de comparer, il faut trier. Sous la même étiquette, on vend aujourd'hui trois produits qui n'ont pas grand-chose en commun.

Les trois sont légitimes. Le premier rend un rapport plus lisible, ce qui n'est pas rien quand on a déjà reçu 400 pages de scan brut. Le second rend un bon pentester plus rapide. Mais seul le troisième change ce qui est trouvé, parce que seul le troisième prend des décisions de test que personne n'avait écrites à l'avance.

Le test pour savoir lequel vous avez en face : demandez qui a décidé d'envoyer telle requête. Si la réponse est « une règle », c'est un scanner. Si c'est « un consultant », c'est un assistant. Si c'est « l'agent, à partir de ce qu'il avait observé deux requêtes plus tôt », vous êtes devant un pentest agentique.

Comment fonctionne un agent de pentest

Un agent de pentest est un modèle de langage placé dans une boucle, avec des outils et des limites. La mécanique tient en quatre temps, que nous avons fini par afficher telle quelle sur notre page d'accueil parce qu'elle explique mieux le produit qu'un paragraphe.

1. Observer. L'agent lit ce que la cible renvoie : les en-têtes, les formulaires, les routes d'API trouvées dans un bundle JavaScript, un message d'erreur trop bavard. Il part aussi de ce que le moteur algorithmique a déjà relevé.
2. Supposer. À partir de ces observations, il formule une hypothèse d'attaque adaptée à la stack. « Ce paramètre url dans une fonction d'import ressemble à un point d'entrée SSRF », par exemple. C'est l'étape qu'un scanner ne fait pas : le scanner applique une liste, l'agent choisit.
3. Tester. Il envoie la requête qui confirme ou écarte l'hypothèse, avec une charge non destructive. Il lit la réponse, et il a le droit de se tromper.
4. Prouver, ou recommencer. Si l'hypothèse tient, il conserve la requête, la réponse et la donnée atteinte : c'est la preuve qui ira dans le rapport. Sinon, il revient à l'étape 1 avec une information de plus.

La différence avec un scanner se voit sur la durée. Un scanner envoie ses mille charges, en avant, et s'arrête. Un agent peut passer vingt requêtes sur un seul formulaire parce que la troisième réponse l'a intrigué, et c'est exactement ce que fait un pentester humain devant un comportement bizarre.

Ce que l'agent ne décide pas seul

Un agent sans limites est un outil d'attaque, pas un produit d'audit. Les garde-fous font partie du produit, et ils sont ce qu'il faut regarder en premier en démonstration :

• Le périmètre est imposé. L'agent ne teste que les actifs validés par le moteur de cartographie et rattachés au domaine du client. Il ne « suit » pas un lien vers un tiers.
• Les charges sont bornées. Prouver une injection SQL en lisant la version de la base, oui. Lire la table des utilisateurs, non. Prouver une exécution de code avec une commande inoffensive, oui. Installer quoi que ce soit, non.
• Le débit est plafonné, et les tests qui peuvent dégrader un service (brute force, charges volumineuses) sont exclus par défaut.
• Chaque requête est journalisée, pour que le client puisse voir ce qui a été envoyé à sa production, et quand.

Chez Flawfence, l'agent ne travaille d'ailleurs jamais seul : il reprend les constats d'un moteur algorithmique qui a d'abord reconstruit le périmètre, identifié les services et passé chaque actif au crible des failles connues. Le moteur est déterministe et exhaustif, l'agent est curieux et sélectif. Nous avons décrit le fonctionnement détaillé de cette boucle dans l'article sur les agents IA de pentest.

Ce qu'un pentest IA trouve de plus qu'un scanner

Ce sont les cas qui reviennent sur nos périmètres, pas une liste théorique.

Les failles qui demandent un enchaînement. Un sous-domaine de préproduction (trouvé par la cartographie), qui expose un Swagger (trouvé par le moteur), dont une route accepte une URL en paramètre (lu par l'agent), et qui atteint les métadonnées du cloud (prouvé par l'agent). Aucune règle de scanner ne décrit cette chaîne, parce qu'elle n'existe que sur ce client.

Les comportements, pas les versions. Un scanner reconnaît un produit vulnérable à sa bannière. Un agent constate qu'une route renvoie des données différentes selon un identifiant qu'elle n'est pas censée accepter, sans savoir quel produit est derrière.

Les formulaires isolés. La fonction d'import d'un back-office, le point d'entrée d'un webhook, un endpoint d'export : ce qui n'est référencé nulle part et que seul quelqu'un qui lit le JavaScript trouvera.

Les erreurs de configuration contextuelles. Un CORS trop permissif n'est grave que si une API sensible est derrière ; un agent qui a vu l'API peut le dire, un scanner le signale dans tous les cas, ou jamais.

Sur un point, l'automatisation gagne sans discussion, et nous l'avions déjà écrit à propos du pentest automatisé en général : la fréquence. Un agent qui repasse chaque jour voit la faille le jour où un déploiement l'introduit. Aucun consultant, aussi bon soit-il, n'est là ce jour-là.

Ce qu'il ne trouvera pas

La partie que les plaquettes oublient. Elle est importante parce que c'est là que se décident les mauvais achats.

La logique métier qui demande de comprendre votre activité. Valider sa propre note de frais, commander à un prix négatif, sauter l'étape de paiement. Un agent peut parfois tomber dessus, mais il ne sait pas ce que « ne devrait pas être possible » veut dire chez vous. Il faudrait lui expliquer vos règles de gestion, et le jour où on le fait, c'est un pentest applicatif encadré, pas un abonnement.

L'espace authentifié qu'on ne lui a pas ouvert. Un agent externe sans compte voit ce que voit un anonyme. C'est beaucoup, et c'est ce que voit un attaquant opportuniste. Ce n'est pas l'espace client de votre SaaS.

Le réseau interne. Un pentest externe, agentique ou non, s'arrête à la frontière d'Internet. Active Directory, mouvements latéraux, élévation de privilèges : c'est un autre métier et d'autres outils.

L'humain. L'hameçonnage, l'appel au support, le badge prêté. Un agent teste des machines, un red team teste une organisation.

Et une limite propre aux modèles de langage, qu'il faut dire franchement : un agent peut se convaincre d'une faille qui n'existe pas. Il lit une réponse ambiguë, construit une histoire cohérente et la rapporte avec assurance. La seule parade sérieuse est de n'accepter dans le rapport que ce qui est accompagné d'une preuve reproductible : la requête, la réponse, la donnée. Une « vulnérabilité probable » sans requête n'est pas un constat, c'est une opinion.

Les risques spécifiques, et ce qu'il faut exiger

Un pentest IA ajoute trois questions que le pentest automatisé classique ne posait pas.

Où va ce que l'agent lit ? L'agent raisonne sur des réponses HTTP de votre production, qui peuvent contenir des données personnelles, des jetons, des extraits de base. Ces réponses transitent par un modèle de langage. Chez qui, dans quel pays, conservées combien de temps, utilisées pour entraîner quoi ? Un éditeur qui ne répond pas précisément n'a pas regardé. Nous avons détaillé pourquoi cette question a une réponse souveraine dans l'article sur le pentest IA français.

Qui est responsable d'une requête de trop ? Un agent décide de ses requêtes. S'il en envoie une qui dégrade votre service, le contrat doit dire ce qui était autorisé. Regardez la liste des tests exclus par défaut et la possibilité de définir des plages horaires. Et rappelons l'évidence juridique : automatisé, agentique ou manuel, un test sans autorisation du responsable du système relève de l'article 323-1 du Code pénal. Un outil qui teste n'importe quel domaine saisi dans un formulaire, sans attestation, expose son client autant que lui-même.

Le résultat est-il reproductible ? Deux passages d'un agent sur la même cible ne suivent pas forcément le même chemin. C'est une force (il explore) et une faiblesse (il peut rater au second passage ce qu'il avait trouvé au premier). Un bon produit garde les constats confirmés d'un passage à l'autre et les reteste explicitement, au lieu de compter sur la chance.

Comment évaluer une offre de pentest IA

Six questions, à poser à la personne technique.

1. Montrez-moi la boucle. Sur un constat réel, quelles requêtes l'agent a-t-il envoyées avant celle qui a prouvé la faille ? S'il n'y en a qu'une, c'est une règle, pas un agent.
2. Qu'est-ce que l'agent n'a pas le droit de faire ? La réponse doit être une liste, pas une phrase rassurante.
3. Où tourne le modèle, et que voit-il ? Hébergeur, pays, rétention, entraînement.
4. Comment mesurez-vous vos faux positifs ? Une validation par exploitation est une mesure. Un tiers qui juge (programme de bug bounty, contre-audit) en est une meilleure.
5. Que se passe-t-il quand l'agent se trompe ? Comment un constat non reproductible est-il traité ? Est-il publié, retesté, écarté ?
6. Qu'est-ce que votre agent ne trouve pas ? Un éditeur qui n'a pas de réponse ne connaît pas son produit.

Pour les montants, notre grille de prix des audits de sécurité reste valable : une année de couverture agentique continue se situe dans l'ordre de grandeur d'un pentest externe court.

Où se situe Flawfence

Puisque nous posons la question 6 aux autres.

Flawfence combine les deux couches. Un moteur algorithmique reconstruit le périmètre à partir du domaine, identifie les services et confronte chaque actif aux failles connues et aux tests OWASP, à chaque passage, de façon déterministe. Un agent de pentest IA reprend ensuite ses constats, explore les applications trouvées, formule ses hypothèses et tente l'exploitation en charges non destructives. Rien ne remonte sans preuve : requête, réponse, donnée atteinte, et la commande pour rejouer. L'agent raisonne principalement avec les modèles de Mistral AI, et la plateforme est hébergée à Paris.

Sur les faux positifs, notre mesure est publique : le moteur et l'agent tournent sur des programmes de bug bounty, où une faille ne compte que si l'entreprise visée la valide. Les résultats sont sur notre profil YesWeHack et repris sur la page d'accueil.

Ce que Flawfence ne trouve pas : la logique métier qui demande de connaître vos règles, l'espace authentifié, le réseau interne, et l'humain. Pour l'application qui porte votre chiffre d'affaires, gardez un budget de pentest applicatif. Nous vous le dirons si c'est ce qu'il vous faut.

FAQ

Qu'est-ce qu'un pentest IA ?

Un test d'intrusion dans lequel une intelligence artificielle prend des décisions de test : elle observe la cible, formule des hypothèses d'attaque, les vérifie en envoyant des requêtes et conserve la preuve. On parle aussi de pentest agentique. À distinguer d'un scanner dont les résultats sont seulement résumés par une IA, et d'un assistant qui aide un pentester humain.

Un pentest IA remplace-t-il un pentest manuel ?

Pas entièrement. Il couvre mieux et plus souvent les failles techniques, les mauvaises configurations, les actifs oubliés et les enchaînements qui ne demandent pas de comprendre le métier. Il ne remplace pas un humain sur la logique métier d'une application critique, ni sur l'espace authentifié ou le réseau interne.

Quelle différence entre un pentest IA et un scanner de vulnérabilités ?

Le scanner applique des règles écrites à l'avance et signale des correspondances. L'agent de pentest choisit ses tests à partir de ce qu'il observe, enchaîne plusieurs constats et tente l'exploitation pour prouver la faille. Le scanner est exhaustif et reproductible, l'agent est sélectif et adaptatif. Les meilleurs produits combinent les deux.

Un agent de pentest IA est-il dangereux pour la production ?

Il peut l'être s'il n'a pas de limites. Un produit sérieux impose le périmètre, borne les charges à la preuve (sans lecture ni modification de données), plafonne le débit, exclut par défaut les tests dégradants et journalise chaque requête. Demandez la liste de ce que l'agent n'a pas le droit de faire.

Les données lues par l'agent sont-elles envoyées à un modèle étranger ?

Cela dépend de l'éditeur. L'agent raisonne sur les réponses de votre production, qui transitent par un modèle de langage. Demandez où tourne le modèle, dans quel pays, avec quelle rétention et s'il est entraîné sur vos données. Flawfence utilise principalement les modèles de Mistral AI et héberge la plateforme en France.

Combien coûte un pentest IA ?

Les offres externes par abonnement se situent dans l'ordre de grandeur d'un pentest externe court par an pour une PME, et croissent avec le nombre d'actifs. Chez Flawfence, l'abonnement commence à 5 000 € HT par an.

Conclusion

Le mot « IA » sur une plaquette de pentest ne dit rien tant qu'on ne sait pas qui décide d'envoyer les requêtes. Si c'est une règle, vous achetez un scanner, et il y en a de bons. Si c'est un agent qui observe, suppose, teste et prouve, vous achetez quelque chose de nouveau : un pentester qui ne dort pas, borné par des garde-fous qu'il faut lire avant de signer.

Dans les deux cas, exigez la preuve. Un rapport qui ne contient pas la requête et la réponse ne vous dit pas ce qui est exploitable chez vous. Il vous dit ce qu'un modèle de langage pense qu'il pourrait l'être, et ce n'est pas la même chose.