Pentest : obligations, autorisation et suivi des tests
Pentest : ce que prévoient RGPD et DORA, convention, périmètre, choix du prestataire et vérification des corrections après un test d’intrusion.
Un test d’intrusion, ou pentest, vérifie jusqu’où un intervenant autorisé peut compromettre un périmètre informatique défini. Son intérêt dépend autant de la préparation et des corrections que du rapport final. Avant de commander une mission, précisez le risque à évaluer, les systèmes concernés et la décision que les résultats doivent permettre de prendre.
Le pentest est-il obligatoire ?
L’Art. 32(1)(d) RGPD prévoit une procédure d’évaluation régulière de l’efficacité des mesures de sécurité, dans une approche adaptée au risque. Il n’impose pas à toutes les organisations un pentest annuel. La nature des vérifications, leur fréquence et leur périmètre doivent pouvoir être expliqués au regard du traitement. Source : RGPD, Art. 32(1) et (2).
La directive NIS2 prévoit des politiques et procédures d’évaluation de l’efficacité des mesures de gestion des risques à son Art. 21(2)(f). Cette disposition ne fixe pas non plus un calendrier universel de pentest. Son articulation avec les règles nationales et sectorielles doit être vérifiée pour l’entité concernée. Source : directive (UE) 2022/2555, Art. 21.
DORA distingue plusieurs niveaux. L’Art. 24(6) prévoit des tests appropriés au moins annuels sur les systèmes et applications soutenant des fonctions critiques ou importantes des entités financières concernées, hors microentreprises. Les tests avancés fondés sur la menace, ou TLPT, relèvent de l’Art. 26 : les entités désignées les réalisent au moins tous les trois ans, avec adaptation possible par l’autorité. Un test annuel approprié et un TLPT ne sont donc pas interchangeables. Source : règlement (UE) 2022/2554, Art. 24 à 27.
Autoriser les opérations et limiter leurs effets
Les articles 323-1 et suivants sanctionnent notamment l’accès frauduleux et l’entrave au fonctionnement. L’exception de motif légitime pour certains outils, prévue par l’article 323-3-1, ne permet pas de tester n’importe quel système. Source : Code pénal, Art. 323-1 à 323-3-1.
La convention écrite sert à établir l’autorisation et ses limites. Elle doit être validée par les personnes habilitées à autoriser les opérations, y compris lorsque des systèmes de prestataires sont concernés. Le propriétaire d’un compte cloud ne peut pas présumer qu’il dispose de tous les droits sur l’infrastructure de son fournisseur.
La convention doit préciser les environnements, comptes, méthodes, exclusions et plages horaires. Elle désigne les contacts joignables, l’autorité pouvant arrêter les opérations et le sort des preuves. Prévoyez aussi les livrables et la vérification des corrections : ils doivent être discutés avant de signer, pas découverts dans les options du devis.
Si le prestataire traite des données personnelles pour votre compte, examinez l’encadrement de la sous-traitance au titre de l’article 28. Un engagement de confidentialité ne remplace pas les obligations de cet article. Source : RGPD, Art. 28(3).
Choisir le type de test
Une mission en boîte noire part de peu d’informations ; une mission en boîte grise utilise des informations ou comptes limités ; une mission en boîte blanche donne davantage de visibilité sur l’architecture ou le code. Ces approches répondent à des questions différentes : exposition externe, abus de droits entre utilisateurs, robustesse d’une conception.
Demandez au prestataire d’expliquer ce que son approche permettra de conclure et ce qui restera hors champ. Un scan automatique de vulnérabilités et une exploration manuelle de scénarios métier ne fournissent pas les mêmes résultats. Le choix doit alimenter l’analyse de risques, et non simplement cocher une ligne dans un contrat.
Pour une prestation PASSI, vérifiez la qualification et son périmètre effectif. L’ANSSI distingue plusieurs activités, dont le test d’intrusion, l’audit d’architecture et l’audit de code. Une certification individuelle du consultant n’est pas identique à cette qualification du service. Le référentiel couvre le prestataire, son personnel et le déroulement des audits. Source : ANSSI, référentiels de qualification, rubrique PASSI.
Cas pratique : autoriser un portail client avant son ouverture
Exemple hypothétique, sans test réellement réalisé. Une PME de maintenance industrielle prépare un portail permettant à ses clients de consulter leurs interventions et leurs factures. Douze entreprises doivent l’utiliser au lancement. Le risque prioritaire est qu’un utilisateur d’un client puisse consulter les documents d’un autre. La responsable du projet veut une décision de mise en service, pas seulement un décompte de vulnérabilités.
Elle commande une mission en boîte grise avec deux comptes appartenant à deux organisations fictives et un compte de gestion limité. La plateforme testée reproduit les composants et règles d’accès prévus en production, mais contient des documents créés pour l’exercice. Le prestataire doit signaler les écarts de configuration : une conclusion obtenue sur un environnement différent ne sera pas transposée sans examen.
Le devis prévoit trois journées pour le périmètre applicatif, une restitution et une demi-journée réservée au contrôle des corrections. Cette durée est une hypothèse de contrat, sans valeur de tarif ni de standard. Le directeur technique conserve du temps dans le planning pour corriger les défauts ; fixer l’audit la veille d’une ouverture irrévocable rendrait le résultat difficile à utiliser.
Le cadrage renseigné de la mission
| Décision | Contenu retenu dans ce scénario |
|---|---|
| Question centrale | Vérifier la séparation des dossiers entre deux clients et les droits du gestionnaire |
| Périmètre autorisé | Portail de préproduction et son API ; inventaire des composants annexé à la convention |
| Hors périmètre | Messagerie, postes des salariés, prestataire de paiement et infrastructure partagée de l’hébergeur |
| Autorisation | Convention signée par le représentant habilité ; conditions de l’hébergement vérifiées avant ouverture des accès |
| Comptes et données | Deux organisations fictives, trois profils, factures et demandes inventées pour la mission |
| Opérations exclues | Déni de service, destruction, hameçonnage des salariés et consultation volontaire de dossiers réels |
| Fenêtre choisie | Du 5 au 7 octobre 2026, de 9 h à 17 h, heure de Paris ; prolongation soumise à accord |
| Arrêt | Incident de disponibilité, donnée réelle rencontrée ou système externe atteint : suspension et appel au contact désigné |
| Restitution attendue | Constats reproductibles dans le périmètre, impact métier, limites, mesures proposées et échange avec les développeurs |
| Fin de mission | Retrait des comptes et secrets de test ; preuves nécessaires remises puis suppression des copies selon la convention |
Le prestataire découvre pendant la préparation un lien vers le service de paiement. Il demande de l’ajouter au test. La responsable refuse cet élargissement immédiat : la convention ne couvre pas le fournisseur tiers. Elle conserve la demande comme un sujet à traiter séparément, après vérification des droits et autorisations nécessaires. Un bouton visible dans le portail n’intègre pas automatiquement le système destinataire au mandat.
La procédure d’arrêt doit pouvoir fonctionner. Un numéro inscrit dans une annexe, mais jamais joignable aux horaires convenus, ne suffit pas. Avant les opérations, les deux parties vérifient leurs contacts et le canal de transmission confidentiel. Si aucun interlocuteur compétent ne peut être joint après une alerte, la mission reste suspendue ; le silence ne vaut pas autorisation de poursuivre.
Du défaut découvert à une décision de lancement
Dans la suite fictive, le prestataire démontre qu’un compte du client A peut ouvrir une facture fictive réservée au client B. Il s’arrête au niveau nécessaire pour établir le constat, conserve une preuve réduite et alerte le directeur technique. Il ne télécharge pas des milliers de documents pour rendre le rapport plus impressionnant. La gravité tient ici au franchissement de la séparation entre clients et aux documents exposés.
L’équipe corrige une vérification de droits et annonce le problème réglé. Le premier contrôle confirme que l’accès direct est désormais refusé, mais révèle que la fonction d’export garde le même défaut. Le constat reste ouvert. La responsable reporte le lancement et demande une correction couvrant les différents parcours concernés, au lieu d’accepter une capture montrant uniquement le premier écran réparé.
Le second contrôle utilise les mêmes profils et vérifie la consultation, le téléchargement et l’export prévus dans la mission. Dans notre scénario, les accès croisés sont alors refusés, tandis que chaque client retrouve ses propres documents. Le dossier indique la version contrôlée et les résultats obtenus. Il distingue ce constat résolu des autres limites de l’audit : paiement tiers exclu, aucun test de résistance à une forte charge, aucun examen des postes salariés.
La mise en service est autorisée après rapprochement des configurations de préproduction et de production. Si ce rapprochement révélait une autre gestion des droits, la direction ne pourrait pas se contenter du rapport reçu : elle devrait traiter l’écart avant de reprendre la décision. Après une évolution majeure du portail, elle réexaminerait également le besoin d’une nouvelle vérification ciblée.
Ce parcours illustre une règle de pilotage : « corrigé par le développeur », « contrôlé par l’auditeur » et « risque accepté par la direction » sont trois décisions distinctes. La direction peut devoir arbitrer un risque résiduel, mais le dossier doit nommer ce risque, son responsable, les mesures temporaires et la date de réexamen. Une signature en fin de rapport ne transforme pas une faiblesse encore présente en correction réussie.
Passer du rapport aux corrections
Organisez la restitution autour de quatre questions : quel scénario est démontré, quel service est exposé, qui corrige et comment vérifier le résultat ? Une criticité technique doit être rapprochée du contexte métier. Une faille permettant à un utilisateur de lire le dossier d’un autre client mérite une analyse spécifique, même si le service continue de fonctionner.
Pour chaque constat, conservez son identifiant, les versions concernées, le responsable de correction, l’échéance décidée et le résultat du contrôle. Une ligne résolue renvoie à une preuve ; une ligne reportée renvoie à une décision motivée et à une prochaine revue. Ce suivi complète l’audit de sécurité informatique.
Si le test révèle une compromission réelle ou provoque un incident, déclenchez votre procédure de gestion des incidents. Évaluez les obligations des Art. 33 et 34 RGPD selon les données et le risque ; l’accès autorisé à des données pendant un test ne constitue pas automatiquement une violation.
La détection quotidienne demeure un travail distinct. Pour la protection des terminaux, le guide de choix d’un EDR aide à examiner les capacités attendues et l’organisation du traitement des alertes.
Ce qu’il faut retenir
- Aucun pentest annuel universel ne découle du seul RGPD.
- Formalisez l’autorisation, les exclusions et les conditions d’arrêt.
- Choisissez un test qui répond à des scénarios de risque précis.
- Prévoyez dès le contrat le suivi et la vérification des corrections.
FAQ
À quelle fréquence commander un pentest ?
La fréquence découle des risques, des changements importants et des règles applicables à l’organisation. Une cadence annuelle peut être retenue dans un programme interne, mais ne doit pas être présentée comme une obligation générale du RGPD.
Un rapport externe a-t-il automatiquement une valeur supérieure ?
Non. La qualité du périmètre, de la méthode, des constats et de leur traçabilité doit être examinée. L’indépendance peut être importante ou exigée dans certains cadres, sans dispenser d’évaluer la qualité réelle du travail.
Un test réussi garantit-il l’absence de vulnérabilités ?
Non. Il couvre un périmètre et une période déterminés. Les limites de la mission et les changements ultérieurs doivent rester visibles dans le dossier de sécurité.
Recevez nos analyses pratiques sur la sécurité et le RGPD.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.