Tester un site web : quelles autorisations légales ?

Tester la sécurité d’un site ne bénéficie pas d’une autorisation générale de la loi. Les dispositions introduites en 2013 sur la recherche et la sécurité informatique ne permettent pas d’accéder librement aux systèmes d’autrui. Pour une mission de test, le périmètre autorisé et les opérations permises doivent être établis avant l’intervention.

Cette page, publiée en 2014, présentait une lecture trop extensive de ces dispositions. Son analyse est corrigée ici : ni l’annulation automatique des poursuites en cours, ni une liberté générale d’attaquer des sites ne découlent des textes cités.

Ce que permet réellement le Code de la propriété intellectuelle

L’Art. L. 122-6-1, III du CPI permet à la personne ayant le droit d’utiliser un logiciel d’en observer, étudier ou tester le fonctionnement ou la sécurité afin d’en déterminer les idées et principes. Cela s’inscrit dans les opérations qu’elle est en droit d’effectuer : chargement, affichage, exécution, transmission ou stockage.

Le texte règle donc une question d’autorisation de l’auteur du logiciel dans un cadre défini. Il ne dispense pas de vérifier les droits d’accès au système qui l’exécute et ne transforme pas tout visiteur d’un site en auditeur autorisé. Le VIII interdit aussi une interprétation portant atteinte à l’exploitation normale du logiciel ou causant un préjudice injustifié aux intérêts légitimes de l’auteur.

Le motif de recherche n’efface pas les infractions informatiques

L’Art. 323-3-1 du Code pénal vise la détention, l’importation, l’offre ou la mise à disposition d’outils adaptés à certaines infractions, lorsqu’il n’existe pas de motif légitime, notamment de recherche ou de sécurité informatique. Cette règle relative aux outils ne constitue pas une autorisation d’accomplir les infractions elles-mêmes.

Les Art. 323-1 à 323-3 continuent notamment de sanctionner l’accès ou le maintien frauduleux, les entraves au fonctionnement et certaines opérations frauduleuses sur les données. Le caractère frauduleux s’apprécie dans les faits ; annoncer une bonne intention ne suffit pas à le faire disparaître.

Une faille accessible n’est pas un blanc-seing

Dans l’arrêt Cass. crim., 20 mai 2015, n° 14-81.336, relatif au système de l’ANSES, la Cour de cassation a rejeté le pourvoi concernant notamment un maintien frauduleux après prise de conscience de l’accès indu. La distinction entre découverte initiale et poursuite des opérations est essentielle. Cet arrêt ne doit pas être réduit à « un accès sans mot de passe est autorisé ».

En cas de découverte imprévue, arrêtez l’exploration et privilégiez un signalement prudent du contexte observé. Ne présumez pas un droit de copier les données pour démontrer la faille. La conservation et la transmission de preuves demandent elles aussi un cadre approprié.

Fiche de cadrage d’un test d’intrusion

Avant les tests d’intrusion, faites valider les éléments suivants par une personne habilitée à autoriser la mission :

Cette fiche est une recommandation de cadrage ; elle n’étend pas les droits de celui qui donne l’autorisation. Un client ne peut pas autoriser indistinctement des interventions sur les systèmes de ses prestataires.

Reliez le rapport à l’audit de sécurité, à l’analyse des risques et aux mesures de protection des données. Les preuves d’audit peuvent elles-mêmes contenir des informations sensibles.

Identifier la personne qui peut autoriser l’intervention

Une demande commerciale et une autorisation technique peuvent provenir de personnes différentes. Avant de commencer, identifiez l’entité qui exploite le système, les personnes compétentes pour la représenter et les limites de leurs droits. Un interlocuteur capable de commander une prestation ne dispose pas nécessairement de droits sur toutes les infrastructures auxquelles son application est reliée.

La préparation doit relier trois éléments : le système visé, le pouvoir de celui qui autorise et les opérations acceptées. La mention « audit du site » ne précise pas si le prestataire peut agir sur l’authentification, modifier des données, solliciter un service externe ou intervenir pendant les heures d’ouverture.

Pour un hébergement mutualisé, une interface de paiement ou un service d’identité externe, distinguez les ressources propres au client et les ressources du fournisseur. L’accord du premier ne règle pas les conditions du second. Vérifiez les documents contractuels, les éventuelles procédures de test et les exclusions. Si le périmètre reste incertain, la décision pratique consiste à suspendre cette partie de l’intervention jusqu’à clarification.

Une autorisation écrite permet de conserver cette clarification. Elle ne constitue pas une immunité pénale ni une garantie que toutes les opérations futures seront couvertes. Son utilité dépend de sa précision, de l’habilitation de son auteur et du respect effectif de ses limites.

