Pentest automatisé par IA : le vrai coût d'une campagne multi-agents

On promet à l'IA qu'elle va « révolutionner » la cybersécurité. En pratique, la vraie question d'ingénieur est plus terre à terre : peut-on confier un test d'intrusion à des agents autonomes, et si oui, combien ça coûte réellement et qu'est-ce que ça ne remplace pas ?

J'ai lancé une campagne complète de pentest pilotée par des agents IA sur un périmètre applicatif de test, en mode exploitation active (les agents ne se contentent pas de signaler une faille : ils la prouvent). Cet article est un retour d'expérience chiffré : le déroulé, la décomposition du coût poste par poste, l'écart entre le prix affiché et le prix réellement payé, et la limite au-delà de laquelle l'humain reste indispensable.

Je n'y montre aucune vulnérabilité concrète ni aucune cible identifiable, et j'explique plus bas pourquoi : un rapport de pentest ne se publie pas. Ce qui se partage, c'est la méthode et l'économie.

Le dispositif : un pentest orchestré par agents

L'outil utilisé est Shannon, un pentesteur IA autonome open source bâti sur le SDK d'agents de Claude et piloté en ligne de commande. Sa particularité : il travaille en white-box. Au lieu de tâtonner de l'extérieur comme un scanner de signatures, une flotte d'agents lit le code source pour identifier les vecteurs d'attaque, formule des hypothèses de vulnérabilités, puis les exploite réellement contre l'application en cours d'exécution — c'est aussi pourquoi le volume de code, plus bas, n'est pas un détail : c'est la matière que les agents ingèrent.

La bascule entre les deux mondes se joue à la reconnaissance : les agents explorent l'application en fonctionnement et mettent en correspondance ce qu'ils observent avec ce que le code annonce. C'est ce recoupement qui oriente le test dynamique vers des chemins d'attaque plausibles, au lieu de balayer à l'aveugle. Le code ne remplace pas l'attaque, il la cible.

Shannon applique une règle stricte, « No Exploit, No Report » : une faille qui ne peut pas être démontrée par une exploitation concrète est écartée comme faux positif. C'est un choix de conception qui privilégie la fiabilité du rapport sur l'exhaustivité — et qui explique, on le verra, pourquoi l'exploitation pèse autant dans le budget.

La cible n'était pas une application de démonstration, et l'ordre de grandeur compte pour lire les chiffres qui suivent. Il s'agissait d'une application métier multi-tenant de taille conséquente : une API moderne et une couche applicative historique coexistant sur la même base, un back-office d'administration, de la gestion de fichiers et plusieurs intégrations tierces. Concrètement, le périmètre représentait plus de 1,5 million de lignes de code PHP, des dizaines de modules fonctionnels et plusieurs milliers de points d'entrée HTTP — une API moderne de l'ordre de 900 routes doublée d'une couche historique de près de 4 000 actions. Autrement dit, une surface d'attaque très étendue.

Les ~140 $ et les 3 h 30 évoqués plus bas portent sur ce périmètre-là, pas sur un formulaire de contact. Sur une petite application, la même campagne coûterait une fraction de ce budget ; sur un système encore plus vaste, il faudrait la découper en plusieurs passes.

Le périmètre couvrait cinq classes de failles applicatives, qui recoupent l'essentiel du Top 10 OWASP :

• Injection — injection SQL, injection de commande, injection de template côté serveur
• XSS — cross-site scripting stocké et réfléchi
• Auth — authentification, gestion des sessions, robustesse des jetons
• Authz — contrôle d'accès, élévation de privilèges, IDOR
• SSRF — falsification de requête côté serveur vers les services internes

Deux modèles se répartissent le travail : un modèle « raisonnement » plus onéreux pour la phase de reconnaissance initiale, où les décisions d'architecture d'attaque se prennent, et un modèle plus rapide et plus économique pour tout le reste, où le volume prime. Ce choix de dimensionnement — le modèle cher là où il décide, le modèle sobre là où il exécute — est déjà, en soi, une décision de coût.

Comment se déroule une campagne

La campagne s'enchaîne en cinq phases, dont deux s'exécutent en parallèle sur cinq agents simultanés (un par classe de vulnérabilité) :

Treize agents au total sont intervenus sur cette campagne. Le livrable final est un rapport d'un peu plus de mille lignes, où chaque vulnérabilité confirmée est accompagnée d'une preuve reproductible — la requête exacte à rejouer et la sortie observée. C'est la différence entre « il y a peut-être une faille ici » et « voici comment on entre ».

Le vrai coût n'est pas là où on l'attend

C'est le cœur du sujet, et c'est là que l'intuition se trompe le plus souvent. Il faut distinguer trois grandeurs qui n'ont rien à voir : le coût affiché, le coût réellement payé, et le temps.

Le coût « équivalent API » : environ 140 $

Facturée à l'usage, tous agents confondus, la campagne représenterait de l'ordre de 140 $. Mais la moyenne ne dit rien d'utile : c'est la répartition qui est instructive.

• Pré-reconnaissance — ~4 % du coût
• Reconnaissance — ~13 % du coût
• Analyse de vulnérabilités — ~27 % du coût
• Exploitation — ~55 % du coût
• Rapport — ~1,5 % du coût

