Un dirigeant veut faire vérifier son application avant son lancement. Un responsable informatique souhaite éprouver la sécurité d’un serveur. Un prestataire propose un pentest, autrement dit un test d’intrusion destiné à rechercher et à démontrer des vulnérabilités. Avant de fixer le prix ou la date de l’intervention, une question commande les autres : qui peut autoriser les opérations envisagées, sur quels systèmes et avec quelles limites ?
Le dossier concerne généralement plusieurs acteurs : l’entreprise qui commande, la société qui réalise les tests, les personnes qui interviennent effectivement, mais aussi un hébergeur, un éditeur ou une autre entreprise dont l’infrastructure est utilisée. Les données consultées peuvent appartenir aux activités de clients ou de salariés. L’autorisation du donneur d’ordre, le contrat de prestation et les instructions relatives aux données personnelles doivent donc être examinés séparément.
Pour préparer un pentest en France, la méthode consiste à identifier ces parties, à vérifier les pouvoirs du signataire, à décrire précisément les opérations permises et à organiser les preuves de leur exécution. Les développements suivants portent sur une mission commandée et encadrée contractuellement. Les recommandations pratiques proposées doivent être adaptées au système concerné ; elles ne constituent ni une autorisation générale d’intrusion ni une garantie d’absence d’incident.
I. Qui peut autoriser le pentest et jusqu’où peut aller le test d’intrusion ?
A. Vérifier le signataire, les systèmes concernés et les autorisations des tiers
Commencer par la personne qui donne l’accord. Un interlocuteur technique peut connaître parfaitement le réseau sans être habilité à engager l’entreprise pour toutes les opérations proposées. Le bon réflexe consiste à identifier la société contractante, son représentant et, lorsqu’une autre personne signe, le document qui lui donne pouvoir. L’article 1153 du Code civil précise que le représentant est fondé à agir uniquement « dans la limite des pouvoirs qui lui ont été conférés ». Cette vérification porte sur l’autorité du signataire, et pas seulement sur son intitulé de poste (article 1153 du Code civil).
Il est utile de conserver avec le contrat l’identité de la personne qui approuve le périmètre technique et celle qui pourra ordonner l’arrêt des opérations. Ces fonctions peuvent être confiées à des personnes différentes. Le contrat doit alors permettre de comprendre quelle décision appartient à chacune. Une validation du budget, une validation du calendrier et une autorisation de tester une infrastructure ne répondent pas à la même question.
Décomposer le système au lieu d’autoriser une marque ou un domaine entier. La formule audit de notre informatique laisse trop d’incertitudes. Une application accessible sous le nom de l’entreprise peut utiliser un service de paiement, une messagerie externalisée, une infrastructure partagée et plusieurs interfaces exploitées par des partenaires. La liste des cibles doit permettre de distinguer ce que le client contrôle de ce qui dépend d’un tiers.
Le dossier de cadrage peut ainsi préciser les applications visées, leurs environnements, les comptes de test, les interfaces concernées et les composants exclus. Il doit aussi identifier les ressources partagées. L’objectif est pratique : un intervenant doit pouvoir déterminer si une opération envisagée entre dans sa mission sans devoir interpréter une formule commerciale générale.
Examiner le contrat de cloud ou d’hébergement. La possibilité d’utiliser un service ne signifie pas que toutes les opérations sur son infrastructure ont été autorisées. Il faut lire les conditions applicables aux tests de sécurité, les éventuelles procédures de déclaration et les restrictions portant sur les ressources mutualisées. Selon le service et l’opération, une autorisation distincte, une procédure particulière ou une exclusion du périmètre pourra être nécessaire.
Cette vérification s’appuie notamment sur l’effet relatif des contrats : l’article 1199 du Code civil prévoit que le contrat crée des obligations entre les parties. Un contrat signé entre le client et l’auditeur ne peut donc pas, par lui-même, imposer à un hébergeur tiers d’accepter les opérations décrites. La capacité du client à les autoriser doit être vérifiée au regard de ses droits et des accords effectivement applicables (article 1199 du Code civil).
Obtenir une autorisation écrite exploitable. Pour la mission, un écrit précis constitue un moyen de documenter l’accord et ses limites. Il est préférable qu’il renvoie à une annexe technique datée, identifiée et conservée avec lui. Le document doit permettre de relier les personnes autorisées, les cibles, la période d’intervention, les méthodes admises et les exclusions. Il ne faut pas présenter cet écrit comme une immunité pénale : la qualification des faits dépendra des opérations réellement accomplies et des conditions légales.
La période d’intervention est une borne contractuelle à définir clairement, avec les conditions de prolongation et les personnes qui peuvent la modifier ; la force obligatoire de cet accord découle de l’article 1103 du Code civil (article 1103 du Code civil). Une autorisation ancienne ne devrait pas être réutilisée par simple habitude pour une nouvelle version de l’application ou pour des cibles ajoutées.
Exemple de cadrage. Une entreprise commande la vérification du portail de ses clients. Elle peut prévoir une mission sur un environnement de préproduction, avec des comptes dédiés et des données fictives, tout en excluant l’interface de paiement exploitée par un autre prestataire. Si la vérification révèle un chemin vers cette interface, la marche à suivre devrait être prévue : arrêter l’exploration de cette cible, décrire le constat et demander une décision aux interlocuteurs habilités.
Ce dossier ne se réduit donc pas à un bon de commande. Avant le démarrage, il est recommandé de rapprocher cinq éléments : le contrat commercial, l’autorisation de tester, l’annexe technique, les accords nécessaires concernant les tiers et les consignes sur les données. Toute contradiction importante entre ces documents doit être résolue avant les opérations concernées.
B. Distinguer les opérations permises, les infractions informatiques et le dépassement de mission
La finalité de sécurité ne dispense pas de vérifier les actes. Le terme hacker éthique décrit une démarche ; il ne remplace pas l’analyse juridique des opérations. L’article 323-1 du Code pénal réprime l’accès ou le maintien frauduleux dans tout ou partie d’un système de traitement automatisé de données. Le même texte distingue les conséquences ayant entraîné une suppression ou une modification de données, ou une altération du fonctionnement du système (article 323-1 du Code pénal).
Il faut également examiner la nature de l’action. L’entrave ou le fait de fausser le fonctionnement d’un système relève de l’article 323-2. Les opérations frauduleuses portant sur les données, notamment leur extraction, leur reproduction, leur transmission, leur suppression ou leur modification, sont visées par l’article 323-3. Une permission de vérifier une application doit donc être rapprochée des actes autorisés, et pas seulement de la cible indiquée (article 323-2 et article 323-3 du Code pénal).
Tout incident technique ou écart au contrat ne constitue pas automatiquement une infraction intentionnelle. Les éléments du texte applicable et les circonstances doivent être établis. L’article 121-3 du Code pénal pose le principe selon lequel les crimes et délits supposent une intention, tout en prévoyant les hypothèses particulières qu’il énonce. Il faut garder cette distinction entre un désaccord contractuel, une erreur technique et des faits susceptibles de recevoir une qualification pénale (article 121-3 du Code pénal).
Le régime des outils ne vaut pas autorisation d’accès. L’article 323-3-1 vise certains équipements, programmes ou données conçus ou spécialement adaptés pour commettre les infractions informatiques qu’il mentionne. Sa rédaction prend expressément en compte le « motif légitime, notamment de recherche ou de sécurité informatique ». Cette disposition doit être lue pour son objet propre : les opérations portant sur ces moyens. Elle ne délivre pas, à elle seule, une autorisation générale d’intervenir sur les systèmes d’autrui (article 323-3-1 du Code pénal).
Définir des limites opérationnelles compréhensibles. Les parties ont intérêt à distinguer l’observation, les vérifications actives, l’accès à des informations et les actions pouvant affecter le service. Le contrat peut exclure certains scénarios, réserver une opération à une validation complémentaire ou imposer l’utilisation de données de test. Ces choix doivent apparaître dans les documents remis aux intervenants.
Les expressions boîte noire, boîte grise ou boîte blanche renseignent sur les informations mises à disposition de l’auditeur. Elles ne décrivent pas à elles seules tout ce qu’il peut faire. Un accès administrateur communiqué pour faciliter l’évaluation n’autorise pas par sa seule existence une suppression de données, une modification du service ou une extension de la mission à d’autres environnements.
Prévoir le traitement d’une découverte hors périmètre. Une annexe utile indique comment signaler un résultat inattendu, qui décide de la suite et comment conserver une preuve proportionnée. Il peut être suffisant de décrire l’anomalie et son emplacement, sans poursuivre l’exploration. Une extension décidée en cours de mission doit être documentée et approuvée par les personnes habilitées. L’article 1193 du Code civil prévoit que les contrats se modifient par le consentement mutuel des parties, ou pour les causes autorisées par la loi (article 1193 du Code civil).
Le contrat doit aussi organiser l’arrêt à la demande du client ou en présence d’un risque opérationnel identifié. Il est recommandé de préciser les interlocuteurs, le canal d’alerte, la consignation de la décision et les conditions de reprise. Ces précautions permettent de ne pas découvrir, pendant un incident, que personne ne sait qui peut donner une instruction opposable aux équipes.
II. Quel contrat prévoir pour les données, le rapport et les conséquences d’un incident ?
A. Définir les engagements de confidentialité et le sort des informations collectées
Établir un inventaire des informations accessibles. Une mission peut mettre l’auditeur en présence de journaux d’activité, de dossiers clients, d’identifiants et de documents internes. Avant le démarrage, les parties devraient décrire les catégories d’informations susceptibles d’être rencontrées et celles qui sont étrangères aux vérifications commandées. Ce travail permet de rapprocher l’autorisation technique des précautions attendues pendant la prestation.
Les clauses présentées ici portent sur l’organisation contractuelle de la mission. La conformité réglementaire des traitements de données personnelles appelle un examen distinct, tenant compte des opérations et des acteurs concernés. Le contrat de pentest doit être articulé avec cet examen, plutôt que présenté comme un document suffisant pour résoudre toutes les questions relatives aux données.
Transformer la confidentialité en consignes concrètes. Une formule générale selon laquelle le rapport est confidentiel laisse plusieurs questions ouvertes. Quelles personnes peuvent recevoir les résultats ? Qui peut ouvrir les annexes techniques ? L’entreprise autorise-t-elle la communication au prestataire chargé de corriger l’application ? Comment les échanges sont-ils protégés ? Il est recommandé de régler ces questions dans le contrat et dans les instructions remises aux intervenants.
Les engagements souscrits doivent être identifiables, puisque les contrats légalement formés obligent les parties en application de l’article 1103 du Code civil. La bonne foi exigée par l’article 1104 accompagne leur négociation et leur exécution. La rédaction doit donc permettre de comprendre les précautions promises et les informations que chaque partie doit fournir pour les mettre en œuvre (article 1103 et article 1104 du Code civil).
Un engagement peut, par exemple, prévoir la transmission du rapport à un cercle défini de destinataires et la séparation des annexes contenant des informations particulièrement sensibles. Il faut indiquer comment une modification de cette liste sera approuvée. Le document devrait aussi identifier l’interlocuteur capable de répondre à une demande de transmission extérieure pendant la mission.
Déterminer ce qui peut être conservé comme preuve. Le contrat peut distinguer les journaux d’opérations, les captures d’écran, les extraits de configuration et les documents nécessaires à la démonstration d’un constat. Les parties doivent chercher ce qui permet de comprendre et de vérifier la vulnérabilité, sans accumuler des informations étrangères à cette démonstration. Une preuve limitée, contextualisée et clairement expliquée peut être plus utile qu’une copie massive dont le lecteur ignore l’origine.
Dans l’exemple du portail clients, les parties peuvent préparer des comptes et des dossiers fictifs pour certaines vérifications. Si des documents réels sont susceptibles d’être rencontrés, il est recommandé de préciser les consignes applicables : ne conserver que les éléments autorisés pour la démonstration, masquer les informations inutiles dans le rapport destiné à une diffusion élargie et signaler toute découverte nécessitant une nouvelle décision. Ces choix de mission doivent être compatibles avec l’examen réglementaire des traitements.
La question de la preuve joue aussi en cas de désaccord. L’article 1353 du Code civil prévoit que celui qui réclame l’exécution d’une obligation doit la prouver et que celui qui se prétend libéré doit justifier le paiement ou le fait ayant produit l’extinction. Le dossier contractuel doit donc permettre de rapprocher l’obligation invoquée des éléments qui établissent sa réalisation (article 1353 du Code civil).
Identifier les personnes et les services extérieurs utilisés. L’entreprise qui signe le devis n’est pas nécessairement celle qui réalise matériellement toutes les opérations. Il est recommandé de demander quels intervenants participeront, comment ils recevront les consignes et quels outils pourront recevoir des informations issues du test. La localisation des espaces de travail et la circulation des fichiers doivent être suffisamment connues pour préparer les vérifications nécessaires.
Le contrat peut prévoir une procédure d’approbation pour l’ajout d’un intervenant ou l’utilisation d’un nouveau service. Une formule autorisant indistinctement tous les outils de l’auditeur mérite d’être examinée à la lumière des objectifs du client. Il faut également déterminer qui répond aux questions de l’entreprise lorsque plusieurs sociétés participent à la mission, sans présumer que leurs obligations sont identiques.
L’article consacré au contrat RGPD à obtenir d’un prestataire informatique traite séparément de la relation de sous-traitance. L’autorisation de tester, les engagements commerciaux et les documents relatifs aux données doivent être rapprochés pour repérer leurs éventuelles contradictions. Une validation technique ne remplace pas cette comparaison documentaire.
Décrire la fermeture de la mission. Il est utile de prévoir la désactivation des comptes créés pour les opérations, la remise des fichiers convenus et le sort des informations détenues par les intervenants. Le contrat doit distinguer ce qui doit être rendu, ce qui doit être supprimé et les éléments dont une conservation serait envisagée. Les motifs et la compatibilité de cette conservation avec les obligations applicables doivent être examinés avant de la prévoir.
La preuve de ces opérations peut prendre la forme d’un relevé des comptes fermés, d’un inventaire des documents remis et d’un écrit décrivant les opérations de suppression réalisées. Le niveau de détail dépend du périmètre convenu. Il est préférable de prévoir un document vérifiable plutôt qu’une attestation générale dont les parties ne partageraient pas la signification.
Ces engagements de clôture font partie de la prestation lorsqu’ils ont été convenus. Leur inexécution doit alors être analysée au regard des obligations promises et des recours ouverts par le droit des contrats. L’article 1217 du Code civil recense les sanctions de l’engagement inexécuté ou imparfaitement exécuté, dont les conditions propres doivent être examinées pour choisir une demande adaptée (article 1217 du Code civil).
B. Fixer les livrables et préparer une réaction documentée en cas de difficulté
Décrire ce que le prix couvre réellement. Le devis devrait distinguer la préparation, les opérations de test, le rapport, la restitution aux équipes et, si elle est commandée, la vérification des corrections. La remise d’un rapport et la correction des vulnérabilités sont des prestations différentes. Le client doit savoir laquelle relève de l’auditeur, laquelle appartient à ses équipes et laquelle nécessite une commande supplémentaire.
Le contrat a force obligatoire entre les parties et doit être négocié, formé et exécuté de bonne foi. Ces principes justifient une rédaction cohérente des engagements et des limites annoncées. Une brochure promettant une vérification générale doit être rapprochée d’une annexe qui exclurait les composants les plus importants pour le client (articles 1103 et 1104 du Code civil).
Le devoir précontractuel d’information doit aussi être examiné dans ses conditions propres. L’article 1112-1 concerne les informations déterminantes pour le consentement, connues d’une partie et légitimement ignorées par l’autre, ou pour lesquelles celle-ci fait confiance à son cocontractant. Il ne suffit donc pas d’affirmer, après une difficulté, que toute limite technique aurait nécessairement dû être expliquée de la même façon. Il faut identifier l’information concernée, son importance et les éléments établissant qu’elle était due (article 1112-1 du Code civil).
Rendre le rapport vérifiable. Un livrable utile décrit les cibles effectivement examinées, la version ou l’environnement contrôlé, les limites rencontrées et les constats. Il sépare les observations démontrées des hypothèses restant à examiner. Pour chaque vulnérabilité, le client devrait pouvoir comprendre le scénario, son incidence sur l’activité, la preuve conservée et la recommandation de traitement.
Il est recommandé d’indiquer les éléments qui n’ont pas pu être testés et les raisons de cette limite : environnement indisponible, autorisation manquante, opération exclue ou changement de configuration. Une conclusion rassurante sur une partie du périmètre ne doit pas masquer une zone importante demeurée hors contrôle. La restitution doit permettre une décision de gestion, et pas seulement transmettre une liste de termes techniques.
La vérification après correction mérite un cadrage distinct. Elle peut porter sur le constat initial, sur les parcours associés ou sur un périmètre plus large, selon l’accord conclu. Le contrat doit dire ce qui sera revérifié et quel document rendra compte du résultat. Une correction déclarée par l’équipe de développement et une correction vérifiée dans l’environnement convenu sont deux informations différentes.
Examiner les clauses de responsabilité sans présumer leur effet. Il faut identifier les obligations promises, les exclusions, les plafonds éventuels et les conditions de mise en œuvre. La qualification des engagements s’apprécie au regard de leur contenu : toutes les tâches d’une mission ne doivent pas être résumées par une même étiquette. L’absence de vulnérabilité détectée et la remise du rapport convenu posent, par exemple, des questions différentes.
L’article 1170 du Code civil prévoit qu’une clause privant de sa substance l’obligation essentielle du débiteur est réputée non écrite. Ce texte impose d’examiner la clause et l’obligation concernées ; il ne permet pas d’annoncer que tout plafond de responsabilité serait automatiquement écarté. Le dossier doit rapprocher les engagements déterminants et les restrictions effectivement stipulées (article 1170 du Code civil).
Lorsqu’un incident survient, reconstituer les faits avant d’attribuer une responsabilité. Une indisponibilité pendant la fenêtre de test peut justifier l’arrêt prévu au protocole et la préservation des éléments utiles. Il faut relever les opérations réalisées, les horaires, les alertes, les changements de configuration et les instructions échangées. La proximité temporelle entre un test et un incident ne dispense pas d’examiner le lien entre les deux.
L’article 1231-1 du Code civil régit les dommages et intérêts liés à l’inexécution ou au retard d’exécution, sous la réserve qu’il énonce concernant la force majeure. La demande suppose d’identifier l’obligation en cause, les conséquences alléguées et les éléments permettant de les rattacher au manquement invoqué. L’article 1353 organise la charge de la preuve de l’obligation et de sa libération (article 1231-1 et article 1353 du Code civil).
Si l’incident concerne les informations accessibles pendant la mission, le dossier devrait décrire ce qui a été consulté, transmis, modifié ou perdu et les destinataires éventuels. Ces faits doivent être rapprochés des consignes contractuelles et des autorisations conservées. L’examen des conséquences réglementaires concernant les données personnelles doit être organisé séparément, à partir des traitements effectivement constatés.
Choisir un recours adapté à l’inexécution constatée. L’article 1217 du Code civil recense les sanctions de l’inexécution, dont l’exécution forcée, la réduction du prix, la résolution et la réparation. Chacune doit être examinée dans ses conditions propres. Un rapport incomplet, un dépassement du périmètre et une interruption de service ne conduisent pas nécessairement à la même demande (article 1217 du Code civil).
Si une résolution par notification est envisagée, l’article 1226 prévoit une démarche aux risques et périls du créancier : sauf urgence, une mise en demeure préalable de satisfaire à l’engagement dans un délai raisonnable, annonçant expressément la possibilité de résoudre le contrat ; en cas d’inexécution persistante, la notification doit exposer les raisons de la résolution, et la gravité de l’inexécution devra être prouvée si elle est contestée (article 1226 du Code civil). Il faut préparer cette décision à partir des engagements et des faits établis.
Conclusion
Un pentest se prépare en reliant trois dossiers : l’autorisation des opérations, le contrat qui décrit la prestation et les consignes contractuelles relatives aux informations utilisées. Le point décisif est de pouvoir expliquer qui a donné son accord, avec quels pouvoirs, sur quelles cibles et pour quelles actions. La participation d’un hébergeur ou d’un autre prestataire doit être traitée à partir des droits et des documents réellement applicables.
Le même soin doit guider la fin de mission : rapport exploitable, limites identifiées, corrections attribuées, vérification prévue lorsqu’elle est commandée et sort des données documenté. En cas de difficulté, conserver les instructions, les preuves techniques et les engagements permet de distinguer ce qui était autorisé, ce qui a été exécuté et ce qui reste contesté. Cette méthode donne au client comme à l’auditeur une base concrète pour décider de la suite.