Pentest : types de tests d’intrusion, méthodes et mise en œuvre

Le coût moyen d’une violation de données en France en 2025 est de 3,59 M€ par incident, soit environ 7% de moins qu’en 2024 (≈ 3,85 M€). Cela démontre l’importance d’un pentest pour évaluer la sécurité informatique des entreprises. Pour les PME françaises, une cyberattaque réussie représente en moyenne 466 000 €, avec un impact pouvant atteindre jusqu’à 10% du chiffre d’affaires, selon des analyses basées sur les travaux de l’ANSSI et de la Cour des comptes.

Un test d’intrusion reproduit les techniques d’un attaquant réel dans un cadre contrôlé et légal. Il permet aux entreprises de découvrir leurs vulnérabilités, de mesurer leur niveau de sécurité et de prioriser leurs efforts de remédiation.

Dans cet article, vous découvrirez les différents types de pentest, les méthodes black box, grey box et white box, ainsi que les étapes clés pour mener à bien un projet de test d’intrusion en entreprise.

Points clés à retenir

Le pentest constitue un pilier essentiel de toute stratégie de cybersécurité moderne. Voici les éléments essentiels à garder en tête avant de vous lancer :

Un pentest simule une attaque réelle pour identifier les vulnérabilités de votre système d’information avant qu’un pirate informatique ne les exploite. Cette approche proactive permet de réduire significativement le risque de cyberattaque.

Les principaux types de pentest couvrent l’ensemble de votre surface d’attaque : applicatif (web, mobile, API), infrastructure et réseau, Red Team et ingénierie sociale. Chaque type répond à des objectifs spécifiques selon votre contexte.

Les approches Black Box, Grey Box et White Box déterminent le niveau d’information fourni au pentester avant le test. Le choix dépend du réalisme recherché et de la profondeur d’analyse souhaitée.

Le pentest s’inscrit dans un cadre de conformité (ISO 27001, PCI DSS, SOC 2) et complète d’autres mesures de sécurité comme les scans de vulnérabilités, les audits et les programmes de bug bounty.

La valeur d’un pentest réside dans son rapport et sa restitution, qui fournissent des recommandations priorisées et actionnables pour renforcer votre défense.

Qu’est-ce qu’un pentest en cybersécurité ?

Le terme pentest vient de l’anglais “penetration test”, traduit en français par test d’intrusion. Il désigne une évaluation de sécurité au cours de laquelle un expert reproduit les techniques utilisées par les hackers pour compromettre un système informatique, une application web ou un réseau.

L’objectif d’un test d’intrusion est de découvrir les failles avant qu’un attaquant malveillant ne le fasse. Les pentesters analysent l’impact potentiel des vulnérabilités selon la triade CIA : confidentialité des données, intégrité des informations et disponibilité des services. Cette approche permet de mesurer le risque réel pour l’entreprise.

Le test se déroule dans un cadre contractuel strict. Une lettre de mission définit les dates, le périmètre (scope), les systèmes autorisés et les règles d’engagement. Sans cette autorisation écrite, les mêmes actions constitueraient un délit informatique.

Prenons un exemple concret : une enseigne française de e-commerce commande un pentest de son site web et de son application mobile en septembre 2025, trois mois avant le pic de ventes de fin d’année. Le but est d’identifier et de corriger les problèmes de sécurité avant que des cybercriminels ne tentent de voler les données de paiement des clients.

Le pentest, piratage éthique encadré

Un hacker malveillant exploite les failles pour voler, détruire ou extorquer. Un pentester utilise exactement les mêmes techniques, mais dans un but opposé : renforcer la sécurité d’un système.

Le pentester est un professionnel certifié qui détient généralement des qualifications reconnues comme l’OSCP, l’eJPT ou le CEH. Son rôle consiste à identifier les vulnérabilités, à les exploiter de manière contrôlée et à démontrer leur impact au client. Contrairement aux pirates informatiques, il opère toujours avec l’accord explicite du propriétaire du système.

Toutes les actions réalisées pendant un pentest sont journalisées : scans réseau, tentatives d’exploitation, élévation de privilèges, exfiltration simulée de données. Ces traces alimentent le rapport final et garantissent la transparence de la mission.

Imaginons un formulaire de connexion vulnérable à une injection SQL. Le pentester exploite cette faille pour accéder à la base clients, puis documente précisément la méthode utilisée et les données accessibles. Il ne modifie ni n’exfiltre réellement ces informations sensibles.

