Pentest : le test d'intrusion expliqué, de la boîte noire au TLPT

Un pentest, ou test d'intrusion, est une attaque simulée et autorisée contre un système d'information, une application ou un réseau, menée pour vérifier si ses failles sont réellement exploitables et jusqu'où elles mènent. C'est l'une des activités de l'audit de cybersécurité, la plus concrète : là où un audit documentaire constate qu'une règle n'est pas appliquée, le pentest montre ce qu'un attaquant en ferait. Voici les différents types de tests, leur déroulé, ce que vous devez exiger du rapport, à quelle fréquence tester, et comment le test de pénétration fondé sur la menace (TLPT) imposé par DORA pousse la logique plus loin.

Le mot vient de l'anglais penetration test, que l'on traduit par test d'intrusion ou test de pénétration. Des spécialistes, les testeurs ou pentesteurs, reproduisent les techniques d'un attaquant contre un périmètre convenu à l'avance : un site web, une application mobile, une adresse IP exposée sur Internet, un réseau interne. Leur objectif n'est pas de dresser l'inventaire de toutes les faiblesses possibles, mais de démontrer des chemins d'attaque réels : partir d'une faille, l'exploiter, en enchaîner une autre, et mesurer l'impact obtenu (lecture de données, prise de contrôle d'un serveur, compte administrateur).

Le guide du NIST sur les tests de sécurité (SP 800-115) le décrit ainsi : des évaluateurs imitent des attaques réelles pour contourner les protections d'une application, d'un système ou d'un réseau, en utilisant les outils et les techniques des attaquants. On le confond souvent avec deux pratiques voisines :

Le pentest ne remplace pas l'analyse de risques : il vérifie des protections, quand l'analyse de risques décide lesquelles sont nécessaires. Mais les deux se nourrissent. Un pentest bien ciblé part des scénarios les plus redoutés, et ses résultats corrigent les hypothèses de vraisemblance de l'analyse.

Deux questions définissent un test d'intrusion : d'où part l'attaquant et que sait-il au départ.

Selon le point de départ

• Test externe : depuis Internet, contre tout ce qui est exposé (sites, messagerie, accès à distance, pare-feu). C'est le point de vue d'un attaquant anonyme, et le plus urgent : les rançongiciels qui entrent par les équipements de bordure en rappellent l'enjeu.
• Test interne : depuis le réseau de l'entreprise, avec un poste ou une prise réseau. Il simule un poste compromis par hameçonnage ou un intervenant malveillant, et mesure la facilité à rebondir jusqu'à l'annuaire ou aux serveurs sensibles.
• Test applicatif : une application web ou mobile, ou une interface de programmation (API). Les testeurs examinent l'authentification, les droits, la gestion des sessions, les injections. Le guide de test de l'OWASP, une fondation ouverte sur la sécurité des applications, sert de référence.
• Autres périmètres : réseaux sans fil, objets connectés et systèmes industriels, ou encore ingénierie sociale (faux courriels, appels) et intrusion physique dans les locaux, qui exigent un cadrage particulièrement précis.

Boîte noire, grise ou blanche

En boîte noire, les testeurs ne reçoivent que le nom de la cible : c'est réaliste, mais une partie du temps passe à découvrir ce que vous auriez pu leur dire. En boîte grise, ils disposent d'un compte utilisateur, ce qui permet de tester ce qu'un client ou un salarié pourrait faire au-delà de ses droits. En boîte blanche, ils ont l'architecture, la configuration, parfois le code source : le test couvre plus de terrain dans le même nombre de jours. Pour une application métier, la boîte grise est souvent le meilleur compromis ; le référentiel PASSI de l'ANSSI demande d'ailleurs de fixer au cadrage le mode de test et les profils d'attaquant simulés.

Les méthodes publiées, comme le guide SP 800-115 du NIST, découpent le test en quatre temps : préparation, découverte, attaque et compte rendu, avec des allers-retours entre découverte et attaque à chaque nouvel accès obtenu. En pratique, une mission se déroule ainsi :

1. Cadrage et autorisation. Périmètre exact (adresses, applications, comptes), exclusions, horaires, mode de test, contacts d'urgence et précautions pour la production. Rien ne commence sans document signé.
2. Reconnaissance. Collecte d'informations publiques et techniques : sous-domaines, services exposés, versions, technologies, adresses de messagerie.
3. Recherche de vulnérabilités. Outils automatiques et analyse manuelle pour repérer les failles candidates : versions obsolètes, configurations faibles, défauts de logique applicative.
4. Exploitation et rebond. Les testeurs confirment les failles en les exploitant de façon maîtrisée, puis utilisent chaque accès obtenu pour aller plus loin, jusqu'aux objectifs convenus.
5. Restitution et rapport. Présentation des constats dès la fin des travaux, puis rapport écrit avec la gravité de chaque faille et les corrections proposées.
6. Correction et contre-test. L'équipe corrige, puis les testeurs vérifient que chaque faille est vraiment fermée.