À elle seule, l'exploitation concentre plus de la moitié de la dépense. C'est logique : c'est la seule phase où les agents itèrent vraiment contre la cible, par essais-erreurs, parfois caractère par caractère pour une extraction en aveugle. Analyser une surface d'attaque est relativement bon marché ; la prouver coûte cher.

Un scanner liste des suspicions pour trois fois rien. C'est la démonstration — l'exploitation réelle — qui consomme le budget.

Le coût réellement payé : proche de zéro

Ces 140 $ sont une facturation théorique à l'usage. La campagne a en réalité tourné sous un abonnement forfaitaire. Le coût marginal en euros est donc, à peu de chose près, nul : il est déjà couvert par l'abonnement mensuel.

La ressource réellement consommée n'est pas de l'argent mais du budget de session : ces abonnements n'ouvrent pas un quota de tokens à l'unité, mais une fenêtre d'usage glissante de quelques heures, au-delà de laquelle il faut attendre la suivante. Cette campagne a absorbé environ 82 % d'une de ces fenêtres. Autrement dit : la bonne question de pilotage n'est pas « combien ça coûte » — c'est inclus — mais « combien de fenêtres de session j'y consacre ». Une passe complète, exploitation comprise, occupe quasiment une session entière.

Cette bascule change la manière de raisonner. En facturation à l'usage, on arbitre au dollar. En forfait, on arbitre en temps de session — une contrainte de débit, pas de trésorerie.

Le temps : parallélisme contre horloge murale

La campagne a duré environ 3 h 30 en temps réel. Pourtant, la somme cumulée des durées de tous les agents dépasse 9 heures. L'écart n'est pas une erreur : il vient des deux phases qui lancent cinq agents en parallèle. Cinq classes de vulnérabilités travaillées simultanément, c'est presque trois fois moins de temps d'attente qu'en séquentiel.

C'est exactement le raisonnement qu'on applique en architecture logicielle : le parallélisme ne réduit pas le travail total, il réduit le temps où l'on attend le résultat. Sur un pentest, ce levier est décisif si l'on veut enchaîner plusieurs passes dans une même fenêtre de session.

Où part le budget, et comment le maîtriser

Un seul poste domine la dépense comme le temps : l'exploitation active (~55 % du coût, ~65 % du temps). C'est le principal levier d'arbitrage.

• Passe en analyse seule — sans le mode exploitation, on coupe la plus grosse part du budget. On obtient une cartographie des vulnérabilités probables, mais sans la preuve qu'elles sont réellement exploitables. Utile pour un premier balayage rapide.
• Passe avec exploitation — plus lente et plus coûteuse, mais chaque faille remontée est démontrée, avec une preuve rejouable. C'est ce qui distingue un vrai rapport d'un export de scanner.
• Dimensionnement des modèles — réserver le modèle « raisonnement » à la phase où les décisions se prennent, et confier le volume à un modèle plus sobre. Inverser ce choix ferait exploser la facture sans gain de qualité.
• Réduction du périmètre — cibler deux ou trois classes de failles plutôt que cinq réduit d'autant le nombre d'agents parallèles et le budget consommé.

Ce que l'automatisation ne remplace pas

Le débit est impressionnant : pour l'équivalent d'une fenêtre de session, on obtient un rapport complet, chiffré, avec des preuves reproductibles. Mais il serait naïf d'en conclure que le pentest est désormais un bouton. Trois limites, apprises sur le terrain, encadrent l'exercice.

Distinguer une faille du code d'un artefact déposé

Un agent peut « trouver » un accès grand ouvert qui n'est pas une vulnérabilité du code mais un artefact laissé sur l'environnement — un fichier de debug, un reliquat d'un test précédent, un outil déposé manuellement. C'est une différence capitale : l'un se corrige dans la base de code, l'autre se retire de l'environnement et interroge la chaîne de déploiement. Faire ce tri demande un jugement humain que l'agent n'a pas.

Le périmètre et les faux négatifs

Une campagne ne teste que ce qu'elle atteint. Un contrôle d'accès qui n'a pas pu être démontré faute de jeton valide dans la base de test n'est pas « absent » — il est non prouvé. Confondre « pas exploité » et « pas exploitable » est la meilleure façon de se croire à l'abri. L'humain lit le rapport en gardant ces angles morts en tête.

Le sens et la priorisation

L'outil classe par criticité technique. Il ne connaît ni votre exposition métier, ni la valeur des données derrière chaque faille, ni le coût réel d'un correctif dans votre contexte. Transformer une liste de vulnérabilités en plan de remédiation priorisé — quoi corriger sous 48 h, quoi peut attendre, quel risque est accepté — reste un travail d'ingénieur.

Pourquoi cet article ne montre aucune faille

Un rapport de pentest est un mode d'emploi pour attaquer un système précis. Le publier, même partiellement, même « anonymisé », c'est offrir une carte à quiconque saurait recouper la stack ou l'infrastructure. La déontologie est simple et non négociable : les vulnérabilités se remontent au responsable du système, se corrigent, se re-testent — elles ne se racontent pas en public.

C'est aussi ce qui fait la différence entre un outil et une pratique. L'automatisation produit le matériau ; la rigueur décide de ce qu'on en fait. Sur ce terrain — divulgation responsable, tri du signal, priorisation métier — l'IA accélère, mais ne dédouane de rien.