Méthodologies de test
Méthodologies de test
Chaque mission Haxoris suit une méthodologie publiée. C’est ce qui rend un test reproductible, comparable d’une année sur l’autre et opposable à un auditeur — plutôt que dépendant du consultant qui vous a été affecté.
Cette page recense les référentiels sur lesquels nous nous appuyons, ce que chacun sert à démontrer et celui qui s’applique à votre périmètre.
Méthodologies de test
Pourquoi la méthodologie décide de la valeur d’un audit
Deux consultants à qui l’on confie la même application sans méthodologie rendent deux rapports différents, et aucun des deux ne peut dire ce qui n’a pas été vérifié. Un référentiel public fixe la couverture à l’avance : « rien n’a été trouvé ici » devient alors une information, et non une absence d’information.
Une méthodologie stable rend aussi vos rapports comparables d’une année sur l’autre et d’un prestataire à l’autre — ce qu’un auditeur ou le questionnaire sécurité d’un grand compte vous demande de démontrer. Le RGPD, à son article 32, 1, d), attend « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles ». Sans référentiel nommé, cette régularité ne se prouve pas.
Objectifs : ce qu’un référentiel apporte à votre test
Un référentiel de test n’est pas une formalité documentaire. C’est l’outil qui transforme une semaine de travail offensif en résultat vérifiable par quelqu’un qui n’était pas dans la pièce. Quel que soit le périmètre, nous l’utilisons pour cinq choses.
- Fixer la couverture avant de commencer : la liste des points à vérifier est publique et arrêtée au cadrage. Vous savez ce que vous achetez, et ce que vous n’achetez pas.
- Rendre le résultat comparable : d’une année sur l’autre et d’un prestataire à l’autre. Un rapport aligné sur le WSTG se relit sans traduction par l’équipe suivante.
- Objectiver l’absence de constat : « aucune injection SQL » ne vaut que si l’on peut montrer quels tests ont été conduits pour l’affirmer.
- Tenir devant un tiers : auditeur ISO 27001, client grand compte ou assureur demandent la méthode, pas seulement la conclusion.
- Cadrer le devis : les jours-homme découlent du nombre de points à couvrir, pas d’une impression commerciale.
Un référentiel ne remplace pas le jugement du consultant : aucune liste publique ne contient vos règles métier, et c’est souvent là que se logent les vulnérabilités les plus coûteuses. Il garantit que le terrain connu a été parcouru avant d’arriver aux cas particuliers. Nous appliquons cette combinaison à nos tests d’intrusion comme à nos audits de sécurité informatique.
Les référentiels que nous appliquons
Six référentiels publics couvrent l’essentiel de nos missions. Trois d’entre eux disposent d’une page dédiée ; les autres sont détaillés plus bas.
OWASP Top 10
Les dix catégories de risque applicatif les plus critiques, révisées en 2025. Le socle couvert par tout test d’application web.
OWASP WSTG
Le Web Security Testing Guide : la procédure détaillée, test par test, qui donne son ossature à un audit applicatif sérieux.
OWASP ASVS
L’Application Security Verification Standard : des exigences mesurables sur trois niveaux, pour que la couverture soit un chiffre et non une appréciation.
OWASP MASVS et MASTG
Les équivalents mobiles de l’ASVS et du WSTG, appliqués à chaque mission iOS et Android.
MITRE ATT&CK
Le catalogue des tactiques et techniques d’attaquants réels, auquel nous rattachons les actions d’un exercice Red Team pour confronter vos détections.
PTES et NIST SP 800-115
Les standards d’exécution qui décrivent une mission de bout en bout : cadrage, renseignement, exploitation, post-exploitation et restitution.
Comment ces référentiels s’articulent
Ces noms circulent souvent ensemble, comme s’ils étaient interchangeables. Ils ne le sont pas : chacun répond à une question différente, et c’est leur combinaison qui couvre à la fois la surface et la profondeur.
OWASP Top 10 : une liste de risques, pas un plan de test
Le Top 10 classe les catégories de risque applicatif les plus répandues — contrôles d’accès défaillants, défauts cryptographiques, injections, conception non sécurisée. Il sert de langage commun entre vos développeurs, votre direction et nous. Sa limite tient à sa nature : dix catégories ne forment pas une procédure, et un rapport qui annonce « couvrir le Top 10 » ne dit rien de ce qui a été essayé. Notre page OWASP détaille chaque catégorie.
OWASP WSTG : la procédure, test par test
Le Web Security Testing Guide est le manuel opératoire derrière un audit applicatif complet : des centaines de contrôles ordonnés par thème — configuration, authentification, gestion de session, autorisation, validation des entrées, logique métier, côté client. C’est lui qui structure la phase de test d’un test d’intrusion d’application web, et le rapport reprend les identifiants des tests conduits. Voir le détail du WSTG.
OWASP ASVS : la mesure, par niveau d’exigence
L’Application Security Verification Standard renverse la logique : au lieu de chercher des vulnérabilités, il énumère des exigences vérifiables, réparties en trois niveaux d’assurance. La couverture devient un chiffre — tant d’exigences de niveau 2 vérifiées, tant de non-conformités — et non une appréciation. C’est le référentiel à retenir lorsqu’un client ou un auditeur demande une preuve de sécurité applicative, ou pour inscrire un objectif opposable dans un cahier des charges. Voir les niveaux ASVS.
MASVS et MASTG : les équivalents mobiles
Le Mobile Application Security Verification Standard et le Mobile Application Security Testing Guide sont, pour iOS et Android, ce que l’ASVS et le WSTG sont pour le web : stockage local, épinglage de certificat, cryptographie, authentification et résistance à la rétro-ingénierie. Nous les appliquons à chaque test d’intrusion d’application mobile, le binaire et l’API étant testés ensemble.
PTES et NIST SP 800-115 : le déroulé de la mission
Le Penetration Testing Execution Standard et la publication NIST SP 800-115 ne décrivent pas quoi chercher, mais comment conduire une mission de bout en bout : cadrage, collecte de renseignement, modélisation de la menace, analyse des vulnérabilités, exploitation, post-exploitation, restitution. Ils structurent nos missions d’infrastructure interne et externe et nos exercices Red Team, où aucun catalogue applicatif ne s’applique.
MITRE ATT&CK : la lecture défensive
ATT&CK est le catalogue des tactiques et techniques observées chez de véritables attaquants. Nous y rattachons chaque action offensive d’un exercice Red Team, ce qui produit une matrice de ce que votre supervision a détecté, de ce qu’elle a enregistré sans alerter et de ce qu’elle n’a pas vu — soit, pour une équipe de détection, une liste de règles à écrire.
S’y ajoutent, selon le périmètre, les CIS Benchmarks et les guides d’architecture des fournisseurs pour un test d’intrusion cloud, ainsi que l’OWASP Top 10 for LLM Applications pour les applications et agents fondés sur des LLM.
Approches : boîte noire, boîte grise et boîte blanche
Le référentiel dit ce qui est vérifié ; l’approche dit avec quelles informations. Les deux choix sont indépendants : on peut parcourir le WSTG en boîte noire comme en boîte blanche, mais pas avec la même profondeur pour un même budget.
Boîte noire (black box)
Aucune information préalable : un nom de domaine ou une plage d’adresses IP, comme un attaquant extérieur. L’approche répond à la question « de quoi ai-je l’air vu d’Internet ? » et fait remonter les actifs oubliés, les environnements de recette exposés et les services laissés ouverts. Sa limite est mécanique : ce qui n’est pas découvert n’est pas testé, et le temps passé à découvrir n’est pas passé à tester.
Boîte grise (grey box)
Un compte par rôle applicatif et une documentation fonctionnelle sommaire. C’est l’approche que nous recommandons dans la majorité des missions : elle reproduit le scénario le plus fréquent — un attaquant qui dispose déjà d’un compte, obtenu par phishing ou par réutilisation de mot de passe — et permet de couvrir tous les rôles, donc l’essentiel des contrôles d’accès, dans le temps imparti.
Boîte blanche (white box)
Comptes, documentation d’architecture et accès au code source. Le WSTG et l’ASVS s’exploitent alors au maximum : nous remontons d’un symptôme à sa cause dans le code, atteignons des chemins d’exécution difficiles à déclencher depuis l’extérieur et examinons la logique métier. Indiquée pour une application critique, une revue de conception ou une vérification ASVS de niveau 2 ou 3.
Aucune n’est plus « réaliste » que les autres : elles déplacent le curseur entre découverte et profondeur. Tableau comparatif sur notre page test d’intrusion (pentest).
Quel référentiel s’applique à votre test ?
| Ce que vous faites tester… | Nous travaillons selon | À lire aussi |
|---|---|---|
| Une application web ou une API | OWASP Top 10:2025, WSTG, ASVS | OWASP · WSTG · ASVS |
| Une application mobile iOS ou Android | OWASP MASVS et MASTG | Test d’intrusion mobile |
| Un réseau interne ou un annuaire Active Directory | PTES, NIST SP 800-115, MITRE ATT&CK | Test d’intrusion interne et externe |
| Une infrastructure cloud AWS, Azure ou GCP | CIS Benchmarks et guides d’architecture du fournisseur | Test d’intrusion cloud |
| Une intégration LLM ou un agent IA | OWASP Top 10 for LLM Applications | Pentest LLM |
| Un objet connecté et son firmware | OWASP IoT Top 10, analyse matérielle et radio | Pentest IoT |
| Vos collaborateurs | Scénarios d’ingénierie sociale dérivés de MITRE ATT&CK (accès initial) | Pentest d’ingénierie sociale |
| Votre capacité de détection et de réaction | PTES et MITRE ATT&CK, scénario sur mesure | Red Team |
Deux cas traversent tous les périmètres. Recenser largement les vulnérabilités connues, sans en démontrer l’exploitation, relève d’un audit de vulnérabilités. Lorsque la demande vient d’un programme de certification ou d’une directive, la méthodologie ne change pas ; seule la restitution s’aligne sur le cadre : ISO 27001 ou NIS 2.
Notre méthodologie : le déroulement d’une mission
Quel que soit le référentiel retenu, une mission suit le même déroulé, calqué sur le PTES et sur la publication NIST SP 800-115. Seules les étapes 3 et 4 changent de contenu selon que nous testons une application, une infrastructure ou une intégration LLM.
Cadrage et autorisation (Pre-engagement)
Objectifs, périmètre, approche, référentiel applicable et règles d’engagement sont arrêtés dans une note de cadrage, puis vous signez le mandat. Rien ne commence avant : cette signature sépare un test d’intrusion d’une infraction aux articles 323-1 et suivants du code pénal.
Collecte de renseignement (Intelligence Gathering)
Nous recensons ce qui est exposé et joignable : sous-domaines, services, technologies, points d’entrée d’API, informations publiques exploitables. Il en sort une cartographie du périmètre et des scénarios d’attaque à instruire.
Analyse des vulnérabilités (Vulnerability Analysis)
Parcours du référentiel applicable, point par point : le WSTG pour le web, le MASTG pour le mobile, les CIS Benchmarks pour le cloud. L’outillage automatisé sert de filet sur les composants à vulnérabilité connue ; sur dix jours-homme, il occupe moins d’une journée.
Exploitation et démonstration d’impact (Exploitation)
Chaque vulnérabilité retenue est exploitée jusqu’à ce que l’impact soit démontré, puis l’exploitation s’arrête. Aucun constat n’est publié sans preuve reproductible ; une découverte critique vous est signalée sans attendre le rapport.
Post-exploitation et latéralisation (Post-exploitation)
Sur les missions d’infrastructure et les exercices Red Team : jusqu’où mène l’accès obtenu ? Élévation de privilèges, rebond, accès aux données. Les actions sont rattachées aux techniques MITRE ATT&CK, puis confrontées à vos journaux.
Rapport, restitution et contre-audit (Reporting)
Rapport en français, restitution animée par le consultant qui a mené le test, puis contre-audit après vos corrections. Le rapport indique le référentiel suivi et les tests conduits, y compris ceux restés sans résultat.
Livrables : rapport, restitution et contre-audit
Une méthodologie ne se voit que dans les livrables. Les nôtres rendent la couverture vérifiable plutôt que déclarative.
Le rapport
Une synthèse de deux pages pour la direction, sans jargon, puis une fiche par vulnérabilité : description, criticité CVSS et criticité métier, preuve d’exploitation reproductible, correction recommandée et effort estimé. Les annexes donnent le périmètre, le référentiel suivi et la liste des tests conduits, y compris ceux restés sans résultat — souvent la partie la plus utile devant un auditeur. Livré en français, en PDF, avec un tableau de suivi importable.
La restitution
Une heure en visioconférence, animée par le consultant qui a mené le test et non par un commercial. Vos développeurs posent leurs questions, nous rejouons au besoin une exploitation à l’écran et nous priorisons le plan de remédiation.
Le contre-audit
Après vos corrections, nous rejouons les tests sur les vulnérabilités identifiées et remettons un rapport de contre-audit attestant de leur fermeture. Il est inclus dans le prix, sans surcoût, dans les 90 jours suivant la remise du rapport initial — un poste que le marché facture habituellement à la journée.
Dernière vérification des références juridiques citées sur cette page : 11 septembre 2026.
Pourquoi Haxoris
Des prestataires capables d’appliquer l’OWASP, il en existe beaucoup : c’est un référentiel public. La différence se joue sur ce qu’il vous reste après la mission.
Certifications de notre équipe
Contre-audit inclus, sans surcoût :
La vérification des correctifs fait partie de la mission, dans les 90 jours suivant le rapport, et donne lieu à un document attestant de la fermeture des vulnérabilités.
Nos tarifs sont publics :
Nous communiquons nos fourchettes de prix et notre unité de compte, le jour-homme, avant tout rendez-vous : vous comparez sur des chiffres, pas sur des impressions.
Vous savez qui teste :
Le nom, le parcours et les certifications du consultant affecté vous sont communiqués avant la signature, et c’est cette même personne qui anime la restitution.
Une couverture vérifiable :
Le rapport nomme le référentiel suivi et liste les tests conduits, y compris ceux restés sans résultat. La couverture se contrôle, elle ne se prend pas sur parole.
Foire aux questions
01 Quelle méthodologie appliquerez-vous à notre test ?
Cela dépend du périmètre. Le web et les API suivent l’OWASP Top 10:2025, le WSTG et l’ASVS ; le mobile suit le MASVS et le MASTG ; l’infrastructure et les exercices Red Team suivent le PTES et la publication NIST SP 800-115, les actions étant rattachées à MITRE ATT&CK. Le référentiel retenu est inscrit dans la note de cadrage et rappelé en annexe du rapport.
02 Pouvons-nous imposer un référentiel précis ?
Oui. Si votre auditeur, votre client ou votre autorité de contrôle a nommé un standard, indiquez-le au cadrage : nous l’intégrons au périmètre et structurons le rapport selon sa nomenclature, pour qu’il soit directement exploitable dans votre dossier.
03 Boîte noire, boîte grise ou boîte blanche : laquelle choisir ?
La boîte grise dans la grande majorité des cas : elle reproduit le scénario le plus fréquent — un attaquant qui possède déjà un compte — et couvre tous les rôles au lieu de consommer des jours en reconnaissance. La boîte noire garde son sens pour évaluer ce que voit un attaquant depuis Internet, la boîte blanche pour une application critique ou une vérification ASVS de niveau 2 ou 3.
04 Combien coûte un test d’intrusion ?
Le prix dépend du périmètre et du nombre de points de référentiel à couvrir. Un test d’intrusion d’application web démarre autour de 2 000 € HT ; une infrastructure interne ou un environnement cloud multicompte se situent plus haut. Contrairement à l’usage du marché français, nous annonçons nos fourchettes avant tout rendez-vous, et le devis détaille les jours-homme et le tarif journalier. Le calcul est expliqué dans notre article sur le prix d’un test d’intrusion.
05 Combien de jours-homme faut-il prévoir ?
Une mission courante représente 5 à 15 jours-homme, soit une à trois semaines entre le début des tests et la remise du rapport. Une application métier de taille moyenne en boîte grise demande souvent 6 à 8 jours ; une infrastructure interne avec Active Directory dépasse fréquemment 10 jours. Le nombre découle du référentiel appliqué et du périmètre, et figure au devis.
06 Utilisez-vous des scanners automatisés ?
Comme une source parmi d’autres, jamais comme le test lui-même. Un scan couvre les composants à vulnérabilité connue, mais ne détecte ni les défauts de contrôle d’accès ni les erreurs de logique métier. Sur dix jours-homme, l’outillage automatisé occupe moins d’une journée, et chaque constat publié est vérifié manuellement : nous ne transmettons pas une sortie d’outil comme résultat. La différence entre les deux démarches est détaillée dans scan de vulnérabilités ou test d’intrusion.
07 Le rapport indique-t-il ce qui n’a pas été testé ?
Oui, explicitement. Un rapport qui se contente d’énumérer des constats ne dit rien de la couverture. Le nôtre précise le référentiel suivi, le périmètre, les exclusions convenues au cadrage et les tests conduits sans résultat : vous savez ce que signifie l’absence de constat sur un point donné.
08 Le contre-audit est-il inclus ?
Oui, et sans surcoût. Après vos corrections, nous rejouons les tests sur les vulnérabilités identifiées et remettons un rapport de contre-audit attestant de leur fermeture, dans les 90 jours suivant la remise du rapport initial. C’est un poste que le marché français facture habituellement à la journée.
09 Faut-il un prestataire qualifié pour réaliser un test d’intrusion ?
Non, pas pour un test commandé par une entreprise privée. Les qualifications délivrées par l’ANSSI relèvent d’une démarche volontaire organisée par le décret n° 2015-350 du 27 mars 2015 ; elles ne conditionnent pas la réalisation d’un test d’intrusion contractuel. Nous ne détenons aucune qualification de l’ANSSI et nous ne le laissons pas entendre. Les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont, eux, réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre ou par des prestataires de service qualifiés : nous ne soumissionnons pas sur ces prestations. Voir comment choisir un prestataire.
Pour aller plus loin
Quelques lectures qui prolongent cette page, côté méthode comme côté cadre français.
- Qu’est-ce qu’un test d’intrusion ? — la définition et le déroulé d’une mission.
- Prix d’un test d’intrusion — jours-homme, tarif journalier et périmètres chiffrés.
- Scan de vulnérabilités ou test d’intrusion ? — ce que chacun démontre.
- Comment choisir un prestataire — les questions à poser avant de signer.
- ReCyF : l’objectif d’audit de l’ANSSI, traduit en périmètre testable.
