Pentest (test d’intrusion) : méthodologie, déroulement, scope et types de tests

Un pentest, ou test d’intrusion, consiste à évaluer concrètement le niveau de sécurité d’un système en reproduisant, dans un cadre contrôlé, les techniques et raisonnements qu’un attaquant pourrait utiliser pour le compromettre.

Applications web ou mobiles, API, infrastructures exposées sur Internet, réseaux internes, Active Directory, environnements cloud, objets connectés, applications desktop, systèmes utilisant des LLM ou encore collaborateurs : les surfaces d’attaque sont nombreuses et les méthodes employées varient fortement selon le périmètre audité.

L’objectif d’un pentest n’est cependant pas uniquement de dresser une liste de vulnérabilités. Il s’agit surtout de déterminer lesquelles sont réellement exploitables, dans quelles conditions elles pourraient l’être, jusqu’où un attaquant pourrait progresser et quels seraient les impacts techniques et métier d’une compromission.

Une vulnérabilité apparemment limitée peut, par exemple, permettre d’obtenir une première information sensible, utilisée ensuite pour accéder à une autre ressource, élever ses privilèges ou atteindre un système critique. C’est précisément cette capacité à contextualiser les vulnérabilités et à construire des scénarios d’attaque réalistes qui distingue le pentest d’un simple scan automatisé.

Dans ce guide, nous détaillons le fonctionnement d’un test d’intrusion, les différents types de pentests, les approches en boîte noire, grise et blanche, la définition du périmètre, les différentes phases d’une mission ainsi que les méthodes utilisées pour identifier et exploiter les vulnérabilités. Nous abordons également les rapports et livrables, ainsi que les critères à prendre en compte pour sélectionner un prestataire.

Guide complet sur les pentests (tests d’intrusion)

Qu’est-ce qu’un pentest ou test d’intrusion ?

Définition d’un pentest

Un pentest est une démarche de sécurité offensive destinée à évaluer la résistance d’un système face à des attaques réalistes. Il est réalisé avec l’autorisation explicite de l’organisation auditée, sur un périmètre défini et selon des règles d’engagement convenues avant le début des tests.

Contrairement à un audit purement documentaire ou à une analyse automatisée, le pentester interagit directement avec la cible. Il recherche des vulnérabilités techniques, des erreurs de configuration, des défauts de logique métier, des faiblesses d’architecture ou encore des problèmes dans les mécanismes d’authentification et d’autorisation.

Lorsqu’une vulnérabilité est identifiée, son exploitation contrôlée permet de vérifier qu’elle est réellement exploitable et surtout d’en mesurer les conséquences. Une injection SQL ne sera ainsi pas évaluée uniquement parce qu’une entrée semble vulnérable. Le pentester cherchera à déterminer si elle permet effectivement de lire ou modifier des données, de contourner un mécanisme d’authentification ou, dans certains contextes, d’obtenir un contrôle plus large du système.

De la même manière, une mauvaise configuration sur un réseau interne prendra une toute autre importance si elle permet à un utilisateur standard de récupérer des identifiants, d’obtenir des privilèges supplémentaires puis d’accéder à des ressources critiques.

Le pentest repose donc sur une démarche volontairement offensive, mais contrôlée. Le but n’est pas de provoquer le maximum de dommages : il est de démontrer les risques avec un niveau de preuve suffisant, en limitant autant que possible l’impact sur les systèmes et les données.

Quels sont les objectifs d’un pentest ?

Le premier objectif d’un test d’intrusion est d’identifier les vulnérabilités qui pourraient être exploitées par un attaquant. Cependant, la valeur d’un pentest ne se limite pas au nombre de failles découvertes.

Il permet d’abord de valider l’exploitabilité réelle des vulnérabilités. De nombreux systèmes peuvent présenter des faiblesses théoriques qui ne sont pas nécessairement exploitables dans leur contexte réel. À l’inverse, plusieurs vulnérabilités de faible criticité prises individuellement peuvent parfois être combinées pour créer un scénario de compromission important.

Le pentest sert également à mesurer les conséquences d’une attaque. L’auditeur cherche notamment à déterminer si une faiblesse peut conduire à un accès à des données sensibles, une prise de contrôle de comptes, une élévation de privilèges, une exécution de code, un mouvement latéral ou une compromission plus globale de l’environnement.

Enfin, il doit fournir aux équipes les informations nécessaires pour corriger durablement les problèmes. Les vulnérabilités sont documentées, expliquées, contextualisées et accompagnées de recommandations adaptées au système audité.

Un pentest répond donc à plusieurs objectifs complémentaires : identifier les faiblesses, vérifier leur exploitabilité, comprendre les chemins d’attaque, mesurer l’impact, prioriser la remédiation et améliorer la posture de sécurité.

Pentest et analyse de vulnérabilités : quelles différences ?

Les scanners de vulnérabilités et les pentests répondent à des besoins différents et complémentaires.

Une analyse de vulnérabilités repose majoritairement sur des outils automatisés qui examinent un périmètre afin d’identifier des vulnérabilités connues : logiciels obsolètes, services vulnérables, configurations faibles, certificats problématiques, ports exposés, fichiers accessibles ou signatures correspondant à des failles documentées.

Cette approche présente plusieurs avantages. Elle est rapide, relativement simple à industrialiser et particulièrement adaptée à la surveillance régulière d’un parc important. Elle offre une bonne capacité de détection sur des problèmes connus et reproductibles.

Mais un scanner reste limité par ce qu’il est capable d’identifier automatiquement. Il peut difficilement comprendre qu’un utilisateur disposant du rôle A peut modifier une donnée appartenant au rôle B, qu’une procédure de remboursement permet de déclencher deux remboursements successifs, qu’un workflow peut être exécuté dans un ordre non prévu ou qu’une combinaison de permissions cloud forme un chemin d’élévation de privilèges.

Le pentester complète donc les outils automatisés par une analyse humaine. Il explore les fonctionnalités, formule des hypothèses, manipule les flux, tente de contourner les contrôles et cherche à combiner les vulnérabilités.

La différence essentielle tient moins à l’utilisation ou non d’outils automatiques qu’à l’analyse, l’exploitation et la contextualisation des résultats. Un scanner cherche principalement à répondre à la question « quelles vulnérabilités potentielles sont présentes ? ». Un pentest cherche plutôt à répondre aux questions « qu’est-ce qu’un attaquant peut réellement exploiter ? », « comment ? », « jusqu’où peut-il aller ? » et « quelles seraient les conséquences ? ».

Pentest et bug bounty : quelle approche choisir ?

Le bug bounty consiste à ouvrir la recherche de vulnérabilités à des chercheurs en sécurité externes, généralement via un programme public ou privé. Les participants signalent les vulnérabilités qui respectent les règles du programme et peuvent être rémunérés selon la sévérité des problèmes découverts.

Cette approche peut mobiliser un grand nombre de profils sur une période longue. Elle est particulièrement intéressante pour des applications déjà matures, disposant d’une équipe capable de qualifier et traiter un flux régulier de signalements.

Le pentest repose sur une logique différente. La mission est limitée dans le temps mais structurée autour d’un périmètre, d’objectifs, d’une méthodologie et de livrables définis à l’avance. Les auditeurs doivent couvrir méthodiquement la surface d’attaque et ne sont pas uniquement incités à rechercher les vulnérabilités les plus rentables.

Un pentest est donc généralement plus adapté lorsqu’une organisation souhaite obtenir une évaluation structurée d’un périmètre donné, disposer d’un rapport exploitable, répondre à une exigence contractuelle ou évaluer une fonctionnalité avant sa mise en production.

Pentest et bug bounty ne sont pas nécessairement concurrents. Une organisation mature peut réaliser régulièrement des pentests approfondis tout en maintenant un programme de bug bounty entre deux campagnes.

