Comme partout, le sujet oscille entre deux discours : l’automatisation complète du test d’intrusion, et le rejet total. La réalité de nos missions est plus banale et plus utile.
Où le gain est réel
La reconnaissance
Rassembler et recouper l’information publique sur une cible — domaines, sous-domaines, technologies, empreinte publique des collaborateurs — est un travail volumineux et peu créatif. Les outils assistés y font gagner des heures.
Attention toutefois : ce qui est produit doit être vérifié. Une association erronée entre un domaine et une organisation peut conduire à tester un périmètre qui n’appartient pas au client, avec les conséquences juridiques que cela suppose.
La compréhension de code
Lire rapidement un code inconnu, identifier les points d’entrée, repérer des schémas dangereux. C’est un accélérateur d’analyse, pas un substitut : le taux de faux positifs reste élevé et chaque piste doit être confirmée manuellement.
La rédaction
C’est le gain le plus tangible et le moins spectaculaire. Structurer des constats, reformuler pour un lecteur non technique, produire une première version de synthèse. Le temps de rédaction représente une part significative d’une mission — voir ce qui fait un bon livrable.
La règle : l’auditeur relit et assume. Un rapport signé engage le cabinet.
L’ingénierie sociale
Les prétextes personnalisés et crédibles se produisent aujourd’hui à faible coût. C’est vrai pour l’auditeur comme pour l’attaquant — raison pour laquelle les indices traditionnels de détection d’un message frauduleux, notamment les fautes de langue, ont perdu beaucoup de leur valeur.
C’est un point à faire passer en sensibilisation : le repérage par la forme ne suffit plus, seul le réflexe de vérification par un canal indépendant tient.
Où ça ne marche pas
L’exploitation d’une faille logique métier. Comprendre qu’un enchaînement d’opérations autorisées permet d’obtenir un avantage indu suppose de comprendre le métier. C’est ce qui distingue un test d’intrusion d’un scan, et cela reste humain.
Le jugement sur la criticité. Un modèle ne sait pas que ce serveur porte la facturation. La priorisation contextuelle demande la connaissance du client.
La confirmation. Un résultat plausible mais faux, présenté avec assurance dans un rapport, coûte plus cher que le temps qu’il a fait gagner. Chaque constat doit être reproduit.
Les précautions à prendre côté prestataire
Un point que les clients devraient systématiquement poser en question :
- Les données du client sortent-elles ? Envoyer des extraits de code, des configurations ou des captures dans un service externe est un transfert, souvent contraire aux clauses de confidentialité du contrat.
- Le prestataire l’a-t-il déclaré ? C’est une question à poser avant la mission, pas après.
- Quelle relecture humaine avant remise du rapport ?
Ces questions rejoignent celles à poser sur tout assistant utilisé en entreprise.
Ce que ça change côté défense
Le coût d’entrée d’une attaque crédible baisse. Les prétextes s’industrialisent, la reconnaissance s’accélère.
Cela ne change pas les fondamentaux : les mesures qui limitent l’impact d’un accès initial — cloisonnement des comptes, authentification renforcée, segmentation, sauvegardes hors de portée — restent celles qui décident de l’issue.
La question que pose le client, et la bonne réponse
« Utilisez-vous l’IA dans vos tests ? » figure désormais dans beaucoup de consultations. Elle appelle deux réponses opposées selon l’intention de celui qui la pose, et il faut la clarifier avant de répondre.
Certains cherchent une garantie de modernité et attendent un oui. D’autres — de plus en plus — cherchent l’inverse : ils veulent savoir si leurs données d’architecture, leurs extraits de code et leurs vulnérabilités vont transiter par un service tiers.
La réponse défendable dans les deux cas est la même, et elle est précise plutôt que binaire : sur quelles étapes ces outils interviennent, quelles données leur sont transmises, et lesquelles ne le sont jamais. Un prestataire qui répond « oui, cela nous rend plus efficaces » sans préciser ce point renseigne surtout sur son absence de politique.
Ce que le client doit exiger au contrat
C’est le prolongement direct des précautions côté prestataire, vu depuis l’acheteur. Quatre clauses méritent d’être posées avant signature, parce qu’elles ne se négocient plus ensuite.
- L’interdiction de transmettre les livrables et les éléments d’architecture à un service tiers sans accord écrit préalable. Cela vise le rapport, les schémas, les extraits de configuration et le code source — c’est-à-dire une cartographie de vos faiblesses, dont la valeur pour un attaquant est considérable.
- La localisation des traitements et l’interdiction d’utilisation des données transmises pour l’entraînement de modèles. Les conditions d’usage professionnelles des principaux services le prévoient généralement, mais cela se vérifie plutôt que se suppose.
- La validation humaine de tout constat. Aucune vulnérabilité ne figure au rapport sans avoir été vérifiée manuellement. Cette clause est simple à écrire et discriminante : elle exclut la remise de résultats bruts.
- La traçabilité des actions menées. Elle est nécessaire pour distinguer, en cas d’incident pendant la prestation, ce qui relève du test de ce qui relève d’un tiers. Elle s’impose d’autant plus lorsque des outils enchaînent des actions de manière autonome.
Le risque propre aux outils autonomes
La distinction structurante n’est pas entre outil classique et outil assisté, mais entre outil qui propose et outil qui agit.
Un dispositif qui enchaîne lui-même des actions sur un système cible pose trois problèmes concrets dans le cadre d’une prestation encadrée :
Le périmètre. Un test d’intrusion s’exerce sur un périmètre contractuellement délimité. Un outil qui décide seul de sa prochaine étape peut suivre une relation de confiance vers un système hors périmètre — appartenant parfois à un tiers. La responsabilité juridique n’est alors pas théorique.
La disponibilité. Les actions destructrices ou déstabilisantes sont normalement exclues par convention. Un enchaînement automatique n’a pas de jugement sur la criticité du système qu’il sollicite, et un environnement de production ancien tolère mal l’insistance.
La reproductibilité. Si le client demande comment un accès a été obtenu, il faut pouvoir le rejouer. Une séquence produite par un raisonnement non déterministe et non journalisée en détail n’est pas reproductible — ce qui prive le rapport de sa valeur démonstrative.
Ces trois points plaident pour une règle simple : l’autonomie est acceptable sur la reconnaissance et l’analyse, elle demande une validation humaine sur l’exploitation.
L’effet sur le métier, à moyen terme
La partie du travail que ces outils absorbent le mieux est la partie basse : reconnaissance, tri de sorties d’outils, rédaction des descriptions génériques, vérification de couverture. C’est aussi, historiquement, la partie sur laquelle un débutant se forme.
L’effet le plus probable n’est donc pas une réduction du nombre de testeurs, mais une difficulté accrue à en former de nouveaux : le chemin d’apprentissage passait par des tâches que la machine fait désormais plus vite. Les cabinets qui laisseront ces tâches entièrement à l’outil produiront des juniors qui savent lire un résultat sans savoir comment il a été obtenu — et qui ne pourront pas le contester quand il sera faux.
C’est un arbitrage de formation, pas un arbitrage technique. Il se traite en conservant délibérément une part de travail manuel pour les profils en apprentissage, même quand elle n’est pas rentable à l’échelle d’une mission.
Ce qui ne change pas
La valeur d’un test d’intrusion n’a jamais résidé dans la découverte de vulnérabilités connues — les outils automatiques le font depuis vingt ans. Elle réside dans la compréhension de ce qui compte pour cette organisation-là : quel enchaînement de faiblesses mineures mène à la donnée qui, si elle disparaît, arrête l’activité.
Cette question demande de comprendre un métier, une organisation et des priorités. C’est ce qui distingue un rapport qui déclenche des décisions d’une liste que personne n’exploite, et rien dans l’outillage actuel ne s’en approche.
Sources
- OWASP Top 10 for LLM Applications
- NIST AI Risk Management Framework
- OWASP Web Security Testing Guide
Aller plus loin
Nos missions de sécurité offensive et nos exigences de livrable sont détaillées ici.