Présentation d’AI Swarm Pentest : d’un pentester IA à une équipe orchestrée d’agents d’attaque

Le développement logiciel devient agentique.

L’IA peut désormais générer, réviser, refactoriser, tester et déployer du code. Les applications évoluent plus vite, les API se multiplient et les équipes de sécurité doivent valider davantage de logiciels sans que leurs effectifs augmentent dans les mêmes proportions.

Les tests d’intrusion commencent à évoluer pour les mêmes raisons.

La première vague d’outils de sécurité par IA aidait surtout les humains à travailler plus vite : expliquer une vulnérabilité, générer une charge utile, résumer les résultats d’un scanner ou suggérer la prochaine étape d’un test d’intrusion.

La vague suivante a gagné en autonomie. Au lieu d’attendre qu’un humain lance chaque commande, un agent d’IA pouvait explorer une application, interagir avec des points de terminaison, tester des hypothèses, analyser les réponses et décider quoi essayer ensuite.

Mais l’autonomie crée un autre problème :

Un test d’intrusion ne se résume pas à une seule tâche.

C’est une longue chaîne de décisions.

Un attaquant peut devoir découvrir un point de terminaison, comprendre l’authentification, repérer une référence à un objet, tester les limites d’autorisation, obtenir du contexte supplémentaire, essayer plusieurs variantes de charge utile, corréler le résultat avec une autre faiblesse, puis prouver que le chemin d’attaque complet fonctionne réellement.

C’est là qu’intervient AI Swarm Pentest.

Plutôt que de traiter le test d’intrusion comme une longue conversation entre un modèle et une cible, AI Swarm Pentest le considère comme une investigation de sécurité orchestrée, dans laquelle des capacités spécialisées peuvent explorer, raisonner, partager le contexte, vérifier le travail des autres et transformer des hypothèses d’attaque en preuves.

L’objectif n’est pas simplement :

Trouver davantage de vulnérabilités.

La question la plus utile est :

Quels chemins d’attaque sont réels, qu’est-ce qu’un attaquant peut effectivement atteindre et de quelles preuves l’équipe d’ingénierie a-t-elle besoin pour agir ?

Cette distinction est au cœur d’AI Swarm Pentest de Plexicus. Plexicus présente AI Swarm Pentest comme une solution qui valide les chemins exploitables dans des applications, des API et du code source autorisés, en s’appuyant sur des preuves et une vérification indépendante avant de déclarer une découverte vérifiée.

Regarder l’animation AI Swarm Pentest sur YouTube.

D’abord : que signifie réellement le « pentest par IA » ?

Il n’existe pas de définition universellement reconnue du test d’intrusion par IA.

Un scanner de vulnérabilités accompagné d’une explication générée par un LLM peut être commercialisé comme un outil de sécurité par IA.

Un pentester qui utilise Claude ou un autre modèle comme copilote peut également qualifier son workflow de pentest par IA.

À l’autre extrémité du spectre, des systèmes autonomes peuvent interagir avec des applications, choisir des outils, générer des charges utiles, analyser les réponses, changer de stratégie, exploiter des vulnérabilités et produire des preuves avec peu d’intervention humaine.

Ces systèmes ne sont pas équivalents.

Même les fournisseurs de plateformes de pentest autonome reconnaissent cette distinction. XBOW, par exemple, décrit le pentest par IA comme un spectre pouvant inclure un LLM relié à un scanner, des tests dirigés par un humain et augmentés par l’IA, ou des systèmes autonomes qui coordonnent des agents spécialisés.

Avant d’aborder AI Swarm Pentest, il est donc utile de distinguer quatre concepts.

Les frontières ne sont pas absolues.

Une plateforme de pentest autonome sophistiquée peut déjà employer plusieurs agents en interne. Par conséquent, « essaim » ne doit pas être compris comme « plus d’un agent d’IA ».

La différence significative tient à la façon dont ces agents sont organisés.

Qu’est-ce qu’AI Swarm Pentest ?

AI Swarm Pentest est une approche de test d’intrusion agentique dans laquelle des capacités de sécurité spécialisées fonctionnent comme un système orchestré, au lieu de confier toute la mission, étape après étape, à un seul agent d’IA généraliste.

Imaginez que vous demandiez à un ingénieur sécurité très compétent d’enquêter seul sur une application, puis que vous confiiez la même mission à une équipe de sécurité coordonnée.

Une personne peut cartographier la surface d’attaque.

Une autre se concentre sur l’authentification.

Une autre examine les autorisations.

Une autre étudie les API.

Une autre cherche à transformer un comportement intéressant en exploit reproductible.

Une autre tente indépendamment de reproduire la découverte avant que l’équipe ne la signale.

L’important n’est pas simplement que plusieurs personnes travaillent.