L’éthique encadre chaque étape : accord écrit du propriétaire, respect du périmètre défini, confidentialité des résultats et conformité à la réglementation, notamment le RGPD en Europe. Un pentester qui outrepasse ces limites s’expose à des poursuites judiciaires.

Objectifs et bénéfices d’un test d’intrusion

Un pentest bien mené génère des bénéfices concrets et mesurables pour l’entreprise :

La réduction du risque de cyberattaque constitue le premier bénéfice. En identifiant les failles exploitables, vous empêchez les ransomwares, les vols de données et les sabotages avant qu’ils ne surviennent. Une vulnérabilité découverte par un pentester coûte infiniment moins cher qu’une brèche exploitée par un attaquant.

Le pentest fournit une vision priorisée des risques. Chaque faille est classée selon sa criticité (critique, haute, moyenne, faible), ce qui permet aux équipes techniques de concentrer leurs efforts sur les corrections les plus urgentes.

Les exigences de conformité représentent souvent le déclencheur d’un pentest. Les normes ISO 27001, SOC 2, PCI DSS ou HDS (Hébergeur de Données de Santé) imposent des évaluations régulières de la sécurité. Dans les secteurs de la santé, de la finance ou du SaaS B2B, les clients grands comptes exigent fréquemment des rapports de pentest avant de signer un contrat.

L’effet pédagogique constitue un bénéfice souvent sous-estimé. Les résultats concrets du test sensibilisent les développeurs, administrateurs et métiers aux bonnes pratiques de sécurité. Voir une faille exploitée dans son propre code marque davantage les esprits qu’une formation théorique.

Les principaux types de pentest

La surface d’attaque d’une entreprise moderne s’étend bien au-delà du simple site web. Elle englobe les applications mobiles, les API, les infrastructures cloud, les objets connectés (IoT), les réseaux internes et même le facteur humain.

Plusieurs types de tests peuvent être combinés dans une même mission. Par exemple, un pentest web associé à un test de réseau interne et une campagne de phishing offre une vision complète de l’exposition aux menaces.

Le choix des types de pentest dépend du contexte : mise en production d’un nouveau service, incident de sécurité récent, exigence d’un client ou préparation d’une certification. Les entreprises matures planifient généralement un pentest global annuel, complété par des tests ciblés avant chaque déploiement applicatif majeur.

Pentest applicatif web

Le pentest applicatif web cible les sites web, portails clients, back-offices et applications métiers exposés sur Internet. C’est le type de test le plus fréquemment demandé, car les applications web constituent souvent la porte d’entrée principale vers le système d’information.

Les vulnérabilités recherchées suivent généralement le référentiel OWASP Top 10 :

• Injections SQL permettant d’accéder à la base de données
• Cross-Site Scripting (XSS) pour voler des sessions utilisateur
• Cross-Site Request Forgery (CSRF) pour exécuter des actions à l’insu de l’utilisateur
• Server-Side Request Forgery (SSRF) pour atteindre des ressources internes
• Mauvaises configurations d’authentification et de gestion des sessions

Les pentesters combinent analyse manuelle et outils spécialisés comme Burp Suite, OWASP ZAP et Sqlmap. L’expertise humaine reste indispensable pour détecter les failles de logique métier que les scanners automatisés ne peuvent identifier.

En 2024, une grande banque française a commandé un pentest de son portail de banque en ligne. Les testeurs ont identifié une faille dans le parcours de virement permettant de modifier le montant après validation. Cette découverte a évité des pertes financières potentiellement considérables.

Pentest d’application mobile

Le pentest d’application mobile couvre les applications iOS et Android, leur backend associé (API REST ou GraphQL), le stockage local sur l’appareil et les communications réseau.

Cette évaluation combine deux approches complémentaires :

• L’analyse statique examine le code de l’application (reverse engineering des fichiers APK pour Android ou IPA pour iOS) pour identifier les secrets codés en dur, les configurations dangereuses et les librairies vulnérables.
• L’analyse dynamique teste l’application en fonctionnement sur un appareil réel ou un émulateur pour observer son comportement, intercepter le trafic réseau et manipuler les données.

Les failles typiques incluent le stockage non chiffré d’informations sensibles sur l’appareil, les défauts de validation de certificat TLS permettant des attaques man-in-the-middle, et le contournement des mécanismes de détection de jailbreak ou root.