Pentest as a Service (PtaaS) : vers des tests plus continus

Le Pentest as a Service, ou PtaaS, vise à faciliter la réalisation et le suivi de tests d’intrusion réguliers. Le principe consiste généralement à associer les interventions de pentesters à une plateforme permettant de centraliser les audits, les vulnérabilités, les échanges avec les auditeurs, les corrections et les contre-tests.

L’intérêt principal réside dans la continuité. Une organisation qui déploie fréquemment de nouvelles versions peut programmer des tests à différents moments du cycle de développement plutôt que de réaliser un unique pentest annuel.

La plateforme peut également permettre de suivre l’évolution des vulnérabilités dans le temps, d’intégrer les résultats à un outil de ticketing ou de faciliter les échanges entre équipes sécurité, développement et exploitation.

Le PtaaS ne signifie cependant pas que le pentest devient automatisé. La plateforme constitue avant tout un moyen de piloter et d’industrialiser la relation entre les équipes internes et les pentesters. La valeur du test continue à reposer sur l’analyse humaine et les tests manuels.

Pourquoi réaliser un pentest ?

La première raison de réaliser un pentest reste la réduction du risque de compromission. Un système accessible depuis Internet, une application métier critique, un environnement cloud ou une infrastructure Active Directory peuvent contenir des vulnérabilités difficiles à détecter lors des phases classiques de développement et d’administration.

Le pentest permet de confronter les mesures de sécurité mises en place à des scénarios d’attaque réalistes. Il ne vérifie pas seulement qu’un contrôle est présent : il cherche à déterminer s’il résiste à des tentatives de contournement.

Un pentest peut notamment être réalisé pour identifier des vulnérabilités avant qu’elles ne soient exploitées, vérifier l’efficacité des contrôles de sécurité, évaluer les risques associés à un nouveau système, sécuriser une application avant sa mise en production, mesurer l’impact d’une compromission interne ou encore vérifier la séparation entre plusieurs environnements ou tenants.

Il peut également répondre à des enjeux de gouvernance : exigences de clients, appels d’offres, due diligence, démarches de certification, obligations contractuelles ou réglementaires. Ces exigences doivent toutefois être appréciées au cas par cas : toutes les normes ou réglementations n’imposent pas automatiquement le même type de pentest, la même fréquence ni le même périmètre.

Enfin, le pentest peut servir d’outil de progression. En répétant les campagnes dans le temps et en analysant les causes récurrentes des vulnérabilités, une organisation peut mesurer l’efficacité de ses actions de sécurisation et améliorer ses pratiques de développement, d’architecture et d’administration.

Quand réaliser un pentest et à quelle fréquence ?

Un test d’intrusion peut être pertinent à différents moments du cycle de vie d’un système. L’un des meilleurs moments se situe avant une mise en production importante. Tester une application à ce stade permet de corriger les vulnérabilités avant qu’elles ne soient accessibles à des utilisateurs réels ou à des attaquants.

Un nouveau pentest peut également être justifié après une évolution majeure : modification de l’architecture, ajout d’un système d’authentification, migration cloud, changement important du code, exposition de nouvelles API, déploiement d’un agent IA ou introduction de fonctionnalités sensibles.

Les environnements particulièrement critiques doivent quant à eux être testés périodiquement, même en l’absence d’évolution majeure. Certains événements peuvent aussi déclencher une nouvelle évaluation : acquisition d’une entreprise, fusion de systèmes d’information, incident de sécurité, découverte d’une nouvelle classe d’attaque ou évolution des exigences applicables.

Il n’existe pas de fréquence universelle. Un pentest annuel peut constituer une base dans certains contextes, mais cette périodicité peut être insuffisante pour une application déployée plusieurs fois par jour ou pour une architecture qui évolue en permanence.

La fréquence doit dépendre de la criticité du système, de son exposition, du volume et de la sensibilité des données traitées, de la fréquence des changements, des menaces auxquelles l’organisation est confrontée et des obligations contractuelles ou réglementaires.

Une approche mature consiste donc moins à définir un calendrier arbitraire qu’à déclencher les pentests en fonction du risque et des changements significatifs, tout en maintenant une périodicité minimale sur les actifs critiques.

Quels sont les différents types de pentest ?

Pentest d’application web

Ce que l’on teste lors d’un pentest web

Un pentest d’application web vise à tester la sécurité d’un site, d’un portail métier, d’une plateforme SaaS, d’un back-office ou de toute application accessible via HTTP ou HTTPS.

L’auditeur commence par comprendre le fonctionnement de l’application : mécanismes d’authentification, rôles disponibles, fonctionnalités, objets métier, flux de données, endpoints, technologies utilisées et interactions avec des services externes.

Les tests portent notamment sur les contrôles d’accès, la gestion des sessions, les mécanismes d’authentification, les entrées utilisateur, les uploads de fichiers, les fonctions d’administration, la logique métier, les intégrations tierces et la configuration de l’environnement d’hébergement lorsqu’elle fait partie du périmètre.

Principaux risques évalués sur une application web

Les contrôles d’accès font partie des éléments les plus importants à tester. Une application peut vérifier qu’un utilisateur est connecté tout en omettant de vérifier s’il possède effectivement les droits nécessaires pour accéder à un objet particulier.

Les pentesters recherchent également des vulnérabilités comme les injections SQL, XSS, SSRF, injections de commandes, traversées de répertoires, failles liées au traitement de fichiers, mauvaises configurations de cookies, problèmes de cache ou défauts dans la gestion des tokens et des sessions.

Les mécanismes d’authentification font l’objet de tests spécifiques : inscription, connexion, réinitialisation de mot de passe, MFA, SSO, changement d’adresse e-mail, élévation de privilèges et invalidation des sessions.

La logique métier est tout aussi importante. Sur un site e-commerce, il peut par exemple être possible de manipuler un prix, de réutiliser plusieurs fois une réduction ou de contourner une étape de paiement. Sur une application financière, le pentester peut rechercher des moyens de dépasser un plafond de transaction ou de modifier l’ordre normal d’un workflow.

Exemple de scénario d’exploitation web

Imaginons une plateforme B2B permettant à chaque client de télécharger ses factures. Lorsqu’un utilisateur ouvre une facture, son navigateur appelle une URL contenant un identifiant numérique.

Le pentester modifie cet identifiant et constate que le serveur retourne la facture d’une autre entreprise. L’application vérifie bien que l’utilisateur est authentifié, mais elle ne contrôle pas que la facture demandée appartient au même tenant. Il s’agit ici d’une IDOR (ou Insecure Direct Object Reference / Référence directe non sécurisée à un objet).

L’auditeur poursuit ensuite l’analyse et découvre que certaines factures exposent des identifiants internes utilisés par une interface d’administration. Une seconde faiblesse de contrôle d’accès lui permet alors d’interroger cette interface avec un compte standard. Deux vulnérabilités qui auraient pu être évaluées séparément forment ainsi un scénario de compromission plus important.

Particularités méthodologiques du pentest web

Les tests web combinent généralement exploration manuelle, interception des requêtes HTTP, comparaison entre différents rôles, fuzzing ciblé et automatisation de certaines vérifications.

Des référentiels comme l’OWASP Web Security Testing Guide sont utiles pour structurer la couverture. Ils ne doivent toutefois pas transformer le pentest en checklist rigide : l’auditeur doit conserver une approche orientée scénario et comprendre les règles métier propres à la cible.

Pentest d’API

Ce que l’on teste lors d’un pentest d’API

Les API exposent directement des fonctions et données utilisées par les applications web, mobiles, partenaires et systèmes internes. Un pentest d’API peut cibler des interfaces REST, GraphQL, SOAP, gRPC ou des protocoles propriétaires selon l’architecture.

