Pentest automatisé : ce qu'il trouve et rate
- BreachVex exécute un pentest automatisé qui trouve seul les failles de contrôle d'accès, d'injection et de configuration, et rate ce qui demande un modèle humain du métier.
- L'agent rejoue de vraies attaques contre une URL, six des dix catégories OWASP Web sont visées aujourd'hui, et le résultat arrive avec la requête qui l'a produit.
- L'écart n'est pas une question de qualité. C'est le type de question posée : l'agent tranche l'exploitabilité, il ne juge pas si votre circuit de validation a un sens métier.
- Utilisez l'exécution automatisée entre deux missions manuelles, pas à leur place.
Ce que « automatisé » change
Deux outils portent le même mot et ne font pas le même travail. Un scanner DAST envoie des requêtes et compare les réponses à des motifs connus ; la sortie est une liste d'endroits qui ont l'air faux. Un pentest automatisé tente l'attaque lui-même, et le constat arrive avec la requête qui a fonctionné. La différence ne porte pas sur la gravité de ce qui est trouvé, mais sur la question de savoir s'il reste quelqu'un pour prouver le résultat avant de le corriger. La validation d'exploit face au scan détaille cette distinction.
Ce qu'il trouve seul
Les parties d'une application web sur lesquelles on peut raisonner de l'extérieur sont celles qu'un agent couvre bien. Sur notre page de couverture, six des dix catégories OWASP Web sont activement visées aujourd'hui, aux côtés des piliers API et LLM (relevé sur breachvex.com le 23 octobre 2026).
- La cartographie de la surface. Routes, paramètres, versions d'API, bundles JavaScript qui nomment des endpoints internes, et le mécanisme d'authentification en place. Une route que le crawl ne trouve pas est une route que personne ne teste : cette étape décide de tout le reste.
- Le contrôle d'accès au niveau objet. IDOR et BOLA sont mécaniques dès que deux comptes existent : changer l'identifiant, comparer les réponses. C'est là qu'un agent bat souvent un humain pressé par une date, parce qu'il essaiera tous les identifiants au lieu des trois qui paraissent intéressants.
- Les injections, y compris aveugles. SQL, NoSQL, commandes, templates et LDAP, avec des rappels hors bande pour les cas où rien ne revient dans le corps de la réponse.
- L'authentification et les sessions. Confusion d'algorithme JWT, secrets faibles, fixation de session, énumération de comptes, et le sort d'une session qui existait déjà au moment du changement de mot de passe.
- Les requêtes côté serveur. Sondage de services internes et endpoints de métadonnées cloud, confirmés par un rappel plutôt que déduits d'un message d'erreur.
- Les mauvaises configurations. Endpoints de débogage, messages d'erreur verbeux, CORS permissif, en-têtes manquants, identifiants laissés dans les bundles côté client.
- La logique métier documentée. Cumul de remises, réutilisation de quota, étapes de workflow prises dans le désordre. Un agent peut parcourir ces chemins parce que la règle est écrite dans le code et atteignable en rejouant une séquence. C'est différent de savoir quelle séquence votre équipe finance avait en tête.
- Les enchaînements dans une même session. Un compte à faibles privilèges, une assignation de masse, un endpoint d'administration : voilà un chemin qu'un agent tente de bout en bout sans se lasser à la deuxième étape.
Là où il s'arrête
La liste honnête est plus longue que la version commerciale ne l'admet d'habitude.
- Une règle que personne n'a écrite. Si l'étape de validation compte à cause d'une politique restée dans une tête, l'agent voit une requête qui fonctionne, pas une violation.
- Les enchaînements entre rôles qui demandent une intention. Décider qu'un utilisateur du support, un remboursement et un endpoint de reprise font une fraude demande de connaître le métier, pas seulement le code.
- Les failles visibles dans le code. Le test en boîte noire voit le comportement. Il ne voit pas la branche jamais déployée, le module accessible seulement derrière un feature flag, ni la dépendance livrée dans un build que vous n'avez jamais exécuté.
- La recherche inédite dans un logiciel tiers. Un agent applique des classes d'attaque connues. Il ne découvre pas une vulnérabilité nouvelle dans une bibliothèque.
- Le réseau interne et Active Directory. Le pipeline tourne depuis l'extérieur. Le mouvement latéral, la segmentation et les chemins vers un contrôleur de domaine demandent un autre point de vue et une autre mission.
- L'ingénierie sociale et l'accès physique. Le phishing, le prétexte et l'entrée dans un bâtiment sont des exercices humains, avec leur propre autorisation et leurs propres risques pour les personnes concernées.
- L'impact dans votre contexte. Un constat arrive avec un vecteur de gravité. Il n'arrive pas avec la connaissance que cet endpoint traite les remboursements de votre plus gros client.
- L'indépendance exigée par un référentiel. Là où un cadre demande un testeur qualifié et indépendant sur le plan organisationnel, une exécution automatisée ne le satisfait pas. La page sur le test d'intrusion expose ce qu'une telle mission couvre.
Pourquoi la preuve change la file
Le tri est l'endroit où le coût de l'outillage se cache. Une file de candidats doit être lue par une personne avant qu'un seul ticket soit créé, et un après-midi de lecture devient une semaine quand la file n'est que du bruit. Un constat reproduit est un autre objet : il porte la requête, la réponse et l'effet, donc la question devient « faut-il corriger » plutôt que « est-ce réel ».
C'est aussi pourquoi notre file est bornée plutôt qu'universelle. Un constat entre dans la file prioritaire une fois l'exploitation reproduite. Ce que le pipeline ne peut pas reproduire part dans une annexe distincte et étiquetée, avec sa raison, au lieu d'être promu ou supprimé en silence.
| Ce que vous lancez | Ce qui revient | Taux de FP | Ce que ça coûte à votre équipe |
|---|---|---|---|
| Mission manuelle | Des constats reproduits et un rapport écrit | Rare, et une personne reproduit chaque constat avant de l'écrire | Des semaines de préparation, plus le re-test |
| Scanner DAST | Des candidats comparés à des motifs connus | Élevé — chaque candidat doit être confirmé par un humain | Du temps de tri, à chaque cycle |
| Pentest automatisé (BreachVex) | Les constats entrés dans la file une fois reproduits, plus une annexe étiquetée | file filtrée par la preuve | La lecture d'une file plus courte |
Où il se place dans un programme de test
Une exécution automatisée est un outil de rythme. Elle vaut le plus sur les déploiements entre deux missions, quand un rapport manuel décrit déjà un code qui a changé, et le moins comme substitut à la mission elle-même.
Le schéma qui tient : une mission manuelle par an sur la partie du produit où le jugement humain se paie, et des exécutions automatisées sur tout ce qui sort entre-temps. Ce que les deux coûtent, et en quoi les unités de facturation diffèrent, est détaillé dans le prix d'un test d'intrusion et dans le détail des modèles de prix du scan. Si vous cherchez encore à savoir lequel des deux vous achetez, qu'est-ce que le pentest automatisé en donne la version définitionnelle.
Sources
- breachvex.com, section couverture, relevé le 23 octobre 2026 : les six catégories OWASP Web activement visées, les piliers API et LLM, et les techniques avancées listées au-delà.
- breachvex.com/fr/pricing, relevé le 23 octobre 2026 : ce que couvre un crédit, et les tarifs fondateur et standard.
- Test d'intrusion : ce qu'un test couvre, publié le 19 octobre 2026 : les frontières de périmètre auxquelles cette page renvoie, et la position de conformité.
- OWASP Web Security Testing Guide : la référence des catégories de test nommées plus haut. Aucun chiffre de cette page n'en provient.
Étape suivante
Le moyen le moins cher de savoir si un agent couvre votre cas est de le pointer sur une application. Nos tarifs, fondateur et standard, sont sur la page des tarifs, et la page sur le test d'intrusion est le document à lire avant de commander une mission manuelle en complément.
BreachVex est en accès anticipé : rejoignez la liste d'attente et nous vous écrirons quand votre accès s'ouvrira.
Frequently Asked Questions
- Qu'est-ce qu'un pentest automatisé trouve qu'un scanner ne trouve pas ?
- Un scanner compare des motifs et rend des candidats. Un pentest automatisé tente l'attaque et conserve la requête qui a fonctionné. Concrètement, cela change surtout les résultats de contrôle d'accès : l'autorisation au niveau objet, l'assignation de masse et les frontières de privilèges deviennent des constats reproductibles au lieu de soupçons. La preuve change la file plus que la liste des catégories.
- Qu'est-ce qu'un pentest automatisé rate ?
- Tout ce qui demande un modèle de votre métier plutôt que de votre code. Une règle que personne n'a écrite, une étape de validation dont l'ordre compte pour la finance mais pas pour le compilateur, un enchaînement qui n'a de sens qu'une fois qu'on sait ce que chaque rôle a le droit de faire. Il rate aussi les failles dans du code qui n'a jamais été déployé, l'ingénierie sociale, l'accès physique, et tout ce qui vit sur le réseau interne.
- Peut-il remplacer un test d'intrusion manuel ?
- Non. Là où un référentiel ou un client demande un testeur indépendant et qualifié, l'exécution automatisée ne répond pas à l'exigence, et aucun travail d'ingénierie ne change cela. Ce que l'automatisation couvre, c'est l'intervalle entre deux missions, quand le dernier rapport décrit un code qui a bougé.
- Pourquoi la preuve d'exploitation compte-t-elle pour le tri ?
- Parce que le tri est là où se cache le coût. Une file de candidats doit être lue par quelqu'un, ligne par ligne, avant qu'on puisse décider quoi corriger. Une file de constats reproduits arrive avec la requête qui a produit chacun, et la décision devient « faut-il corriger » plutôt que « est-ce réel ».