Des frameworks comme Frida, MobSF ou Objection sont mobilisés pour instrumenter l’application et contourner ses protections.

Une fintech française préparant le lancement de son application de paiement mobile en 2026 a fait réaliser un audit complet. Les pentesters ont découvert que les tokens d’authentification étaient stockés en clair dans les préférences partagées Android, permettant à toute application malveillante de les récupérer.

Pentest d’API et de microservices

Les API web (REST, GraphQL, gRPC) constituent aujourd’hui le tissu conjonctif des applications modernes. Elles exposent des fonctionnalités aux partenaires, aux applications mobiles et aux frontends web, ce qui en fait des cibles privilégiées pour les attaquants.

Les risques spécifiques aux API sont catalogués dans l’OWASP API Security Top 10 :

• BOLA (Broken Object Level Authorization) : accès aux données d’autres utilisateurs en modifiant un identifiant
• Gestion incorrecte des permissions entre rôles
• Rate limiting insuffisant permettant le brute-force ou le scraping
• Exposition excessive de données dans les réponses
• Injection dans les paramètres de requête

Un cas fréquent illustre ces risques : l’API d’un SaaS B2B permettait à un utilisateur de consulter les factures d’autres clients simplement en modifiant l’identifiant numérique dans l’URL. Cette faille IDOR (Insecure Direct Object Reference) aurait pu exposer des données confidentielles de centaines d’entreprises clientes.

Toute migration vers des architectures microservices ou cloud-native devrait inclure un pentest d’API dans son planning. La multiplication des points d’entrée augmente mécaniquement la surface d’attaque.

Pentest d’infrastructure et de réseau (interne/externe)

Le pentest d’infrastructure examine les composants techniques qui supportent les applications : serveurs, firewalls, routeurs, VPN, postes de travail, Active Directory et services cloud (IaaS, PaaS).

La distinction entre pentest externe et interne est fondamentale :

Type	Point de vue	Cibles principales
Externe	Attaquant depuis Internet	Services exposés, adresses IP publiques, VPN
Interne	Attaquant déjà dans le réseau	Active Directory, serveurs internes, segmentation

Les vulnérabilités fréquemment découvertes incluent :

• Services obsolètes avec des CVE connues non corrigées
• Ports inutiles ouverts (RDP, SMB exposés sur Internet)
• Mots de passe par défaut sur les équipements réseau
• Segmentation réseau insuffisante permettant des mouvements latéraux
• Configurations Active Directory permissives

Les outils typiques de ce type de pentest comprennent Nmap pour la découverte, Nessus ou OpenVAS pour le scan de vulnérabilités, Metasploit pour l’exploitation, et BloodHound pour l’analyse des chemins d’attaque Active Directory.

Un scénario classique simule un attaquant ayant compromis un poste utilisateur standard. Le pentester démontre comment, à partir de ce point d’entrée, il peut escalader ses privilèges jusqu’à devenir administrateur du domaine et accéder aux serveurs de production.

Red Team et scénarios avancés

Le Red Teaming représente l’approche la plus avancée et la plus réaliste des tests de sécurité. Contrairement à un pentest classique, un exercice Red Team s’étale sur plusieurs semaines voire mois et simule une campagne d’attaque complète.

L’objectif principal n’est pas d’énumérer toutes les failles, mais de tester la capacité de détection et de réaction des équipes de défense : SOC, CERT, RSSI. La Red Team opère en mode furtif, cherchant à atteindre des objectifs précis, définis en amont par le client, sans se faire repérer.

Les scénarios combinent plusieurs vecteurs d’attaque :

• Phishing ciblé (spear phishing) pour obtenir un premier accès
• Exploitation d’une vulnérabilité web comme point d’entrée alternatif
• Mouvement latéral dans le réseau interne
• Élévation de privilèges vers des comptes administrateurs
• Exfiltration simulée de données sensibles

Cette approche est recommandée aux organisations déjà matures en sécurité, disposant d’un SOC opérationnel, de procédures d’incident documentées et d’une cartographie des actifs critiques.

Pentest d’ingénierie sociale

Le pentest d’ingénierie sociale cible le maillon souvent considéré comme le plus faible de la chaîne de sécurité : le facteur humain. Les collaborateurs, prestataires, équipes support et dirigeants font tous partie du périmètre.

Les attaques simulées prennent plusieurs formes :

