Préparer un test d’intrusion : convention, périmètre et sauvegardes

Un test d’intrusion ne doit jamais commencer sans une autorisation écrite du propriétaire du système. Sans elle, l’auditeur s’expose à des poursuites : le Code pénal punit l’accès ou le maintien frauduleux dans un système de traitement automatisé de données (articles 323-1 et suivants). Avant la mission, préparez une convention d’autorisation, un périmètre précis, des sauvegardes vérifiées et une liste de contacts d’urgence.

Cet article détaille ces préparatifs. Il ne remplace pas un avis juridique : pour un contrat sensible, faites-le relire par un professionnel du droit.

Pourquoi faut-il une autorisation écrite avant un pentest ?

Les articles 323-1 et suivants du Code pénal sanctionnent les atteintes aux systèmes de traitement automatisé de données : l’accès ou le maintien frauduleux, mais aussi l’entrave au fonctionnement du système et la modification ou l’extraction frauduleuse de données. Ce qui rend un accès « frauduleux », c’est l’absence d’autorisation de la personne qui a le droit d’en décider.

L’autorisation écrite transforme donc une intrusion en test légitime. Elle protège aussi l’entreprise cliente : elle prouve que l’activité observée dans ses journaux était attendue, ce qui évite de déclencher à tort une procédure d’incident. Les montants des peines figurent dans le texte en vigueur sur Légifrance, que nous vous invitons à consulter plutôt que de les reprendre de seconde main.

Autre point : le propriétaire du site n’est pas toujours seul décideur. Si votre site tourne chez un hébergeur ou sur une plateforme, ses conditions d’utilisation peuvent imposer une demande préalable ou interdire certains tests. Vérifiez-les avant de signer.

Que doit contenir la convention d’autorisation ?

Une convention (ou lettre de mission avec annexe d’autorisation) précise au minimum :

• Les parties : l’entreprise cliente, le prestataire, et la personne habilitée à engager chacun.
• Le périmètre : domaines, sous-domaines, applications, adresses IP, environnements (production ou pré-production).
• Les exclusions : systèmes hors périmètre, tiers (paiement, messagerie), techniques interdites (déni de service, ingénierie sociale).
• Les dates et horaires : fenêtre de test, éventuelles plages à éviter (soldes, clôture comptable).
• Les adresses source : IP depuis lesquelles les tests partent, pour les distinguer d’une vraie attaque.
• La confidentialité : traitement des constats, durée de conservation du rapport, destinataires.
• La gestion des données : si le test peut exposer des données personnelles, les mesures prises et le rôle de chaque partie au regard du RGPD.
• Les contacts d’urgence : voir plus bas.
• Les limites de responsabilité : ce que chacun assume en cas d’incident pendant le test.

Comment définir le périmètre ?

Un périmètre trop vague crée des risques des deux côtés. Dressez l’inventaire de ce qui est en jeu : le site principal, l’espace d’administration, les sous-domaines, les API, les formulaires. Précisez ensuite ce qui est hors cadre, notamment les services d’autres entreprises que vous utilisez sans en être propriétaire (messagerie en ligne, plateforme de paiement, outil d’emailing). Vous ne pouvez pas autoriser le test d’un système qui ne vous appartient pas sans l’accord de son propriétaire.

Notez aussi si le test porte sur l’environnement réel ou sur une copie. Une pré-production fidèle limite les risques, mais elle doit refléter la production sinon les résultats sont moins parlants.

Quelles précautions techniques prendre avant le test ?

Même encadré, un test peut perturber un service. Cette liste d’actions est un bon réflexe :

1. Sauvegarder les fichiers et la base de données, puis vérifier que la restauration fonctionne.
2. Prévenir l’hébergeur si ses règles l’exigent, ainsi que les équipes qui surveillent le site.
3. Créer des comptes de test si la boîte grise est retenue, avec des droits représentatifs et sans données réelles.
4. Geler les évolutions pendant la fenêtre de test pour ne pas mélanger les causes.
5. Désactiver ou signaler les alertes qui déclenchent des actions automatiques (blocage d’adresses, envoi de messages).
6. Prévoir un retour arrière : qui peut restaurer, en combien de temps.

Notre article sur la maintenance et les sauvegardes d’un site explique comment vérifier qu’une sauvegarde est réellement exploitable.

Qui prévenir et qui joindre en cas de problème ?

Prévoyez deux listes : les personnes à informer avant le test, et les contacts joignables pendant. Pour chaque contact, notez le nom, le rôle, un numéro direct et un canal secondaire. Ajoutez la personne autorisée à arrêter le test et celle qui peut décider d’une restauration.

Convenez aussi d’une règle de remontée : si le prestataire découvre une faille critique (par exemple l’accès à des données personnelles), il prévient immédiatement le contact désigné sans attendre le rapport final. Si des données personnelles sont exposées, l’entreprise devra évaluer ses obligations vis-à-vis de la CNIL.

Que se passe-t-il après les tests ?

Les accès temporaires sont supprimés, les comptes de test désactivés, les données de preuve conservées ou détruites selon la convention. Le rapport est remis par un canal sécurisé. La phase de correction commence, puis un contre-test vérifie les points critiques. Le déroulé complet est décrit dans notre article pentest en PME : déroulé, prix et livrables, et la comparaison avec l’audit dans pentest ou audit de sécurité.

Qui doit signer la convention ?

La personne qui signe doit avoir le pouvoir d’engager l’entreprise et de décider de l’accès aux systèmes concernés : dirigeant, ou délégataire désigné par écrit. Un responsable informatique seul n’est pas toujours habilité. Si des systèmes appartiennent à un tiers (hébergeur, éditeur d’une plateforme, agence qui administre le site), son accord est nécessaire pour la partie qui le concerne. Conservez la convention signée pendant toute la durée de la mission et au-delà, selon vos règles d’archivage : elle vous protège si une alerte de sécurité survient pendant la fenêtre de test.

Checklist avant le jour J

• Convention signée par la personne habilitée dans chaque partie.
• Périmètre et exclusions écrits, avec la liste des domaines et adresses.
• Conditions de l’hébergeur et des services tiers vérifiées.
• Sauvegardes complètes réalisées et restauration testée.
• Comptes de test créés si nécessaire, sans données réelles.
• Contacts d’urgence confirmés des deux côtés, avec un canal de secours.
• Fenêtre de test validée et évolutions du site gelées.
• Destinataires du rapport et canal de remise sécurisé définis.

Questions fréquentes sur la préparation

Le prestataire peut-il tester mon site sans me prévenir ?

Non, pas dans un cadre légitime. Un test non annoncé et non autorisé par écrit ressemble à une tentative d’intrusion. Même lorsque l’équipe technique n’est pas informée à l’avance, la direction, elle, signe l’autorisation.

Mon hébergeur doit-il donner son accord ?

Cela dépend de ses conditions d’utilisation. Certains hébergeurs et plateformes encadrent les tests de sécurité ou demandent une notification préalable. Lisez les conditions avant de fixer la date, et demandez confirmation par écrit en cas de doute.

Que faire si des données personnelles apparaissent pendant le test ?

Le prestataire doit s’arrêter à la preuve minimale et vous prévenir sans délai. Vous évaluez ensuite l’incident avec votre responsable de la protection des données ou votre conseil, notamment au regard de l’obligation de notification d’une violation de données. Notre article sur les mentions légales, le RGPD et les cookies rappelle les bases côté site.

Pour préparer un test d’intrusion dans les règles, consultez notre page test d’intrusion ou contactez-nous en décrivant votre périmètre ; ne nous envoyez ni identifiant ni mot de passe par ce canal.