Elles doivent partager une compréhension commune de la cible.

Si un agent découvre que :

/api/invoices/{id}

est accessible après authentification, un autre agent ne devrait pas nécessairement devoir tout redécouvrir depuis le début.

Si le premier agent constate également que les identifiants de facture sont séquentiels, la capacité de test des autorisations peut s’en servir comme nouvelle hypothèse.

Si une autre action révèle un identifiant de locataire, cette observation peut devenir pertinente ailleurs.

Le pentest devient un graphe d’attaque en évolution continue plutôt qu’un ensemble de prompts isolés.

La présentation à venir de José Ramón Palanco lors d’APIAddicts Days, le 15 octobre 2026 propose des compétences spécialisées, MCP et une mémoire des attaques orientée graphe. Il s’agit d’une architecture de preuve de concept proposée pour cette conférence.

Cette analogie se rapproche bien davantage d’une véritable mission de sécurité offensive que :

Prompt → IA → rapport de vulnérabilités.

Pourquoi un seul agent d’IA ne suffit pas toujours

Les grands modèles de langage sont des assistants de sécurité remarquablement capables.

Mais les tests d’intrusion cumulent plusieurs de leurs limites.

Un test d’intrusion est une activité :

de longue durée,

qui conserve son état,

qui dépend fortement des outils,

incertaine,

adversariale,

et fondée sur des preuves recueillies au fil de nombreuses actions antérieures.

L’article PentestGPT a documenté ce problème très tôt. Les chercheurs ont constaté que les LLM étaient utiles pour des sous-tâches ponctuelles de pentest — utiliser des outils, interpréter leurs résultats et proposer les étapes suivantes — mais qu’il restait difficile de conserver une compréhension intégrée de toute la mission. PentestGPT a donc séparé les responsabilités en modules qui interagissent, au lieu de demander à une seule instance du modèle de tout gérer.

Des recherches ultérieures ont continué à relever des difficultés liées à l’énumération, à l’exploitation, à l’élévation de privilèges, à la gestion du contexte et au raisonnement autonome de bout en bout.

Des travaux plus récents sur les systèmes multi-agents vont dans le même sens.

Le système de recherche ARTEMIS, par exemple, utilise des sous-agents dynamiques et un tri automatique des vulnérabilités. Lors d’une étude en conditions réelles sur le réseau d’une université, les chercheurs ont rapporté des avantages en matière d’énumération systématique et d’exploitation parallèle, tout en observant d’importantes limites, notamment des faux positifs et des difficultés avec certains workflows reposant beaucoup sur des interfaces graphiques. Ces résultats doivent être interprétés dans le cadre des cibles, des règles de notation et du budget de cette étude.

La leçon n’est pas que « plusieurs agents résolvent automatiquement le pentest ».

Ce n’est pas le cas.

La leçon est que les travaux complexes de sécurité offensive gagnent à répartir les responsabilités tout en conservant un état partagé et un processus de vérification.

Passer d’un agent unique à un essaim

Un pentester IA autonome simplifié pourrait fonctionner ainsi :

Cible
  ↓
Agent d’IA
  ↓
Reconnaissance
  ↓
Hypothèse
  ↓
Exploitation
  ↓
Rapport

Cela peut très bien fonctionner.

Mais tout dépend alors de la même boucle de raisonnement pour conserver le contexte, déterminer les priorités, utiliser les outils, éviter les impasses, traiter leurs résultats, valider les découvertes et documenter la mission.

Une architecture en essaim s’organise conceptuellement autrement :

                         ┌──────────────────────────┐
                         │ Périmètre autorisé       │
                         │ + Règles d’engagement    │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │ Orchestrateur de l’essaim│
                         └────────────┬─────────────┘
                                      │
          ┌───────────────────────────┼───────────────────────────┐
          ▼                           ▼                           ▼
 ┌────────────────────┐    ┌────────────────────┐    ┌────────────────────┐
 │ Surface / recon.   │    │ Auth. / logique    │    │ Exploitation       │
 │ Capacité           │    │ Capacité           │    │ Capacité           │
 └─────────┬──────────┘    └─────────┬──────────┘    └─────────┬──────────┘
           │                         │                         │
           └─────────────────────────┼─────────────────────────┘
                                     ▼
                         ┌──────────────────────────┐
                         │ Contexte partagé         │
                         │ / graphe / preuves       │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │ Vérification             │
                         │ indépendante             │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │ Découverte vérifiée      │
                         │ + preuves                │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │ Revue humaine +          │
                         │ correction              │
                         └──────────────────────────┘

Le changement d’architecture est subtil, mais important.

L’unité de travail n’est plus seulement le prompt.

Elle devient la mission.

Fonctionnement d’AI Swarm Pentest