• Campagnes de phishing par email : envoi de faux messages pour mesurer le taux de clic sur des liens malveillants et la soumission d’identifiants
• Vishing (voice phishing) : appels téléphoniques usurpant l’identité du support IT ou d’un fournisseur pour obtenir des informations
• Intrusion physique : tentative d’accès aux locaux sans badge valide, récupération de documents dans les poubelles (dumpster diving)

L’objectif est de mesurer concrètement la vulnérabilité humaine : quel pourcentage de collaborateurs clique sur un lien suspect ? Combien divulguent leur mot de passe au téléphone ? Quelqu’un ouvre-t-il la porte à un inconnu prétextant une livraison ?

Le cadrage en amont est crucial pour éviter de démotiver les équipes. La population ciblée, les limites de l’exercice et la communication post-campagne doivent être définis précisément. L’objectif n’est pas de piéger les collaborateurs, mais d’améliorer la sécurité globale.

Ces tests doivent être couplés avec des sessions de sensibilisation et des formations pratiques. Un taux de clic élevé sur une campagne de phishing devient une opportunité pédagogique, pas une sanction.

Autres types de pentest (IoT, cloud, systèmes industriels)

Trois domaines spécialisés méritent une attention particulière :

Pentest IoT (objets connectés) : les caméras, capteurs, terminaux de paiement et autres objets connectés présentent souvent des failles critiques. L’analyse porte sur le firmware (extraction et reverse engineering), les communications radio (BLE, Zigbee, LoRa) et les applications mobiles ou web associées. Les mises à jour sont souvent inexistantes ou difficiles à déployer.

Pentest cloud : les environnements Azure, AWS et GCP introduisent des risques spécifiques liés aux erreurs de configuration. Les buckets S3 publics, les rôles IAM trop permissifs, les ports RDP exposés et les secrets stockés en clair dans les variables d’environnement sont des découvertes fréquentes. Les services managés (bases de données, fonctions serverless) nécessitent également une attention particulière.

Pentest industriel (OT/ICS/SCADA) : les automates programmables, superviseurs et réseaux de production présentent des vulnérabilités souvent anciennes et non corrigées. La contrainte majeure est de ne pas perturber l’activité industrielle. Ces tests requièrent une préparation approfondie et se déroulent généralement lors d’arrêts de maintenance planifiés.

Ces trois domaines nécessitent des compétences très spécialisées et des outils dédiés. Peu de prestataires maîtrisent l’ensemble de ces environnements.

Méthodes de pentest : boîte noire, grise et blanche

Les trois approches Black Box, Grey Box et White Box décrivent le niveau d’information fourni au pentester avant le début du projet. Ce choix influence directement le réalisme du test, sa profondeur d’analyse et son efficacité en fonction du temps disponible.

Le choix dépend des objectifs recherchés : simuler une attaque externe réaliste, analyser en profondeur la sécurité d’une application critique, ou optimiser un budget limité. Les contraintes de temps et les ressources disponibles orientent également la décision.

Dans la pratique, de nombreux projets adoptent une approche hybride. Par exemple, une phase de reconnaissance en boîte noire suivie de scénarios ciblés en boîte grise permet de combiner réalisme et efficacité.

Ces approches s’inscrivent dans des méthodologies reconnues comme le Penetration Testing Execution Standard (PTES) et les guides OWASP qui structurent le déroulement des tests.

Une même application peut être testée successivement selon différentes approches à des moments clés de son cycle de vie : boîte noire avant la mise en production, boîte blanche après un refactoring majeur.

Pentest en boîte noire (Black Box)

En approche boîte noire, le pentester ne dispose que des informations publiquement accessibles : nom de domaine, adresses IP découvertes par ses propres moyens, interfaces accessibles sans authentification.

Cette méthode imite fidèlement un attaquant externe qui ne connaît rien de sa cible. Le réalisme constitue son principal atout : les résultats montrent ce qu’un hacker motivé pourrait accomplir avec les mêmes contraintes.

Les étapes typiques d’un pentest black box suivent une progression logique :

1. Collecte OSINT (Open Source Intelligence) : recherche sur les moteurs de recherche, réseaux sociaux, bases de données de fuites
2. Découverte d’actifs : scan réseau, énumération de sous domaines, identification des technologies
3. Identification de vulnérabilités sur les services exposés
4. Exploitation des failles découvertes

Les limites de cette approche sont connues : l’analyse est plus lente car le testeur consacre du temps à la découverte. Les failles profondes, les problèmes de logique métier et les vulnérabilités internes risquent de passer inaperçues faute de contexte.

