Pentesting éthique pour PME : guide complet 2026

Lecture : 18 minutes · Niveau : intermédiaire · Mise à jour : avril 2026

⚠️ Disclaimer légal et éthique : Toute action décrite dans cet article suppose une autorisation écrite préalable du propriétaire du système testé. Aucune utilisation contre des systèmes tiers sans consentement explicite n’est tolérée. Le pentesting non autorisé est illégal dans la quasi-totalité des juridictions, y compris au Sénégal, en Côte d’Ivoire, au Mali et dans les autres pays de la zone CEDEAO. Cet article est destiné aux dirigeants, RSSI, et professionnels de la sécurité opérant dans un cadre légal.

Une PME ouest-africaine qui digitalise ses opérations devient mécaniquement une cible. Site WordPress, application métier interne, ERP cloud, infrastructure réseau, terminaux de paiement : chaque actif numérique est une porte potentielle pour un attaquant. Le pentesting éthique (test d’intrusion encadré) est la pratique qui consiste à attaquer un système avec le consentement de son propriétaire pour identifier les vulnérabilités avant que des attaquants malveillants ne le fassent. Ce guide complet trace les fondamentaux, la méthodologie, le cadre légal, et les choix concrets pour intégrer le pentesting dans une stratégie de sécurité PME réaliste.

L’objectif n’est pas de transformer chaque dirigeant en hacker mais de comprendre ce qu’est un pentest, comment le commander, comment l’exploiter, et comment éviter les pièges (prestataires douteux, cadrage flou, livrables inutiles). Pour les profils techniques qui veulent se former à la sécurité offensive, ce guide pose aussi les bases méthodologiques avant les ressources techniques détaillées des satellites.

Sommaire

Qu’est-ce que le pentesting éthique ?
Cadre légal en Afrique de l’Ouest
Autorisation écrite : le document indispensable
Types de pentests : black, white, grey box
Méthodologie : phases d’un pentest
Phase 1 : reconnaissance (recon)
Phase 2 : énumération et scan
Phase 3 : exploitation
Phase 4 : post-exploitation
Phase 5 : rapport et remédiation
Pentesting interne vs prestataire externe
Bug bounty : alternative ou complément ?
Coûts à anticiper
Erreurs fréquentes à éviter
FAQ

1. Qu’est-ce que le pentesting éthique ?

Le pentesting (pour penetration testing, ou test d’intrusion) est l’évaluation de la sécurité d’un système informatique en simulant les techniques utilisées par des attaquants réels. À la différence d’un audit de configuration ou d’une analyse statique, un pentest implique de véritablement tenter d’exploiter des vulnérabilités pour démontrer leur impact réel.

Différences avec d’autres pratiques de sécurité :

Audit de sécurité : revue documentaire et technique des configurations, politiques, procédures. Plus large, moins approfondi sur l’exploitation
Vulnerability scanning : scan automatisé qui identifie des vulnérabilités connues. Outil utile mais ne remplace pas un pentest
Red teaming : exercice plus large simulant un attaquant déterminé sur la durée, incluant ingénierie sociale, persistance, contournement des défenses
Bug bounty : programme ouvert où des chercheurs externes signalent des vulnérabilités contre récompense

Le pentest se distingue par son caractère ciblé, encadré, et exploitatif. Le pentester ne se contente pas de signaler une faille théorique — il prouve qu’elle est exploitable et documente l’impact.

Périmètre type d’un pentest PME :
– Application web (site vitrine, e-commerce, portail interne)
– API exposée au public
– Infrastructure externe (IPs publiques, services exposés)
– Infrastructure interne (réseau LAN, Active Directory)
– Application mobile (Android et/ou iOS)
– Wi-Fi (segments invité, employé, équipements industriels)

Le périmètre exact dépend de la taille de la PME et des actifs critiques identifiés au préalable.

2. Cadre légal en Afrique de l’Ouest

Le pentesting non autorisé est illégal. Les codes pénaux des pays de la zone CEDEAO incluent généralement des dispositions sur l’accès frauduleux, le maintien dans un système informatique, et l’altération de données.

Au Sénégal :
– Loi n° 2008-11 sur la cybercriminalité (et ses évolutions)
– Loi n° 2008-12 sur la protection des données personnelles
– Commission de protection des données personnelles (CDP) : cdp.sn — autorité de référence pour le traitement des données personnelles dans le cadre d’un pentest