L’auditeur analyse les endpoints, méthodes, objets, paramètres, rôles, mécanismes d’authentification, tokens, contrôles de rate limiting, gestion des erreurs et interactions avec les services backend.

Une documentation OpenAPI, Swagger, une collection Postman ou une description de schéma GraphQL peut améliorer considérablement la couverture lorsque l’objectif est l’exhaustivité.

Principaux risques évalués sur une API

Les problèmes les plus importants concernent souvent les contrôles d’accès au niveau objet et fonction. Une API peut vérifier qu’un token est valide mais ne pas contrôler qu’un utilisateur a le droit d’accéder à la ressource demandée.

Les tests portent également sur l’authentification, la gestion des clés et tokens, l’exposition excessive de données, le mass assignment, les injections, le rate limiting, les abus de workflows, la consommation non maîtrisée de ressources, les erreurs de configuration CORS et l’exposition d’endpoints non documentés.

GraphQL introduit des problématiques particulières : introspection, profondeur et complexité des requêtes, autorisations au niveau des resolvers ou possibilités de récupérer davantage de données que nécessaire.

Exemple de scénario d’exploitation API

Un utilisateur appelle l’endpoint `/api/orders/1054` pour consulter sa commande. En remplaçant l’identifiant par celui d’une autre commande, le pentester obtient la réponse d’un autre client. Il s’agit d’un défaut de contrôle d’accès au niveau objet, souvent décrit comme une BOLA dans le contexte API.

L’auditeur constate ensuite qu’un champ `role` peut être envoyé lors de la mise à jour du profil alors qu’il n’est pas présent dans l’interface. Si le backend applique automatiquement les propriétés reçues sans liste d’autorisation explicite, cette seconde faiblesse peut permettre une élévation de privilèges.

Particularités méthodologiques du pentest API

Le pentest doit couvrir les différences entre rôles et états de la ressource, pas seulement chaque endpoint isolément. Les séquences de requêtes sont souvent aussi importantes que les requêtes elles-mêmes.

L’OWASP API Security Top 10 constitue un référentiel utile, mais l’analyse des workflows métier et des relations entre objets reste indispensable.

Pentest d’application mobile

Ce que l’on teste lors d’un pentest mobile

Un pentest mobile concerne les applications Android, iOS et les solutions hybrides. Il combine généralement l’analyse de l’application installée sur le terminal avec les tests des API et services distants auxquels elle communique.

L’analyse statique examine le package de l’application sans nécessairement l’exécuter : manifeste, permissions, ressources, bibliothèques, chaînes de caractères, code décompilé et configuration.

L’analyse dynamique s’intéresse au comportement de l’application pendant son exécution : stockage local, logs, communications réseau, interactions avec le système d’exploitation, mécanismes biométriques, protections anti-debugging et réactions à l’instrumentation.

Principaux risques évalués sur une application mobile

Les pentesters recherchent des secrets embarqués, données sensibles stockées en clair, faiblesses cryptographiques, communications insuffisamment protégées, contrôles de sécurité appliqués uniquement côté client, permissions excessives, composants exportés, deep links dangereux ou mécanismes de mise à jour insuffisamment sécurisés.

Les API restent une surface majeure. Une application mobile bien protégée localement ne compense pas des contrôles d’accès défaillants côté serveur.

Exemple de scénario d’exploitation mobile

Une application affiche une fonction premium uniquement lorsque le code local estime que l’utilisateur possède un abonnement actif. Le pentester instrumente l’application et modifie temporairement la valeur retournée par la fonction de vérification.

Si le serveur accepte ensuite les actions premium sans effectuer son propre contrôle d’autorisation, la protection repose entièrement sur un composant contrôlé par l’utilisateur. Le problème fondamental est donc un défaut d’autorisation côté serveur, révélé grâce à l’analyse dynamique mobile.

Particularités méthodologiques du pentest mobile

Les tests peuvent nécessiter des terminaux rootés ou jailbreakés afin d’observer et modifier le comportement de l’application. Cette hypothèse est réaliste : l’attaquant contrôle son propre appareil et peut analyser le binaire aussi longtemps qu’il le souhaite.

L’OWASP MASVS et le Mobile Application Security Testing Guide fournissent des références utiles pour structurer les tests de stockage, cryptographie, authentification, communications réseau, plateforme et résistance au reverse engineering.

Pentest d’applications LLM, RAG, agents IA et MCP

Ce que l’on teste lors d’un pentest LLM

Un pentest LLM ne consiste pas uniquement à essayer de faire produire au modèle une réponse interdite. L’objectif est d’évaluer la sécurité de l’ensemble de l’architecture : application, modèle, prompts système, RAG, bases vectorielles, agents, outils, serveurs MCP, API, données et services tiers.

La cartographie doit identifier les frontières de confiance : quelles entrées sont contrôlées par l’utilisateur ? Quelles données sont récupérées automatiquement ? Quels outils l’agent peut-il utiliser ? Avec quelles permissions ? Quelles actions nécessitent une confirmation ? Comment les données sont-elles séparées entre utilisateurs ou tenants ?

Principaux risques évalués sur les systèmes LLM

La prompt injection directe consiste à fournir au modèle des instructions destinées à détourner son comportement. Elle peut être indirecte lorsque l’instruction malveillante se trouve dans une page web, un document, un e-mail ou toute autre donnée que le système récupère automatiquement.

Les pentesters évaluent également la divulgation d’informations sensibles, les problèmes d’isolation entre utilisateurs, le data poisoning, la sécurité des embeddings et bases vectorielles, les sorties non fiables, les abus d’outils, l’excessive agency, les faiblesses de contrôle des coûts et la sécurité des composants entourant le modèle.

Les architectures agentiques sont particulièrement sensibles parce qu’un modèle peut agir au lieu de simplement répondre. Un agent peut envoyer un e-mail, créer un ticket, modifier une base, déclencher une action dans un CRM ou appeler un service interne. Le risque dépend alors directement des permissions accordées à ses outils.

Les architectures MCP ajoutent d’autres points de contrôle : authenticité et confiance des serveurs, description des outils, paramètres exposés, mécanismes d’authentification, secrets transmis, cloisonnement et validation des actions.

Exemple de scénario d’exploitation LLM

Imaginons un assistant capable de rechercher des documents internes et de créer automatiquement des tickets. Un attaquant dépose dans la base documentaire un fichier contenant une instruction malveillante dissimulée dans un contenu légitime.

Lorsqu’un collaborateur pose ensuite une question correspondant à ce document, le mécanisme RAG le récupère et l’intègre au contexte du modèle. Si l’application ne sépare pas correctement les instructions de confiance des données, le modèle peut interpréter le contenu malveillant comme une instruction.

Si l’agent ne dispose que d’un outil de recherche, l’impact reste limité. S’il peut également créer, modifier ou fermer des tickets avec des droits élevés, la même prompt injection peut conduire à une action non autorisée. Le pentest doit donc tester à la fois le comportement du modèle et l’architecture de permissions qui l’entoure.

Particularités méthodologiques du pentest LLM

Les résultats des modèles peuvent être non déterministes. Un même prompt ne produit pas nécessairement la même réponse à chaque exécution. Les tests doivent donc être reproductibles autant que possible, répétés lorsque nécessaire et évalués selon des critères explicites.

Il faut également distinguer le contournement d’un garde-fou conversationnel d’une vulnérabilité ayant un impact de sécurité. Le pentest doit se concentrer sur les scénarios permettant d’accéder à des données, franchir une frontière d’autorisation, déclencher une action, influencer un autre utilisateur ou compromettre un composant.

Des référentiels comme l’OWASP Top 10 for LLM Applications peuvent structurer la couverture, mais l’analyse de l’architecture agentique et des permissions reste centrale.

Pentest d’infrastructure externe

Ce que l’on teste lors d’un pentest d’infrastructure externe

Le pentest d’infrastructure externe vise les systèmes exposés depuis Internet : adresses IP, domaines, VPN, passerelles, services de messagerie, interfaces d’administration, appliances, services cloud, applications oubliées et autres composants accessibles publiquement.

La mission peut commencer avec très peu d’informations dans un scénario boîte noire, ou avec une liste d’actifs connue lorsque l’objectif est d’obtenir une meilleure couverture.

Principaux risques évalués sur une infrastructure externe

Les pentesters recherchent des services obsolètes, interfaces d’administration accessibles, protocoles faibles, mauvaises configurations, certificats problématiques, authentification insuffisante, services de test oubliés, DNS exposant des informations, secrets publiquement accessibles ou vulnérabilités connues affectant des appliances.

La gestion de la surface d’attaque est essentielle. Un domaine principal peut être correctement sécurisé alors qu’un ancien sous-domaine, une appliance VPN ou une interface temporaire constitue un point d’entrée beaucoup plus simple.

Exemple de scénario d’exploitation externe

Une organisation expose une interface de test sur un sous-domaine créé plusieurs années auparavant. Le service n’est plus référencé dans l’inventaire principal et utilise une version ancienne d’un composant.

Le pentester identifie la technologie, confirme qu’une vulnérabilité connue est applicable puis démontre, dans les limites autorisées, qu’elle permet d’obtenir un accès au serveur. Le risque principal ne réside donc pas uniquement dans la CVE : il provient aussi de l’absence de maîtrise de la surface exposée.

Particularités méthodologiques du pentest externe

La reconnaissance joue un rôle plus important que dans de nombreux autres types de pentest. L’auditeur combine sources publiques, DNS, découverte de services et analyse des technologies afin de construire progressivement une cartographie de l’exposition réelle.

Les tests à fort impact, comme certains dénis de service, doivent être explicitement autorisés avant toute exécution.

Pentest de réseau interne

Ce que l’on teste lors d’un pentest de réseau interne

Le pentest interne simule un attaquant disposant déjà d’un point d’accès au réseau de l’entreprise. Ce scénario peut correspondre à la compromission préalable d’un poste via phishing, à un équipement branché physiquement au réseau, à un compte utilisateur compromis ou à la présence d’un attaquant interne.

L’auditeur analyse les segments réseau, services, partages, postes, serveurs, systèmes d’administration, protocoles d’authentification et relations de confiance.

Principaux risques évalués sur un réseau interne

Les principaux risques sont les défauts de segmentation, services inutiles, protocoles non chiffrés, mots de passe réutilisés, secrets accessibles dans des partages, permissions excessives, systèmes obsolètes, authentification relayable ou encore possibilités de mouvement latéral.

L’objectif est notamment d’éviter qu’un accès initial limité permette progressivement d’atteindre des systèmes critiques.

Exemple de scénario d’exploitation interne

Un utilisateur compromis peut lire un partage réseau contenant un script de déploiement. Le script contient un identifiant technique réutilisé sur plusieurs serveurs. Le pentester vérifie que ces identifiants permettent de se connecter à une machine disposant elle-même d’un accès administratif à un segment plus sensible.

Aucune vulnérabilité logicielle n’est nécessaire : le chemin d’attaque repose sur une mauvaise gestion des secrets et des privilèges.

Particularités méthodologiques du pentest interne

Le point de départ doit être défini précisément. Un compte standard, un poste compromis ou un simple accès réseau ne donnent pas la même visibilité ni les mêmes possibilités.

Il faut également décider si les équipes de supervision sont informées de la campagne. Si l’objectif principal devient l’évaluation de la détection et de la réaction, la mission se rapproche d’un exercice Red Team ou Purple Team.

Pentest Active Directory

Ce que l’on teste lors d’un pentest Active Directory

Active Directory constitue souvent la colonne vertébrale des environnements Windows d’entreprise. Le pentest analyse les utilisateurs, groupes, machines, politiques de sécurité, relations de confiance, permissions, délégations, mécanismes Kerberos, NTLM et services associés.

Le point de départ est fréquemment un compte utilisateur standard afin d’évaluer les chemins d’élévation disponibles pour un attaquant déjà présent dans le réseau.

Principaux risques évalués dans Active Directory

Les tests peuvent porter sur les mots de passe faibles, Kerberoasting, AS-REP Roasting, ACL dangereuses, délégations mal configurées, services exécutés avec des comptes privilégiés, possibilités de NTLM relay, secrets accessibles, comptes inactifs, chemins de privilèges excessifs ou mauvaises configurations d’Active Directory Certificate Services.

L’objectif n’est pas seulement de trouver une faiblesse isolée, mais de comprendre les relations qui permettent de progresser vers des comptes et systèmes privilégiés.

Exemple de scénario d’exploitation Active Directory

Le pentester démarre avec un compte standard. Il identifie un compte de service associé à Kerberos et récupère les données permettant de tester hors ligne la robustesse de son mot de passe. Le mot de passe est faible et peut être retrouvé.

Ce compte de service n’est pas administrateur du domaine, mais il dispose d’un droit de modification sur un autre groupe. Ce groupe contrôle à son tour un serveur sur lequel un compte privilégié se connecte régulièrement.

La compromission résulte donc d’une succession de faiblesses : mot de passe insuffisamment robuste, permissions excessives et relation de confiance mal maîtrisée.

Exemple de scénario AD CS

Lorsqu’Active Directory Certificate Services est déployé, le pentester analyse les autorités de certification, templates de certificats et permissions d’enrôlement.

Une template mal configurée peut permettre à un utilisateur standard de demander un certificat utilisable avec une identité différente de la sienne. Selon le contexte, ce certificat peut ensuite servir à s’authentifier en tant qu’un utilisateur plus privilégié.

Le problème ne provient pas d’une faille cryptographique, mais de la manière dont l’infrastructure PKI a été configurée et intégrée à Active Directory.

Particularités méthodologiques du pentest Active Directory

Les graphes de relations sont particulièrement importants. Une permission apparemment limitée peut devenir critique lorsqu’elle s’inscrit dans un chemin plus long.

Les tests doivent aussi prendre en compte les mécanismes de durcissement, les tiers de privilèges, les postes d’administration, les contrôles de délégation et, dans les environnements hybrides, les interactions avec les identités cloud.

Pentest Wi-Fi

Ce que l’on teste lors d’un pentest Wi-Fi

Le pentest Wi-Fi évalue si un attaquant situé à proximité des locaux peut obtenir un accès réseau non autorisé, intercepter des communications ou tromper les utilisateurs afin qu’ils se connectent à une infrastructure malveillante.

L’auditeur examine les SSID, méthodes d’authentification, protocoles de chiffrement, réseaux invités, mécanismes 802.1X, certificats, séparation des VLAN et isolation des clients.

Principaux risques évalués sur les réseaux Wi-Fi

Les risques incluent les clés partagées faibles ou réutilisées, les configurations WPA2/WPA3 Enterprise incorrectes, l’absence de validation des certificats, des réseaux invités donnant accès à des ressources internes ou encore des terminaux configurés pour faire confiance à des points d’accès non légitimes.

Exemple de scénario d’exploitation Wi-Fi

Une organisation utilise une authentification entreprise mais les postes clients ne valident pas correctement le certificat du serveur d’authentification. Un point d’accès malveillant imitant le réseau légitime peut alors inciter un poste à initier une authentification vers une infrastructure contrôlée par l’auditeur.

L’impact dépend ensuite de la méthode d’authentification et des protections déployées. Le scénario permet surtout de démontrer que la sécurité ne dépend pas uniquement du chiffrement radio, mais aussi de la confiance accordée aux serveurs et certificats.

