Test d'intrusion
Une simulation d'attaque réelle, dans un cadre contractuel, contre votre application ou votre infrastructure
Avant qu'un attaquant ne l'exploite, vous savez ce qu'il pourrait réellement obtenir : preuves à l'appui, rapport CVSS v3.1, recommandations de remédiation priorisées, sur un périmètre type de 5 à 10 jours. Réponse à votre demande sous 48 h ouvrées.
Pourquoi un test d'intrusion
Un scanner de vulnérabilités produit un inventaire : versions obsolètes, en-têtes manquants, CVE potentielles. Il ne dit pas si ces éléments sont exploitables dans votre contexte, ni surtout ce qu'ils permettent une fois combinés. Combinez une faille moyenne, une mauvaise configuration et un compte de service trop privilégié : elles forment rarement trois problèmes moyens, mais souvent une compromission complète.
Le test d'intrusion répond à la seule question qui compte : qu'est-ce qu'un attaquant peut obtenir concrètement, en combien de temps, en partant de quoi.
Les déclencheurs typiques :
-
Une exigence externe. Client grand compte, assureur cyber, ou référentiel (NIS2, DORA, ISO 27001) qui demande un test d'intrusion documenté.
-
Une vulnérabilité vient d'être découverte ou exploitée. Elle est corrigée, la situation est stabilisée. Le pentest vérifie qu'elle l'est vraiment, et surtout qu'aucun vecteur voisin ne reste ouvert : une faille trouvée par hasard signale rarement un problème isolé.
-
Une mise en production majeure. Nouvelle application, refonte, exposition d'une API qui était interne.
-
Une démarche volontaire. Pas d'incident, pas d'obligation, mais la volonté de mesurer la résistance réelle de votre exposition pour avoir une vision claire de vos risques.
Périmètres et modes de test
Applicatif
Applications web, API REST et SOAP, applications mobiles Android. Méthodologies OWASP Testing Guide, OWASP ASVS, OWASP MASTG.
Infrastructure
Serveurs exposés, configurations système et cloud, Active Directory, chemins d'élévation de privilèges. Méthodologie PTES.
Blackbox, greybox ou whitebox
En blackbox, je pars de zéro, comme un attaquant externe sans accès préalable. En greybox, vous me fournissez des comptes : je simule un attaquant qui a déjà franchi la première barrière (compte compromis, phishing réussi) ou un utilisateur légitime qui abuse de ses droits. Le bon mode est celui qui correspond à la menace qui vous préoccupe, et c'est la première chose que nous cadrons ensemble : tester votre exposition externe et tester ce qu'un compte peut faire une fois à l'intérieur ne répondent pas à la même question.
En whitebox, vous me donnez aussi accès au code source. Je l'utilise comme accélérateur : il pointe vers les chemins vulnérables qu'un test en aveugle mettrait beaucoup plus longtemps à trouver, ou ne trouverait pas dans le temps imparti. L'objectif reste l'exploitation : démontrer qu'une faille est réellement atteignable et ce qu'elle permet, preuve à l'appui. C'est le mode le plus efficace dès que vous pouvez me laisser accéder au code source. À l'inverse, si l'objectif est de couvrir le code en profondeur et de documenter chaque finding, la réponse adaptée est probablement plus un audit de code : au cours duquel le code est lu pour le cartographier, là où le whitebox le lit pour l'attaquer.
Comment se déroule le test d'intrusion
-
Premier échange (gratuit, sans engagement)
Nous passons en revue votre contexte, vos attentes, le périmètre envisagé, vos contraintes. Il en sort une proposition forfaitaire ferme sous 48 h ouvrées.
-
Cadrage et convention de test
Au démarrage de la prestation, nous formalisons par écrit le périmètre, les exclusions, les fenêtres horaires, les contacts d'urgence. Rien n'est testé hors de ce cadre.
-
Tests
Je mène quatre phases : reconnaissance, recherche de vulnérabilités, exploitation contrôlée, post-exploitation. Toute vulnérabilité critique découverte est signalée immédiatement, pas à la remise du rapport.
-
Rapport et restitution
Pour chaque finding, je documente la description, la preuve d'exploitation reproductible, le score CVSS v3.1, une recommandation de correction. Une synthèse managériale d'une page ouvre le rapport. La restitution se fait en deux temps si besoin : une session technique avec l'équipe, une session courte avec la direction.
-
Test de remédiation (optionnel)
Après vos corrections, je rejoue une session de test sur les findings corrigés et je délivre une attestation de remédiation. C'est souvent ce document que votre client final demande.
Ce que ce test ne fait pas
-
Il ne prouve pas l'absence de failles : il établit ce qui a été trouvé sur le périmètre convenu, dans le temps imparti. Plus le périmètre est large pour le temps donné, plus il reste de zones non explorées. La sécurité durable se construit en amont, dans le développement (voir audit de code et formation).
-
Il ne couvre pas l'ingénierie sociale ni l'intrusion physique, sauf demande explicite et cadrage spécifique.
Combien ça coûte
En bref
Forfait déterminé au premier échange. Une application web standard en greybox : 5 à 7 jours. Une infrastructure avec Active Directory : 5 à 10 jours. Le test de remédiation : 1 journée.
Trois facteurs déterminent le forfait. La taille du périmètre d'abord : une application isolée, un parc d'API, plusieurs plages IP ne demandent pas le même temps de couverture. Le mode de test ensuite : à résultat égal, le blackbox coûte plus cher, car une partie du budget passe en reconnaissance avant d'atteindre ce que le greybox attaque directement. Les exigences de restitution enfin : un rapport en anglais ou une présentation au COMEX s'ajoutent à la charge d'audit elle-même.
Questions fréquentes
- Qui réalise le test ?
- Jean-Baptiste Astarie, fondateur d'Ordanche Solutions, certifié OSCP. L'examen OSCP est lui-même un test d'intrusion documenté de bout en bout, exploitation et rapport compris : la certification prouve l'exercice réel, pas un badge théorique. Mon parcours et mes certifications vérifiables sont sur la page à propos.
- À quelle fréquence faut-il tester ?
- Le standard du marché et des référentiels : une fois par an, et après tout changement majeur d'architecture. Si vous livrez en continu, un pentest annuel plus un audit de code sur les composants modifiés est un meilleur usage du budget que deux pentests.
- Le test peut-il casser la production ?
- Le risque n'est jamais nul, mais il est cadré : pas de déni de service sauf demande explicite, exploitation contrôlée, fenêtres horaires convenues, contact d'urgence joignable. Si un environnement de pré-production fidèle existe, c'est souvent le bon terrain de test.
- Fournissez-vous une attestation pour mes clients ?
- Oui : une attestation de réalisation, et, le cas échéant, après les tests de remédiation, une attestation de remédiation. Le rapport complet est votre propriété ; vous décidez de ce que vous transmettez.
- Quel est le délai pour démarrer ?
- Réponse à votre demande sous 48 h ouvrées. Démarrage généralement sous 2 à 4 semaines, selon mon planning.
Évaluation de périmètre gratuite
Décrivez votre contexte technique : je vous réponds sous 48 h avec une estimation de charge et une proposition d'intervention.
Me contacter