Un exemple courant : un groupe international exige un pentest black box du portail client de son futur fournisseur avant de signer un contrat majeur. Le test simule exactement ce qu’un concurrent malveillant pourrait tenter.

Pentest en boîte grise (Grey Box)

L’approche boîte grise fournit au pentester un accès utilisateur standard ou une documentation partielle. Cette configuration imite un collaborateur, un client légitime ou un attaquant ayant obtenu des identifiants par phishing.

Cette méthode excelle pour tester :

• La séparation des droits entre différents rôles
• Les possibilités d’élévation de privilèges
• Les failles de logique métier accessibles aux utilisateurs authentifiés
• La protection des données entre tenants dans une application multi-clients

Le temps est mieux utilisé qu’en pure boîte noire. Les étapes de découverte sont accélérées, permettant de consacrer davantage d’efforts à l’analyse approfondie des fonctionnalités critiques.

Prenons l’exemple d’une plateforme SaaS B2B avec trois rôles : utilisateur, manager et administrateur. Le pentester reçoit un compte de chaque type et vérifie qu’un utilisateur standard ne peut pas accéder aux fonctions d’administration, qu’un manager ne peut pas voir les données d’autres équipes, etc.

L’approche grey box est souvent recommandée pour un premier pentest applicatif complet. Elle offre un bon équilibre entre réalisme et exhaustivité.

Pentest en boîte blanche (White Box)

Le pentest en boîte blanche donne au testeur un accès maximal : code source, schémas d’architecture, configurations d’infrastructure, documentation technique et comptes privilégiés de test.

L’objectif est de rechercher des vulnérabilités profondes impossibles à détecter de l’extérieur :

• Erreurs de logique métier dans le code
• Mauvaises pratiques de développement (secrets codés en dur, algorithmes cryptographiques faibles)
• Vulnérabilités dans des composants non exposés directement
• Problèmes d’architecture favorisant les mouvements latéraux

Cette approche se combine naturellement avec des revues de code sécurisées et des tests unitaires de sécurité. Elle s’intègre bien dans une démarche DevSecOps.

Un cas concret : une fintech prépare sa certification PCI DSS en 2025. Elle commande un audit white box complet de son API de paiement. Les pentesters accèdent au code source, aux logs de production anonymisés et à l’architecture complète. Ils identifient une race condition dans le traitement des transactions qui aurait pu permettre des doubles débits.

Le pentest white box nécessite une collaboration étroite entre pentesters, développeurs et architectes. Les résultats sont souvent plus riches, mais le test demande davantage de préparation et de coordination.

Étapes clés d’un test d’intrusion

Un pentest structuré suit des phases séquentielles inspirées des méthodologies reconnues comme PTES (Penetration Testing Execution Standard) et NIST SP 800-115. Cette organisation garantit la traçabilité des actions et la répétabilité des tests.

La durée d’un pentest varie considérablement selon le périmètre. Comptez environ 5 jours ouvrés pour une application web de taille moyenne, 2 à 3 semaines pour un audit d’infrastructure complet, et jusqu’à 4 semaines ou plus pour un exercice Red Team.

La communication continue entre pentesters et client est indispensable. Des points d’avancement réguliers, des canaux sécurisés pour les échanges sensibles et une procédure d’escalade en cas de découverte critique doivent être établis dès le départ.

Le cycle de pentest doit être répété après chaque évolution majeure du système et au minimum une fois par an pour maintenir un niveau de sécurité adapté aux menaces actuelles.

1. Définition du périmètre (scope) et cadrage

Cette phase préliminaire précède toute action technique. Elle se conclut par un document de cadrage validé par les deux parties, qui constitue le contrat moral et technique de la mission.

Les éléments typiques du scope incluent :

Élément	Exemples
Cibles techniques	URL, adresses IP, plages réseau, noms d’applications
Environnements	Production, préproduction, développement
Comptes de test	Identifiants fournis, rôles associés
Fenêtres horaires	Plages autorisées, jours d’exclusion
Contacts	Interlocuteurs techniques, procédure d’escalade

Les règles d’engagement définissent les actions interdites (pas de déni de service, pas d’exfiltration réelle de données clients), les seuils de charge à respecter et les procédures en cas d’incident.

Un site de commerce en ligne choisit par exemple de limiter le pentest à l’environnement de préproduction pour éviter tout impact sur les clients finaux. Les données de test sont anonymisées mais représentatives.