Particularités méthodologiques du pentest Wi-Fi

Les tests doivent être réalisés avec une attention particulière aux interférences et à la disponibilité. Les attaques de désauthentification ou autres techniques perturbatrices ne doivent être effectuées que lorsqu’elles sont explicitement autorisées.

Pentest d’environnements cloud

Ce que l’on teste lors d’un pentest cloud

Le pentest cloud analyse les ressources et configurations propres à AWS, Microsoft Azure, Google Cloud ou d’autres plateformes. Il ne se limite pas aux machines virtuelles exposées sur Internet.

L’auditeur étudie les identités, rôles, politiques IAM, stockages, services managés, fonctions serverless, bases de données, réseaux virtuels, secrets, pipelines CI/CD, conteneurs, clusters Kubernetes et relations entre comptes ou subscriptions.

Principaux risques évalués dans le cloud

Les mécanismes IAM sont centraux. Une identité peut disposer de permissions trop larges, être capable d’assumer un autre rôle, modifier une politique ou accéder à un secret ouvrant une nouvelle étape de compromission.

Les pentesters recherchent également les stockages publics, clés statiques exposées, services accessibles sans authentification, metadata services mal protégés, fonctions trop privilégiées, secrets présents dans des variables d’environnement, segmentation insuffisante et relations de confiance dangereuses entre comptes.

Exemple de scénario d’exploitation cloud

Une application compromise utilise une identité technique limitée. L’auditeur constate cependant que cette identité peut lire un service de gestion de secrets. L’un des secrets contient les identifiants d’un second composant disposant de permissions plus importantes.

Ces nouveaux droits permettent ensuite d’accéder à un espace de stockage contenant des données sensibles. La compromission finale ne repose pas sur une unique vulnérabilité cloud, mais sur l’enchaînement entre une faiblesse applicative, une permission IAM excessive et une mauvaise gestion des secrets.

Exemple de mauvaise séparation entre environnements cloud

Une entreprise utilise plusieurs comptes afin de séparer développement et production. Une identité du compte de développement peut toutefois assumer un rôle dans un compte partagé. Ce rôle possède lui-même une relation de confiance vers un composant de production.

La séparation logique existe dans l’organisation des comptes, mais les relations IAM permettent de la franchir. Le pentest permet de démontrer concrètement ce chemin.

Particularités méthodologiques du pentest cloud

Une approche boîte blanche ou grise est souvent pertinente, car les permissions et relations de confiance ne sont pas toujours observables depuis Internet.

Les règles propres au fournisseur doivent également être prises en compte. Certaines activités peuvent être autorisées sans formalité supplémentaire, tandis que d’autres types de tests restent interdits ou encadrés.

Pentest IoT et objets connectés

Ce que l’on teste lors d’un pentest IoT

Un système IoT associe généralement plusieurs composants : matériel, firmware, communications radio ou réseau, application mobile, plateforme cloud, API et mécanismes de mise à jour.

Le pentest doit donc analyser l’écosystème dans son ensemble plutôt que le seul objet physique.

L’analyse matérielle peut porter sur les interfaces de debug, mémoires, protections physiques, ports série, mécanismes de démarrage et stockage des secrets. Le firmware est étudié à la recherche de comptes par défaut, clés, certificats, composants obsolètes et services internes.

Principaux risques évalués sur un système IoT

Les risques incluent les secrets codés en dur, interfaces de debug laissées actives, firmwares non signés, mises à jour insuffisamment vérifiées, communications non chiffrées, protocoles radio réutilisables, absence d’authentification entre composants, APIs vulnérables ou applications mobiles trop permissives.

Exemple de scénario d’exploitation IoT

Le pentester extrait le firmware d’un dispositif et identifie une clé API commune à tous les équipements. Cette clé permet d’interroger un service cloud utilisé pour l’enrôlement.

Si le service ne limite pas correctement les opérations associées à cette clé, la compromission d’un seul appareil peut avoir des conséquences sur l’ensemble du parc. L’analyse montre alors qu’un secret embarqué dans le firmware constituait une frontière de sécurité qui ne devait pas être partagée globalement.

Particularités méthodologiques du pentest IoT

Les manipulations matérielles peuvent être destructrices. Il est donc fréquent de prévoir plusieurs exemplaires du produit et de définir à l’avance les opérations autorisées : ouverture du boîtier, dessoudage, extraction mémoire, modification du firmware ou tests électriques.

Les communications doivent être analysées sur l’ensemble des interfaces utilisées : Wi-Fi, Bluetooth, Zigbee, NFC, protocoles propriétaires ou liaisons filaires.

Pentest d’ingénierie sociale

Ce que l’on teste lors d’une campagne d’ingénierie sociale

La sécurité d’un système d’information ne repose pas uniquement sur les contrôles techniques. Un attaquant peut tenter de convaincre un collaborateur de divulguer des informations, d’ouvrir une pièce jointe, de communiquer un code MFA ou d’exécuter une action particulière.

Les tests d’ingénierie sociale reproduisent ces scénarios dans un cadre contrôlé. Ils peuvent inclure phishing par e-mail, vishing par téléphone, smishing par SMS, QR phishing, demandes d’informations, scénarios physiques ou combinaison de plusieurs canaux.

Principaux risques évalués en ingénierie sociale

L’objectif n’est pas simplement de mesurer un taux de clic. Les tests doivent évaluer les processus qui permettent à l’attaque de fonctionner : filtrage e-mail, signalement, validation des demandes sensibles, procédures de support, protection MFA, contrôle physique des accès et réaction des équipes.

Exemple de scénario d’ingénierie sociale

Un faux message du support informatique demande à un collaborateur de valider une nouvelle procédure d’authentification. Plutôt que de s’arrêter au clic, le scénario évalue si l’utilisateur saisit ses identifiants, si un second facteur peut être contourné ou abusé et si l’événement est signalé aux équipes internes.

Particularités méthodologiques de l’ingénierie sociale

Le cadrage est essentiel. La population ciblée, les données collectées, les scénarios interdits, les critères de réussite et les procédures d’arrêt doivent être définis en amont.

L’objectif n’est pas de mettre individuellement les collaborateurs en difficulté, mais d’identifier les mécanismes humains et organisationnels permettant à une attaque de réussir.

Pentest en boîte noire, boîte grise ou boîte blanche : quelles différences ?

Les notions de boîte noire, boîte grise et boîte blanche décrivent le niveau d’information dont dispose le pentester avant et pendant la mission. Elles ne déterminent pas à elles seules la qualité ou la difficulté du pentest.

Le bon choix dépend du scénario que l’organisation souhaite tester et du niveau de couverture attendu.

Pentest en boîte noire

Dans un pentest en boîte noire, le pentester dispose de très peu d’informations sur sa cible. L’objectif est généralement de reproduire la position d’un attaquant externe qui découvre progressivement l’organisation.

La phase de reconnaissance occupe donc une place importante. Cette approche est particulièrement intéressante pour mesurer l’exposition publique d’une organisation ou la résistance d’une infrastructure accessible depuis Internet.

En revanche, une partie significative du temps peut être consacrée à découvrir des informations que l’organisation aurait pu fournir directement. Pour un audit dont l’objectif est l’exhaustivité technique d’une application précise, une approche uniquement boîte noire n’est donc pas toujours la plus efficace.

Pentest en boîte grise

Le pentest en boîte grise fournit au pentester un niveau intermédiaire d’information. Il peut par exemple disposer d’un compte utilisateur, de plusieurs comptes avec des rôles différents, d’une documentation fonctionnelle, d’un accès VPN ou d’une description partielle de l’architecture.

Cette approche est particulièrement pertinente pour les applications. Un compte utilisateur permet au pentester de consacrer davantage de temps aux fonctionnalités authentifiées et aux contrôles d’accès plutôt qu’à tenter d’obtenir un accès initial.

