Red team vs pentest : différences, coûts, et
lequel choisir

Le devis arrive un mardi matin : "Opération red team, huit semaines, 85 000 € HT." L'entreprise en question n'a jamais fait tester son application principale, n'a pas de SOC, et son EDR se limite à l'antivirus fourni avec les licences Microsoft. Le commercial jure pourtant que c'est "le test ultime". Il n'a pas tort sur un point : c'est bien l'exercice le plus avancé du marché. Il oublie juste de préciser que, dans ce contexte, c'est aussi le plus inutile.

Red team vs pentest : la confusion est partout, entretenue par des plaquettes commerciales qui utilisent les deux termes comme des synonymes premium l'un de l'autre. Ce sont pourtant deux exercices différents, qui répondent à deux questions différentes, avec des ordres de grandeur de budget sans rapport. Cet article pose des définitions honnêtes, compare objectifs, périmètre, durée et coût, et vous donne une matrice de décision selon votre maturité, y compris là où se placent le bug bounty, le scan automatisé et l'EASM.

Deux exercices, deux questions

Pour ne plus les confondre, regardez d'abord ce qu'on cherche à évaluer dans chaque cas.

Le test d'intrusion évalue un système. On définit un périmètre (une application web, une API, un réseau interne), puis un pentester y cherche le maximum de vulnérabilités exploitables dans le temps imparti et les documente toutes. La question qu'il pose est simple : "quelles failles un attaquant pourrait-il exploiter sur ce périmètre ?"

