Dans une salle de réunion, un écran affiche une carte du système d’information. À gauche, une équipe déroule le scénario d’une attaque crédible : un message convaincant, un compte compromis, une porte entrouverte vers des données sensibles. À droite, une autre équipe cherche les traces laissées par l’intrusion, vérifie les alertes et décide quoi isoler. Entre les deux, ce n’est pas un jeu de rôle décoratif : c’est une manière de vérifier si l’organisation voit réellement ce qui lui arrive.
Le principe des red teams et des blue teams vient du monde de la sécurité, mais son intérêt dépasse largement la cybersécurité. Il formalise une idée simple, souvent négligée dans les organisations : une stratégie ne vaut pas seulement par sa cohérence sur un document, mais par sa capacité à résister à un adversaire, à un imprévu ou à une lecture hostile.
Dans un contexte où les entreprises dépendent de chaînes logicielles, de prestataires, de données et de décisions distribuées, cet exercice apporte une vertu rare : il remplace l’assurance par de l’apprentissage. La red team ne cherche pas à avoir raison ; elle cherche le point de rupture. La blue team ne cherche pas à sauver les apparences ; elle apprend à détecter, contenir et rebondir.
Deux couleurs, deux disciplines du réel
La red team adopte le regard de l’adversaire. En sécurité informatique, elle tente de pénétrer un périmètre autorisé en exploitant les failles techniques, les habitudes humaines et les angles morts des procédures. Elle peut examiner une configuration négligée, tester la résistance à l’ingénierie sociale, ou suivre le chemin qu’emprunterait un intrus après avoir obtenu un premier accès.
La blue team se place de l’autre côté : elle protège, surveille, enquête et répond. Son enjeu n’est pas de bâtir une forteresse imaginaire, mais de repérer les signaux utiles au milieu du bruit. Quels événements sont enregistrés ? Qui reçoit l’alerte ? Les équipes savent-elles distinguer une anomalie bénigne d’un incident sérieux ? Peuvent-elles couper un accès sans paralyser l’activité ?
Il serait tentant d’y voir une opposition simple entre attaquants et défenseurs. En réalité, une bonne red team a besoin d’une blue team solide pour que ses découvertes soient utiles. Et une blue team a besoin d’être mise à l’épreuve pour ne pas confondre conformité et capacité de réaction.
Le but n’est pas de démontrer qu’une organisation est vulnérable. Toute organisation l’est, à un endroit ou à un autre. Le but est de savoir comment elle découvre, comprend et réduit cette vulnérabilité.
Cette nuance change tout. Un exercice mal conçu devient une chasse au trophée : les uns veulent « entrer », les autres veulent prouver qu’ils auraient pu les arrêter. Un exercice mature produit au contraire une connaissance partagée du système et de ses fragilités.
Le test ne porte pas seulement sur la technologie
Une intrusion réussie raconte rarement une seule erreur de code. Elle révèle plutôt un enchaînement : une information trop accessible, une validation expédiée, un outil mal paramétré, une personne surchargée, une alerte ignorée parce qu’elle ressemblait à beaucoup d’autres. C’est pourquoi l’approche red team / blue team est aussi un test d’organisation.
La red team examine les surfaces d’exposition : applications, identités numériques, appareils, services externes, mais aussi annuaires, documentation publique, processus d’arrivée des collaborateurs ou relations avec les fournisseurs. Elle observe les écarts entre les règles écrites et les pratiques effectives. Une procédure excellente sur le papier est inutile si personne ne peut l’appliquer pendant une crise.
La blue team révèle, quant à elle, la qualité des mécanismes collectifs. Dispose-t-elle d’une visibilité suffisante ? Les responsabilités sont-elles claires ? Les équipes techniques, juridiques, métiers et de communication savent-elles quand se parler ? Existe-t-il un protocole d’escalade compréhensible sous pression ?
Cette lecture systémique est précieuse parce qu’elle évite le réflexe du bouc émissaire. Lorsqu’un test réussit, la question n’est pas seulement : « qui a commis l’erreur ? » Elle devient : « qu’est-ce qui rendait cette erreur probable, difficile à voir ou impossible à corriger à temps ? »
Quand le désaccord devient une infrastructure de sécurité
La valeur culturelle du modèle se situe peut-être là. Une red team institutionnalise le désaccord informé. Elle donne un mandat clair à des personnes chargées de mettre en doute une décision, une architecture ou un scénario dominant. Dans beaucoup d’entreprises, ce rôle existe déjà de manière informelle : le collègue qui pose la question gênante, l’ingénieure qui demande ce qui se passera si un fournisseur disparaît, le juriste qui relève une dépendance mal documentée.
Mais l’informel a ses limites. Sans cadre, la contradiction peut être perçue comme du pessimisme, de la défiance ou une attaque personnelle. Le dispositif red team transforme cette énergie en travail utile. Il déplace le débat : on ne juge plus l’intention des personnes, on examine la robustesse d’une hypothèse.
Cette pratique peut s’étendre à d’autres domaines :
- avant le lancement d’un produit, une équipe peut imaginer les usages détournés, les incompréhensions et les effets indésirables ;
- avant une décision stratégique, elle peut chercher les hypothèses cachées qui rendent le plan séduisant ;
- avant un changement d’outil, elle peut simuler les contournements que les équipes inventeront pour continuer à travailler ;
- avant une communication sensible, elle peut anticiper la lecture d’un client mécontent, d’un concurrent ou d’un régulateur.
On parle alors parfois de pré-mortem : non pas prédire l’avenir, mais se placer mentalement après l’échec pour en reconstituer les causes plausibles. La différence avec une critique classique est importante. Il ne s’agit pas d’énumérer des objections abstraites, mais d’élaborer des scénarios concrets, vérifiables et hiérarchisables.
La « purple team », ou le moment où l’on apprend ensemble
Le vocabulaire des couleurs peut sembler martial. Il devient pourtant plus fécond lorsqu’il mène à la coopération. La purple team désigne moins une troisième équipe qu’une pratique de rapprochement entre l’attaque et la défense. Au lieu d’attendre la fin d’un exercice pour remettre un rapport, les participants partagent certains apprentissages au fil de l’eau.
La red team montre par exemple comment elle a exploité une faiblesse. La blue team vérifie immédiatement si ses outils auraient pu détecter cette séquence et ajuste ses règles de surveillance. L’enjeu n’est plus uniquement de mesurer un niveau de protection ; il est d’augmenter la capacité d’apprentissage.
Cette approche évite deux pièges. Le premier est le rapport qui dort dans un dossier, rempli de recommandations raisonnables mais jamais intégrées aux priorités. Le second est le perfectionnisme défensif : vouloir tout couvrir, tout journaliser, tout verrouiller, jusqu’à produire une sécurité impraticable.
Une organisation ne peut pas supprimer tous les risques. Elle doit choisir ceux qu’elle accepte, ceux qu’elle réduit et ceux qu’elle surveille avec une attention particulière. La purple team aide à faire ces arbitrages à partir d’observations, plutôt qu’à partir de principes généraux.
Le danger d’un exercice qui devient un spectacle
Le modèle est puissant, mais il peut être mal employé. Une red team qui cherche à humilier les équipes de défense produit de la rétention d’information. Une blue team qui dissimule ses faiblesses pour éviter le reproche prive l’organisation d’un diagnostic utile. Dans les deux cas, la performance locale détruit l’intelligence collective.
Un autre risque consiste à privilégier les scénarios spectaculaires. Obtenir un accès très sensible peut être techniquement impressionnant, mais une succession de défauts ordinaires est parfois plus instructive : des droits qui persistent après un changement de poste, des sauvegardes peu testées, une alerte sans destinataire clairement désigné, une dépendance à une seule personne.
Le bon exercice est proportionné au contexte et encadré. Son périmètre est explicite, ses règles d’engagement sont connues, les activités critiques sont protégées et un mécanisme permet d’interrompre le test en cas de danger opérationnel. Surtout, les résultats doivent déboucher sur des décisions : corriger, accepter un risque, modifier une procédure, entraîner une équipe, ou revoir une priorité.
Installer un réflexe adversarial sans créer une culture de la méfiance
Il n’est pas nécessaire de disposer d’une unité dédiée pour adopter l’esprit red team / blue team. Une petite organisation peut commencer par un rituel simple : sur un projet important, confier à une personne ou à un groupe distinct la tâche de chercher les défaillances plausibles. Cette fonction doit être temporaire, explicite et protégée de la logique hiérarchique.
Quelques règles permettent de préserver la qualité du dispositif :
- attaquer les hypothèses, jamais les individus ;
- partir de scénarios réalistes plutôt que de catastrophes vagues ;
- documenter les signaux qui auraient permis de détecter le problème plus tôt ;
- classer les corrections selon leur impact et leur faisabilité ;
- revenir sur les décisions prises pour vérifier que l’apprentissage s’est réellement traduit dans les pratiques.
Le mot important est résilience. Une organisation résiliente n’est pas celle qui prétend être invulnérable. C’est celle qui sait qu’elle sera surprise, qui détecte assez tôt, qui limite les dégâts et qui améliore ses défenses sans attendre l’incident suivant.
Red team, blue team : derrière les couleurs, il y a donc une philosophie du travail. Elle invite à considérer chaque plan comme une hypothèse, chaque contrôle comme un mécanisme à éprouver, chaque désaccord bien formulé comme une chance d’éviter une erreur coûteuse. À l’heure où les organisations cherchent de la certitude, elle propose mieux : une méthode pour rester lucide.
