Pourquoi un(e) pentesteur a intérêt à maîtriser les prompts IA
Le pentesteur — testeur d’intrusion — passe une part significative de son temps sur des tâches de traitement de l’information : trier des centaines de vulnérabilités exportées par des outils automatisés, rédiger des rapports techniques complets avec des résumés exécutifs lisibles par des non-techniciens, rechercher les CVE associées aux services découverts lors d’une reconnaissance, ou scripter des scénarios répétitifs sur des environnements standardisés. L’IA générative s’insère naturellement dans ce flux de travail, à condition de savoir lui déléguer les bonnes tâches avec les bonnes contraintes — notamment le cadre légal de la mission.
Un prompt bien formulé permet au pentesteur de gagner plusieurs heures sur la production documentaire, d’automatiser la recherche contextuelle d’informations sur des versions de services, et de générer des artefacts de test (wordlists, scripts de scan, scénarios de phishing pour campagnes autorisées) plus rapidement. La différence entre un prompt amateur et un prompt expert tient souvent à la précision du contexte : type d’environnement, périmètre de la mission, système d’exploitation cible, technologies en jeu.
Les règles d’or du prompting pour pentesteur
- Toujours préciser le cadre légal de la mission. Ajoutez dans chaque prompt sensible la mention : « Cette mission est conduite dans le cadre d’un test d’intrusion autorisé par écrit par [CLIENT / ORGANISATION]. Le périmètre est [PÉRIMÈTRE]. » Cela contextualise la demande et ancre l’usage dans la légitimité.
- Nommer les outils et versions exactes. « Nessus 10.x », « OpenVAS 22.4 », « Metasploit Framework », « Burp Suite Pro » — les réponses seront beaucoup plus précises et exploitables avec les noms exacts des outils et versions impliqués.
- Fournir le contexte technique complet pour les CVE. OS, version du service, architecture, configuration réseau connue — sans ces éléments, la recherche de CVE produit des listes génériques peu utiles pour prioriser les vecteurs d’attaque réels.
- Décomposer la rédaction du rapport en étapes. Section technique d’abord (findings, CVSS, preuve de concept), résumé exécutif ensuite dans un second prompt — mélanger les deux niveaux dans un seul prompt produit des sorties qui ne satisfont ni le RSSI ni la direction.
- Itérer sur les wordlists et scripts avec des contraintes précises. Longueur minimale/maximale, charset, patterns de l’organisation cible, langue — une wordlist générique est toujours moins efficace qu’une wordlist construite sur le contexte de la cible.
- Ne jamais exposer d’informations réelles d’une cible de production. Anonymisez les IP, noms de domaine, identifiants et versions réelles avant de les soumettre à un outil IA externe — travaillez avec des données fictives représentatives.
Tableau des prompts par tâche
| Tâche | Ce que l’IA peut faire | Exemple de prompt |
|---|---|---|
| Tri des faux positifs dans les rapports de vulnérabilités | Analyser une liste de findings et identifier les critères de faux positifs probables | « Voici un extrait de rapport Nessus : [COLLER LES FINDINGS]. Identifie les vulnérabilités qui ressemblent à des faux positifs en expliquant les raisons (plugin connu pour les FP, contexte non applicable, etc.). Ne tranche pas définitivement — signale les cas à vérifier manuellement. » |
| Rédaction des comptes-rendus post-mission | Structurer un rapport technique et produire un résumé exécutif adapté à une direction non technique | « À partir des findings suivants : [LISTE], rédige un résumé exécutif de [N] paragraphes pour un COMEX. Explique le risque business sans jargon technique. Ne cite aucune CVE dans cette section. » |
| Génération de wordlists personnalisées | Créer des listes de mots adaptées au contexte de la cible à partir d’informations fournies | « Génère une wordlist de mots de passe potentiels pour une organisation dont le secteur est [SECTEUR], l’acronyme est [ACRONYME], l’année de fondation est [ANNÉE]. Formats à inclure : [MOTIF]. Longueur : [MIN] à [MAX] caractères. » |
| Recherche de CVE associées aux services détectés | Recenser les vulnérabilités connues pour une version de service donnée et prioriser les vecteurs | « Le service détecté est [SERVICE] version [VERSION] sur [OS] [VERSION OS]. Liste les types de vulnérabilités connues pour cette version (sans inventer de CVE — indique [CVE À VÉRIFIER SUR NVD] si une référence précise est utile), classe par sévérité CVSS estimée. » |
| Scripting de scénarios d’exploitation répétitifs | Générer un squelette de script pour automatiser un scénario de test sur un environnement connu | « Écris un script Python qui automatise [SCÉNARIO DE TEST] sur un environnement [OS / STACK]. Le script doit : [LISTE DES ACTIONS]. Inclus des commentaires explicatifs et un mode dry-run. » |
Prompt pour trier les faux positifs dans un rapport de vulnérabilités automatisé
Utilise ce prompt pour accélérer le dépouillement d’un rapport Nessus ou OpenVAS avant la phase de validation manuelle.
Tu es ingénieur sécurité offensive expérimenté. Je te soumets une liste de vulnérabilités issues d’un scan automatisé [Nessus / OpenVAS / autre]. Ta mission est de m’aider à identifier les faux positifs probables pour prioriser mes validations manuelles. Contexte de la mission (autorisée par écrit par [CLIENT]) : - Périmètre : [DÉCRIRE LE PÉRIMÈTRE] - Environnement cible : [OS / STACK / SERVICES PRINCIPAUX] - Outil de scan utilisé : [OUTIL ET VERSION] Findings à analyser : [COLLER LA LISTE DES FINDINGS — ANONYMISER LES IP ET NOMS DE DOMAINE] Pour chaque finding, indique : 1. Probabilité de faux positif (élevée / moyenne / faible) avec la justification. 2. Raison technique (plugin connu pour les faux positifs, condition d’exploitabilité non réunie, service non exposé sur ce périmètre, etc.). 3. Action recommandée : [valider manuellement / écarter / investiguer davantage]. N’invente aucun numéro de CVE. Si une CVE est pertinente pour la justification, indique [CVE À VÉRIFIER SUR NVD : description de la vulnérabilité].
Prompt pour rédiger le rapport de pentest (section technique + résumé exécutif)
Utilise ce prompt en deux temps : d’abord la section technique, puis le résumé exécutif dans un second échange.
Tu es rédacteur de rapports de tests d’intrusion. Je te fournis les findings d’une mission de pentest [INTERNE / EXTERNE / APPLICATIF WEB] menée dans le cadre d’un contrat autorisé par [CLIENT]. Findings validés : [LISTE DES VULNÉRABILITÉS — préciser pour chacune : titre, sévérité, service concerné, preuve de concept synthétique, impact, recommandation de remediation] ÉTAPE 1 — Rédige la section technique du rapport : - Un titre pour chaque finding - Description de la vulnérabilité (langage technique, niveau : ingénieur sécurité) - Preuve de concept reformulée - Impact technique - Recommandation de remédiation avec niveau de priorité (critique / élevé / moyen / faible) ÉTAPE 2 (dans ma prochaine demande) : je te demanderai le résumé exécutif destiné au COMEX. Contrainte : n’invente aucun chiffre de coût, aucune statistique sectorielle, aucun cas réel d’incident. Utilise [DONNÉE À RENSEIGNER] si une valeur est nécessaire mais non fournie.
Prompt pour générer des artefacts de campagne d’ingénierie sociale (phishing autorisé)
Utilise ce prompt exclusivement dans le cadre d’une campagne de phishing autorisée par le client pour un test de sensibilisation.
Tu es spécialiste en ingénierie sociale pour tests de sécurité autorisés. Je réalise une campagne de phishing simulé dans le cadre d’un test autorisé par écrit par [CLIENT]. L’objectif est de tester la sensibilisation des employés, pas de compromettre un système réel. Contexte de la cible simulée : - Secteur d’activité : [SECTEUR] - Prétexte du scénario : [ex. fausse notification RH / fausse alerte IT / fausse facture fournisseur] - Audience cible : [PROFIL DES DESTINATAIRES : ex. employés non techniques / équipe comptable] - Ton attendu : [OFFICIEL / URGENT / ROUTINIER] Génère : 1. Un email de phishing simulé avec objet, corps et appel à l’action (lien fictif [LIEN-CIBLE-SIMULÉ]). 2. Une wordlist de [N] noms de domaine typosquattés plausibles pour le domaine [DOMAINE-FICTIF-REPRESENTATIF] (ne pas utiliser de vrais domaines clients). 3. Un prétexte alternatif si le premier ne convient pas. Rappel : ces artefacts sont destinés à un environnement de test contrôlé dans le cadre d’une mission autorisée.
Les pièges à éviter
- Soumettre des données réelles de cible à un outil IA externe. Les IP, noms de domaine, identifiants de services et versions réelles d’une cible de production ne doivent jamais transiter par un outil IA non homologué — travaillez toujours avec des données anonymisées ou fictives représentatives.
- Utiliser des CVE générées sans vérification sur NVD. L’IA peut produire des numéros de CVE plausibles mais inventés — ne jamais mentionner une CVE dans un rapport sans l’avoir vérifiée sur le National Vulnerability Database ou une source officielle équivalente.
- Croire qu’un script généré est prêt à l’emploi sans relecture. Les scripts produits par l’IA peuvent contenir des erreurs de logique, des dépendances manquantes ou des comportements inattendus — relisez, testez en environnement isolé, et commentez le code avant tout usage en mission.
- Mélanger résumé exécutif et section technique dans un seul prompt. Ces deux audiences ont des besoins radicalement différents — produisez-les séparément pour garder le niveau d’abstraction adapté à chaque lecteur.
- Oublier de préciser le cadre légal dans les prompts sensibles. Sans contexte de mission autorisée, l’IA peut refuser de collaborer ou produire des réponses trop génériques — ancrez toujours la demande dans son contexte professionnel légitime.
Vérifier les sorties de l’IA
En sécurité offensive, une erreur dans un rapport ou un artefact mal calibré peut compromettre la qualité de la mission, la relation client ou la conformité légale. Appliquez cette checklist avant toute utilisation des sorties générées.
- Chaque CVE mentionnée a-t-elle été vérifiée sur NVD ou une source officielle équivalente ?
- Le rapport ne contient-il aucune donnée réelle de la cible (IP, nom de domaine, identifiant) soumise à l’IA ?
- Les scripts générés ont-ils été relus et testés en environnement isolé avant usage en mission ?
- Les artefacts de phishing sont-ils clairement destinés à une campagne autorisée et ne seront-ils pas réutilisés hors périmètre ?
- Le résumé exécutif est-il compréhensible par un lecteur non technique sans que des conclusions erronées puissent en être tirées ?
- Aucune statistique sectorielle ou coût d’incident n’a-t-il été inventé pour « convaincre » dans le rapport ?