FAQ – Pentest & cybersécurité

Un scan dresse surtout une liste d’anomalies (versions, configs, faiblesses connues). Un pentest va plus loin : il enchaîne des scénarios d’attaque réalistes (exploitation, élévation, mouvement latéral), démontre l’impact, priorise ce qui compte vraiment et fournit des preuves + des remédiations.

Selon votre besoin, on peut couvrir : pentest web (site/portail/API), pentest réseau (interne/externe), audit de configuration (exposition, durcissement), et scénarios orientés phishing / sécurité organisationnelle (uniquement dans un cadre autorisé et défini). Le périmètre est toujours cadré avant : cibles, horaires, limites, règles d’arrêt.

Selon le périmètre : 3 à 10 jours ouvrés typiques. L’objectif est de ne pas impacter la production. Les actions potentiellement “bruyantes” (tests de charge, bruteforce, certains fuzzings) se font sur des créneaux convenus, ou sur une préprod quand c’est possible.

Un pentest se fait avec une autorisation écrite (lettre d’engagement) qui définit le périmètre, les cibles, les horaires, les IP de test, les règles d’arrêt et les contacts. Côté données, on applique la minimisation et un cadre de suppression. Pour situer : la CNIL rappelle les exigences de sécurité (RGPD, notamment l’article 32) et l’ANSSI centralise l’information sur NIS2.

La confidentialité fait partie du cadrage : NDA possible, stockage minimal, accès limité, et destruction des éléments de mission après livraison (selon ce qui est convenu). Les preuves dans le rapport sont choisies pour être utiles sans exposer plus que nécessaire (captures, logs, chemins d’attaque, sans “sur-collecte”).

Vous recevez généralement : 1) un résumé exécutif (risques, priorités, plan d’action), 2) un rapport technique (preuves, criticité, recommandations, étapes de correction), et un debrief pour expliquer clairement le “quoi / pourquoi / comment corriger”.

Le retest sert à valider que les corrections sont effectives et qu’il n’y a pas de régression. Il peut être inclus selon le package, ou proposé en option (souvent sur les failles critiques/majeures).

Pour gagner du temps (et éviter les mauvaises surprises), préparez :

• Le périmètre exact (URLs/IPs, applis, environnements, exclusions).
• Un contact technique disponible pendant la mission.
• Des comptes de test (si portail client, back-office, API…)
• Les fenêtres horaires “sensibles” et une règle d’arrêt claire.

Côté web, un standard reconnu est l’OWASP Web Security Testing Guide (WSTG). Pour structurer une démarche d’évaluation (tests, résultats, restitution), le NIST SP 800-115 est une référence utile. Et pour décrire des techniques d’attaque/défense, les référentiels MITRE (ATT&CK / D3FEND) donnent un vocabulaire standard.

MITRE ATT&CK · MITRE D3FEND

Le prix dépend du périmètre (nombre d’applications, complexité, interne/externe, délais, retest). Le plus simple : un devis rapide avec 3 infos (cibles, contexte, échéance). Ensuite, je vous propose une option claire (périmètre + livrables + planning).