À un niveau général, AI Swarm Pentest peut se comprendre comme sept étapes liées :

1. Définir la mission autorisée. La cible, l’environnement, les identifiants si nécessaire, les limites, la durée et les règles d’engagement sont définis avant le début des tests. Chez Plexicus, le périmètre et les règles sont convenus avant la mission, et le système est conçu pour rester dans ce périmètre autorisé.

2. Cartographier la surface de l’application. Le système explore les applications et API accessibles, les routes, les paramètres, les états d’authentification, les formulaires et d’autres surfaces d’attaque pertinentes, au lieu de simplement lancer un ensemble fixe de signatures. La documentation de Plexicus distingue ce comportement du DAST : ses agents de pentest par IA peuvent interagir avec les applications, remplir des formulaires, utiliser des sessions authentifiées et poursuivre des chaînes d’attaque plus complexes.

3. Formuler des hypothèses d’attaque. Les observations deviennent des questions. Cet identifiant peut-il être modifié ? Ce point de terminaison interne peut-il être atteint depuis l’extérieur ? Une limite de rôle peut-elle être contournée ? Deux faiblesses modérées prises séparément peuvent-elles être combinées ?

4. Déléguer l’exploration. Les capacités pertinentes examinent ces hypothèses. Certaines pistes s’arrêtent rapidement. D’autres produisent de nouvelles informations utiles au reste de l’essaim.

5. Relier les preuves en chemins d’attaque. Au lieu de traiter les découvertes comme des alertes isolées, les observations peuvent devenir des relations : utilisateur → point de terminaison → objet → autorisation → opération vulnérable → ressource sensible.

6. Vérifier la découverte indépendamment. Découvrir n’équivaut pas automatiquement à prouver. Plexicus indique que les découvertes présentées comme vérifiées font l’objet d’une reproduction distincte et que les hypothèses non étayées peuvent être écartées, plutôt que conservées uniquement pour allonger le rapport.

7. Transmettre les preuves aux humains. Le résultat inclut le contexte d’impact, les preuves techniques, la priorisation et les informations nécessaires à la correction. Les changements en production ne sont pas appliqués automatiquement ; la décision finale revient aux équipes humaines.

Cette dernière étape est importante.

Le but du pentest autonome ne devrait pas être de générer des vulnérabilités de manière autonome.

Il devrait être de mener une investigation autonome accompagnée de preuves vérifiables.

La vue de l’évaluation présente la configuration et les captures de la cible pendant l’exécution du pentest.

AI Swarm Pentest et le DAST traditionnel

Le DAST reste utile.

Mais le DAST et AI Swarm Pentest répondent à des questions différentes.

Un scanner dynamique classique est très efficace pour vérifier de façon répétée de nombreuses cibles à la recherche de catégories de faiblesses connues.

Il peut demander :

Ce paramètre réagit-il à une sonde d’injection SQL connue ?

Un pentester agentique peut poser une question plus proche de celle-ci :

À quoi sert ce point de terminaison, quelles hypothèses l’application fait-elle sur l’appelant, et puis-je les manipuler pour atteindre une ressource à laquelle je ne devrais pas accéder ?

La documentation de Plexicus illustre directement cette différence. Son mode DAST envoie des sondes automatiques pour détecter notamment des erreurs de configuration de sécurité HTTP et des schémas d’exploitation connus, tandis que l’AI Pentest explore les applications de manière interactive, prend en charge les parcours authentifiés et tente des chaînes d’attaque complexes ainsi que des vulnérabilités de logique métier.

Cette distinction compte, car de nombreuses vulnérabilités réelles d’applications dépendent du contexte.

Le problème n’est pas nécessairement :

Le paramètre X accepte la charge utile Y.

Il peut plutôt être :

Un utilisateur à faibles privilèges peut obtenir l’identifiant X dans le workflow A, le transmettre à l’API B, contourner la vérification de propriété et accéder à la ressource d’un autre locataire.

Aucune requête isolée ne semble forcément extraordinaire.

C’est la relation entre les requêtes qui constitue la vulnérabilité.

C’est précisément là que le raisonnement sur l’état de l’attaque devient précieux.

AI Swarm Pentest et le pentest IA « classique »

C’est la distinction la plus importante — et aussi la plus facile à simplifier à l’excès.

Un pentest IA autonome ordinaire suit souvent une boucle d’agent :

observer → raisonner → agir → observer → recommencer.

Cette méthode peut être puissante.

Mais à mesure que la mission prend de l’ampleur, l’agent doit simultanément se souvenir de tout ce qu’il a appris, fixer les priorités, utiliser les outils, conserver l’état d’authentification, examiner de nombreuses hypothèses, abandonner les pistes improductives et distinguer une réussite réelle d’un résultat trompeur.