En Côte d’Ivoire, Mali, Burkina Faso, Bénin, Togo, Niger : des lois équivalentes existent, souvent inspirées de la convention de Budapest sur la cybercriminalité ratifiée par certains pays. Vérifier au cas par cas auprès d’un juriste local avant tout engagement.

Conséquences d’un pentest non autorisé :
– Sanctions pénales (amende, voire emprisonnement)
– Action civile en dommages et intérêts
– Saisie de matériel et fermeture d’activité

Même un pentester bien intentionné qui « teste pour aider » un système qu’il n’est pas autorisé à toucher s’expose à des poursuites. L’intention ne suffit pas — il faut l’autorisation écrite préalable.

Cas particuliers :
– Cloud externe : si la cible est hébergée chez AWS, Azure, GCP, etc., il faut aussi l’accord du fournisseur cloud (chacun a une politique de pentesting publiée)
– SaaS : pentester un SaaS sans son accord viole quasiment toujours les CGU et peut être illégal
– Sous-traitants : si la cible utilise des services tiers (passerelle de paiement, hébergement, CDN), bien identifier le périmètre pour éviter d’attaquer un actif hors périmètre

3. Autorisation écrite : le document indispensable

L’autorisation écrite, parfois appelée lettre d’autorisation ou rules of engagement (ROE), est le document qui transforme une attaque illégale en pentest légitime.

Éléments essentiels d’une autorisation de pentest :

Identité du pentester (nom, société, coordonnées)
Identité du commanditaire autorisé (signataire ayant le pouvoir de mandater des tests sur les actifs concernés)
Périmètre précis : URLs, IPs, applications, environnements (production / staging)
Hors-périmètre explicite : ce qui ne doit pas être touché
Période d’autorisation : dates de début et fin
Types de tests autorisés : reconnaissance, exploitation, social engineering ou non, déni de service ou non
Heures autorisées : seulement la nuit, week-end, ou 24/7
Procédure d’urgence : qui contacter en cas de découverte critique
Confidentialité : NDA encadrant les vulnérabilités identifiées
Limites de responsabilité : que se passe-t-il si un test casse un service de production
Signatures : commanditaire et pentester

Pour une PME qui commande un pentest, exiger ce document signé. Pour un pentester, refuser de démarrer sans. Sans ce document, la mission est illégale et indéfendable en cas de problème.

Modèle de phrase clé : « [Nom du commanditaire] autorise [Nom du pentester] à mener des tests d’intrusion sur le périmètre défini en annexe, du [date] au [date], dans le respect des règles d’engagement. Cette autorisation peut être révoquée à tout moment. »

4. Types de pentests : black, white, grey box

Black box : le pentester n’a aucune information préalable sur la cible. Il part comme un attaquant externe lambda. Avantage : reflète la réalité d’une attaque externe non ciblée. Inconvénient : beaucoup de temps en reconnaissance, certaines vulnérabilités internes échappent au scope.

White box : le pentester a un accès complet (code source, accès admin, documentation, schémas réseau). Avantage : couverture maximale, détection en profondeur. Inconvénient : moins représentatif d’une attaque externe.

Grey box : intermédiaire. Le pentester a un compte utilisateur standard (par exemple un compte client d’une appli web) ou des informations partielles. Avantage : équilibre entre temps et profondeur. Souvent recommandé pour les PME car offre un bon ratio temps/valeur.

Pour une PME démarrant en sécurité offensive :
– Première mission : grey box sur l’application web critique principale
– Seconde mission : étendre au périmètre infrastructure
– Plus tard : envisager du red teaming si la maturité sécurité est élevée

5. Méthodologie : phases d’un pentest

Plusieurs méthodologies de référence existent :

PTES (Penetration Testing Execution Standard) : référence générale, sept phases
OWASP Testing Guide : focus applications web, très détaillé sur chaque type de test
OSSTMM (Open Source Security Testing Methodology Manual) : approche scientifique et auditable
NIST SP 800-115 : guide officiel américain, sobre et structuré

En pratique, la quasi-totalité des pentests suit un cycle similaire :

Pre-engagement : cadrage, ROE, signature
Reconnaissance : collecter de l’information sur la cible
Énumération / scan : cartographier les services exposés
Exploitation : tenter d’exploiter les vulnérabilités identifiées
Post-exploitation : escalade de privilèges, mouvement latéral, persistance (selon scope)
Reporting : rapport détaillé avec preuves et recommandations
Re-test (optionnel) : valider les correctifs après remédiation