Sur un réseau interne ou un environnement cloud, un compte standard peut également permettre d’évaluer ce qu’un attaquant ferait après la compromission initiale.

Pentest en boîte blanche

Dans un pentest en boîte blanche, le pentester dispose d’informations techniques approfondies. Cela peut inclure le code source, les configurations, les schémas d’architecture, la documentation, les accès aux infrastructures ou des comptes privilégiés.

Cette approche facilite l’analyse de mécanismes complexes et permet généralement d’obtenir une meilleure couverture à temps équivalent. Elle est particulièrement adaptée lorsqu’un niveau de confiance élevé est recherché sur une fonctionnalité critique, un mécanisme cryptographique, une architecture complexe ou une logique d’autorisation sensible.

L’accès au code ne remplace pas les tests dynamiques. Il permet au contraire de combiner la compréhension de l’implémentation avec la validation réelle des scénarios d’exploitation.

Peut-on combiner plusieurs approches ?

Oui. Une mission peut commencer en boîte noire afin d’étudier ce qu’un attaquant peut découvrir depuis Internet, puis se poursuivre en boîte grise avec différents comptes.

Sur une application critique, l’accès au code source peut ensuite permettre d’approfondir les mécanismes les plus sensibles. Les approches doivent donc être considérées comme des moyens d’adapter le test aux objectifs de la mission plutôt que comme trois catégories strictement exclusives.

Comment préparer et cadrer un pentest ?

Un pentest commence bien avant les premiers tests techniques. La qualité de la mission dépend en grande partie de la manière dont les objectifs, le périmètre et les conditions d’intervention ont été définis.

Un cadrage insuffisant peut conduire les pentesters à consacrer du temps à des éléments secondaires, à ne pas disposer des accès nécessaires pour tester certaines fonctionnalités ou, à l’inverse, à réaliser des opérations présentant un risque non anticipé pour l’environnement.

Définir les objectifs du pentest

La première question à poser n’est pas « combien d’adresses IP devons-nous tester ? », mais « qu’essayons-nous de vérifier ? ».

Une entreprise peut vouloir évaluer son exposition externe, obtenir une analyse approfondie d’une nouvelle application, vérifier les possibilités de mouvement latéral depuis un poste compromis, tester l’isolation entre plusieurs clients d’une plateforme SaaS ou valider les permissions d’un agent IA.

Ces objectifs conditionnent ensuite la méthodologie, le périmètre, les accès fournis et le temps nécessaire.

Définir le scope du pentest

Le scope correspond à l’ensemble des éléments que les pentesters sont autorisés à tester. Il doit être suffisamment précis pour éviter toute ambiguïté.

Pour une application web, il peut inclure le domaine principal, les sous-domaines, les API, les interfaces d’administration et les différents rôles utilisateurs. Pour une infrastructure, il peut être défini à partir de plages IP, de domaines, de réseaux internes, de tenants cloud ou de domaines Active Directory.

Le scope doit également identifier les éléments explicitement exclus. Une application peut appeler un prestataire de paiement ou un service SaaS tiers. Le fait que cette intégration soit utilisée par l’application ne signifie pas que le pentester est autorisé à tester directement l’infrastructure du fournisseur.

Il faut aussi distinguer le périmètre technique du périmètre fonctionnel. Une URL peut être dans le scope tandis que certaines fonctionnalités ou données restent exclues, par exemple un module de paiement réel ou une interface connectée à un système industriel critique.

Définir les règles d’engagement

Les règles d’engagement, ou Rules of Engagement, précisent les techniques autorisées et les éventuelles restrictions.

Le cadrage doit notamment préciser les conditions applicables aux attaques susceptibles de perturber la disponibilité, aux tests de brute force, aux modifications de données, à l’installation de fichiers ou de mécanismes de persistance, à l’exfiltration de données, aux campagnes d’ingénierie sociale ou aux tentatives d’intrusion physique.

Sur un environnement de production, le pentester privilégie généralement une démonstration proportionnée au risque. S’il identifie une injection SQL permettant potentiellement d’extraire une base contenant plusieurs millions d’enregistrements, il n’est pas nécessaire d’exfiltrer l’ensemble de la base pour démontrer la vulnérabilité.

Les règles d’engagement définissent précisément ce niveau de preuve acceptable et permettent d’éviter que la recherche d’un impact ne crée elle-même un incident.

Cadre légal, autorisations et systèmes tiers

Un pentest doit être autorisé de manière explicite par l’organisation légitime à le faire. Cette autorisation doit correspondre au périmètre réellement testé et aux techniques prévues.

Les dépendances tierces constituent un point de vigilance important. Héberger une application sur une infrastructure cloud ou intégrer un service SaaS ne donne pas automatiquement le droit de tester les systèmes du fournisseur au-delà de ce que ses conditions autorisent.

Le cadrage doit donc vérifier qui possède les actifs, quelles autorisations sont nécessaires et quelles restrictions sont imposées par les fournisseurs impliqués.

Les règles relatives au traitement des données doivent également être définies : stockage des preuves, chiffrement, durée de conservation, personnes autorisées à y accéder et modalités de suppression à la fin de la mission.

Pentest en production ou en préproduction ?

De nombreux pentests sont réalisés directement sur des environnements de production. Cela permet de tester la configuration réellement exposée aux utilisateurs et aux attaquants.

Mais le risque opérationnel doit être maîtrisé. Le pentester privilégiera autant que possible les preuves d’exploitation minimales permettant de démontrer une vulnérabilité sans provoquer d’impact inutile.

Une préproduction représentative peut être préférable pour certaines manipulations invasives. Elle doit toutefois reproduire suffisamment fidèlement l’architecture, la configuration, les rôles et les mécanismes de sécurité de la production, sans quoi les conclusions peuvent perdre en pertinence.

Méthodologie et déroulement d’un pentest

Il n’existe pas une méthodologie unique applicable à toutes les missions. Un pentest mobile, Active Directory ou LLM nécessite des techniques spécifiques.

Les pentesters s’appuient néanmoins sur différents référentiels reconnus, par exemple l’OWASP Web Security Testing Guide pour les applications web, l’OWASP MASVS et MASTG pour les applications mobiles, l’OWASP API Security Top 10, le NIST SP 800-115 ou encore des méthodologies comme PTES.

Dans la pratique, un pentest suit plusieurs grandes phases. Elles ne doivent pas être considérées comme strictement linéaires. La découverte d’une vulnérabilité peut conduire le pentester à revenir sur la cartographie, à découvrir une nouvelle partie du système puis à reprendre ses tests sur cette surface nouvellement accessible.

Reconnaissance et identification de la surface d’attaque

La reconnaissance consiste à collecter les informations permettant de comprendre la cible. Dans un scénario externe, une partie de ces informations peut provenir de sources publiques.

Le pentester peut rechercher des domaines et sous-domaines, plages IP, technologies, services exposés, documents publics, dépôts de code accessibles, métadonnées ou informations divulguées sur Internet.

Cette phase peut révéler des éléments qui ne sont plus réellement suivis par l’organisation : ancienne application, environnement de test, sous-domaine oublié ou service exposé par erreur.

Sur une application, la reconnaissance consiste également à identifier les technologies utilisées, mécanismes d’authentification, fonctions publiques, API et différents points d’entrée disponibles.

Cartographie et compréhension de la cible

Une fois la surface d’attaque identifiée, le pentester cherche à comprendre son fonctionnement.

Sur une application, cela signifie parcourir les fonctionnalités, identifier les différents rôles, comprendre les objets métier et observer les échanges entre le navigateur, les API et les services backend.

Sur un réseau interne, la cartographie porte sur les machines, services, utilisateurs, groupes, relations de confiance et mécanismes d’authentification.