Une architecture en essaim peut répartir ces responsabilités.

Toutefois, ce tableau décrit des modèles d’architecture, pas des catégories strictes du secteur.

Certains produits récents de pentest autonome utilisent déjà des agents spécialisés et des validateurs. XBOW, par exemple, décrit publiquement la coordination d’agents spécialisés et l’utilisation d’agents validateurs pour confirmer l’exploitabilité.

La question essentielle pour les acheteurs ne devrait donc jamais être :

« Est-ce qu’il y a plusieurs agents ? »

Il vaut mieux demander :

« Comment le système les coordonne-t-il, conserve-t-il l’état, vérifie-t-il les découvertes, contrôle-t-il le périmètre et transforme-t-il les résultats en preuves auxquelles mon équipe peut se fier ? »

L’essaim, c’est la coordination, pas le nombre d’agents

Imaginez que vous déployiez 100 agents d’IA contre une application.

Si chacun scanne indépendamment les mêmes points de terminaison puis produit son propre rapport, vous avez techniquement plusieurs agents.

Vous n’avez pas nécessairement un essaim utile.

Un essaim devient utile lorsque les connaissances découvertes par une capacité peuvent influencer les décisions d’une autre.

Imaginons qu’une capacité d’exploration découvre :

POST /api/projects/{project_id}/export

L’utilisateur authentifié semble appartenir à :

tenant_A

Une autre capacité découvre un identifiant de projet appartenant à :

tenant_B

Une capacité de test des autorisations relie ces observations.

Elle remplace le premier identifiant par le second dans la requête initiale.

La requête aboutit de manière inattendue.

Une capacité de vérification reproduit alors la séquence avec un état vierge.

Le système dispose désormais d’un résultat bien plus utile que :

IDOR potentiel détecté.

Il dispose d’une chaîne d’attaque :

Utilisateur à faibles privilèges
        ↓
Point de terminaison d’export de projet authentifié
        ↓
Identifiant de projet contrôlé par l’attaquant
        ↓
Absence de vérification de la propriété du locataire
        ↓
Export de projet entre locataires
        ↓
Exposition de données sensibles

Et chaque étape peut être accompagnée de preuves.

Voilà la différence entre détecter une anomalie et démontrer un chemin d’attaque.

Le tableau de bord War room en direct intégré est affiché pendant la connexion au flux.

Le contexte partagé change ce que l’IA peut examiner

Les tests d’intrusion de longue durée produisent d’énormes quantités de connaissances temporaires.

Un agent peut apprendre que :

un point de terminaison exige un jeton particulier,

un utilisateur appartient à un rôle donné,

un paramètre contrôle un objet du back-end,

un service révèle un nom d’hôte interne,

une charge utile qui a échoué a tout de même révélé la version d’un framework,

ou qu’un parcours d’authentification crée des identifiants utiles ailleurs.

Si ces observations restent enfermées dans le contexte local de l’agent qui les a découvertes, leur valeur est limitée.

Une représentation partagée des attaques permet de cumuler les informations.

La description de la présentation à venir d’APIAddicts Days 2026, le 15 octobre, propose une preuve de concept de Plexicus combinant des compétences spécialisées, MCP et une base de données orientée graphe pour la mémoire des attaques. La représentation proposée relie les actifs, les vulnérabilités et les chemins d’exploitation.

Les représentations sous forme de graphe sont intuitives en sécurité offensive, car les attaques sont elles-mêmes des graphes.

Un nœud peut représenter :

Utilisateur
Point de terminaison
Identifiant
Dépôt de code
Service
Rôle
Vulnérabilité
Actif
Secret

Une arête peut représenter :

CAN_ACCESS
AUTHENTICATES_TO
CALLS
OWNS
EXPOSES
DEPENDS_ON
BYPASSES
LEADS_TO

La question de sécurité intéressante devient alors :

Quel nouveau chemin ces relations font-elles apparaître ?

C’est beaucoup plus proche de la manière dont raisonnent les attaquants expérimentés.

La vérification compte plus que la génération

L’IA générative introduit un problème évident en sécurité offensive :

Elle peut se tromper avec assurance.

Un modèle peut mal interpréter une réponse.

Une commande peut renvoyer un code de réussite inattendu.

Une application peut se comporter de façon incohérente.

Une charge utile peut sembler fonctionner alors que son impact réel diffère de la conclusion de l’agent.

C’est pourquoi un système de pentest par IA ne devrait pas confondre :

« Le modèle pense avoir trouvé une vulnérabilité »

avec :

« Une vulnérabilité a été vérifiée. »

Le secteur de l’IA offensive converge de plus en plus vers cette idée.

XBOW décrit publiquement l’utilisation d’agents validateurs et exige des preuves avant de signaler des découvertes validées.