Les sections suivantes détaillent chaque phase technique.

Voir Outils essentiels du pentesting pour la boîte à outils détaillée.

6. Phase 1 : reconnaissance (recon)

La reconnaissance vise à collecter un maximum d’informations sur la cible sans interaction directe agressive. C’est la phase la plus longue souvent, mais elle conditionne le succès des phases suivantes.

Reconnaissance passive (sans toucher la cible directement) :
– Recherche Google sur le nom de l’entreprise, ses employés, ses technologies
– Consultation des registres DNS publics, certificats SSL via crt.sh
– Profils LinkedIn pour identifier les employés et stack technique
– GitHub, GitLab pour repos publics liés à l’entreprise (souvent sources de fuites)
– Wayback Machine pour anciennes versions du site

Reconnaissance active (interaction limitée) :
– DNS lookups, queries WHOIS
– Banner grabbing sur services exposés
– Identification des technologies via Wappalyzer ou BuiltWith

À documenter à cette phase :
– Liste des sous-domaines
– Adresses IP publiques
– Services exposés et versions
– Employés clés (DSI, RSSI, dev) — utile pour social engineering si autorisé
– Technologies utilisées (CMS, frameworks, langages)

7. Phase 2 : énumération et scan

L’énumération approfondit la recon en cartographiant précisément les services exposés.

Outils de référence :
– Nmap : scan de ports, identification de services, OS fingerprinting
– Masscan : scan ultra-rapide à grande échelle (à manier avec précaution sur production)
– Amass, Subfinder : énumération de sous-domaines
– Nikto, Nuclei : scanners web pour vulnérabilités courantes
– Gobuster, ffuf : énumération de répertoires et fichiers cachés

Scan typique d’une cible web :
1. Nmap pour les ports ouverts
2. Vérification des versions de services
3. Énumération des sous-domaines
4. Crawling de l’application web
5. Identification des endpoints API non documentés

Précaution : un scan trop agressif peut perturber un service de production. Toujours valider les options avec le commanditaire avant de lancer Masscan, Nikto en mode complet, ou Burp Active Scan sur un environnement live.

8. Phase 3 : exploitation

L’exploitation est la phase où le pentester tente d’exploiter concrètement les vulnérabilités identifiées pour démontrer leur impact.

Catégories de vulnérabilités fréquentes :

Côté web (applications) : injections SQL, XSS, IDOR, authentification faible, session hijacking, désérialisation, SSRF, RCE. Voir Pentesting d’applications web : guide pratique pour le détail.

Côté infrastructure : services obsolètes avec CVE connues, mots de passe par défaut, partages SMB ouverts, services SNMP avec community public, mauvaises configurations cloud (S3 buckets ouverts, IAM trop permissifs).

Côté humain (si scope autorise) : phishing ciblé, vishing, dépôt de USB.

Outils d’exploitation :
– Metasploit Framework : exploits pour CVE connues, payload generation
– Burp Suite : interception et manipulation HTTP, scanner web
– sqlmap : injection SQL automatisée
– Hydra : brute force protocoles d’authentification
– CrackMapExec, impacket : exploitation Active Directory

Règle d’or : ne jamais exécuter un exploit sans comprendre ce qu’il fait. Un mauvais payload peut casser un service critique en production. Toujours tester en environnement contrôlé avant. En cas de doute, demander confirmation au commanditaire avant d’aller plus loin.

9. Phase 4 : post-exploitation

Après une compromission initiale, le pentester évalue jusqu’où un attaquant pourrait aller depuis ce point d’entrée.

Activités typiques :
– Énumération du système compromis (utilisateurs, processus, fichiers sensibles)
– Escalade de privilèges (de user à root/admin)
– Mouvement latéral (compromettre d’autres machines depuis la première)
– Identification de données critiques accessibles
– Documentation des chemins d’attaque

Important : la post-exploitation s’arrête là où le ROE le dit. Si le scope ne couvre pas le mouvement latéral, ne pas le faire. Si l’exfiltration de données réelles est interdite, se contenter de prouver l’accessibilité (ex. : capture du nom de fichier, pas du contenu sensible).

Persistance : rarement autorisée dans un pentest classique. Ne jamais installer un backdoor sans accord écrit explicite, et toujours fournir au commanditaire les mécanismes de désinstallation immédiate.

