Un adversaire indépendant que votre équipe ne peut pas s’auto-évaluer.

Un exercice red team commence par une seule décision : que cherchons-nous à atteindre, et qu’est-ce qui prouve que nous y sommes parvenus ? L’objectif est un résultat métier concret — l’accès à un magasin de données précis, le contrôle d’un système de paiement, un point d’appui en production — et non un décompte de vulnérabilités. Tout le reste en découle. Nous convenons des systèmes et des identités dans et hors du périmètre, des techniques autorisées, des équipes de détection mises ou non dans la confidence, et des règles qui empêchent un test maîtrisé de devenir un incident. Un exercice red team cadré sur un objectif réel vous dit ce qu’un scanner ne dira jamais : si le chemin existe seulement, et si quelqu’un le remarquerait.

Le périmètre est aussi ce qui distingue un exercice red team d’un test d’intrusion. Un test d’intrusion procède en largeur — trouver et démontrer les vulnérabilités sur un périmètre convenu. Un red team procède en profondeur, guidé par l’objectif : il peut ignorer dix constats pour enchaîner les trois qui mènent réellement au but, car la question porte sur votre détection et votre réponse, pas sur votre nombre de failles. La plupart des équipes y arrivent après qu’un test d’intrusion a déjà déblayé le terrain évident. La progression est délibérée : évaluation et test d’intrusion d’abord, red teaming une fois qu’il existe une détection et une réponse à mettre à l’épreuve.

La plupart des missions débutent par une simulation d’attaque orientée objectif — un test à l’aveugle qui vérifie si le chemin existe et si votre équipe le voit. Lorsque le but est l’amélioration plutôt qu’un verdict, un exercice de purple team rejoue les mêmes techniques aux côtés de vos défenseurs, pour que les détections soient construites et affinées au fil de l’eau plutôt que rédigées après coup. Les deux ne s’opposent pas : beaucoup de programmes mènent d’abord une simulation d’attaque pour révéler les lacunes, puis un purple team pour les combler.

Pour les entités régulées, la mission devient un test d’intrusion avancé guidé par la menace — des scénarios fondés sur le renseignement et alignés sur TIBER-EU, CBEST ou le régime TLPT de DORA, exécutés sous contrôle et restitués dans la forme qu’attend votre superviseur. Ce test d’intrusion avancé partage la méthode du red team, mais ajoute une phase de renseignement sur la menace en amont et une traçabilité des preuves conçue pour une transmission réglementaire. Lorsque cette exigence vient de DORA, notre préparation DORA et les tests forment un seul programme. Nous vous dirons honnêtement quelle variante convient lors du cadrage — une simulation à l’aveugle n’a aucune valeur face à une équipe qui n’a encore rien pour détecter.

Dans le périmètre convenu, une mission s’appuie sur les techniques qu’utiliserait une véritable intrusion — chaînées vers l’objectif, et non cataloguées pour elles-mêmes :

Avant tout début, nous convenons des règles par écrit. Ce ne sont pas des clauses de style — ce sont elles qui rendent la mission sûre et utile :

Périmètre écrit. L’objectif, les systèmes et identités dans et hors champ, et les techniques approuvées — le tout signé avant l’exécution.

Limites de sécurité. Des contraintes explicites pour protéger la production, les données et les personnes, pour qu’un test ne devienne jamais un incident.

Techniques approuvées. Les méthodes autorisées pour cette mission, et celles délibérément exclues.

Notification et escalade. Un contact nommé et un chemin d’escalade, pour que tout élément sensible atteigne immédiatement la bonne personne.

Conditions d’arrêt. Les déclencheurs qui suspendent ou mettent fin à la mission, et un bouton d’arrêt que votre côté peut actionner à tout moment.

Calendrier. Une exécution en heures ouvrées ou hors heures convenue en amont, selon ce qui rend le test réaliste sans créer de risque indu.

Nous gardons le red teaming délibérément sobre. Il n’y a pas de mise en scène de hacker, pas de perturbation incontrôlée, et aucune ingénierie sociale qui n’ait pas été explicitement autorisée dans les règles d’engagement. Le but est de trouver où le processus, la vigilance et la détection se brisent pour que vous puissiez combler l’écart — pas de prendre des individus en défaut ni de produire un récit spectaculaire.

Nous prenons aussi soin de ne pas surévaluer. Un red team est une simulation maîtrisée sous contraintes convenues ; c’est une preuve solide de la tenue de votre détection et de votre réponse, mais ce n’est pas un attaquant réel sans contraintes, et nous ne prétendrons pas le contraire. Lorsqu’un régulateur exige des tests guidés par le renseignement sur la menace — TIBER-EU, CBEST ou le régime de tests guidés par la menace de DORA (TLPT) — nous alignons la mission sur ce cadre et en rendons compte dans une forme attendue par votre superviseur.

Nous facturons au forfait, par tranche selon l’objectif et la taille de l’environnement, et nous vous communiquons la tranche au cadrage avant tout engagement — sans surprise de taux journalier ni intérêt à gonfler les heures. L’échange de cadrage est gratuit ; tout ce qui suit est une mission définie et facturée.

Nous ne vendons aucun outil et ne percevons aucune commission d’éditeur, de sorte que la mission ne porte d’autre intention que de répondre à votre vraie question. Si vous travaillez avec un budget, indiquez-le au cadrage et nous serons clairs sur l’objectif qu’il couvre.