Plexicus applique le même principe général dans son modèle Proof-Driven AppSec : les découvertes présentées comme vérifiées doivent être reproductibles et faire l’objet d’une confirmation distincte. Si une deuxième passe ne permet pas de reproduire le résultat, Plexicus indique que la découverte reste non vérifiée ou qu’elle est écartée.

Cela change l’objectif d’optimisation.

Un système de sécurité par IA faible optimise :

Combien de vulnérabilités pouvons-nous générer ?

Un système fondé sur les preuves devrait optimiser :

Combien de chemins d’attaque pertinents pouvons-nous démontrer à l’aide de preuves défendables ?

Le tableau de bord agrandi présente quatre agents hunter et un skeptic, l’activité de chaque agent et le fil narratif. Cette capture montre zéro résultat et des tentatives bloquées ; elle ne démontre pas un exploit vérifié.

Pourquoi les chaînes d’attaque comptent plus que le nombre d’alertes

Les équipes de sécurité manquent rarement d’alertes.

Une organisation moderne dispose peut-être déjà de résultats issus :

du SAST,

du SCA,

du DAST,

de scanners cloud,

de scanners de conteneurs,

de scanners de secrets,

du CSPM,

de solutions de renseignement sur les dépendances,

de programmes de bug bounty,

et de tests d’intrusion manuels.

Le plus difficile est de déterminer ce qui compte vraiment.

Considérez ces trois découvertes isolées :

Un point de terminaison accessible publiquement révèle un identifiant de service.

Un service interne accepte une cible de redirection non validée.

Un point de terminaison privilégié fait confiance aux requêtes provenant de ce service.

Pris séparément, aucun de ces constats ne semble nécessairement catastrophique.

Ensemble :

Attaquant externe
      ↓
Point de terminaison public
      ↓
Découverte de services internes
      ↓
SSRF / primitive de routage
      ↓
Requête interne de confiance
      ↓
Point de terminaison privilégié

Le risque vient du chemin, pas seulement des découvertes.

C’est pourquoi Plexicus met l’accent sur des chemins d’attaque validés avec AI Swarm Pentest, plutôt que sur une liste interminable de problèmes potentiels.

Pourquoi parler d’un « essaim » ?

Le mot peut ressembler à du jargon marketing.

Il ne devrait pas vouloir dire « nous avons lancé plein d’agents ».

Dans un essaim de sécurité utile, les capacités contribuent à une mission commune.

Le modèle mental ressemble à celui d’une équipe de pentest coordonnée :

                     Mission
                        │
           ┌────────────┼────────────┐
           │            │            │
      Explorer       Raisonner   Exploiter
           │            │            │
           └────────────┼────────────┘
                        │
                 Contexte partagé
                        │
           ┌────────────┼────────────┐
           │                         │
      Contester                    Vérifier
           │                         │
           └────────────┬────────────┘
                        │
                     Preuves

Différentes capacités peuvent examiner différentes parties de l’attaque.

Mais elles ne sont pas des chercheurs indépendants qui rédigent des notes sans lien entre elles.

Elles contribuent à une même représentation de la cible, en évolution constante.

L’intelligence du système vient donc non seulement du modèle, mais aussi de l’orchestration qui l’entoure.

Ce point est particulièrement important à mesure que les modèles à poids ouverts progressent.

La présentation à venir d’APIAddicts pose une question connexe : comment l’orchestration, les compétences spécialisées, les outils MCP et une mémoire persistante des attaques peuvent aider un modèle à poids ouverts à examiner une cible autorisée.

AI Swarm Pentest dans Proof-Driven AppSec

Le pentest est utile.

Mais découvrir une vulnérabilité exploitable n’est que le début du workflow d’ingénierie.

Quelqu’un doit comprendre le code concerné.

Quelqu’un doit évaluer l’accessibilité et l’impact métier.

Quelqu’un doit déterminer la correction la plus sûre.

Quelqu’un doit l’implémenter.

Quelqu’un doit réviser le changement.

Et quelqu’un doit vérifier que l’exploit initial ne fonctionne plus.

C’est pourquoi Plexicus présente AI Swarm Pentest comme l’un des composants d’un workflow plus large de Proof-Driven AppSec.

Le modèle peut se résumer ainsi :

VALIDER
AI Swarm Pentest
      │
      │ chemin exploitable + preuves
      ▼
COMPRENDRE
Deep Code Analysis
      │
      │ contexte du code + impact
      ▼
CORRIGER
Remédiation révisée
      │
      │ correction proposée
      ▼
RETTESTER
L’attaque est-elle toujours reproductible ?