Nettoyage : à la fin du pentest, supprimer tous les comptes créés, fichiers déposés, exploits laissés. Le commanditaire ne doit pas avoir à découvrir des artefacts du pentest des semaines plus tard.

10. Phase 5 : rapport et remédiation

Le rapport est le livrable principal du pentest. Sans rapport clair et actionnable, les vulnérabilités identifiées ne servent à rien.

Structure recommandée d’un rapport de pentest :

Executive summary : résumé non-technique pour la direction (page max), niveau de risque global, principales recommandations
Méthodologie et scope : ce qui a été testé, comment, dans quelles conditions
Synthèse des vulnérabilités : tableau récapitulatif avec sévérité (CVSS)
Détails par vulnérabilité : description, preuve d’exploitation (screenshots, payloads), impact, recommandation de remédiation
Annexes : logs, scripts, références externes (CVE, OWASP)

Sévérités CVSS standards :
– Critical (9.0–10.0)
– High (7.0–8.9)
– Medium (4.0–6.9)
– Low (0.1–3.9)
– Informational (0.0)

Voir Rédiger un rapport de pentesting professionnel pour le détail.

Remédiation : une fois le rapport remis, le commanditaire planifie les corrections. Un re-test après remédiation permet de valider que les correctifs sont effectifs et n’ont pas introduit de nouvelles vulnérabilités.

11. Pentesting interne vs prestataire externe

Internalisation :
– Avantages : connaissance fine du contexte, pentests fréquents possibles, coût marginal faible une fois l’équipe en place
– Inconvénients : recrutement difficile (profils rares), biais (on connaît trop le système, on rate les angles morts), pas de regard externe certifiant

Prestataire externe :
– Avantages : regard frais, expertise variée, certifications souvent demandées par audits/clients (PASSI en France, équivalents locaux)
– Inconvénients : coût plus élevé par mission, dépend de la qualité du prestataire (très variable)

Pour une PME ouest-africaine type :
– Audit annuel par prestataire externe sur les actifs critiques
– Scans automatisés mensuels en interne avec des outils comme OpenVAS ou Nuclei
– Bug bounty sur le périmètre public (alternative ou complément)

Choisir un prestataire : vérifier les certifications (OSCP, OSWE, CEH, GPEN, GWAPT, PASSI), demander des références clients vérifiables, exiger un échantillon de rapport caviardé pour évaluer la qualité du livrable.

12. Bug bounty : alternative ou complément ?

Le bug bounty est un programme où une entreprise invite des chercheurs externes à signaler des vulnérabilités contre récompense.

Plateformes principales : HackerOne, Bugcrowd, Intigriti, YesWeHack (européen).

Avantages du bug bounty :
– Test continu (pas une photo à un instant T)
– Diversité des chercheurs et techniques
– Paiement au résultat (pas de frais pour les rapports invalides)

Inconvénients :
– Pas de garantie de couverture exhaustive
– Suppose une maturité interne (équipe sécurité capable de trier et valider les rapports)
– Coût potentiellement élevé sur des programmes ouverts populaires

Pour une PME : bug bounty est plutôt une étape avancée après plusieurs cycles de pentests classiques. Démarrer en privé (programme invitation-only) pour limiter le bruit avant d’ouvrir publiquement.

Alternative locale : programmes de divulgation responsable (responsible disclosure) — l’entreprise publie une politique acceptant les rapports de vulnérabilité de bonne foi sans nécessairement de récompense financière. Plus simple à démarrer.

13. Coûts à anticiper

Les coûts d’un pentest dépendent du périmètre, de la complexité, et du prestataire.

Ordres de grandeur indicatifs (à confirmer auprès des prestataires locaux ou via cybersecurite-pme-afrique-guide) :

Pentest web standard (1 application, grey box, 5-7 jours) : enveloppe importante mais accessible pour une PME
Pentest infra externe (quelques IPs publiques) : moins coûteux car périmètre plus restreint
Pentest infra interne (LAN, AD) : généralement plus cher (déplacement, durée)
Red teaming complet : significativement plus élevé

Les coûts varient fortement entre prestataires. Un prestataire low-cost qui livre un rapport automatique sans valeur ajoutée est plus cher que rien ne pas faire de pentest. Privilégier la qualité documentée sur le prix.

Au-delà du coût direct : prévoir le coût de la remédiation (souvent supérieur au coût du pentest lui-même) et le coût d’un re-test pour valider les correctifs.

