D'où vient la confusion
Un pentest et un red teaming font tous deux appel à des compétences adversariales : ils testent. Ils produisent tous deux un rapport qui énumère des failles. Un client entend parler de « test d'intrusion » et « red teaming » dans un même contexte et les juge équivalents. C'est faux, mais l'erreur est compréhensible.
La différence réelle n'est pas dans les outils ou les techniques employées — un red teamer utilise souvent les mêmes exploits qu'un pentesteur. Elle réside dans l'hypothèse : en pentest, on demande au testeur « trouves-moi ce qui fuit ». En red teaming, on lui dit « tu es un adversaire motivé, montre-moi ce qu'on ne peut pas empêcher ».
Acheter un « red teaming » alors qu'on a besoin d'un pentest, ou inversement, c'est recevoir un diagnostic incomplet. Et la facture reste la même.
Les deux démarches côte à côte
Voici les quatre dimensions où elles divergent vraiment.
Périmètre
Infrastructure applicative fixe, frontières établies à l'avance. On teste une URL, un serveur, une API nommée, dans un environnement annoncé.
Périmètre
Périmètre délibérément flou. La cible peut être le modèle, ou l'agent qui l'utilise, ou les données qu'il consomme. L'attaquant reel n'a pas de frontières.
Durée
Nombre de jours fixe. Souvent : 5 jours, 10 jours, 2 semaines. La campagne s'arrête au jour J convenu. C'est un calendrier contractuel.
Durée
Durée flexible, liée aux objectifs atteints. On arrête quand on a trouvé X failles graves, ou quand aucune faille supplémentaire n'apparaît depuis Y jours. C'est une question d'épuisement, pas de calendrier.
Posture
Le pentesteur connaît les frontières : il ne teste que ce qu'on lui a dit de tester. Il respecte les règles d'engagement annoncées. L'équipe bleue sait qu'il vient.
Posture
L'équipe rouge agit sans règles d'engagement préalables — ou avec des règles volontairement vagues. Elle simule un attaquant réel qui ne demande la permission à personne. L'équipe bleue ne sait pas que le test a commencé.
Objectif
Lister les vulnérabilités découvertes et les failles observables. Le résultat : un catalogue exploitable, rangé par sévérité. La question : « qu'est-ce qui fuit ? »
Objectif
Démontrer que le système ne résiste pas à une posture adversariale soutenue et adaptée. Le résultat : un scénario d'attaque cohérent, avec éventuellement une chaîne d'exploitation. La question : « peut-on vraiment m'arrêter ? »
Quand utiliser l'un, quand utiliser l'autre
Le choix dépend de ce que tu veux vraiment vérifier.
- Tu fais un pentest si…Tu as une application en production, tu dois vérifier qu'elle ne fuite pas de données d'identifiants ou de clés d'accès, et tu as besoin d'un avis rapide et listé avant une deadline. Temps typique : 1–2 semaines.
- Tu fais un red teaming si…Tu as un système critique (IA déployée, API stratégique), tu dois vraiment savoir s'il résiste à un adversaire qui prend son temps, et tu es prêt à mener des tests itatifs pendant un ou deux mois. L'enjeu : réputation, données sensibles, actions non autorisées.
- Tu fais les deux si…Tu as une application qui intègre une IA, tu besoin d'assurance sur ses couches d'infrastructure (pentest), et tu dois aussi démontrer que son comportement intelligent n'est pas détournable (red teaming). Budget plus large, durée plus longue, équipes différentes.
Pour l'IA, la ligne s'efface
Sur les systèmes d'intelligence artificielle, la distinction se brouille. Un pentest classique teste des routes HTTP, des authentifications, des injections SQL. Mais un LLM n'a pas de « SQL à injecter ».
Il existe donc une zone grise : les tests spécifiques au modèle — jailbreak, prompt injection, fuite de prompt système — sont-ils du pentest ou du red teaming ? La réponse pragmatique : c'est du red teaming, même si la durée reste courte (quelques jours) et le périmètre étroit (le modèle seul). Car tu cherches à démontrer qu'on ne peut pas arrêter l'écart de comportement, pas à lister les bugs applicatifs.
Tout ce qui touche aux garde-fous du modèle, au prompt système, aux données qu'il consomme, ou aux actions qu'il peut exécuter en tant qu'agent, relève du red teaming. La séparation pentest/red teaming cesse d'être pertinente. Ce qui compte : une campagne adversariale méthodique, avec reproduction de chaque faille trouvée.
Ce que tu reçois en retour
| Pentest | Red teaming |
|---|---|
| Liste des vulnérabilités trouvées, classées par sévérité | Rapport de campagne avec scénarios d'exploitation complets |
| Preuve pour chaque faille : screenshot, requête HTTP rejouée | Chaque faille reproduite, avec l'intention derrière son exploitation |
| Recommandations correctives par faille | Pistes de remédiation systémiques, au-delà du simple patch |
| Temps d'exécution : 1–3 semaines | Temps d'exécution : 2–12 semaines selon la complexité |
| Coût : modéré | Coût : plus élevé (équipe plus diverse, durée plus longue) |
Comment décider
Trois questions à te poser :
1. Quel est le risque résiduel acceptable ?
Si c'est un risque zéro ou proche — données critiques, santé, finance — tu fais un red teaming. Si c'est « on veut pas d'bugs évidents », un pentest suffit.
2. Combien de temps as-tu à consacrer ?
Pentest : quelques semaines. Red teaming : quelques mois. C'est contractuel vs. itératif.
3. Le système teste-t-il du code ou du raisonnement ?
Code classique (backend, API) : pentest. Modèle IA ou agent : red teaming.