La plateforme actuelle de Plexicus décrit ce processus ainsi : Valider → Comprendre → Corriger : AI Swarm Pentest explore les chemins d’attaque autorisés, Deep Code Analysis ajoute le contexte au niveau du code et le workflow de correction peut produire des changements prêts pour la revue, puis les tester à nouveau.

Ce lien est important.

Sans lui, le pentest autonome risque de créer une nouvelle version d’un ancien problème de sécurité :

davantage de découvertes que les équipes d’ingénierie ne peuvent en corriger.

Ce qu’AI Swarm Pentest n’est pas

AI Swarm Pentest n’est pas simplement un scanner de vulnérabilités accompagné de descriptions générées par l’IA.

Ce n’est pas un chatbot qui explique comment un attaquant pourrait exploiter quelque chose en théorie.

Ce n’est pas une autorisation donnée à un agent autonome d’attaquer n’importe quelle infrastructure.

Ce n’est pas la garantie que toutes les vulnérabilités seront découvertes.

Et il n’a pas pour vocation d’éliminer le jugement humain dans les décisions de sécurité.

Plexicus décrit explicitement AI Swarm Pentest comme une mission à périmètre défini, encadrée par des règles d’engagement convenues, des étapes de décision humaine, une vérification indépendante et l’absence de modifications automatiques des systèmes de production.

Ces garde-fous ne sont pas des limitations à supprimer.

Ils font partie de ce qui rend la sécurité offensive autonome utilisable dans un cadre professionnel.

AI Swarm Pentest peut-il remplacer les pentesters humains ?

Pas complètement.

Et cela ne devrait pas être l’objectif immédiat.

Les pentesters humains restent particulièrement précieux lorsque les tests demandent une créativité inhabituelle, une connaissance approfondie de l’organisation, un raisonnement social, un accès physique, l’analyse de processus métier ambigus ou un jugement sur des conséquences qu’il n’est pas prudent de confier à un logiciel.

L’IA a d’autres atouts.

Les machines peuvent énumérer systématiquement de vastes surfaces.

Elles peuvent répéter des tâches sans fatigue.

Elles peuvent examiner de nombreuses hypothèses.

Elles peuvent retester après des changements.

Et elles peuvent mener certaines formes d’exploration parallèle à une échelle dont la reproduction avec du travail humain coûterait cher.

Les recherches comparant les agents d’IA aux professionnels de la cybersécurité montrent déjà cette combinaison de forces et de limites. Les systèmes multi-agents peuvent être efficaces pour l’énumération systématique et l’exploitation en parallèle, tout en rencontrant encore des difficultés sur certaines tâches faisant largement appel aux interfaces graphiques et en produisant davantage de faux positifs sans vérification suffisante.

L’avenir le plus réaliste n’est donc pas :

IA contre pentester

C’est plutôt :

L’IA explore à grande échelle
        +
La vérification réduit le bruit
        +
Les humains contrôlent le périmètre et exercent leur jugement
        +
Les experts en sécurité examinent les cas difficiles

Plexicus indique également qu’AI Swarm Pentest automatise les explorations répétitives, la corrélation et la reproduction, sans supprimer le contexte humain ni la prise de décision finale.

Dans quels cas AI Swarm Pentest peut-il être particulièrement utile ?

Cette approche devient particulièrement intéressante pour les organisations dont la surface logicielle évolue plus vite que ne peuvent raisonnablement suivre des tests manuels périodiques.

Une équipe peut livrer des changements applicatifs chaque jour.

Des API peuvent apparaître et disparaître entre deux cycles de pentest.

Le code généré par IA peut accroître considérablement le débit de développement.

De nouvelles dépendances et de nouveaux services peuvent être ajoutés en continu.

Un pentest annuel traditionnel reste utile, mais il ne constitue qu’un instantané.

Les tests agentiques permettent d’envisager une validation offensive plus fréquente.

Pas seulement :

« Notre scanner a-t-il détecté quelque chose ? »

Mais :

« Un attaquant peut-il encore reproduire ce chemin d’attaque après le dernier changement ? »

C’est un passage important de la découverte périodique de vulnérabilités à la validation continue de la sécurité.

Un exemple pratique

Imaginez une application SaaS générée par IA.

Elle comprend :

Interface web
Service d’authentification
API de facturation
API de projets
Stockage de fichiers
API d’administration

Un scanner classique détecte quelques en-têtes de sécurité et une dépendance obsolète.

C’est une information utile, mais pas nécessairement le problème le plus risqué.

Lors d’un pentest AI Swarm Pentest, l’étape d’exploration découvre :

GET /api/projects/{project_id}

Un utilisateur ordinaire peut consulter son propre projet.

L’essaim consigne la relation :

USER_A → OWNS → PROJECT_123

Une autre observation révèle :

PROJECT_456 → OWNED_BY → USER_B

Une hypothèse concernant les autorisations est formulée.