14. Erreurs fréquentes à éviter

Cadrer le pentest trop large pour le budget. « On veut tout tester » sans budget proportionnel produit un pentest superficiel inutile. Mieux vaut un pentest profond sur un périmètre ciblé.

Confondre scan automatisé et pentest. Un rapport Nessus brut n’est pas un pentest. Un pentest implique exploitation et analyse manuelle.

Pentester en production sans précautions. Risque de casser un service. Toujours valider les fenêtres de test et les types de tests autorisés.

Ne pas planifier la remédiation. Recevoir un rapport et le ranger sans corriger les vulnérabilités est l’erreur la plus fréquente. Le pentest sans remédiation est de l’argent perdu.

Choisir un prestataire au moins-disant. La qualité varie énormément. Un prestataire qui ne demande pas le ROE, ne signe pas de NDA, ou produit un rapport en 2 jours sur un périmètre complexe doit alerter.

Oublier la conformité données personnelles. Si le pentest implique des données réelles (clients, employés), prévoir un cadre conforme cdp.sn au Sénégal et équivalents dans la zone CEDEAO.

Pas de communication interne. Les équipes IT/dev doivent être prévenues du pentest pour ne pas confondre l’exercice avec une attaque réelle (et déclencher des actions disruptives).

Pentest unique sans suite. Un pentest ponctuel après lequel on n’évolue pas est un coup d’épée dans l’eau. La sécurité est un processus, pas un livrable.

FAQ

Combien de temps prend un pentest typique pour une PME ?

Pour une application web standard en grey box : 5 à 10 jours de test + 3 à 5 jours de rapport. Pour une infrastructure complète : 2 à 4 semaines selon la taille. Pour un red teaming : plusieurs semaines voire mois. Toujours discuter le timing avec le prestataire en amont.

Faut-il prévenir les équipes internes du pentest ?

Cela dépend de l’objectif. Pour un pentest classique : oui, prévenir l’équipe IT pour éviter qu’elle déclenche des contre-mesures. Pour un red teaming visant aussi à tester la détection (équipe SOC), garder les équipes opérationnelles dans l’ignorance est délibéré — seul un cercle restreint (DSI, RSSI) est au courant.

Le pentest peut-il casser ma production ?

C’est un risque réel mais maîtrisable. Un pentester sérieux discute des fenêtres de test, évite les outils destructifs en production, et a une procédure d’urgence. Pour les actifs très critiques, préférer un pentest sur environnement de pré-production identique au prod.

Comment vérifier qu’un prestataire de pentest est sérieux ?

Demander : certifications (OSCP au minimum côté pentester, agréments locaux le cas échéant), références clients vérifiables, échantillon de rapport caviardé, méthodologie écrite, NDA standard, processus de gestion des vulnérabilités critiques découvertes, assurance responsabilité civile professionnelle.

Le pentest remplace-t-il un audit de conformité (ISO 27001, PCI DSS) ?

Non. Un pentest est une composante technique. Un audit de conformité couvre aussi la gouvernance, les processus, la documentation, les contrôles organisationnels. Les deux sont complémentaires.

Quelle fréquence de pentests pour une PME ?

Recommandation type : un pentest annuel des actifs critiques, ou après chaque changement majeur (migration cloud, refonte applicative, nouveau service public). Pour des actifs financiers, augmenter la fréquence (semestriel).

Puis-je apprendre le pentesting moi-même pour ma PME ?

Oui, des plateformes comme HackTheBox, TryHackMe, PortSwigger Web Security Academy permettent d’apprendre sur des environnements légaux conçus pour ça. Compter 6-12 mois de pratique régulière pour une vraie compétence. Cela ne dispense pas d’un audit externe mais permet de maintenir une vigilance interne et de comprendre les rapports.

Que faire si mon pentester découvre une attaque en cours non liée ?

C’est rare mais ça arrive. Le ROE doit prévoir cette éventualité : arrêt immédiat des tests, communication d’urgence au commanditaire, conservation des preuves, et bascule vers une réponse à incident (forensic). Cette situation justifie pleinement la procédure d’urgence définie dans le ROE.

Articles liés (cluster Pentesting)

Voir aussi : Cybersécurité pour PME africaines : guide complet pour le cadre stratégique global, Linux administration avancée pour les fondamentaux système indispensables au pentester.

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.