Le RSSI et les équipes techniques doivent être impliqués dès cette étape. Leur connaissance du système et des contraintes opérationnelles est essentielle pour définir un scope réaliste et utile.

2. Reconnaissance et collecte d’informations

La phase de reconnaissance consiste à rassembler toutes les informations disponibles sur la cible pour cartographier sa surface d’attaque.

La collecte d’informations publiques (OSINT) exploite de nombreuses sources :

• Enregistrements DNS et données WHOIS
• Moteurs de recherche (Google dorks, Bing)
• Réseaux sociaux professionnels (LinkedIn pour identifier les employés et technologies)
• Bases de données de fuites (Have I Been Pwned, DeHashed)
• Archives web (Wayback Machine)

Les outils techniques complètent cette recherche passive. Nmap scanne les ports et services, Shodan recense les équipements exposés sur Internet, theHarvester collecte les emails et sous domaines, Amass cartographie l’infrastructure DNS.

Cette étape permet de dresser une première carte de la surface d’attaque. Elle révèle parfois des surprises : un sous-domaine d’administration oublié mais toujours accessible, un serveur de développement exposé par erreur, ou une ancienne version d’application encore en ligne.

Même avec un scope restreint, aucune action ne doit viser des systèmes non autorisés. La frontière entre reconnaissance légitime et intrusion illégale doit rester parfaitement claire.

3. Analyse de vulnérabilités

L’analyse de vulnérabilités recherche systématiquement les failles potentielles sur la base des informations collectées. Elle combine approches automatisées et tests manuels.

Les scanners de vulnérabilités comme Nessus, OpenVAS ou Qualys identifient les failles connues : versions logicielles obsolètes, CVE non corrigées, configurations par défaut dangereuses. Pour les applications web, Nikto et les scanners intégrés à Burp Suite complètent l’arsenal.

L’expertise humaine reste indispensable pour :

• Filtrer les faux positifs générés par les outils automatisés
• Contextualiser les résultats en fonction de l’environnement
• Identifier les failles de logique métier invisibles aux scanners
• Découvrir les chaînages de vulnérabilités mineures

Les découvertes typiques incluent un serveur web Apache dans une version vulnérable, une bibliothèque JavaScript avec une CVE critique, un formulaire sans validation côté serveur permettant des injections, ou un service d’administration accessible sans authentification forte.

Les vulnérabilités jugées prometteuses sont sélectionnées pour la phase suivante. L’exploitation validera leur impact réel.

4. Exploitation et post‑exploitation

L’exploitation transforme une vulnérabilité théorique en accès réel. C’est la phase qui démontre concrètement l’impact d’une faille sur l’entreprise.

Les techniques d’exploitation varient selon le contexte :

• Injection SQL pour extraire des données de la base
• Exécution de code à distance via une CVE non corrigée
• Contournement d’authentification pour accéder à des fonctions privilégiées
• Exploitation de mots de passe faibles ou réutilisés

La post-exploitation mesure jusqu’où un attaquant peut aller après un premier accès :

• Élévation de privilèges : passer d’un compte utilisateur à un compte administrateur
• Mouvement latéral : atteindre d’autres systèmes depuis le point d’entrée initial
• Persistance : maintenir l’accès malgré les redémarrages ou changements de mot de passe
• Accès aux données sensibles : démontrer la capacité à exfiltrer des informations critiques

Des outils comme Metasploit, Empire ou CrackMapExec facilitent ces opérations. Pour les environnements Active Directory, BloodHound cartographie les chemins d’attaque vers les comptes à privilèges.

Un scénario classique : le pentester exploite un mot de passe faible sur un compte de service, l’utilise pour se connecter à un serveur, y découvre des identifiants d’administration stockés en clair, et démontre qu’il peut prendre le contrôle complet du domaine Active Directory.

Les données réellement sensibles ne sont jamais utilisées au-delà de la démonstration minimale nécessaire. Le pentester documente ce qu’il aurait pu faire sans le faire réellement.

5. Rapport de pentest et restitution

Le rapport constitue le livrable principal du pentest. Sa qualité détermine la valeur réelle de la mission pour le client.

La structure typique d’un rapport comprend :

• Résumé exécutif : synthèse en langage non technique pour la direction, avec niveau de risque global et recommandations prioritaires
• Périmètre et méthodologie : rappel du scope, des conditions de test et de l’approche utilisée
• Résultats détaillés : chaque vulnérabilité documentée avec description, preuves (captures d’écran, logs, payloads), évaluation de criticité et recommandations de correction
• Scénarios d’attaque : démonstration des chaînages de failles et de leur impact métier
• Annexes techniques : données brutes, configurations testées, outils utilisés