La capacité concernée envoie la requête suivante :

GET /api/projects/456

en étant authentifiée comme l’utilisateur A.

Le serveur renvoie des métadonnées.

Intéressant, mais ce n’est pas encore suffisant.

L’investigation se poursuit.

Les métadonnées renvoyées contiennent :

export_id: EXP-8821

Une autre capacité découvre :

GET /api/exports/{export_id}/download

La requête aboutit.

L’archive téléchargée contient les données privées du projet de l’utilisateur B.

Le chemin d’attaque devient alors :

Utilisateur A
  ↓
Modifier l’identifiant du projet
  ↓
Lire les métadonnées du projet de l’utilisateur B
  ↓
Découvrir l’identifiant de l’export
  ↓
Télécharger l’export
  ↓
Exposition de données entre locataires

L’étape de vérification reproduit ensuite la chaîne de façon indépendante.

Si l’exploit est reproductible, le système peut associer des preuves à chaque étape.

Deep Code Analysis peut alors remonter à l’absence du contrôle d’autorisation.

Un workflow de correction peut proposer une validation limitée au locataire.

Après revue, l’exploit initial peut être rejoué.

S’il échoue :

Attaque reproductible avant la correction : OUI
Attaque reproductible après la correction : NON

C’est un élément de sécurité bien plus solide que :

IDOR potentiel — Élevé

Le résultat le plus important, c’est la preuve

L’IA va rendre la formulation d’hypothèses de sécurité extrêmement peu coûteuse.

C’est à la fois puissant et dangereux.

Un modèle peut générer des centaines d’explications plausibles sur les raisons pour lesquelles une application serait vulnérable.

Mais les équipes AppSec n’ont pas besoin de centaines d’explications plausibles.

Elles ont besoin de confiance.

Elles doivent savoir :

Qu’avez-vous atteint ?

Comment y êtes-vous parvenu ?

Le résultat peut-il être reproduit ?

Quel est l’impact ?

D’où vient le comportement vulnérable ?

Que faut-il changer ?

La correction a-t-elle réellement bloqué l’attaque ?

C’est pourquoi les preuves deviennent plus importantes — et non moins — à mesure que l’IA gagne en capacités.

Plus la sécurité devient autonome, plus sa couche de vérification doit être solide.

L’avenir du pentest ne repose pas sur un modèle toujours plus gros

Pendant plusieurs années, les progrès de l’IA ont souvent été décrits en termes de taille des modèles.

Un modèle plus intelligent donnait de meilleures réponses.

Le pentest montre pourquoi cette vision est incomplète.

La sécurité offensive n’est pas seulement un benchmark de raisonnement.

C’est un problème de système.

L’IA a besoin d’outils.

Elle a besoin de mémoire.

Elle a besoin d’autorisations.

Elle a besoin d’état.

Elle a besoin d’une représentation de l’environnement.

Elle doit savoir quand explorer.

Elle doit savoir quand s’arrêter.

Elle doit distinguer une hypothèse prometteuse d’un exploit démontré.

Et il lui faut un mécanisme permettant à un autre processus de remettre en question ses conclusions.

L’avenir du test d’intrusion autonome pourrait donc dépendre autant de l’architecture et de l’orchestration que de l’intelligence brute des modèles.

La progression ressemble à ceci :

Scanner de sécurité
      ↓
Assistant de sécurité fondé sur un LLM
      ↓
Agent de pentest autonome
      ↓
Pentest multi-agents
      ↓
Essaim d’IA orchestré
      ↓
Proof-Driven AppSec

Chaque étape ne remplace pas nécessairement la précédente.

Les scanners restent utiles.

Les pentesters humains restent utiles.

Les systèmes à agent unique restent utiles.

La question est de savoir quelle architecture correspond le mieux à la complexité et à la fréquence du problème de sécurité à tester.

AI Swarm Pentest chez Plexicus

AI Swarm Pentest de Plexicus repose sur un principe simple :

Ne vous arrêtez pas à la détection de ce qui pourrait être vulnérable. Démontrez ce qu’un attaquant peut réellement atteindre.

Dans un périmètre autorisé, Plexicus explore le comportement des applications et des API, formule et teste des hypothèses d’attaque, relie les observations pertinentes et associe des preuves aux découvertes.

Les découvertes présentées comme vérifiées font l’objet d’une reproduction indépendante.

Le résultat est ensuite relié au reste du workflow Proof-Driven AppSec de Plexicus, où les équipes peuvent ajouter le contexte du code, comprendre l’impact, examiner la correction et vérifier de nouveau le résultat.

L’objectif n’est pas de produire le rapport de pentest le plus volumineux.

Il s’agit de donner aux équipes de sécurité et d’ingénierie quelque chose de plus utile :

