Test d’intrusion (pentest)
Nous testons vos applications, vos API, vos infrastructures et vos environnements cloud comme le ferait un attaquant réel — sur mandat écrit et dans un périmètre défini contractuellement. Vous recevez un rapport en français, hiérarchisé par criticité, avec les preuves d’exploitation ; le contre-audit après correction est inclus, sans surcoût.
Ils nous font confiance
Qu’est-ce qu’un test d’intrusion (pentest) ?
Un test d’intrusion, ou pentest, est une attaque contrôlée menée contre vos propres systèmes, dans un périmètre arrêté à l’avance et avec votre autorisation écrite. Nos consultants emploient les techniques d’un attaquant réel — reconnaissance, exploitation, élévation de privilèges, déplacement latéral — mais chaque action est tracée et chaque vulnérabilité démontrée sans mettre vos données ni votre production en danger.
L’objectif est de rendre le risque visible tant qu’il coûte encore peu à corriger — la démarche est détaillée dans notre article qu’est-ce qu’un test d’intrusion. Vous repartez avec un rapport en français indiquant, pour chaque vulnérabilité, ce qui ne va pas, la gravité associée et la correction attendue, classé par priorité de traitement.
Tous nos tests d’intrusion sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal). Rien ne commence avant cette signature, et lorsque votre application est hébergée chez un tiers, l’accord de l’hébergeur est demandé au cadrage.
Objectifs d’un test d’intrusion
Un test d’intrusion répond à une question que ni un scan ni une revue documentaire ne tranchent : jusqu’où un attaquant irait-il réellement, aujourd’hui, sur votre périmètre ? Selon le contexte, une mission poursuit un ou plusieurs de ces objectifs.
- Mesurer l’exposition réelle : les vulnérabilités exploitables, et non la liste théorique des correctifs manquants.
- Démontrer l’impact : accès à des données personnelles, prise de contrôle d’un compte à privilèges, atteinte à un service facturé.
- Hiérarchiser la remédiation selon le risque dans votre contexte, et pas seulement selon un score générique.
- Vérifier les mesures en place : pare-feu applicatif, cloisonnement réseau, authentification multifacteur, journalisation.
- Apporter une preuve opposable à un client grand compte, à un assureur ou à un auditeur ISO 27001.
- Objectiver un choix technique : valider une architecture avant sa mise en production, arbitrer entre deux options de conception.
Un test d’intrusion photographie en profondeur un périmètre à un instant donné ; il ne remplace pas un audit de vulnérabilités récurrent, qui couvre largement mais sans exploitation. Les deux se complètent — voir scan de vulnérabilités ou test d’intrusion.
Types de test d’intrusion : que testons-nous ?
De l’application web à l’objet connecté, nous couvrons votre surface d’attaque. Chaque type de test d’intrusion a son outillage et sa méthodologie ; le périmètre, lui, suit ce qui compte pour votre activité.
Pour éprouver vos collaborateurs plutôt que vos systèmes, voyez le pentest d’ingénierie sociale ; pour mesurer votre détection et votre réaction dans la durée, le Red Team.
Approches : boîte noire, boîte grise et boîte blanche
L’approche détermine ce que l’équipe sait avant la mission. Elle ne change pas le réalisme du test, mais la profondeur que vous achetez pour un même budget : une heure passée à redécouvrir ce que vous savez déjà n’est pas passée à chercher une vulnérabilité.
Boîte noire (black box)
Aucune information : nous partons d’un nom de domaine ou d’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 ressortir les actifs oubliés et les environnements de recette exposés. Sa limite est mécanique : ce qui n’est pas découvert n’est pas testé.
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 possède déjà un compte, obtenu par phishing ou par réutilisation de mot de passe — et couvre tous les rôles dans le temps imparti.
Boîte blanche (white box)
Comptes, documentation d’architecture et code source. Nous remontons d’un symptôme à sa cause dans le code, atteignons des chemins difficiles à déclencher depuis l’extérieur et examinons la logique métier. Indiquée pour une application critique ou avant une mise en production structurante.
Les trois se combinent : commencer en boîte noire sur le périmètre externe, puis passer en boîte grise une fois la cartographie établie. L’approche retenue est écrite dans le devis.
Tableau comparatif des trois approches
À budget égal, l’approche retenue déplace le curseur entre le réalisme de la découverte et la profondeur des tests.
| Critère | Boîte noire | Boîte grise | Boîte blanche |
|---|---|---|---|
| Informations fournies | Aucune : uniquement ce qui est public. | Comptes par rôle et documentation fonctionnelle. | Comptes, architecture et code source. |
| Ce qui est reproduit | Un attaquant extérieur, sans connaissance préalable. | Un utilisateur authentifié ou un compte compromis. | Un attaquant doté d’une connaissance interne. |
| Couverture du périmètre | Partielle : ce qui n’est pas découvert n’est pas testé. | Large : tous les rôles et toutes les fonctions. | Complète, jusqu’à la cause dans le code. |
| Effort de votre côté | Minimal : un périmètre et une autorisation. | Modéré : la création des comptes de test. | Élevé : accès au dépôt et disponibilité des développeurs. |
| Quand la retenir | Pour évaluer la surface exposée sur Internet. | Dans la plupart des missions applicatives. | Application critique ou revue de conception. |
Haxoris réalise des tests d’intrusion ciblés : un périmètre net produit plus de valeur qu’un balayage large. Si votre question porte moins sur un système que sur votre capacité à détecter et à réagir, c’est un exercice Red Team qu’il vous faut.
Périmètre et cadrage
Le cadrage détermine la valeur d’un test bien davantage que le nombre de jours vendus. Il prend une heure et fixe :
- les cibles : URL, plages d’adresses IP, comptes par rôle, abonnements cloud, dépôts de code le cas échéant ;
- les exclusions : systèmes tiers, environnements hors périmètre, déni de service, actions destructrices ;
- la fenêtre d’intervention et un contact joignable de votre côté pendant toute la mission ;
- les règles d’engagement : profondeur d’exploitation autorisée, traitement des données réelles, conduite à tenir en cas de découverte critique — nous vous alertons sans attendre le rapport ;
- l’environnement : préproduction équivalente à la production lorsqu’elle existe, production avec précautions renforcées sinon.
Nous testons régulièrement en production. L’exploitation s’arrête dès que l’impact est démontré, et nous vous communiquons nos adresses sources — ou nous les gardons pour nous, si l’exercice doit également évaluer votre détection.
Le devis découle du cadrage : jours-homme, consultant affecté, date de remise et délai de contre-audit. Si le périmètre décrit ne justifie pas un test d’intrusion, nous le disons avant de chiffrer.
Notre méthodologie : le déroulement d’un test d’intrusion
Nos missions suivent un déroulé stable, appuyé sur le PTES et sur les guides de l’OWASP — le WSTG pour le web, le MASTG pour le mobile, l’ASVS pour la vérification des exigences : nos méthodologies en détail.
Cadrage et autorisation (Scoping)
Nous arrêtons ensemble objectifs, périmètre et règles d’engagement, puis vous signez le mandat. Rien ne commence avant : c’est cette signature qui distingue un test d’intrusion d’une infraction pénale.
Reconnaissance et cartographie (Information 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 carte du périmètre et une liste de scénarios.
Tests manuels (Manual Testing)
Sur dix jours-homme, l’outillage automatisé occupe moins d’une journée ; le reste est manuel, parce qu’un scanner ne trouve ni les défauts de contrôle d’accès ni les erreurs de logique métier.
Exploitation et démonstration d’impact (Exploitation & Verification)
Chaque vulnérabilité retenue est exploitée dans des conditions maîtrisées, jusqu’à ce que l’impact soit établi et pas au-delà. Vous voyez quelles données et quels comptes sont concernés.
Rapport et restitution (Reporting)
Le rapport en français réunit, par constat, la preuve, le niveau de risque et la correction attendue. Il est présenté devant vos équipes par le consultant qui a mené le test.
Contre-audit après correction (Contre-audit)
Après déploiement des correctifs, nous rejouons les tests sur les vulnérabilités identifiées et émettons un rapport attestant de leur fermeture. Inclus dans le prix de la mission.
Référentiels de test que nous appliquons
Nous travaillons selon les référentiels publics du secteur : le PTES pour le déroulé, les guides de l’OWASP pour le contenu. Deux missions comparables produisent des résultats comparables, et vous vérifiez ce qui a été couvert.
Livrables : rapport, restitution et contre-audit
Ce que vous achetez n’est pas une semaine de test, c’est ce qu’il en reste ensuite. Trois livrables, aucun en option.
Le rapport
Une synthèse de deux pages pour la direction : niveau de risque, constats majeurs, décisions à prendre, 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, la méthode et la liste des tests effectués, 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 ou sur site, animée par le consultant qui a 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 correction.
Le contre-audit
Après vos corrections, nous rejouons les tests sur les vulnérabilités identifiées et émettons 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.
Souveraineté et traitement des données
Haxoris est une société établie dans l’Union européenne. Nos consultants interviennent depuis l’Union européenne, et l’intégralité des données produites pendant une mission — captures, extraits de journaux, notes de test, rapports — est stockée et sauvegardée dans l’Union européenne.
Le RGPD nous est directement applicable : ni mécanisme de transfert à construire, ni clauses contractuelles types à négocier. Nous intervenons comme sous-traitant au sens de l’article 28 ; la liste de nos sous-traitants ultérieurs et de leurs pays d’implantation vous est communiquée avant la signature, et toute évolution vous est notifiée. N’étant pas soumis à la juridiction des États-Unis, nous ne relevons pas du CLOUD Act.
Les données de test sont chiffrées au repos et en transit, accessibles aux seuls consultants affectés à votre mission et supprimées à l’échéance prévue au contrat, par défaut à l’expiration du délai de contre-audit. Le rapport vous appartient : nous ne le réutilisons pas et ne citons votre nom qu’avec votre accord écrit.
Pourquoi choisir Haxoris ?
Des prestataires capables de tester, il en existe beaucoup. La différence se joue sur ce qu’il vous reste ensuite : un rapport exploitable, un interlocuteur qui a mené le test, et la preuve que la faille est refermée.
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.
Des consultants certifiés :
Certifications offensives OSCP, OSEP, OSWE ou CISSP, plus de dix ans d’expérience et des dizaines de missions menées en Europe.
Témoignages clients
Ce que nos clients disent de nous
Répondez aux exigences : RGPD, NIS 2, ISO 27001, PCI DSS
La seule disposition européenne qui mentionne explicitement le test est l’article 32, 1, d) du RGPD : les mesures appropriées comprennent « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles ». Nous documentons chaque mission pour que le rapport tienne devant un auditeur : périmètre, dates, constats et ce qui a été rejoué après correction.
NIS 2
La directive (UE) 2022/2555 demande des mesures de gestion des risques et l’évaluation de leur efficacité. En France, la transposition n’est pas achevée : le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025, reste en cours d’examen. Nous travaillons donc en anticipation, sur les objectifs de la directive et non sur des obligations françaises qui n’existent pas encore. Notre page NIS 2.
PCI DSS
La norme applicable aux données de cartes de paiement impose des tests d’intrusion externes et internes périodiques, et après toute modification significative. Le rapport est livré au niveau de détail attendu par votre QSA.
ISO/IEC 27001
Les mesures A 8.8 et A 8.29 de l’annexe A supposent des tests documentés. Nous produisons cette preuve technique pour votre SMSI ; la certification, elle, est délivrée par un organisme accrédité et jamais par le prestataire qui teste. Notre accompagnement ISO 27001.
Dernière vérification : 11 septembre 2026. Cette section cite des textes en cours d’évolution.
Foire aux questions
01 Combien coûte un test d’intrusion ?
Le prix dépend du périmètre et de la complexité. 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 communiquons 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.
02 Combien de jours-homme faut-il prévoir ?
Une mission courante représente 5 à 15 jours-homme, soit 1 à 3 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. Les dates figurent dans le devis.
03 Boîte noire ou boîte grise : que faut-il 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 dépenser 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.
04 Un test d’intrusion peut-il perturber ma production ?
Le risque n’est jamais nul, mais il se maîtrise. Les actions destructrices et les tests de déni de service sont exclus par défaut, l’exploitation s’arrête dès que l’impact est démontré, et un contact reste joignable des deux côtés pendant la fenêtre convenue. Lorsqu’une préproduction équivalente existe, nous y travaillons en priorité.
05 Le contre-audit est-il inclus ?
Oui, sans supplément. Après le déploiement de vos correctifs, nous rejouons les tests sur les vulnérabilités identifiées et émettons un rapport de contre-audit attestant de leur fermeture, dans les 90 jours suivant la remise du rapport initial. C’est un des rares postes que le marché facture à la journée ; chez nous il fait partie de la prestation.
06 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. Ce que nous mettons en face est vérifiable avant la signature : le nom du consultant, ses certifications, un exemple de rapport et le contre-audit inclus. Voir comment choisir un prestataire.
07 Comment protégez-vous les données collectées pendant le test ?
Nous intervenons comme sous-traitant au sens de l’article 28 du RGPD. Les données produites pendant la mission — code source compris, lorsqu’il nous est confié en boîte blanche — sont chiffrées au repos et en transit, stockées dans l’Union européenne, accessibles aux seuls consultants affectés et supprimées à l’échéance convenue. Nous ne relevons pas de la juridiction des États-Unis et ne sommes donc pas soumis au CLOUD Act.