Chaque vulnérabilité est classée par criticité selon une grille interne ou le score CVSS v3.1. Les recommandations de correction sont concrètes et actionnables, pas de vagues conseils du type “améliorer la sécurité”.

La restitution se fait généralement en réunion, en présentiel ou en visioconférence, avec les équipes techniques et les décideurs métiers. Cette session permet de contextualiser les résultats, de répondre aux questions et de prioriser les actions de remédiation.

Un livrable complémentaire appréciable : une synthèse managériale d’une page destinée à la direction générale ou aux investisseurs, vulgarisant les enjeux sans entrer dans les détails techniques.

Planifier un retest ciblé permet de vérifier la bonne mise en œuvre des corrections les plus critiques quelques semaines voire mois après le rapport initial.

Pentest, scan de vulnérabilités et bug bounty : comment choisir ?

Trois approches complémentaires permettent d’évaluer la sécurité d’un système. Leur combinaison offre une couverture optimale.

Le scan de vulnérabilités est une analyse automatisée, rapide et peu coûteuse. Il identifie les failles connues (CVE, configurations par défaut) sur un large périmètre. Ses limites : beaucoup de faux positifs, pas de validation d’exploitation, incapacité à détecter les failles de logique métier. C’est un excellent outil de première ligne pour un diagnostic initial ou un suivi régulier.

Le pentest va beaucoup plus loin. Un expert humain valide les vulnérabilités, les exploite de manière contrôlée et démontre leur impact réel. L’analyse est contextualisée, les faux positifs sont éliminés, et les failles complexes sont identifiées. Le coût est plus élevé, mais la valeur ajoutée est considérable pour les périmètres critiques.

Le bug bounty ouvre la recherche de failles à une communauté externe de chercheurs via des plateformes spécialisées (YesWeHack, HackerOne, Bugcrowd). Le modèle de rémunération à la faille découverte est attractif, mais nécessite une maturité sécurité préalable pour trier et corriger le flux de rapports.

Approche	Forces	Limites	Maturité requise
Scan de vulnérabilités	Rapide, large, automatisé	Faux positifs, pas d’exploitation	Faible
Pentest	Profond, contextualisé, actionnable	Ponctuel, coût plus élevé	Moyenne
Bug bounty	Continu, diversité des approches	Volume de rapports à gérer	Élevée

Une combinaison efficace pour une entreprise moyenne : scan de vulnérabilités hebdomadaire automatisé, pentest annuel complet sur les actifs critiques, et éventuellement bug bounty privé sur les fonctionnalités les plus exposées.

Pour un premier diagnostic, commencez par un scan. Pour les systèmes critiques (paiement, données personnelles, accès partenaires), le pentest est incontournable. Le bug bounty convient aux organisations déjà matures avec des processus de correction établis.

Outils et ressources couramment utilisés en pentest

L’arsenal du pentester combine des outils open source et commerciaux, organisés par phase du test.

Reconnaissance et OSINT : Nmap reste l’outil de référence pour la découverte réseau et l’énumération de services. Amass et Sublist3r cartographient les sous domaines. TheHarvester collecte emails et informations publiques. Maltego visualise les relations entre entités. Recon-ng automatise les workflows de reconnaissance. Shodan et Censys recensent les équipements exposés sur Internet.

Analyse de vulnérabilités : Nessus (commercial) et OpenVAS (open source) dominent le marché des scanners d’infrastructure. Qualys offre une solution cloud pour les grandes organisations. Pour le web, Nikto détecte les configurations dangereuses et les fichiers sensibles exposés.

Exploitation : Metasploit Framework est la référence pour le développement et l’exécution d’exploits. CrackMapExec facilite les attaques sur les réseaux Windows et Active Directory. BloodHound cartographie graphiquement les chemins d’attaque vers les comptes privilégiés dans l’AD. Impacket fournit une collection de scripts Python pour manipuler les protocoles réseau.

Tests web et applicatifs : Burp Suite Professional est l’outil central des pentesters web, combinant proxy d’interception, scanner automatisé et extensions via le BApp Store. OWASP ZAP offre une alternative open source complète. Sqlmap automatise la détection et l’exploitation des injections SQL. Nuclei permet d’exécuter des templates de détection de vulnérabilités à grande échelle.

