23 juin 2026 Astuces .

Types de pentest : guide complet pour choisir le bon test d'intrusion

Web, API, DNS, OSINT, cloud, mobile, subdomain takeover : ce guide couvre 18 types de tests d'intrusion, ce que chaque approche teste réellement, et comment choisir selon votre contexte.

11h02. Vous êtes RSSI et vous devez valider la mise en production d'une nouvelle application. Votre client vous demande une seule chose avant de signer : la preuve d'un test d'intrusion récent.

9h14. Vous êtes CEO. Un prestataire vous appelle pour vous demander si votre site est sécurisé, parce qu'il vient de repérer un sous-domaine qui répond bizarrement. Vous répondez que vous allez lancer un audit offensif pour vérifier.

16h40. Vous êtes compliance manager. Un contrôle réglementaire vous demande de justifier la dernière date de test sur votre périmètre exposé. Vous réalisez que la réponse dépend du type de pentest qu'on vous a livré, et de ce qu'il couvrait vraiment.

Trois moments, trois rôles, la même question en fond : quel type de pentest répond à cette situation précise ?

En 2025, 97 % des organisations ont subi une violation liée à leur chaîne d'approvisionnement ou à un actif non maîtrisé (SecurityScorecard 2025). Dans la majorité des cas documentés, l'actif compromis n'était dans le périmètre d'aucun pentest précédent.

À retenir

  • Il existe 3 méthodologies de base : black-box (zéro info), grey-box (info partielle), white-box (info complète)

  • Le périmètre définit ce qui est testé : web, API, DNS, OSINT, cloud, réseau, mobile, ingénierie sociale, et plus encore

  • Pour la majorité des organisations : commencer par l'externe (web, API, DNS, OSINT), en continu

  • Un pentest ponctuel est obsolète le lendemain de sa remise : la surface d'attaque évolue en permanence

  • Certains périmètres (cloud profond, DevOps, IoT) nécessitent un accès initial pour aller au-delà de la détection d'exposition

Black-box, grey-box, white-box : quelle méthodologie de pentest choisir ?

La première distinction à maîtriser est celle des méthodologies, aussi appelées "boîtes" (boîte noire, boîte grise, boîte blanche) en référence à la quantité d'information fournie au testeur avant le début du test. Le pentest black box, ou boîte noire, est la méthodologie la plus utilisée pour évaluer la sécurité d'un système exposé sur Internet.

Black-box : zéro information fournie

Le testeur ne dispose d'aucune information préalable sur la cible : architecture, technologies, accès. Il opère exactement comme un attaquant externe : depuis zéro, avec uniquement un nom de domaine ou une adresse IP comme point de départ.

C'est la méthodologie qui donne la vision la plus réaliste de votre exposition réelle. Elle révèle aussi les actifs que vous n'avez pas déclarés dans votre inventaire.

Idéal pour : simuler une attaque externe réaliste, tester l'exposition Internet, valider la posture de sécurité externe, découvrir les actifs inconnus et renforcer la sécurité du périmètre en conséquence.

Grey-box : information partielle fournie

Le testeur dispose d'informations partielles : accès utilisateur standard, documentation d'architecture limitée, ou connaissance de certaines technologies utilisées. Simule un attaquant avec un accès initial : employé malveillant, credential volé, accès partenaire compromis.

Idéal pour : tests applicatifs avec accès authentifié, simulation d'une menace interne (employé malveillant ou compromis), test des fonctionnalités réservées aux utilisateurs connectés.

White-box (boîte blanche) : information complète fournie

Le testeur dispose de toutes les informations : code source, architecture complète, accès administrateur, documentation technique. Permet une couverture maximale, y compris des vulnérabilités non visibles depuis l'extérieur.

Idéal pour : audit de code, revue d'architecture, conformité ISO 27001, audits PASSI (Prestataire d'Audit de la Sécurité des Systèmes d'Information, qualification ANSSI obligatoire pour certaines réglementations françaises).

En résumé : les différents types de tests selon votre objectif

ObjectifMéthodologie recommandéePourquoi
Simuler une attaque externe réaliste Black-box Reproduit la perspective d'un attaquant sans information préalable
Tester une application avec login Grey-box Couvre les fonctionnalités authentifiées et les privilèges
Audit de code avant mise en production White-box Couverture exhaustive du code source et de l'architecture
Conformité NIS2/DORA Grey-box + White-box Les référentiels exigent une couverture documentée
Validation continue de l'exposition Internet Black-box continu La surface d'attaque évolue. Seul le test continu garantit la couverture

