Un test d’intrusion, ou pentest, est une évaluation offensive commanditée : une équipe de spécialistes tente de compromettre un système d’information avec l’autorisation écrite de son propriétaire, sur un périmètre et selon des règles convenus à l’avance. La démarche établit ce qu’un attaquant obtiendrait concrètement — lecture de données confidentielles, prise de contrôle d’un serveur puis rebond vers d’autres environnements — pour en déduire des corrections. Le NIST en décrit la méthode dans son guide SP 800-115 consacré aux tests et évaluations de sécurité. Pour un établissement bancaire ou financier, l’exercice confronte au terrain l’appréciation du risque cyber menée sur documents : une faille restée théorique dans les analyses change de priorité le jour où elle a permis d’atteindre un applicatif de paiement.
Boîte noire, grise ou blanche : trois niveaux d’information
La quantité d’information remise aux testeurs définit l’approche retenue. En boîte noire, l’équipe part de zéro, sans compte ni documentation ; elle reproduit la situation d’un attaquant externe qui découvre sa cible. Cette approche est la plus proche des conditions d’une attaque réelle, mais une part du temps se consomme en reconnaissance, au détriment de la profondeur d’analyse.
La boîte grise fournit un point de départ intermédiaire, le plus souvent un ou plusieurs comptes et une description sommaire de l’environnement. Elle correspond au scénario d’un client malveillant, d’un salarié ou d’un attaquant ayant déjà dérobé des identifiants. Les applications s’y prêtent bien, parce que l’effort se concentre sur les contrôles d’accès et sur l’étanchéité entre profils — un enjeu central dès lors que l’application manipule des comptes bancaires.
En boîte blanche, les testeurs reçoivent l’architecture, les configurations, parfois le code source. L’objectif n’est plus de simuler un attaquant mais de passer le périmètre au crible : ce mode met au jour des faiblesses qu’aucune approche externe n’aurait atteintes dans le temps imparti, en contrepartie d’un réalisme moindre.
Le déroulé d’une mission
Cinq phases s’enchaînent classiquement, et la première conditionne toutes les autres. Le cadrage fixe le périmètre exact, les plages horaires autorisées, les techniques exclues, les contacts d’urgence et la conduite à tenir en cas de découverte critique. Les scénarios retenus gagnent à refléter des menaces plausibles pour le métier, telles que les recense le référentiel des scénarios de risques cyber. Le commanditaire décide aussi à ce stade si le SOC est prévenu : un test mené à l’insu des équipes de supervision renseigne sur leur capacité de détection, en plus des vulnérabilités techniques.
Suivent la reconnaissance — cartographie des services exposés et des technologies employées, collecte d’informations publiques exploitables — puis l’exploitation des faiblesses repérées. En phase de post-exploitation, l’équipe mesure la portée réelle de chaque accès obtenu : élévation de privilèges, puis progression vers d’autres systèmes jusqu’aux données visées. Chaque action est journalisée, de façon à rester traçable et réversible.
Le rapport clôt la mission. Il documente chaque constat avec sa preuve et son niveau de criticité, assorti d’une recommandation, en distinguant la synthèse destinée au management du détail technique utile aux équipes. Si les testeurs découvrent en cours de route la trace d’une compromission réelle et antérieure, les règles convenues prévoient une notification immédiate : le sujet relève alors de l’équipe de réponse à incident, non plus du prestataire.
Ce qu’un test d’intrusion n’est pas
La confusion la plus fréquente concerne le scan de vulnérabilités automatisé. Un scanner compare des versions installées à des bases de failles publiées ; il produit une liste large mais superficielle, où figurent des faux positifs. Le pentest ajoute l’exploitation manuelle et la démonstration d’impact, y compris en enchaînant des faiblesses de gravité modeste pour construire un chemin d’attaque complet. Un établissement combine généralement les deux : le scan pour surveiller en continu un parc étendu, le pentest pour éprouver en profondeur un périmètre délimité.
Il se distingue aussi des tests fondés sur la menace, dits TLPT : des exercices d’ampleur qui simulent un attaquant avancé visant les fonctions critiques d’un établissement, en s’appuyant sur du renseignement sur la menace. Le règlement européen DORA impose ce format à certaines entités financières, et la préparation d’un TLPT au titre de DORA obéit à un cadre spécifique, avec des exigences propres aux testeurs comme aux scénarios. Un pentest classique reste plus court et plus ciblé ; son organisation demeure au libre choix de l’établissement.
Troisième dispositif voisin, le programme de bug bounty ouvre la recherche de failles à une communauté de chercheurs, en continu et avec une rémunération au résultat. Le test d’intrusion mobilise au contraire une équipe désignée, sur une durée convenue, avec un rapport couvrant l’ensemble du périmètre — y compris ce qui a résisté.
Choisir un prestataire
En France, la qualification PASSI — prestataires d’audit de la sécurité des systèmes d’information — est délivrée sous l’égide de l’ANSSI, sur la base d’un référentiel d’exigences couvrant la compétence des auditeurs et la protection des informations manipulées pendant la mission. L’agence recense les prestataires qualifiés parmi ses solutions certifiées et qualifiées. Cette qualification est fréquemment demandée dans les appels d’offres du secteur financier, sans être obligatoire pour toute mission.
D’autres critères pèsent dans le choix : la méthodologie proposée, les références sur des périmètres comparables, l’assurance couvrant un éventuel dommage causé pendant le test, les engagements de confidentialité. Le rapport final concentre des informations dont la divulgation serait dommageable ; ses conditions de stockage puis de destruction méritent d’être écrites au contrat.
Tirer parti des résultats
Passé la restitution, chaque constat rejoint le processus de gestion des vulnérabilités de l’établissement, où il est priorisé — la grille CVSS, publiée par le FIRST, sert de langage commun — au regard de l’exposition des actifs concernés, puis suivi jusqu’à correction. Les faiblesses organisationnelles relevées, une gestion des droits défaillante par exemple, alimentent le plan d’action du système de management de la sécurité ; dans une démarche de certification ISO 27001, les tests réguliers viennent documenter l’amélioration continue.
La contre-vérification mérite d’être prévue dès le contrat. Cette nouvelle passe, limitée aux constats corrigés, confirme l’efficacité des mesures : une correction peut s’avérer partielle, ou contournable par une variante du même chemin d’attaque. Répétés dans le temps, les rapports permettent de suivre l’évolution du niveau de sécurité d’un périmètre ; ils comptent parmi les éléments par lesquels un établissement financier démontre la robustesse de son dispositif, au même titre que les exercices de continuité qui nourrissent la résilience opérationnelle.
Questions fréquentes sur le test d’intrusion
À quelle fréquence tester un même périmètre ?
Aucune périodicité universelle ne s’impose. L’usage consiste à tester après tout changement significatif — refonte applicative ou exposition d’un nouveau service, par exemple — et à intervalle régulier pour les systèmes sensibles, selon un rythme que chaque organisation fixe dans sa politique de sécurité, en tenant compte des exigences réglementaires ou contractuelles qui lui sont propres.
Un test d’intrusion peut-il perturber la production ?
Le risque existe, et le cadrage sert précisément à le contenir : les scénarios les plus intrusifs peuvent être rejoués en préproduction plutôt que sur les systèmes réels, les techniques destructives comme le déni de service écartées d’emblée, et les créneaux d’intervention choisis hors des pics d’activité. Un incident demeure possible malgré ces précautions, ce qui justifie l’autorisation écrite préalable et l’examen de l’assurance du prestataire.
Quelle différence entre un pentest et un exercice red team ?
Le test d’intrusion cherche à couvrir un périmètre convenu et à en recenser les faiblesses. L’exercice red team poursuit un objectif — atteindre une donnée ou un système désigné — par tout chemin réaliste, dans la discrétion et sur une durée plus longue, afin d’éprouver également la détection et la réaction des équipes. Les TLPT du secteur financier relèvent de cette seconde famille, avec un encadrement réglementaire en plus.
Un rapport sans constat critique garantit-il la sécurité du système ?
Il atteste qu’une équipe donnée, dans un temps donné, n’a pas trouvé de chemin d’attaque majeur sur le périmètre convenu. La conclusion ne s’étend pas aux systèmes voisins ni aux vulnérabilités publiées après la mission. Le rapport mentionne donc sa date, son périmètre et ses limites méthodologiques, et ses conclusions ne valent que dans ce cadre.