Sur une architecture LLM, elle doit également intégrer les modèles, prompts système, RAG, bases vectorielles, agents, outils, workflows et serveurs MCP.

L’objectif n’est pas simplement de dresser un inventaire. La cartographie permet surtout d’identifier les relations entre les composants et donc les scénarios d’attaque potentiels.

Modélisation des scénarios d’attaque

À partir de la cartographie, le pentester formule des hypothèses.

Si une application dispose de plusieurs rôles, il cherchera par exemple à vérifier si un utilisateur peut accéder aux fonctionnalités d’un autre rôle. Si un environnement cloud contient plusieurs identités et rôles IAM, il analysera les possibilités de changement de rôle ou d’escalade. Si un agent IA peut appeler plusieurs outils, il cherchera à déterminer quelles actions pourraient être déclenchées depuis une entrée non fiable.

Cette approche orientée scénario évite de réduire le pentest à l’exécution mécanique d’une checklist.

Identification des vulnérabilités

Le pentester combine tests manuels et outils spécialisés. Les outils permettent notamment d’automatiser certaines tâches répétitives : découverte de services, détection de composants, fuzzing, analyse de réponses ou identification de vulnérabilités connues.

Les tests manuels sont indispensables pour comprendre les comportements inattendus et les failles de logique. Une réponse légèrement différente, un comportement inhabituel après modification d’un paramètre ou une incohérence entre deux rôles peuvent constituer les premiers indices d’une vulnérabilité.

Exploitation contrôlée

Une vulnérabilité potentielle n’est pas automatiquement considérée comme exploitable. Le pentester cherche donc à la valider.

L’objectif est d’obtenir une preuve suffisamment forte pour démontrer le risque tout en limitant l’impact sur le système.

Pour une injection SQL, il pourra par exemple démontrer qu’il peut lire une information précise sans extraire l’intégralité de la base. Pour une vulnérabilité de contrôle d’accès, il pourra accéder à un objet de test appartenant à un autre compte plutôt qu’aux données d’un véritable utilisateur.

Cette logique de preuve proportionnée est particulièrement importante lors des tests en production.

Enchaînement des vulnérabilités et construction de chemins d’attaque

Les vulnérabilités ne doivent pas toujours être étudiées séparément. L’une des principales valeurs ajoutées d’un pentest réside dans la capacité à construire des chaînes d’attaque.

Une application peut par exemple exposer une adresse interne. Cette fuite d’information paraît faible. Le pentester découvre ensuite une SSRF limitée permettant à l’application d’effectuer des requêtes vers certaines destinations internes. L’adresse découverte précédemment permet alors d’atteindre un service d’administration non exposé sur Internet. Ce service présente à son tour un défaut de contrôle d’accès.

Aucune de ces failles ne raconte à elle seule l’ensemble du risque. Leur combinaison révèle un chemin de compromission beaucoup plus important.

Cette logique est particulièrement présente dans Active Directory, le cloud et les architectures agentiques, où plusieurs permissions ou configurations apparemment limitées peuvent former un chemin vers un actif critique.

Post-exploitation

Lorsque le cadre de la mission l’autorise, le pentester peut poursuivre les tests après l’obtention d’un premier accès.

L’objectif n’est pas nécessairement d’obtenir le contrôle maximal de l’environnement, mais de déterminer les conséquences de la compromission.

Sur un réseau interne, cela peut impliquer de rechercher des possibilités de mouvement latéral ou d’élévation de privilèges. Sur une infrastructure cloud, le pentester peut examiner les permissions obtenues et les autres ressources accessibles. Sur un système LLM, il peut évaluer les effets d’une action déclenchée par un agent sur les autres composants.

La post-exploitation doit toujours respecter les objectifs et limites définis dans les règles d’engagement.

Nettoyage de l’environnement

Les modifications réalisées pour les besoins des tests doivent être supprimées lorsque cela est possible. Comptes temporaires, fichiers déposés, données de test ou autres artefacts doivent être nettoyés afin de laisser le système dans un état maîtrisé.

Les éventuelles modifications qui ne peuvent pas être annulées doivent être documentées et signalées.

Analyse et qualification des risques

Les vulnérabilités identifiées sont ensuite analysées afin de déterminer leur criticité. Cette étape ne doit pas être réduite à l’application automatique d’un score.

La facilité d’exploitation, les privilèges nécessaires, l’exposition de la cible, les données accessibles, l’impact métier et les possibilités d’enchaînement doivent être pris en compte.

Reporting, restitution et contre-audit

La mission se termine par la formalisation des résultats. Le rapport doit permettre aux équipes de comprendre les scénarios, reproduire les problèmes et corriger les causes.

Une restitution orale permet ensuite d’échanger avec les auditeurs. Après correction, un contre-audit peut vérifier que les vulnérabilités ont réellement été supprimées et qu’aucun effet de bord n’a été introduit.

Comment évaluer la criticité des vulnérabilités ?

Les rapports de pentest classent généralement les vulnérabilités selon plusieurs niveaux : informationnel, faible, moyen, élevé ou critique. Des systèmes de scoring comme CVSS peuvent servir de base pour objectiver certains critères.

Mais la criticité réelle dépend fortement du contexte. Une vulnérabilité permettant de lire un fichier arbitraire n’aura pas le même impact si le serveur contient uniquement des informations publiques ou s’il héberge des secrets donnant accès à toute l’infrastructure.

Prendre en compte l’exploitabilité

L’attaque nécessite-t-elle une authentification ? Des privilèges particuliers ? Une interaction d’un utilisateur ? Un accès au réseau interne ? Une condition rare ? Une connaissance préalable ?

Une vulnérabilité très simple à exploiter depuis Internet n’a pas le même niveau de risque qu’une faiblesse nécessitant déjà un accès administrateur local.

Mesurer l’impact technique

L’évaluation porte sur les conséquences techniques : atteinte à la confidentialité, l’intégrité ou la disponibilité, exécution de code, lecture ou modification de données, élévation de privilèges, contournement d’authentification, mouvement latéral ou contrôle d’un composant critique.

Intégrer l’impact métier

L’impact technique doit être replacé dans le contexte de l’organisation. Une faille touchant un système secondaire n’a pas nécessairement le même poids qu’une faiblesse affectant des transactions financières, des données de santé, un service réglementé ou un actif indispensable à l’activité.

Prendre en compte les chaînes d’attaque

Une vulnérabilité peut sembler modérée lorsqu’elle est évaluée isolément, mais devenir critique si elle fournit l’étape manquante d’un chemin d’attaque.

Le rapport doit donc expliquer les interactions entre failles lorsque celles-ci modifient significativement le risque.

Prioriser au-delà du score

La remédiation ne doit pas toujours suivre mécaniquement l’ordre des scores. Une faiblesse facilement exploitable sur un actif très exposé peut mériter une priorité supérieure à une vulnérabilité théoriquement plus sévère mais extrêmement difficile à atteindre.

Le pentest doit fournir suffisamment de contexte pour aider l’organisation à arbitrer ces priorités.

Rapport de pentest : quels résultats et livrables ?

Le rapport constitue l’un des principaux livrables d’un pentest. Sa qualité est déterminante car c’est à partir de ce document que les équipes pourront comprendre et corriger les vulnérabilités.

Que doit contenir un rapport de pentest ?

Un rapport technique complet doit préciser le contexte de la mission, le périmètre testé, les conditions et éventuelles limitations, la méthodologie utilisée, les vulnérabilités identifiées, leur criticité, leur impact, les preuves d’exploitation et les recommandations de correction.

Pour chaque vulnérabilité, le rapport doit permettre à une équipe technique de comprendre le problème sans avoir participé au pentest. Les étapes de reproduction, captures, requêtes ou extraits nécessaires doivent être suffisamment précis.