Les périmètres de pentest externe : applications web, API, DNS et OSINT

Ces quatre familles couvrent ce qu'un attaquant voit en premier : votre exposition publique sur Internet, sans avoir besoin d'un accès initial.

Pentest des applications web et site web : la surface la plus visible

Le pentest web teste la sécurité de tout ce qui est accessible via un navigateur : site institutionnel, application métier, plateforme transactionnelle. C'est historiquement le périmètre le plus testé en cybersécurité, et celui qui concentre le plus grand nombre de vulnérabilités documentées.

Qui est concerné : toute organisation avec un site corporate, une plateforme ou une application accessible publiquement. C'est la cible la plus fréquente des attaques opportunistes.

Le pentest web se décline en plusieurs niveaux de profondeur. Un test sur un site web vitrine ou corporate cible principalement les failles OWASP Top 10 (liste des 10 vulnérabilités web les plus critiques) et les erreurs de configuration serveur : SSL/TLS faible, mauvais durcissement NGINX ou Apache. Un test sur une application web va plus loin : il cible la logique métier, l'authentification, et les interactions utilisateur pour évaluer la résistance aux injections et aux attaques orientées données. Un test sur une plateforme web (e-commerce, SaaS, extranet) combine application, infrastructure et APIs. Des actions réelles sont testées plutôt qu'une simple analyse informationnelle, car ces plateformes gèrent des flux critiques de données et de transactions.

TypeVecteurs testésImpact techniqueImpact métier
Site web OWASP Top 10, SSL/TLS faible, config serveur Serveur compromis, contenu remplacé Site hors ligne ou défiguré, perte de crédibilité visible publiquement
Application web Injection, authentification cassée, gestion d'erreurs Base de données accédée, comptes utilisateurs détournés Vol de données clients (emails, mots de passe, coordonnées), comptes utilisateurs piratés
Plateforme web Failles logiques, élévation de privilèges, session management Accès non autorisé aux fonctions admin, contournement des contrôles métier Fraude financière, fuite de données de paiement ou de transactions, perte de confiance des utilisateurs