Environnement de travail : Kali Linux reste la distribution de référence avec plus de 600 outils préinstallés. Parrot Security OS offre une alternative plus légère. Exegol propose un environnement conteneurisé Docker avec des outils à jour et une configuration optimisée pour les tests d’intrusion professionnels.

Purple Team : la synergie entre attaque et défense

Entre les approches offensives du Red Teaming et défensives du Blue Teaming, le Purple Teaming incarne une démarche collaborative où les deux univers travaillent ensemble pour améliorer continuellement la posture de sécurité. Plutôt qu’un affrontement simulé, il s’agit d’un exercice coordonné : les attaquants (Red Team) exécutent des scénarios réalistes pendant que les défenseurs (Blue Team) observent, détectent, réagissent et affinent leurs mécanismes de défense.

Cette approche favorise une boucle d’apprentissage directe, permettant d’ajuster en temps réel les outils de détection, les règles de corrélation ou les procédures de réponse du SOC. En pratique, une session de Purple Teaming transforme chaque attaque simulée en opportunité de renforcement défensif concret. Ce modèle est particulièrement adapté aux organisations déjà dotées d’un SOC mature souhaitant mesurer l’efficacité opérationnelle de leurs mesures de détection et de réponse aux incidents, tout en renforçant la coopération entre les équipes offensives et défensives.

Foire aux questions (FAQ)

À quelle fréquence une entreprise devrait-elle réaliser un pentest ?

Un rythme minimum annuel est recommandé pour les systèmes critiques traitant des données sensibles ou des paiements. Au-delà de cette fréquence de base, des tests supplémentaires doivent être planifiés avant chaque mise en production majeure : lancement d’une nouvelle application, refactoring important du code, migration vers le cloud. Les entreprises très exposées comme les banques, les opérateurs télécoms ou les éditeurs de SaaS sensibles planifient souvent des campagnes trimestrielles ou semestrielles. Les exigences réglementaires comme PCI DSS imposent également des fréquences spécifiques.

Le pentest interrompt-il les services en production ?

L’objectif est de minimiser tout impact sur les opérations. Les tests les plus intrusifs sont planifiés en heures creuses ou sur des environnements de préproduction. Certaines actions comme les tests de déni de service ou les tests de charge sont généralement exclues du périmètre sauf demande explicite. En cas de risque identifié pendant le test (service instable, comportement inattendu), les pentesters coordonnent immédiatement avec les équipes internes pour suspendre l’action concernée. Un bon cadrage préalable et une communication continue réduisent ces risques à un niveau très faible.

Combien de temps dure un test d’intrusion typique ?

La durée varie considérablement selon le périmètre et l’approche. Un pentest ciblé d’application web dure généralement de 3 à 10 jours ouvrés selon la complexité fonctionnelle. Un audit d’infrastructure réseau de taille moyenne s’étale sur 1 à 2 semaines voire mois. Un exercice Red Team complet peut durer plusieurs mois pour les grandes organisations. Le temps nécessaire dépend du scope défini, de l’approche choisie (black box plus longue que white box à périmètre égal) et du niveau de profondeur attendu.

Quelle est la différence entre un pentest interne et un pentest externe ?

Un pentest externe simule un attaquant venant d’Internet, sans accès préalable au réseau de l’entreprise. Il cible les systèmes exposés publiquement : sites web, API, VPN, serveurs de messagerie. Un pentest interne part du principe que l’attaquant a déjà un pied dans le réseau, par exemple via un poste de travail compromis, un accès VPN détourné ou un collaborateur malveillant. Il évalue la segmentation réseau, la sécurité de l’Active Directory et la protection des ressources internes. Les deux approches sont complémentaires et souvent combinées dans un audit global.

Que faire après la réception d’un rapport de pentest ?

La première étape consiste à organiser une réunion de restitution avec les équipes techniques pour bien comprendre chaque vulnérabilité et son contexte. Ensuite, priorisez les corrections à partir de la criticité indiquée : les failles critiques et hautes doivent être traitées en priorité. Établissez un calendrier de remédiation réaliste en impliquant les équipes concernées (développement, infrastructure, métiers). Si possible, demandez un retest ciblé pour valider que les corrections des failles les plus critiques sont effectives. Enfin, capitalisez sur les enseignements pour améliorer vos processus de développement sécurisé et la sensibilisation des équipes.