Démontrée
Les agents ont exploité la faille dans le périmètre. Une hypothèse ou un risque théorique n’est pas publié.
Méthodologie
Huit étapes, de la déclaration au retest.
Rien n’est testé avant que vous ayez prouvé le contrôle du domaine et validé le périmètre. Voici ce qui se passe à chaque étape, ce que vous fournissez, et où le test s’arrête.
Déroulé
Ce qui se passe à chaque étape.
Déclaration de l’application
Vous créez votre espace et déclarez l’URL exacte de l’application. Elle est enregistrée comme cible : rien n’est testé à ce stade.
Ce que vous fournissez
L’URL HTTPS de l’application.
Vérification du domaine et autorisation
Vous publiez un enregistrement DNS TXT unique sur le domaine ; SpectrAI le contrôle. En acceptant le devis et les conditions, vous autorisez explicitement le test de ce périmètre.
Ce que vous fournissez
L’accès à la zone DNS du domaine, et la décision d’autoriser le test.
Définition du périmètre
Vous listez les URL ou parcours à tester et les chemins exclus. Vous décrivez le contexte, les priorités et les règles de validation : c’est la Guidance donnée aux agents. SpectrAI vérifie que l’application entre dans le périmètre standard.
Ce que vous fournissez
Les URL, les exclusions, le contexte métier et, si vous en avez, la documentation de l’API (OpenAPI, Swagger ou export Postman).
Comptes et contraintes
Vous fournissez les comptes de test, un par rôle, et vos contraintes : chemins à ne pas toucher, débit maximal, mode prudent pour la production, fenêtre de démarrage. Les comptes sont stockés chiffrés.
Ce que vous fournissez
Jusqu’à deux comptes de test dédiés, sans données personnelles réelles, et vos contraintes d’exploitation.
Exécution contrôlée
Des agents IA attaquent l’application dans le périmètre, avec un budget et un nombre de tours fixés avant le lancement. Vous suivez leurs requêtes et leurs outils en direct, et vous pouvez arrêter le test à tout moment.
Ce que vous fournissez
Rien, sauf si vous voulez suivre ou arrêter le test.
Analyse et revue humaine
Seules les vulnérabilités de la dernière exécution réussie, avec des preuves cohérentes, sont retenues pour la revue. Un humain relit chacune : il la retient ou la rejette avant publication. La sévérité est recalculée à partir du vecteur CVSS.
Ce que vous fournissez
Rien. Vous recevez le résultat de la revue avec le rapport.
Livraison du rapport
Le rapport est figé : périmètre, couverture déclarée par les agents, vulnérabilités avec leurs preuves, impact, CVSS, CWE et recommandations, chaînes d’attaque quand elles sont démontrées. Il s’exporte en PDF, JSON, SARIF, CSV et Markdown.
Ce que vous fournissez
Rien. Un résultat sans vulnérabilité démontrée est un résultat valide et donne aussi un rapport.
Retest
Une fois une vulnérabilité corrigée, vous la marquez comme corrigée et demandez le retest. Un test ciblé rejoue la preuve d’origine et ses contournements évidents, dans les 60 jours suivant le rapport. Verdict par vulnérabilité : corrigée ou toujours présente.
Ce que vous fournissez
Le correctif déployé et la demande de retest. Dans l’application, l’action s’appelle « Vérifier le correctif ».
Vulnérabilité
Ce qui compte comme une vulnérabilité.
Une alerte n’est pas une vulnérabilité. Une vulnérabilité publiée est démontrée, prouvée et relue.
Prouvée
La preuve (requêtes, réponses, étapes de reproduction) est conservée avec la vulnérabilité. Les cookies et secrets cités sont masqués.
Relue par un humain
Un humain relit chaque vulnérabilité avant publication. Sans preuve cohérente, elle n’entre pas dans le rapport.
Qualifiée
Chaque vulnérabilité est publiée avec son impact, sa sévérité CVSS, sa faiblesse CWE et une recommandation de correction.
Ce qui n’est pas publié
- Un score de risque sans exploitation.
- Une version logicielle ancienne ou une CVE de dépendance dont l’exploitation n’est pas démontrée.
- Un constat sans preuve cohérente.
Limites
Où le test s’arrête.
Ce que SpectrAI ne fait pas, et ce qu’il ne garantit pas.
Web externe uniquement
Applications web accessibles en HTTPS depuis Internet, sous un domaine que vous avez prouvé. Pas d’infrastructure interne, pas d’application mobile, pas de code source.
Aucune garantie de découverte
Un pentest ne prouve pas l’absence de vulnérabilité. La couverture indiquée dans le rapport est déclarée par les agents, elle n’est pas mesurée.
Ni qualification PASSI, ni conformité garantie
SpectrAI n’est pas un prestataire qualifié PASSI. Le rapport fournit des preuves datées qu’un auditeur peut utiliser ; il ne garantit aucune conformité (ISO 27001, PCI DSS, NIS2, DORA).
Exploitation contrôlée, pas garantie
Les agents reçoivent des consignes impératives : pas de déni de service, pas de test destructif, pas de persistance, pas de rebond. Ce sont des consignes données à des agents IA, pas une garantie technique. Seule la fenêtre de démarrage est appliquée par la plateforme. Pour une application critique, testez de préférence une préproduction.
Trafic sortant non cloisonné
Le trafic sortant des agents n’est pas encore cloisonné au niveau réseau : réservez le test à des domaines qui vous appartiennent.
Modèle d’IA tiers
Un modèle de langage tiers analyse les réponses de l’application et vos consignes. Aucun traitement dans l’Union européenne n’est garanti à ce jour. La politique de confidentialité en détaille le fournisseur.
Comptes de test en clair pendant l’exécution
Les identifiants de test sont stockés chiffrés, mais les agents les utilisent en clair pendant le test. Fournissez des comptes dédiés, sans données personnelles réelles, à révoquer ensuite.
Aller plus loin
Lisez un rapport avant de commander.
Le rapport type montre ce que vous recevez : périmètre, vulnérabilités démontrées, preuves, impact, recommandations et limites.