La red team évalue une organisation : ses défenses, ses équipes, ses procédures. On définit un objectif (exfiltrer les données clients, prendre la main sur l'Active Directory, accéder à la salle serveurs), et une équipe simule un attaquant réel qui tente de l'atteindre par n'importe quel chemin : phishing, intrusion applicative, mots de passe faibles, parfois même intrusion physique. La question qu'elle pose est d'un autre ordre : "votre organisation sait-elle détecter et stopper une attaque réelle ?"

Tout découle de là. Le pentest vise l'exhaustivité sur un périmètre étroit ; il n'a aucune raison d'être discret, et les équipes sont au courant. La red team vise la furtivité sur un périmètre large ; elle n'a besoin que d'un seul chemin d'attaque qui fonctionne, et seule une poignée de personnes (le "white team", en général le RSSI et la direction) sait que l'exercice est en cours. Les équipes de défense, le "blue team", SOC en tête, ne sont pas prévenues : c'est leur réaction qu'on mesure.

Red teaming : définition sans le marketing

Une red team (ou opération de red teaming) est une simulation d'attaque réaliste, menée dans la durée, qui reproduit les tactiques, techniques et procédures (TTP) d'un attaquant plausible pour votre secteur : cybercriminel opportuniste, concurrent, groupe étatique. Les opérateurs s'appuient sur des référentiels comme MITRE ATT&CK pour calquer leurs actions sur des modes opératoires documentés, et déroulent une vraie kill chain : reconnaissance, accès initial (souvent du phishing ciblé), élévation de privilèges, latéralisation, puis action sur l'objectif.

Le livrable ne ressemble pas à un rapport de pentest. Au lieu d'une liste de vulnérabilités classées par sévérité, vous recevez un récit d'attaque horodaté, croisé avec ce que vos défenses ont vu, ou pas. "Jour 12 : mail de phishing ouvert par 3 utilisateurs, charge exécutée, aucune alerte EDR. Jour 19 : compte admin de domaine compromis via un partage réseau, le SOC ouvre un ticket... et le classe sans suite." C'est inconfortable à lire, et c'est le but : chaque détection manquée est un axe de travail pour le blue team.

Deux variantes méritent d'être connues. Le purple teaming casse le secret : attaquants et défenseurs travaillent côte à côte, technique par technique ("on rejoue ce dump de credentials, qu'est-ce que ton SIEM voit ?"). Moins réaliste, mais bien plus pédagogique pour faire progresser un SOC jeune. Et pour le secteur financier, le cadre TIBER-EU normalise les red teams fondées sur la menace réelle (threat intelligence dédiée, opérateurs certifiés) : c'est le modèle des tests TLPT rendus obligatoires par le règlement DORA pour certaines entités financières.

Le pentest : l'exhaustivité sur un périmètre défini

Le test d'intrusion prend le contre-pied exact : périmètre écrit noir sur blanc, durée courte (3 à 12 jours pour une mission web type), équipes prévenues, aucune contrainte de discrétion. Le pentester peut donc passer 100 % de son temps à chercher des failles au lieu d'en passer 60 % à éviter de déclencher vos alertes. Résultat : sur le périmètre testé, la couverture est bien meilleure que celle d'une red team, qui s'arrête au premier chemin qui marche.

C'est le bon outil pour répondre à "cette application est-elle sûre ?" avant une mise en production, pour satisfaire un client grand compte qui l'exige, ou pour prioriser la remédiation avec des preuves d'exploitation plutôt que des scores CVSS théoriques. On a détaillé les phases concrètes d'une mission (cadrage, reconnaissance, exploitation, rapport, retest) dans comment se déroule un test d'intrusion web. Et si votre doute porte plutôt sur la différence avec un scanner automatique, c'est l'objet de pentest, scan de vulnérabilité ou EASM.

Red team vs pentest : le tableau des différences

Un pentest se facture au TJM multiplié par le nombre de jours. Les grilles des prestataires annoncent 3 000 à 20 000 € HT, et dans la commande publique, 12 des 20 missions citant le test d'intrusion tombent dans cette fourchette ; on a décortiqué les facteurs de prix dans combien coûte un test d'intrusion web. Une red team mobilise plusieurs opérateurs pendant plusieurs semaines, plus de la threat intelligence, de l'infrastructure d'attaque dédiée (domaines de phishing vieillis, serveurs C2) et un pilotage white team. Une offre de "red team" en quelques jours est en réalité un pentest avec un scénario de phishing.

Dans les marchés publics : 41 tests d'intrusion, une seule red team

Les prix de red team sont encore moins publics que ceux des pentests. L'un des rares endroits où l'on peut compter ce que des organisations achètent vraiment, ce sont les données essentielles que les acheteurs publics publient (obligatoirement au-delà de 40 000 € HT, volontairement en dessous). J'ai relu à la main chaque marché d'audit de sécurité, de test d'intrusion et de red team qu'elles contiennent, de 2019 au 7 octobre 2026. Le contraste est net : 41 consultations citent le test d'intrusion dans leur objet, et une seule cite la red team.

Ce chiffre ne dit pas que la red team n'existe pas dans le secteur public : un exercice peut être commandé sur un accord-cadre de centrale d'achat, qui ne publie pas chaque commande, ou décrit autrement dans l'objet du marché. Il dit en revanche que, pour un acheteur public qui publie, le test d'intrusion est l'achat courant et la red team l'exception. Un seul point ne fait pas une moyenne : les 46 750 € de ce marché, sur deux mois, donnent un ordre de grandeur compatible avec "des dizaines de milliers d'euros", rien de plus.

Bug bounty vs pentest : et la prime au bug ?

Troisième format souvent jeté dans la même case : le bug bounty. Le principe inverse la logique économique : au lieu de payer un prestataire au jour, vous payez au résultat des chercheurs indépendants qui trouvent des failles sur votre programme (via des plateformes comme YesWeHack ou HackerOne). Une prime par vulnérabilité valide, barémée selon la criticité : de quelques centaines d'euros pour une faille mineure à plusieurs dizaines de milliers pour une compromission critique chez les grands programmes.

Sur le papier, c'est imbattable : des centaines de chercheurs, en continu, payés uniquement s'ils trouvent. En pratique, le bug bounty ne remplace pas le pentest, pour trois raisons. Il ne garantit aucune couverture : les chercheurs vont où les primes sont bonnes et les cibles intéressantes, et personne ne vous doit un rapport disant "on a tout regardé". Il exige une vraie capacité de triage : un programme public reçoit un flux continu de rapports, dont beaucoup de doublons et de hors-scope, qu'il faut qualifier et payer dans des délais décents ; sans équipe pour ça, vous brûlez votre réputation sur la plateforme. Et il suppose un périmètre déjà durci : ouvrir un bug bounty sur une application jamais pentestée, c'est acheter au prix fort, faille par faille, ce qu'une mission de dix jours aurait listé d'un coup. L'ordre raisonnable : pentest d'abord, correction, puis bug bounty (souvent privé, sur invitation) pour la profondeur et la continuité.

Scan, EASM, pentest continu : le reste du spectre

Red team, pentest et bug bounty sont des évaluations humaines. En dessous, et surtout entre, il y a les couches continues et automatisées, celles qui travaillent pendant que personne ne vous teste. Ces formats s'empilent.

L'EASM (External Attack Surface Management) joue un rôle particulier dans cette pile : c'est la reconnaissance permanente. Une red team commence toujours par cartographier votre surface exposée : sous-domaines oubliés, services de préproduction, identifiants qui traînent. Un EASM fait ce travail en continu, pour vous, avant l'attaquant. Quant au pentest continu, il comble le défaut structurel du pentest ponctuel : la photo vieillit à chaque déploiement. Rejouer automatiquement les techniques d'exploitation sur le périmètre, en permanence, c'est l'idée détaillée dans pentest automatisé vs pentest humain. Aucune de ces couches ne remplace la red team ; elles rendent surtout la red team utile le jour où vous la faites, parce que les failles évidentes auront déjà été éliminées.

La matrice de décision : quel format selon votre maturité

La question à se poser est "où en suis-je ?", plutôt que "quel est le meilleur test ?". Chaque format mesure quelque chose de différent, et mesurer la détection d'une organisation qui n'a rien à détecter ne produit qu'un rapport cher et démoralisant. Le cheminement honnête ressemble à ceci :

Il reste un cas particulier. Si vous êtes une entité financière soumise à DORA et désignée pour des tests TLPT, la question de "choisir" ne se pose plus : le régulateur a choisi pour vous. Mais même dans ce cas, le cheminement reste le même : les établissements qui abordent un TIBER-EU sans hygiène de pentest en ressortent avec un rapport douloureux, pas avec un apprentissage.

À retenir

• Le pentest évalue un système : toutes les failles exploitables d'un périmètre défini, en quelques jours. Médiane publique : 14 637,5 € HT sur 20 missions.
• La red team évalue une organisation : un scénario d'attaque réaliste, furtif, sur plusieurs semaines, pour des dizaines de milliers d'euros. Un seul marché public de red team publié depuis 2019, contre 41 de test d'intrusion. Elle mesure la détection et la réponse, pas l'exhaustivité des failles.
• Le prérequis de la red team, c'est la maturité : sans SOC/EDR à éprouver et sans pentests déjà digérés, elle ne mesure rien que vous ne sachiez déjà.
• Le bug bounty complète, il ne remplace pas : paiement au résultat, aucune garantie de couverture, et un vrai coût de triage. À ouvrir après les pentests, pas à la place.
• Entre les exercices humains, l'automatisation travaille : EASM pour la surface exposée, scan pour les failles connues, détection automatisée en continu entre deux missions humaines.

Chez own2pwn, on couvre les niveaux qui concernent la grande majorité des PME et ETI : des missions de pentest web blackbox et whitebox menées par un pentester certifié OSWE (retest inclus), et une plateforme EASM qui surveille votre surface d'attaque en continu entre deux missions. Pour resituer le pentest dans la décision d'achat côté entreprise, pourquoi et quand le commander, voir le pentest en entreprise. Et si vous hésitez encore sur le bon format pour votre contexte, écrivez-nous : on vous dira honnêtement si vous avez besoin d'un pentest, ou si vous êtes mûr pour une red team.

Questions fréquentes sur la red team et le pentest