Outils et techniques : OWASP ZAP, Burp Suite, Nuclei pour la détection automatisée OWASP Top 10. XSS (injection de script), SQLi (injection SQL), CSRF (falsification de requête), LFI/RFI (inclusion de fichier malveillant), IDOR (accès non autorisé via manipulation d'identifiants), SSRF (forcer le serveur à effectuer des requêtes internes) sont les vecteurs les plus fréquemment testés.

Pentest API : la porte d'entrée des applications modernes

Le pentest API teste les interfaces de programmation qui permettent à des applications de communiquer entre elles, indépendamment de toute interface visuelle. Une API peut être attaquée directement, sans jamais passer par le site web ou l'application qui l'utilise.

Qui est concerné : tout éditeur SaaS, application mobile ou plateforme qui expose des fonctionnalités via API REST, GraphQL ou SOAP. C'est la quasi-totalité des services numériques modernes.

Les APIs exposent des fonctionnalités et des données aux applications mobiles, web et tierces. Les tests ciblent la logique métier, l'authentification et la résilience face aux abus et au bruteforce (essai automatisé de combinaisons pour deviner un mot de passe).

Vecteurs testés : Broken Authentication (authentification mal sécurisée), absence de rate limiting (limitation du nombre de requêtes), injections, Broken Object Level Authorization, BOLA (accès à des ressources d'autres utilisateurs en manipulant les identifiants).

Impact technique : API mise hors service (déni de service), prise de contrôle complète de l'API par un tiers, accès aux données d'autres utilisateurs sans autorisation.

Impact métier : fuite de données personnelles ou financières de vos clients, service indisponible pour tous les utilisateurs pendant l'incident, obligation de notification CNIL en cas de données personnelles concernées.

Pentest DNS : la première étape avant le site web

Le pentest DNS teste la résilience du système qui traduit un nom de domaine en adresse réseau. C'est une couche souvent oubliée des audits de sécurité, alors qu'elle conditionne l'accès à tous les autres services.

Qui est concerné : toute organisation avec un nom de domaine public, donc systématiquement.

Concrètement, ce test évalue la résilience de votre infrastructure de résolution de noms contre des attaques type transfert de zone (exposition de la liste complète des sous-domaines), empoisonnement de cache (corruption des réponses DNS mises en cache) et détournement DNS. Dans la logique d'exploitation d'un attaquant, le DNS est souvent testé avant même le site web. C'est le point d'entrée qui révèle l'architecture complète d'un domaine.

Impact technique : trafic redirigé vers une infrastructure contrôlée par l'attaquant, réponses DNS falsifiées pour tous les visiteurs.

Impact métier : vos clients redirigés vers un faux site qui vole leurs identifiants ou leurs données de paiement, emails interceptés, usurpation complète de votre présence en ligne pendant l'incident.

OSINT automatisé : ce qu'un attaquant trouve sans vous toucher

L'OSINT teste ce qu'un attaquant peut apprendre sur votre organisation sans jamais interagir avec vos systèmes, uniquement à partir de sources publiques. Aucune connexion, aucune requête vers vos serveurs : tout se fait depuis l'extérieur, en silence.

Qui est concerné : toute organisation présente publiquement, ce qui inclut de fait toutes les organisations.

L'OSINT (Open Source Intelligence, renseignement à partir de sources ouvertes) consiste en la collecte automatisée d'informations publiques sur l'entreprise et ses actifs via des outils comme Shodan ou Censys, qui indexent en continu les services exposés sur Internet.

Ce qui est trouvé : métadonnées exposées, informations sensibles dans les bannières de services, technologies utilisées, organigramme déductible des offres d'emploi.

Impact technique : cartographie complète de votre infrastructure et de vos technologies, disponible pour préparer une attaque ciblée ultérieure.

Impact métier : aucun dommage direct et immédiat, mais c'est l'étape de reconnaissance qui précède presque toujours un incident plus grave. L'OSINT seul ne casse rien : il prépare ce qui va casser quelque chose ensuite.

Brand Protection, Shadow IT et Subdomain Takeover

Ces trois périmètres ciblent un problème commun : ce que votre organisation expose sans le savoir ou sans le contrôler.

Shadow IT Discovery : l'inventaire que personne n'a fait

La découverte de Shadow IT teste ce que votre organisation expose sur Internet sans que l'équipe sécurité ou la DSI en ait connaissance. C'est moins un test d'intrusion classique qu'un exercice de cartographie, mais le résultat alimente directement les autres types de pentest externe.

Qui est concerné : toute organisation avec plus de 50 actifs Internet, des équipes dev autonomes, ou un historique de fusions-acquisitions.

La découverte de Shadow IT identifie les actifs externes non inventoriés exposés publiquement : sous-domaines créés pour un projet pilote, services SaaS souscrits sans validation IT, adresses IP publiques jamais documentées. Cette découverte s'appuie sur les mêmes techniques que l'OSINT, orientées spécifiquement vers la cartographie exhaustive du périmètre.

Impact technique : actifs non patchés, non surveillés, souvent avec des configurations par défaut jamais durcies.

Impact métier : un service que personne ne savait exposé devient le point d'entrée d'un incident, sans qu'aucune équipe ne soit en position de le détecter rapidement, ni même de savoir à qui appartient l'actif compromis.

Subdomain Takeover : le sous-domaine qui ne vous appartient plus vraiment

Le test de subdomain takeover identifie les sous-domaines dont l'entrée DNS pointe encore vers un service tiers qui n'existe plus. C'est l'équivalent numérique de garder une boîte aux lettres à votre nom après avoir déménagé : le nouvel occupant peut recevoir votre courrier, et personne d'autre ne s'en aperçoit. C'est un vecteur d'attaque qui ne nécessite aucune faille technique au sens classique, juste une négligence administrative.

Qui est concerné : toute organisation qui a utilisé un service tiers (CDN, hébergeur, plateforme SaaS) pour un sous-domaine, puis a arrêté ce service sans retirer l'entrée DNS associée.

Un subdomain takeover se produit quand un sous-domaine pointe vers un service tiers qui n'existe plus ou n'est plus configuré. Exemple concret : promo.monentreprise.com pointait vers une instance d'un service d'emailing marketing arrêtée il y a un an. L'entrée DNS existe toujours. Un attaquant peut créer un compte sur ce même service, revendiquer ce sous-domaine, et l'utiliser pour héberger un site de phishing sous un nom de domaine qui semble parfaitement légitime.

Impact technique : le sous-domaine est entièrement contrôlé par un tiers, sans qu'aucune faille technique classique n'ait été exploitée.

Impact métier : des clients reçoivent un email ou visitent une page de phishing hébergée sous votre propre nom de domaine, pensant légitimement avoir affaire à votre entreprise. C'est l'un des vecteurs les plus sous-estimés parce qu'il ne dépend d'aucune vulnérabilité technique, juste d'une entrée DNS oubliée.

Dark Web et fuites de credentials

La surveillance du dark web teste si des identifiants liés à votre organisation circulent déjà dans des bases de fuites ou des marketplaces criminelles, indépendamment de toute vulnérabilité présente dans vos systèmes.

Qui est concerné : toute organisation, particulièrement celles avec un historique d'incidents chez des tiers ou des employés utilisant des mots de passe réutilisés.

La surveillance du dark web identifie les identifiants liés à votre organisation qui circulent dans des bases de fuites ou des marketplaces criminelles, souvent issus d'une violation chez un tiers totalement extérieur à votre SI.

Impact technique : un attaquant se connecte directement avec des credentials valides, sans avoir besoin d'exploiter aucune vulnérabilité technique.

Impact métier : accès complet à un compte employé ou client comme s'il s'agissait du titulaire légitime, ce qui rend l'intrusion quasiment indétectable jusqu'à ce qu'une action suspecte soit constatée.

Pentest réseau, infrastructure et système d'information global

Le pentest réseau teste la résistance de l'infrastructure qui relie vos systèmes entre eux : équipements, segmentation, règles de filtrage. Il peut couvrir uniquement ce qui est exposé sur Internet, ou s'étendre à l'ensemble du système d'information.

Qui est concerné : organisations avec une infrastructure réseau structurée, plusieurs zones (DMZ, LAN, WAN), ou la nécessité d'une vue d'ensemble sur l'exposition de tout le SI.

Le pentest réseau se décline en deux profondeurs. En externe, il cible les services exposés sur Internet : versions SSH, partages SMB exposés, serveurs FTP, ports non standards, sans toucher au web applicatif. En interne, il s'étend à l'Active Directory (annuaire de gestion des identités Windows), aux serveurs internes et à la segmentation réseau.

Le pentest du système d'information global combine tests techniques, audits de process et tests organisationnels pour évaluer l'ensemble du SI d'une entreprise, incluant la cartographie des noms de domaine et de leurs relations, le Shadow IT, et les processus de gestion des accès.

PérimètreVecteurs testésImpact techniqueImpact métier
Réseau externe Services obsolètes, mauvaise config firewall, ports exposés Accès non autorisé au réseau, point de pivot vers d'autres systèmes Service interrompu pour les utilisateurs, première étape d'une compromission plus large
Réseau interne Sniffing, MITM (interception de trafic), VLAN hopping, segmentation insuffisante Trafic interne intercepté, déplacement entre systèmes sans détection Données confidentielles internes (RH, finance, stratégie) interceptées en clair
SI global Shadow IT, configurations faibles, processus défaillants Compromission de plusieurs systèmes simultanément Arrêt d'activité prolongé, fuite de données touchant plusieurs métiers de l'entreprise en même temps

Cloud, DevOps et IoT : exposition externe et exploitation en profondeur

Ces trois familles ont un point commun : on peut les tester à deux niveaux de profondeur différents. Le premier niveau, la détection d'exposition, est observable depuis l'extérieur sans accès particulier. Le deuxième niveau, l'exploitation en profondeur des configurations internes, nécessite généralement un point d'entrée déjà obtenu : une faille trouvée ailleurs, des identifiants, ou des clés d'accès.

Pentest cloud : configurations et expositions

Le pentest cloud teste la sécurité des ressources hébergées chez un fournisseur cloud public, qu'il s'agisse de stockage, de calcul ou de gestion des accès.

Qui est concerné : toute organisation hébergeant des données ou services dans le cloud public. La mauvaise configuration du cloud est la première cause d'exposition de données en 2025, devant les exploits techniques classiques.

La détection automatisée identifie les ressources cloud exposées publiquement : buckets S3 ou Azure Blob ouverts, bases Elasticsearch accessibles sans authentification, instances mal configurées. Aller plus loin, en auditant les rôles IAM (Identity and Access Management, gestion des droits d'accès cloud) en profondeur ou en exploitant des permissions trop larges, nécessite généralement des clés d'accès initiales, dont la portée dépend des permissions associées. Un rôle IAM trop permissif revient à donner les clés de tout un bâtiment à quelqu'un qui n'avait besoin d'accéder qu'à une seule salle : tant que personne n'essaie les autres portes, le problème reste invisible.

Impact technique : données copiées hors de votre infrastructure cloud, ressources cloud détournées pour héberger une activité malveillante, déplacement vers d'autres services cloud connectés.

Impact métier : vol massif de données clients stockées dans le cloud (souvent des To de données en une fois), facture cloud explosée si l'infrastructure est utilisée pour du minage ou des attaques par un tiers, obligation de notification réglementaire.

DevOps : pipelines CI/CD et secrets exposés

Le pentest DevOps teste la sécurité des chaînes d'intégration et de déploiement automatisées qui transforment du code en application en production, souvent sans validation humaine à chaque étape.

Qui est concerné : toute organisation avec des pipelines de déploiement automatisés : GitLab, GitHub Actions, Jenkins.

La détection automatisée identifie les assets DevOps exposés publiquement. Aller au-delà, en auditant un pipeline CI/CD en profondeur, nécessite un accès initial : une faille trouvée sur un autre périmètre, ou une base de données exposée donnant accès aux secrets de configuration.

Impact technique : clés d'accès et mots de passe de production récupérés directement depuis le code, pipeline de déploiement détourné.

Impact métier : code malveillant déployé automatiquement en production sans qu'aucun humain ne valide l'action, ce qui peut toucher tous les clients utilisant le service en quelques minutes.

IoT et objets connectés : entre exposition réseau et analyse physique

Le pentest IoT teste la sécurité des objets connectés, à la fois sur le plan réseau (ce qu'ils exposent en ligne) et sur le plan physique (le matériel et son logiciel embarqué).

Qui est concerné : toute organisation avec des objets connectés, qu'ils soient exposés sur Internet ou seulement accessibles depuis le réseau interne. Caméras de surveillance, imprimantes réseau, badges d'accès, capteurs industriels, équipements médicaux connectés : le périmètre IoT est large et souvent mal cartographié.

Le pentest IoT complet couvre deux dimensions distinctes. La première est l'exposition réseau : ports ouverts, services accessibles, absence de chiffrement sur les communications. La deuxième est l'analyse physique et logicielle de l'objet lui-même : extraction et analyse du firmware (le logiciel embarqué dans l'appareil), test des interfaces physiques (ports de débogage, connecteurs), reverse engineering du matériel. Cette deuxième dimension nécessite un accès physique à l'objet et des compétences spécialisées en sécurité matérielle.

Vecteurs testés : ports ouverts, firmware vulnérable ou jamais mis à jour, absence de chiffrement sur les communications, interfaces de débogage laissées actives, identifiants par défaut jamais changés.

Impact technique : appareil contrôlé à distance par un tiers, intégré dans un réseau de machines compromises (botnet) sans que l'utilisateur s'en aperçoive, firmware modifié pour y insérer une porte dérobée.

Impact métier : caméras de surveillance utilisées pour espionner vos locaux, imprimantes utilisées comme point d'entrée vers le réseau interne, arrêt d'une chaîne de production si l'objet IoT pilote un processus industriel, compromission de la chaîne d'approvisionnement si l'objet fait partie d'un produit commercialisé.

Les périmètres hors automatisation : mobile, ingénierie sociale, physique, red team

Ces quatre familles nécessitent une intervention humaine spécialisée. Elles ne sont pas automatisables par construction.

Application mobile. Le pentest mobile couvre l'app iOS ou Android, les APIs back-end associées et les serveurs. Il se concentre sur le reverse engineering (rétro-ingénierie du binaire), le stockage non sécurisé de données et l'analyse cryptographique.

Impact technique : code de l'application décompilé et analysé, secrets ou clés API extraits du binaire, communications interceptées.

Impact métier : données personnelles des utilisateurs (localisation, contacts, historique) exposées, application clonée et republiée avec du code malveillant ajouté (repackaging), ce qui peut tromper vos propres clients.

Ingénierie sociale. Teste la vigilance humaine face à des scénarios d'arnaque : phishing, vishing (hameçonnage vocal). Simule l'exploitation des faiblesses humaines plutôt que techniques.

Impact technique : identifiants de connexion récupérés directement auprès d'un employé, logiciel malveillant installé suite à l'ouverture d'une pièce jointe.

Impact métier : accès complet au SI obtenu sans avoir touché à aucun système technique, premier maillon de la majorité des grandes compromissions documentées ces dernières années.

Thick client. Les logiciels desktop installés localement peuvent être attaqués via reverse engineering, manipulation mémoire ou décryptage de données locales. Vecteurs : stockage d'identifiants en clair, debug actif, DLL hijacking (détournement de bibliothèque logicielle).

Impact technique : identifiants stockés en clair récupérés directement sur le poste de travail, mémoire de l'application manipulée pour contourner des contrôles.

Impact métier : un seul poste compromis donne accès aux mêmes identifiants et données que l'utilisateur légitime, sans qu'aucune alerte réseau ne se déclenche.

Physique et red team. Les tests physiques visent à pénétrer des locaux sécurisés ou contourner des contrôles d'accès. Le red team combine tous les vecteurs (technique, physique, social) pour simuler une attaque réaliste complète contre la défense globale de l'organisation.

Impact technique : accès physique à des serveurs, postes de travail ou équipements réseau non protégés contre une intrusion sur site.

Impact métier : vol de matériel contenant des données sensibles, accès direct aux systèmes sans passer par aucune protection numérique, ce qui rend obsolètes tous les investissements en cybersécurité purement logicielle.

Simulation de phishing. Campagne simulée testant la vigilance des collaborateurs face à des emails malveillants. Elle est distincte de l'ingénierie sociale générale, car c'est un exercice répété et mesuré dans le temps plutôt qu'un test ponctuel.

Impact mesuré : taux de clic sur les liens piégés, taux de saisie d'identifiants sur de fausses pages de connexion, taux de signalement aux équipes sécurité. Ces métriques servent à mesurer la progression de la sensibilisation dans le temps, pas

Comment choisir son type de pentest selon son contexte

Le bon type de pentest dépend de trois facteurs : votre niveau de maturité sécurité, votre contexte réglementaire et la nature de vos actifs exposés. Évaluer la sécurité d'un système ne se résume pas à cocher une case réglementaire : c'est un choix qui doit refléter ce qui est réellement exposé et exploitable.

Deux erreurs sont fréquentes. La première : choisir le pentest le moins cher plutôt que le plus adapté au périmètre réellement exposé. La deuxième : traiter le pentest comme une obligation annuelle plutôt que comme un outil de pilotage continu du risque.

Ce que chaque rôle cherche généralement en priorité :

Vous êtesVotre besoin principalTypes de pentest prioritaires
RSSI Vision complète et continue de l'exposition réelle Externe continu, web, API, réseau
CEO / dirigeant Éviter l'incident qui fait la une et engage la responsabilité de l'entreprise Externe continu, Shadow IT, Subdomain Takeover
DevOps / équipe technique Détecter les secrets et configurations à risque avant la mise en production Cloud, DevOps, API
Compliance manager / risk manager Démontrer une conformité documentée à un auditeur ou un régulateur Grey-box, White-box, SI global, Red team (selon secteur)
Responsable produit / CTO (SaaS) Garantir la sécurité de l'app à chaque release sans ralentir les déploiements Web, API, Cloud, en continu
DSI (grand groupe multi-filiales) Couvrir un périmètre hérité de fusions-acquisitions, souvent mal cartographié Externe continu, Shadow IT, réseau interne ponctuel

Pourquoi le pentest ponctuel ne suffit plus

La limite fondamentale de tout pentest ponctuel, quelle que soit sa méthodologie ou son périmètre, est la même : il est obsolète dès le lendemain de sa remise.

Les surfaces d'attaque modernes évoluent en continu. Chaque déploiement DevOps, chaque migration cloud, chaque nouveau service SaaS crée de nouvelles expositions. Automatiser la sécurité d'un système devient alors nécessaire : des outils automatisés permettent une analyse de vulnérabilités en continu, là où un audit humain ponctuel ne peut couvrir qu'un instant figé. Une organisation qui déploie du code quotidiennement ne peut pas attendre un audit annuel pour valider sa posture de sécurité.

Les organisations découvrent en moyenne 30 à 40 % d'actifs Internet non maîtrisés après déploiement d'une solution d'EASM (External Attack Surface Management, cartographie continue de la surface d'attaque externe). Des actifs absents de tout périmètre de pentest précédent.

En résumé :

Pentest ponctuelValidation continue
Couverture dans le temps Figée à l'instant T Permanente 24/7
Périmètre Déclaré manuellement Découverte automatique des actifs inconnus
Nouvelles CVE Non couvertes entre deux audits Alerte en quelques heures
Retest après remédiation Manuel, sur demande Automatique
Coût Élevé par audit Dégressif selon le volume d'actifs

Tableau récapitulatif : couverture par type de pentest

Type de pentestCouvertureCondition
Site web✓ OuiScans externes récurrents automatisés
Application web✓ OuiDétection OWASP Top 10 automatisée
Plateforme web◐ PartielScans externes, pas de tests logiques métier approfondis
API✓ OuiTests OWASP API Top 10 automatisés
DNS✓ OuiTests automatisés sur configurations publiques
OSINT automatisé✓ OuiVia outils externes intégrés (Censys, Shodan)
Shadow IT Discovery✓ OuiInventaire automatique via scanners et OSINT
Subdomain Takeover✓ OuiDétection automatisée
Dark Web / fuites credentials◇ VariableSelon intégration spécifique
Réseau externe✓ OuiScans périmètre (ports, services exposés)
Réseau interne✕ NonNécessite intervention sur site ou VPN dédié
SI global◐ PartielVue sur l'exposition externe uniquement
Cloud (détection exposition)✓ OuiS3, Blob, Elasticsearch exposés publiquement
Cloud (audit IAM profond)✕ NonNécessite un accès initial (clés selon permissions)
DevOps (détection exposition)◐ PartielDétection des assets exposés publiquement
DevOps (audit pipeline)✕ NonNécessite un accès initial trouvé via une faille
IoT exposé sur Internet✓ OuiCaméras, imprimantes, équipements industriels exposés
IoT (firmware, physique)✕ NonNécessite une analyse dédiée
Ingénierie sociale✕ NonNécessite des tests humains
Thick client✕ NonNécessite une analyse dédiée du logiciel local
Application mobile✕ NonNécessite l'analyse des binaires
Red team complet✕ NonNécessite un scénario multi-vectoriel dédié
Physique✕ NonNécessite un audit sur site

Pour les périmètres marqués "Oui" ou "Partiel" automatisé, Patrowl couvre la détection en continu avec validation humaine sur les findings critiques. Pour les périmètres marqués "Non", un prestataire qualifié PASSI ou spécialisé est recommandé en complément.

Valider votre surface d'attaque externe en continu

Black-box · Zéro faux positif · Premier rapport en moins de 24h

Manuel, automatisé, hybride : trois approches pour réaliser un pentest

Au-delà du périmètre testé, une dernière dimension détermine la qualité et la fréquence de vos tests de sécurité : qui ou quoi réalise le pentest.

L'approche manuelle. Un pentesteur certifié (OSCP, OSWE, PASSI) mène le test entièrement à la main, avec son expertise et sa créativité pour enchaîner les vecteurs d'attaque comme le ferait un attaquant réel. C'est l'approche qui détecte le mieux les failles logiques complexes et les chaînes d'exploitation que personne n'a anticipées. Sa limite : le coût et le temps. Un audit manuel complet prend plusieurs jours, coûte cher, et capture un état figé à l'instant T.

L'approche automatisée. Des outils automatisés scannent le périmètre en continu, détectent les vulnérabilités connues, les configurations à risque, les actifs exposés. C'est rapide, peu coûteux à l'échelle, et permet une surveillance permanente impossible à tenir manuellement. Sa limite : un outil automatisé seul génère du bruit. Il remonte des CVE qui ne sont pas exploitables dans le contexte réel, et rate les failles logiques métier qu'un humain identifierait en quelques minutes.

L'approche hybride, renforcée par l'IA. C'est la combinaison des deux : des outils automatisés et des modèles d'IA pour la découverte continue, la priorisation contextuelle et la corrélation de renseignement sur les menaces (threat intelligence) en temps réel, couplés à une validation humaine systématique par des pentesteurs certifiés sur chaque résultat critique. L'automatisation fait le volume, l'humain fait le discernement. C'est ce qui permet d'avoir à la fois la fréquence d'un outil automatisé et la fiabilité d'un audit manuel.

Patrowl réunit justement ces trois dimensions. Découverte et tests automatisés en continu sur l'ensemble du périmètre externe, enrichissement par IA pour la priorisation contextuelle et le renseignement sur les menaces en temps réel, et validation humaine systématique par des pentesteurs certifiés avant que tout résultat critique ne remonte à vos équipes. Le tout sans jamais sacrifier l'un pour l'autre.

Pour conclure

Aucun type de pentest ne couvre tout, et c'est précisément le piège le plus fréquent : choisir un seul type de test et considérer le sujet réglé. Un audit web annuel ne dit rien de votre exposition DNS. Un test réseau interne ne révèle pas un sous-domaine abandonné prêt à être détourné. Une certification ISO obtenue sur un périmètre white-box ne garantit pas l'absence d'un bucket S3 public ouvert depuis six mois.

La bonne approche combine plusieurs types de tests de sécurité selon ce qui est réellement exposé, avec une fréquence adaptée à la vitesse à laquelle votre organisation change. Pour la majorité des organisations, cela veut dire une surveillance continue sur tout ce qui est visible depuis Internet (web, API, DNS, OSINT, cloud exposé), complétée par des audits ponctuels plus profonds sur l'interne, le mobile ou l'organisationnel selon le contexte réglementaire et le niveau de maturité.

Le tableau de couverture ci-dessus n'est pas une liste figée. C'est un point de départ pour cartographier ce que vous testez aujourd'hui, ce qui manque, et dans quel ordre le combler.

FAQ

Quelle est la différence entre un pentest black-box, grey-box et white-box ?

En black-box, le testeur ne dispose d'aucune information préalable. Il opère comme un attaquant externe réel. En grey-box, il dispose d'informations partielles pour simuler un employé malveillant ou un attaquant avec accès initial. En white-box, il dispose de tout : code source, accès administrateur, documentation technique. Le black-box donne la vision la plus réaliste de votre exposition externe.

Qu'est-ce qu'un subdomain takeover ?

Un subdomain takeover se produit quand un sous-domaine pointe vers un service tiers (CDN, hébergeur, SaaS) qui n'existe plus ou n'est plus configuré. Un attaquant peut alors revendiquer ce service tiers et prendre le contrôle du sous-domaine, l'utilisant pour du phishing ou de l'usurpation de marque sous un nom de domaine qui semble légitime. C'est l'un des vecteurs les plus sous-estimés parce qu'il ne dépend d'aucune vulnérabilité technique classique.

Quelle est la différence entre un pentest et un audit de sécurité ?

Un audit de sécurité évalue la conformité à des référentiels sans nécessairement exploiter les vulnérabilités. Un pentest est une simulation d'attaque active : le testeur tente réellement d'exploiter les failles. Les deux sont complémentaires.

Faut-il commencer par un pentest externe ou interne ?

Pour la grande majorité des organisations, commencez par l'externe : web, API, DNS, OSINT. C'est le périmètre le plus exposé aux attaquants réels. Le pentest interne est prioritaire en cas de risque avéré de menace interne ou d'exigence réglementaire spécifique.

Le pentest automatisé remplace-t-il tous les types de pentests ?

Non. Il couvre excellemment la surface d'attaque externe : web, API, DNS, OSINT, cloud exposé, réseau externe. Il ne couvre pas l'interne profond, le mobile, l'ingénierie sociale, le red team complet ni le physique. L'architecture optimale combine pentest continu automatisé pour l'externe et prestataire qualifié pour le reste.

Qu'est-ce qu'un RSSI doit vérifier avant de choisir un prestataire de pentest ?

Les certifications des pentesters (OSCP, OSWE, PASSI), le processus zéro faux positif, le périmètre exact couvert et exclu, la souveraineté des données, et la continuité entre deux audits.

Sources : OWASP Top 10 et OWASP API Top 10 · ANSSI qualification PASSI · SecurityScorecard Global Third-Party Breach Report 2025 · NIS2 (UE 2022/2555) · DORA (UE 2022/2554) · OWASP Mobile Application Security (MAS)