Les recommandations doivent être concrètes. Indiquer qu’une application doit « renforcer ses contrôles d’accès » est rarement suffisant. Le rapport doit expliquer quel contrôle manque, à quel endroit et quel principe de sécurité doit être appliqué.

Comment présenter les preuves d’exploitation ?

La preuve doit démontrer l’impact sans exposer inutilement des données sensibles. Une capture montrant l’accès à un compte de test peut être préférable à l’affichage de nombreuses données réelles.

Les preuves peuvent inclure des requêtes HTTP, captures d’écran, sorties de commandes, chemins de privilèges, extraits de configuration ou séquences d’actions. Elles doivent être choisies en fonction du type de vulnérabilité.

La synthèse managériale

Un rapport technique peut être difficile à exploiter par une direction ou par des interlocuteurs non spécialistes de cybersécurité.

Une synthèse managériale présente les principaux résultats dans un langage orienté risque. Elle peut expliquer le niveau de sécurité global observé, les principaux scénarios de compromission, les actifs concernés, les risques métier et les priorités de remédiation.

L’objectif n’est pas de simplifier à l’excès, mais de permettre une prise de décision.

La restitution des résultats

Le rapport ne devrait idéalement pas être simplement envoyé sans échange. Une réunion de restitution permet aux pentesters et aux équipes auditées d’examiner les résultats, de poser des questions et de discuter des différentes options de correction.

Cette étape favorise également le transfert de compétences : les développeurs et administrateurs comprennent mieux comment les vulnérabilités ont été identifiées et exploitées.

Le contre-audit ou re-test

Une fois les vulnérabilités corrigées, un contre-audit permet de vérifier l’efficacité des remédiations. Le pentester reprend les vulnérabilités concernées et tente de reproduire les scénarios précédemment identifiés.

L’objectif est de vérifier non seulement que le symptôme a disparu, mais que la cause du problème a réellement été corrigée. Cette étape peut également révéler d’éventuels effets de bord introduits par les correctifs.

Combien coûte un pentest ?

Le prix d’un pentest dépend principalement du temps nécessaire pour obtenir le niveau de couverture attendu. Il est donc difficile de donner un tarif pertinent sans connaître le périmètre.

Plusieurs facteurs influencent directement la charge de travail : taille du périmètre, nombre de fonctionnalités, nombre de rôles utilisateurs, complexité de l’architecture, technologies utilisées, nombre d’environnements, niveau de profondeur attendu, approche boîte noire/grise/blanche, besoins particuliers de reporting et éventuels tests complémentaires.

Une application composée de quelques fonctionnalités avec deux rôles ne nécessite évidemment pas la même charge qu’une plateforme SaaS comportant plusieurs dizaines de modules, une architecture microservices et une dizaine de niveaux de privilèges.

Comment est généralement construit un devis de pentest ?

Le prestataire commence par qualifier le périmètre et les objectifs. Il estime ensuite le nombre de jours d’audit nécessaire, les profils mobilisés et le temps de reporting ou de restitution.

Le coût peut donc être exprimé à partir d’un nombre de jours/homme, mais ce chiffre n’a de sens qu’après cadrage. Deux périmètres de taille visuellement similaire peuvent nécessiter des efforts très différents selon leur complexité fonctionnelle.

Pourquoi les tarifs peuvent-ils varier fortement entre prestataires ?

La différence peut provenir du niveau d’expérience des consultants, de la profondeur des tests, de la part d’automatisation, du temps consacré à l’analyse manuelle, de la qualité du reporting, de la présence ou non d’un contre-audit et de l’accompagnement proposé.

Un prix très faible doit donc être analysé à la lumière de la couverture réellement prévue. Un scan automatisé accompagné d’un rapport standardisé ne fournit pas la même valeur qu’un pentest manuel approfondi.

Comment choisir un prestataire de pentest ?

Le choix d’un prestataire ne doit pas reposer uniquement sur le prix. Deux pentests annoncés avec un périmètre similaire peuvent en réalité fournir des niveaux de profondeur très différents.

Vérifier la place accordée aux tests manuels

Les outils automatisés sont utiles et font partie du travail du pentester. Mais une prestation reposant essentiellement sur l’exécution de scanners ne constitue pas un véritable pentest approfondi.

Les tests manuels sont indispensables pour les contrôles d’accès, la logique métier, les chaînes de vulnérabilités et de nombreux mécanismes spécifiques à l’application.

Évaluer l’expertise sur le périmètre concerné

Les compétences nécessaires pour tester une application web, une architecture cloud, Active Directory, un objet connecté ou un système LLM sont différentes.

Il est donc important de vérifier que l’équipe dispose de l’expertise correspondant à la technologie et au niveau de profondeur attendu.

S’intéresser à la qualité du rapport

Le rapport constitue une part majeure de la valeur du pentest. Il doit permettre aux équipes de comprendre les vulnérabilités, de les reproduire et surtout de les corriger.

Un exemple de rapport anonymisé peut être utile pour évaluer le niveau de détail, la clarté des preuves et la qualité des recommandations.

Vérifier l’accompagnement après les tests

Les échanges avec les pentesters, la restitution et la possibilité de réaliser des contre-audits facilitent considérablement la remédiation.

Le pentest ne devrait pas s’arrêter au simple envoi du rapport.

Prendre en compte les certifications et qualifications

Les certifications peuvent apporter des éléments objectifs concernant les compétences des auditeurs ou les processus du prestataire.

Les certifications individuelles comme OSCP, OSWE, BSCP ou d’autres certifications techniques permettent de valider certaines compétences spécifiques. Les certifications et qualifications organisationnelles comme CREST, ISO 27001, ISO 27701 ou PASSI apportent quant à elles des éléments sur les processus, la gestion de la sécurité de l’information ou l’encadrement des prestations.

Elles ne garantissent toutefois pas à elles seules la qualité d’une mission particulière. Elles doivent être combinées avec l’expérience, la méthodologie, la spécialisation et la qualité des livrables.

Vérifier la gestion des données et la confidentialité

Le prestataire manipulera potentiellement des preuves sensibles : données extraites, identifiants, configurations, code source ou informations sur l’architecture.

Il est donc important de vérifier les mesures de protection mises en place : chiffrement, accès restreint, conservation limitée, procédures de suppression et sécurité des canaux d’échange.

Comprendre qui réalisera réellement la mission

Il peut être utile de savoir si les tests sont réalisés par une équipe interne, par des sous-traitants ou par un réseau externe de consultants.

Ce point peut avoir un impact sur la maîtrise des processus, la confidentialité, la communication et la continuité entre les différentes phases de la mission.

Conclusion : le pentest comme outil de mesure du risque réel

Le pentest ne consiste pas simplement à lancer des scanners ou à rechercher le plus grand nombre possible de vulnérabilités.

Sa valeur réside dans la combinaison de plusieurs compétences : compréhension du système, connaissance des techniques d’attaque, créativité, capacité à exploiter les vulnérabilités et aptitude à mesurer leur impact réel.

Un test d’intrusion bien conduit permet ainsi de passer d’une vision théorique des risques à une compréhension concrète des scénarios de compromission. Il montre ce qu’un attaquant pourrait réellement atteindre, dans quelles conditions et à partir de quelles faiblesses.

Pour autant, un pentest reste une photographie d’un périmètre à un instant donné. Il doit donc s’inscrire dans une démarche plus globale comprenant développement sécurisé, gestion des vulnérabilités, durcissement, supervision, sensibilisation et tests réguliers.

L’enjeu n’est finalement pas de pouvoir affirmer qu’un système est « sécurisé », mais de connaître ses faiblesses, de comprendre les chemins d’attaque qui comptent réellement et de disposer des informations nécessaires pour les réduire durablement.