Le cadre administratif de la mission (vérification de l'aptitude du prestataire, convention, réunion de clôture, destruction des données) est détaillé dans notre article sur l'audit de cybersécurité, qui suit les sept étapes du référentiel PASSI. Le schéma ci-dessous montre ce qui se passe pendant la partie technique.

Techniquement, un pentest et une attaque réelle se ressemblent. Ce qui les distingue, c'est l'autorisation. En France, accéder ou se maintenir frauduleusement dans tout ou partie d'un système de traitement automatisé de données est puni de trois ans d'emprisonnement et de 100 000 euros d'amende par l'article 323-1 du Code pénal, avec des peines plus lourdes si des données sont modifiées ou le fonctionnement perturbé. L'article 323-3-1 vise aussi la détention et la diffusion d'outils d'attaque, sauf motif légitime, notamment de recherche ou de sécurité informatique.

D'où trois précautions. L'autorisation doit être signée par une personne habilitée à engager le propriétaire du système. Elle doit couvrir les systèmes hébergés chez des tiers : un hébergeur ou un fournisseur de services en nuage a souvent ses propres règles, et tester son infrastructure sans son accord pose problème. Enfin, toute action risquant une indisponibilité (déni de service, exploitation instable) doit être expressément acceptée, avec un contact joignable pour tout arrêter.

Un rapport de pentest se lit à deux niveaux. Exigez :

• une synthèse pour la direction : appréciation générale, scénarios d'attaque réussis racontés simplement, risques majeurs, limites du test (ce qui n'a pas été testé et pourquoi) ;
• une fiche par faille : description, systèmes touchés, preuves (captures, requêtes), conditions d'exploitation, gravité, correction recommandée et priorité ;
• le chemin d'attaque quand plusieurs failles ont été enchaînées : c'est souvent la combinaison qui crée le risque, pas chaque faille isolée ;
• le rappel du cadre : périmètre, dates, mode de test, comptes fournis.

Pour coter la gravité, beaucoup de prestataires utilisent le système commun de notation des vulnérabilités (CVSS), maintenu par le FIRST, le forum international des équipes de réponse aux incidents. Sa version 4.0, publiée le 1er novembre 2023, donne une note de 0 à 10 selon la facilité d'exploitation et l'impact technique. Une note CVSS ne dit pourtant rien de votre activité : une faille critique sur un serveur de test isolé peut attendre, une faille moyenne sur l'application de paie, non. Rapprochez chaque constat de vos propres échelles, celles de votre matrice des risques, pour décider de l'ordre des corrections.

Aucune loi n'impose un pentest annuel à toutes les entreprises. La fréquence dépend de votre exposition, de la vitesse à laquelle vos systèmes changent et des cadres qui s'appliquent à vous :

• Cartes de paiement : la norme PCI DSS (exigence 11.4) demande des tests internes et externes au moins tous les douze mois et après toute modification importante de l'infrastructure ou des applications, ainsi que la correction des failles exploitables et un nouveau test.
• Secteur financier : DORA (articles 24 et 25) impose un programme de tests de résilience qui couvre au moins une fois par an tous les systèmes soutenant des fonctions critiques ou importantes ; les tests d'intrusion figurent parmi les tests cités.
• Entités NIS 2 : l'article 21 de la directive demande des politiques et procédures pour évaluer l'efficacité des mesures de cybersécurité. Le pentest est l'un des moyens les plus convaincants d'y répondre (voir notre article sur NIS 2).
• ISO 27001 : la norme demande de gérer les vulnérabilités techniques et de tester la sécurité lors des développements ; les tests d'intrusion en sont une preuve courante pour votre SMSI.

En dehors de ces cadres, une pratique répandue consiste à tester chaque année les systèmes exposés et critiques, et à déclencher un test à chaque changement important : nouvelle application, refonte, ouverture d'un accès à distance. Vos clients peuvent aussi l'exiger : la synthèse du dernier test d'intrusion fait partie des preuves demandées dans un questionnaire de sécurité fournisseur ou un plan d'assurance sécurité.

En France, l'ANSSI qualifie des prestataires d'audit de la sécurité des systèmes d'information (PASSI) selon un référentiel public, dont la version 2.2 date du 1er août 2024. Le test d'intrusion est l'une des cinq activités qualifiables, aux côtés des audits d'architecture, de configuration, de code source et de l'audit organisationnel et physique, à un niveau substantiel ou élevé. Un prestataire n'est qualifié que pour certaines activités : vérifiez sa portée dans le catalogue de l'ANSSI.

La qualification n'est obligatoire que dans certains cadres, comme les contrôles des opérateurs d'importance vitale. Ailleurs, elle reste un bon repère : compétences vérifiées, règles de confidentialité, déroulé maîtrisé. Quel que soit le prestataire, posez quelques questions simples : qui seront les testeurs, quelle méthode, quelles précautions en production, comment les données collectées seront-elles protégées puis détruites, et le contre-test est-il compris dans le prix ?

Sur le prix, aucun barème public n'existe et les fourchettes qui circulent ne sont pas sourcées. Le coût dépend du nombre de jours de test, qui dépend lui-même du périmètre, du mode de test et du niveau d'exigence ; notre article sur l'audit de cybersécurité détaille ces facteurs.

Le règlement DORA va plus loin pour les entités financières que leur autorité désigne : elles doivent mener, au moins tous les trois ans, un test de pénétration fondé sur la menace (TLPT, de l'anglais threat-led penetration testing). Trois différences le séparent d'un pentest classique :

• il part du renseignement sur la menace : un fournisseur spécialisé étudie les groupes d'attaquants qui visent l'entité et en tire des scénarios réalistes ;
• il vise la production : les systèmes réels qui soutiennent les fonctions critiques, y compris ceux confiés à des prestataires ;
• il teste aussi la défense : l'équipe rouge agit pendant au moins douze semaines sans que les défenseurs soient prévenus, puis les deux équipes rejouent ensemble les attaques.

Le règlement délégué 2025/1190 détaille les phases, et la Banque centrale européenne a aligné son cadre TIBER-EU sur ces exigences en février 2025. Notre chapitre du guide DORA sur les tests de résilience et le TLPT décrit le déroulé complet. Pour la plupart des entités, en revanche, le programme de tests annuel, pentests compris, reste l'essentiel de l'obligation.