Décrire les opérations dans une annexe exploitable

Le tableau de cadrage gagne à être accompagné d’une annexe datée. Les équipes doivent pouvoir déterminer ce qui est compris dans la mission sans devoir interpréter une promesse commerciale générale.

Il s’agit d’une structure proposée, pas d’une liste légale exhaustive. Une mission peut nécessiter d’autres précisions. L’important est que le contrat, l’autorisation et les consignes opérationnelles décrivent le même périmètre : une exclusion écrite dans le contrat ne disparaît pas parce qu’un courriel informel demande ensuite de « tout vérifier ».

Prévoyez également comment un changement est approuvé. L’auditeur ne doit pas décider seul qu’une nouvelle adresse appartient forcément au périmètre parce qu’elle répond au même nom commercial. Une extension doit être qualifiée, autorisée par la personne compétente et transmise aux intervenants avant les opérations concernées.

Exemple : un portail client et deux services tiers

Ce dossier est entièrement fictif. La société Osier veut faire examiner son portail de suivi des commandes. Elle dispose d’une préproduction et propose des comptes de démonstration. Le portail utilise aussi un prestataire d’identification et une interface de paiement, exploités par d’autres sociétés.

La fiche de mission peut retenir les choix suivants, sous réserve des droits effectivement vérifiés :

• le portail de préproduction constitue la cible identifiée ;
• les comptes fournis servent uniquement aux opérations définies dans l’annexe ;
• les services d’identification et de paiement des tiers sont exclus de l’intervention ;
• aucune opération perturbatrice n’est comprise dans cette mission ;
• la production n’est pas incluse par simple analogie avec la préproduction.

La date, le responsable d’Osier et le responsable de mission sont renseignés dans le dossier de travail. Les coordonnées d’arrêt sont transmises avant le début. Cette préparation reste hypothétique : aucun accord de fournisseur ni résultat de test réel n’est allégué ici.

Si une action prévue conduit vers le service d’identification externe, l’équipe doit respecter l’exclusion et clarifier le parcours avec Osier. La présence d’un lien ou d’une dépendance technique ne transforme pas ce service en cible autorisée. Le rapport peut expliquer que la vérification concernée n’a pas été réalisée dans le périmètre convenu, au lieu de conclure que le dispositif entier est sûr.

Si le client souhaite ensuite ajouter la production, il faut reprendre l’examen des droits, des risques, des données et des modalités d’intervention. Modifier une ligne dans le devis sans actualiser les consignes ne suffit pas à informer les intervenants des nouvelles limites.

Organiser les preuves et la fin de mission

Une preuve utile montre le problème et permet sa correction. Elle n’exige pas nécessairement de récupérer l’ensemble des informations accessibles. Lorsque des données personnelles sont concernées, les principes de minimisation et de conservation limitée des Art. 5(1)(c) et (e) s’appliquent, avec les autres exigences du RGPD. Une autorisation de test ne constitue pas, à elle seule, une base légale pour tous les traitements de données réalisés pendant la mission.

Définissez les destinataires du rapport, les éléments à masquer dans les versions diffusées et la séparation éventuelle entre synthèse de direction et annexe technique restreinte. Si l’auditeur traite des données pour le compte du client, examinez l’application de l’Art. 28 et les instructions correspondantes. Source : RGPD, Art. 28 et 32.

À la clôture, faites le point sur les comptes de démonstration, les accès temporaires, les copies et les pièces conservées pour une finalité justifiée. Fixez les suites de correction et leur responsable. Une nouvelle vérification après correction doit elle aussi rester dans un périmètre autorisé ; le contrat initial ne doit pas être présumé couvrir indéfiniment toute intervention ultérieure.

Ce qu’il faut retenir

• L’exception de droit d’auteur n’est pas une autorisation générale d’accès aux systèmes.
• Le motif légitime concernant certains outils ne neutralise pas les infractions commises avec eux.
• Cadrez par écrit le périmètre et les techniques d’un test.
• Préparez l’arrêt, le signalement et la gestion des données découvertes.

FAQ

Une adresse accessible publiquement peut-elle être testée librement ?

Son accessibilité ne permet pas de présumer une autorisation pour toute opération. Il faut distinguer la consultation permise de l’accès, du maintien et des autres actions effectivement réalisés.

Un programme de recherche de vulnérabilités suffit-il ?

Il faut lire son périmètre et ses conditions. Les systèmes exclus, les tiers et les techniques interdites restent en dehors de l’autorisation offerte.

L’autorisation du client couvre-t-elle son hébergeur ?

Pas automatiquement. Vérifiez les droits du client et les conditions du fournisseur avant d’intervenir sur son infrastructure.

Recevez nos analyses de droit et de sécurité informatique.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies.