1. Fixer le vocabulaire avant de fixer les outils​

Trois métiers proches, souvent confondus :

• Pentester : simule des attaques dans un périmètre autorisé pour aider une organisation à corriger ses failles.
• Red teamer : imite un adversaire réel sur toute la surface d'attaque, y compris le facteur humain et le physique. Plus long, plus discret, plus rare.
• Analyste SOC / bleu : détecte et répond aux attaques réelles, en continu. Souvent la vraie porte d'entrée du secteur.

Beaucoup de débutants visent tout de suite le rôle de red teamer. C'est comme viser chirurgien avant d'avoir fait médecine générale : possible, mais rarement le meilleur trajet.

2. Les bases non négociables​

Sans ces socles, un cours de pentest n'a pas de prise :

• Réseau : TCP/IP, routage, NAT, DNS, HTTP. Savoir lire une capture Wireshark. Sans ça, la moitié des scans Nmap ne veulent rien dire.
• Linux : navigation en ligne de commande, permissions, gestion des services. Un pentester passe sa journée dans un terminal.
• Un langage : Python en priorité. Pour automatiser, comprendre les exploits publiés, lire du code offensif sans exécuter aveuglément.
• Windows et Active Directory : la majorité des missions internes sont Windows. Comprendre les GPO, les tickets Kerberos, la propagation d'identifiants.

Compter six mois à un an pour être à l'aise sur ces bases si vous partez de zéro. Ce temps n'est pas perdu : c'est celui qui vous rendra utile une fois embauché.

3. Kali Linux : outil, pas objectif​

Kali est une distribution d'outils. L'installer ne fait pas de vous un pentester, exactement comme installer Photoshop ne fait pas de vous un graphiste. Ce qui compte :

• Une seule VM Kali avec un instantané base propre auquel vous revenez entre exercices.
• Notes obsessionnelles : chaque commande apprise finit dans un notes.md structuré. C'est votre vrai capital.
• Réseau isolé : jamais de test sur un réseau que vous ne contrôlez pas.

Une routine efficace : chaque outil que vous découvrez, vous l'utilisez trois fois sur trois cibles différentes avant de passer au suivant. Vingt outils maîtrisés valent mieux que deux cents survolés.

4. Une méthode plutôt qu'une collection​

Une mission de pentest suit toujours le même chemin. Le plan ci-dessous est celui de notre cours gratuit Tests d'intrusion — vous pouvez le suivre pour vous entraîner :

1. Planification — cadrer avec un document de Rules of Engagement.
2. Reconnaissance passive — OSINT, DNS, certificats publics, moteurs de recherche.
3. Reconnaissance active — scans Nmap, énumération de services.
4. Recherche de vulnérabilités — CVE, NVD, EPSS, KEV.
5. Exploitation — web, système, humain.
6. Post-exploitation — élévation, pivot, exfiltration contrôlée.
7. Rapport — le vrai livrable.

Un débutant qui maîtrise ces sept étapes vaut plus qu'un « expert » d'un outil précis. La méthode est portable, l'outil vieillit.

5. Certifications : lesquelles, quand​

En 2026, le paysage tient sur quelques choix, pas sur une liste à cocher :

• Débutant réel : commencer par une formation structurée (comme la nôtre), pas par une certification. Une certification atteste, elle n'enseigne pas.
• Junior visant l'embauche : eJPT est un bon premier tampon, abordable, orienté pratique.
• Confirmé : OSCP reste la référence pour les postes de pentester interne. Longue, coûteuse, mais reconnue.
• Spécialisation : Burp Suite Certified Practitioner pour le web, OSEP pour l'évasion.

Piège classique : accumuler des certifications sans mission concrète à décrire en entretien. Un CV avec une seule mission simulée bien documentée bat un CV rempli de badges.

6. Se rendre visible sans se surexposer​

Trois choses en 2026 :

• Un dépôt GitHub public avec des projets défensifs (analyse de logs, détection). Poster des exploits, même publics, n'aide pas votre recrutement.
• Un blog technique — même deux articles par an suffisent — expliquant des concepts avec vos mots.
• Des plateformes d'entraînement (HackTheBox, TryHackMe) avec un profil qui montre une progression régulière plutôt qu'un pic sur un mois.

Les recruteurs cherchent des personnes qui expliquent ce qu'elles font. Beaucoup savent hacker ; peu savent l'expliquer à un chef de projet.

7. La vraie ligne rouge​

Une intrusion sans autorisation écrite est un délit, y compris chez un ami, y compris sur une machine que vous croyez « sans importance ». Le meilleur pentester junior perd son embauche s'il a un antécédent judiciaire.

Le juste chemin : votre labo, des plateformes prévues pour ça, des missions en stage encadré. Le reste vient naturellement.

Envie de démarrer ? Notre cours Tests d'intrusion est gratuit sur inscription. Il suit exactement les sept étapes ci-dessus, avec trois travaux pratiques et un certificat vérifiable à la fin.

1. Le contrôle d'accès repose sur le front-end (A01)​

Le cas typique : une application cache un bouton « supprimer utilisateur » aux comptes non-admin, mais l'API accepte la requête si vous la rejouez à la main. La règle du front-end n'a jamais protégé personne.

Requête d'attaque :

POST /api/users/42/delete HTTP/1.1
Cookie: session=<un cookie standard, non-admin>

Réponse : 204 No Content. Compte supprimé. Aucun contrôle serveur.

Correction — Node/Express :

app.post('/api/users/:id/delete', requireAuth, requireRole('admin'), async (req, res) => {
  await userService.delete(req.params.id, { by: req.user.id });
  res.status(204).end();
});

Le contrôle doit être dans requireRole côté serveur. Le front peut cacher le bouton pour l'ergonomie, jamais pour la sécurité.

2. La requête SQL est construite par concaténation (A03)​

Elle a disparu des cours il y a quinze ans, elle est encore dans le code hérité. Un exemple qu'on voit régulièrement :

$id = $_GET['id'];
$sql = "SELECT * FROM produits WHERE id = " . $id;
$result = mysqli_query($conn, $sql);

Requête d'attaque :

GET /produits?id=1%20UNION%20SELECT%20null,current_database(),null--

Correction — PHP / PDO :

$stmt = $pdo->prepare('SELECT * FROM produits WHERE id = :id');
$stmt->execute(['id' => $_GET['id']]);
$produit = $stmt->fetch();

La parade n'est pas « filtrer les caractères ». C'est le requêtage paramétré, dans tout langage, tout ORM, sans exception.

3. Les entrées sont assainies mais le contexte est ignoré (A03)​

Une XSS moderne ne vient plus d'un alert(1) naïf, elle vient d'une donnée injectée dans un mauvais contexte — attribut, URL, JavaScript inline.

Ceci est vulnérable, même si vous appliquez htmlspecialchars :

<a href="{{ url_utilisateur }}">Voir</a>

Un attaquant met javascript:alert(1) : le HTML est propre, le contexte URL ne l'est pas.

Correction — filtrer selon le contexte :

function estUrlHttpSecuritaire(v) {
  try {
    const u = new URL(v);
    return u.protocol === 'https:' || u.protocol === 'http:';
  } catch { return false; }
}

Pour aller plus loin : une Content Security Policy stricte qui interdit l'inline JavaScript est la meilleure protection systémique.

4. Le SSRF est encore trivial dans les intégrations tierces (A10)​

Application qui accepte une URL fournie par l'utilisateur pour aller chercher une image, un webhook, un fichier. La requête sort du serveur, souvent avec des privilèges internes.

Requête d'attaque, contre AWS EC2 :

POST /import HTTP/1.1
Content-Type: application/json

{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Le service de métadonnées d'instance renvoie des identifiants temporaires. En moins d'une minute, l'attaquant s'authentifie en AWS avec le rôle de la machine.

Correction :

• Interdire les IP privées et de bouclage côté serveur, avant toute requête sortante.
• Passer par un proxy sortant contrôlé (par exemple smokescreen).
• Utiliser IMDSv2 en AWS (sinon considérez que vos rôles sont exposés).

5. Les mots de passe sont stockés « chiffrés », pas hachés (A02)​

Un rappel qui devrait être inutile mais ne l'est pas : un mot de passe n'est pas chiffré, il est haché avec un algorithme conçu pour ça. AES sur un mot de passe est une erreur, sha256 aussi, md5 est un crime.

Ce qu'il faut :

from argon2 import PasswordHasher

ph = PasswordHasher()
empreinte = ph.hash(mot_de_passe)  # à stocker en base
ph.verify(empreinte, mot_de_passe)  # à la connexion

Argon2id est le standard actuel (2026). bcrypt reste acceptable. scrypt aussi. Tout ce qui n'est pas dans cette liste doit être remplacé, y compris les hachages « avec sel » basés sur SHA-256.

Le fil rouge​

Les cinq erreurs se ressemblent : l'application fait confiance à un endroit qu'elle ne devrait pas — front-end, chaîne construite, URL brute, contexte, algorithme. Chaque contrôle doit être posé au bon niveau, celui que l'attaquant ne peut pas contourner.

Le OWASP Top 10 en pratique : c'est la semaine 7 de notre cours gratuit Tests d'intrusion. On y exploite chaque erreur ci-dessus, on écrit la remédiation, et on rédige les constats comme un rapport professionnel.

Pourquoi le RoE conditionne tout le reste​

Le RoE protège trois parties :

• Le client, qui sait ce qui va être testé, quand, et à quel prix.
• Le prestataire, qui a une trace écrite de son autorisation.
• La personne qui exécute, qui pourra montrer un document opposable en cas de litige.

En cas d'incident (données touchées, service interrompu, découverte d'une intrusion préexistante), la première question posée sera : qu'est-ce qui était autorisé ? La seule réponse acceptable est un PDF signé, pas un fil de messages.

Contenu minimal — Neuf sections​

1. Identification des parties​

Noms officiels, adresses, représentants autorisés à signer. Un RoE signé par une personne sans autorité contractuelle n'a pas de valeur.

2. Périmètre​

Ce qui est dans le périmètre :

• Plages IP publiques et privées, avec masques.
• Noms de domaine et sous-domaines explicites.
• Applications, chemins d'URL, endpoints API.
• Comptes de test fournis (avec date d'expiration).

Ce qui est hors périmètre, énoncé explicitement :

• Systèmes tiers hébergés par des SaaS que vous ne pouvez pas autoriser.
• Environnements de production critique, sauf mention contraire.
• Systèmes patrimoniaux avec risque de rupture.

Le périmètre doit être défini par écrit, pas décrit oralement ni « on verra ».

3. Techniques autorisées, techniques interdites​

Un exemple typique :

4. Fenêtres d'intervention​

• Dates de début et de fin.
• Créneaux horaires précis pour les tests bruyants (scans agressifs, force brute).
• Marge de sécurité : un scan qui déborde d'une fenêtre sort du contrat.
• Périodes noires (fermeture annuelle, ouverture d'exercice, jour de fin de mois).

5. Contacts d'urgence​

Nom, fonction, téléphone joignable 24 h, courriel. Deux contacts distincts, avec un chemin d'escalade explicite. Le RoE indique qui vous appelez si vous voyez passer une intrusion réelle.

6. Traitement des découvertes critiques​

Un pentest découvre parfois qu'un attaquant est déjà dans le système. La procédure doit être écrite :

• Arrêt immédiat des tests offensifs.
• Notification par téléphone au contact principal sous 2 heures.
• Préservation des preuves sans intervention.
• Basculement, si demandé, en mission d'incident-response (contrat séparé).

7. Gestion des preuves et des données​

• Où les preuves sont stockées (poste chiffré, dépôt Git privé, coffre-fort).
• Durée de conservation, procédure de destruction.
• Traitement des données personnelles touchées incidemment. Sous Loi 25 (Québec) ou RGPD (UE), ces éléments doivent être documentés.

8. Livrables​

• Rapport principal, format, langue, nombre de pages attendues.
• Rapport de synthèse pour la direction.
• Séance de restitution, date et durée.
• Remise éventuelle des scripts et outils personnalisés.

9. Clauses de responsabilité​

• Assurance responsabilité professionnelle du prestataire.
• Limite de responsabilité en cas de rupture de service accidentelle.
• Confidentialité mutuelle, durée post-mission.

Trois erreurs qui reviennent​

Erreur 1 : oublier les sous-traitants du client. Le client héberge son ERP chez un SaaS tiers. Le RoE ne mentionne pas ce SaaS. Vous scannez, le SaaS vous détecte, et c'est votre société qui est en défaut, pas le client.

Erreur 2 : marges de temps trop courtes. Une fenêtre « samedi 20 h à dimanche 2 h » vaut pour la nuit d'un weekend, pas pour les scans qui se relancent tout seuls. Prévoir 30 minutes de battement à chaque bout.

Erreur 3 : pas de procédure pour l'intrusion préexistante. Personne ne prévoit ce cas parce que « ça n'arrive jamais ». Il arrive statistiquement sur une mission sur dix.

Modèle simplifié — Prêt à adapter​

# Rules of Engagement — Mission d'intrusion

## Parties
- Client : ...
- Prestataire : ...
- Signataires autorisés : ...

## Périmètre
- Dans le périmètre : ...
- Hors périmètre : ...

## Techniques autorisées
- ...

## Techniques interdites
- Déni de service en production
- Modification de données réelles
- ...

## Fenêtres d'intervention
- Du ... au ...
- Créneaux bruyants autorisés : ...

## Contacts d'urgence
- Principal : ... (téléphone 24 h)
- Secondaire : ...

## Découverte d'une intrusion préexistante
1. Arrêt des tests.
2. Notification sous 2 h.
3. Préservation des preuves.

## Gestion des preuves
- Stockage : ...
- Destruction : ...

## Livrables
- Rapport principal : ...
- Synthèse direction : ...
- Restitution : ...

## Responsabilité
- Assurance : ...
- Confidentialité : ...

Signature client : ______________ Date : ______________
Signature prestataire : __________ Date : __________

Une dernière chose​

Le RoE n'est pas un document contre le client. C'est le document qui rend la mission possible. Un client qui refuse d'en signer un a compris qu'il vous ferait porter le risque. Ne travaillez pas sans.

Nous consacrons la semaine 2 du cours Tests d'intrusion à la rédaction d'un RoE simulé. Le cours est gratuit sur inscription et se termine par un quiz final délivrant un certificat vérifiable.