Les questions posées avant de signer

Un scan de vulnérabilités est automatisé : il compare votre système à une base de défauts connus et produit une liste, souvent longue et partiellement fausse. Un test d’intrusion ajoute un travail humain : comprendre votre métier, tester le contrôle d’accès, détourner la logique applicative, enchaîner plusieurs défauts mineurs pour en démontrer un impact majeur. Le scan répond à « des défauts connus sont-ils présents ? », le test d’intrusion à « que peut obtenir un attaquant ? ». Chez Reconmind, le scan fait partie de la mission mais n’en constitue jamais le livrable.

Un test d’intrusion d’application web prend de 2 à 15 jours de test selon le périmètre : 2 à 3 jours pour le périmètre d’entrée publié sur la page des tarifs, davantage quand les rôles, les parcours ou les intégrations se multiplient. Un audit cloud ou d’infrastructure se situe entre 2 et 12 jours. Une mission red team s’étale sur 3 à 8 semaines, car la discrétion impose un rythme lent. Le cadrage, fait en amont, fixe la durée exacte avant la signature.

Le délai habituel entre l’accord et le début des tests est de deux à quatre semaines, le temps du cadrage, de l’autorisation écrite et de la mise à disposition des comptes de test. Pour une réponse à incident, l’intervention démarre sous 24 h ouvrées, et sous 4 h pour les clients sous contrat de supervision.

Deux documents. Une synthèse de direction qui se lit en dix minutes : ce qui est exposé, l’impact, les décisions à prendre et dans quel ordre. Et un rapport technique avec une fiche par vulnérabilité : requête exacte, réponse obtenue, impact démontré, cause, correctif applicable, et classement par exploitabilité réelle. S’ajoutent les preuves rejouables et, à l’issue de la correction, une attestation de vérification.

Oui, une passe de vérification est incluse dans toutes les missions d’audit et de test d’intrusion, utilisable jusqu’à trois mois après la remise du rapport. Elle rejoue les preuves d’origine, contrôle les variantes voisines et produit une attestation de correction opposable à un client ou à un assureur.

En boîte grise dans la grande majorité des cas, et c’est un choix d’efficacité. En boîte noire, une partie du budget sert à reconstituer ce que vous pourriez simplement nous dire. Avec des comptes de test sur chaque rôle et, idéalement, un accès en lecture au code, le même budget couvre beaucoup plus de surface. La boîte noire garde son sens dans un contexte précis : mesurer ce qu’un attaquant externe découvre sans aucune information préalable.

Par défaut, non : les tests se déroulent sur une préproduction représentative. Quand seule la production existe (ce qui est fréquent), les règles d’engagement fixent par écrit ce qui est interdit : pas de déni de service, pas d’action destructive, pas d’envoi d’e-mails aux utilisateurs réels. Les tests bruyants peuvent être planifiés hors des heures ouvrées, et un contact de votre côté peut tout interrompre à tout moment.

Les deux, à leur place. Notre plateforme interne industrialise la reconnaissance, l’exécution des scanners et la corrélation entre résultats : le travail de largeur, qu’une machine fait mieux. L’exploitation, le contrôle d’accès, la logique métier et le chaînage restent menés par un humain : c’est là que se trouvent les vulnérabilités les plus graves, et aucun outil ne les trouve seul aujourd’hui. Nous ne vendons pas un rapport de scan sous le nom de test d’intrusion.

Applications web et API (REST, GraphQL, gRPC), applications mobiles côté serveur, environnements cloud AWS, Azure et GCP, Kubernetes, infrastructures internes Windows et Active Directory, Linux, et chaînes de déploiement CI/CD. Côté code : TypeScript et JavaScript, Python, Go, Java et Kotlin, PHP, C#, Ruby, Rust, ainsi que l’infrastructure as code. Si une technologie sort de ce périmètre, nous le disons au cadrage.