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

Vous voulez ne plus jamais 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 — et un pentester cherche à y trouver le maximum de vulnérabilités exploitables dans le temps imparti, puis 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. Et 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 précisément 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 exactement 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. Autrement dit, la red team n'est plus seulement un exercice de luxe : pour certains secteurs régulés, elle devient une exigence, avec un formalisme précis.

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 incomparablement 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

Regardons les coûts de plus près. Un pentest se facture au TJM multiplié par le nombre de jours, et la fourchette 3 000 à 20 000 € HT couvre la grande majorité des missions web — 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 : sous 40 000 €, ce qu'on vous vend s'appelle en réalité un pentest avec un scénario de phishing. Les exercices TIBER-EU/TLPT du secteur financier dépassent couramment les six mois de bout en bout, threat intelligence comprise.

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. C'est un empilement, pas un menu où choisir un seul plat.

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 staging, credentials 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. L'idée — rejouer automatiquement les techniques d'exploitation sur le périmètre, en permanence — est détaillée dans pentest automatisé par IA 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 bonne question n'est pas « quel est le meilleur test ? » mais « où en suis-je ? ». 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, et on l'assume franchement. 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 3 à 12 jours, pour 3 000 à 20 000 € HT.
• La red team évalue une organisation : un scénario d'attaque réaliste, furtif, sur 4 à 12 semaines, pour 40 000 € et bien plus. 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, pentest continu pour rejouer l'exploitation à chaque déploiement.

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. 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, vraiment, vous êtes mûr pour une red team.