Un chemin d’attaque validé.
Des preuves montrant pourquoi il est réel.
Un contexte expliquant ce qu’il affecte.
Et une voie claire pour le corriger.

Foire aux questions

AI Swarm Pentest est-il la même chose qu’un scanner automatisé de vulnérabilités ?

Non.

Un scanner exécute généralement des contrôles ou des sondes prédéfinis, puis signale les comportements correspondants. AI Swarm Pentest s’appuie sur un raisonnement agentique pour explorer une cible autorisée, formuler des hypothèses, interagir avec le comportement de l’application et examiner les chemins d’attaque.

Plexicus propose à la fois des modes DAST et AI Pentest, et les documente séparément.

AI Swarm Pentest consiste-t-il simplement à faire tourner plusieurs LLM en même temps ?

Non.

Le parallélisme à lui seul ne crée pas un comportement d’essaim utile.

Les éléments essentiels sont l’orchestration, la spécialisation des responsabilités, le contexte d’attaque partagé, l’exécution contrôlée et la vérification.

Chaque agent doit-il utiliser un modèle d’IA différent ?

Non.

La spécialisation des agents et celle des modèles sont deux choses différentes.

Plusieurs agents peuvent utiliser le même modèle sous-jacent tout en ayant des missions, des outils, des autorisations, un contexte ou des responsabilités de validation différents.

À l’inverse, une couche d’orchestration peut choisir des modèles différents selon les tâches.

Le concept d’« essaim » est-il propre à Plexicus ?

Les systèmes de sécurité multi-agents ne sont pas propres à Plexicus.

Des systèmes universitaires et des plateformes commerciales de pentest autonome utilisent également des architectures multi-agents, des agents spécialisés ou des agents validateurs.

Plexicus emploie le terme AI Swarm Pentest pour décrire sa mise en œuvre de cette approche dans son workflow plus large Proof-Driven AppSec, qui met l’accent sur le contexte d’attaque partagé, les preuves, la vérification indépendante, l’analyse du code et la correction.

AI Swarm Pentest peut-il trouver des vulnérabilités de logique métier ?

Les tests agentiques sont particulièrement adaptés aux vulnérabilités métier et aux attaques en plusieurs étapes, car ils peuvent interagir avec des workflows au lieu de s’appuyer uniquement sur des signatures fixes.

La documentation de Plexicus indique que son AI Pentest peut tester des parcours authentifiés et découvrir des chaînes d’attaque complexes ainsi que des failles de logique métier.

AI Swarm Pentest attaque-t-il automatiquement les systèmes de production ?

Les tests doivent rester dans un périmètre explicitement autorisé et respecter des règles d’engagement convenues.

Plexicus indique que ses missions sont limitées par le périmètre et qu’elles ne modifient pas automatiquement les systèmes de production.

Élimine-t-il les faux positifs ?

Aucun système de sécurité autonome ne devrait le promettre.

L’objectif est de réduire l’incertitude grâce à la reproductibilité et aux preuves.

Chez Plexicus, une découverte doit réussir une étape de vérification distincte avant d’être présentée comme vérifiée.

AI Swarm Pentest remplace-t-il les tests d’intrusion manuels ?

Non.

Il change les aspects des tests d’intrusion qui peuvent être automatisés et répétés à l’échelle d’une machine.

L’expertise humaine reste importante pour définir le périmètre, interpréter les résultats, traiter des cas particuliers difficiles et prendre les décisions finales.

De la découverte de vulnérabilités à la preuve de chemins d’attaque

L’IA facilite la génération de code.

Elle facilite aussi la génération d’attaques.

La validation de la sécurité doit évoluer en conséquence.

La réponse ne peut pas se limiter à un nouveau scanner qui ajoute une nouvelle file d’alertes.

Et ajouter un LLM à ce scanner ne résout pas automatiquement le problème.

Ce qui change le workflow, c’est la capacité à mener une investigation dynamique :

Explorer.
Formuler une hypothèse.
La tester.
Partager les apprentissages.
Les relier à une autre observation.
Remettre la conclusion en question.
Reproduire l’attaque.
Conserver les preuves.

C’est l’idée qui sous-tend AI Swarm Pentest.

Pas une IA unique qui prétend être toute une équipe Red Team.

Un système orchestré au service d’une seule mission de sécurité autorisée.

Et surtout :

Pas de preuve reproductible, pas de découverte vérifiée.

Voyez ce qu’un attaquant peut réellement atteindre

AI Swarm Pentest de Plexicus explore les chemins d’attaque autorisés dans les applications et les API, valide ce qui est exploitable et fournit à votre équipe des preuves qu’elle peut examiner et utiliser.

Validez le chemin. Comprenez l’impact. Corrigez avec des preuves.

Découvrir AI Swarm Pentest →