cyberviseurblog02-matrice-de-risque

Matrice de risque : se défendre contre quoi ?

Une matrice de risque ne te rend pas invulnérable. Elle te rend rationnel.

Il existe un type d'infopreneur qui dépense 3 000 € par an en outils de sécurité : scanner de vulnérabilités, WAF cloud haut de gamme, service de monitoring zero-day. Il fait ça parce qu'il a lu un article qui lui a fait peur et qu'il a cliqué sur le premier abonnement rassurant.

Pendant ce temps, sa clé API Stripe vit dans un fichier .env partagé sur Google Drive avec ses deux freelances. Son webhook de paiement n'est pas vérifié côté serveur. Son compte Stripe n'a pas de MFA.

Le jour où l'un de ses freelances se fait phisher, l'attaquant a accès à tout le tunnel de paiement en cinq minutes. Les 3 000 € de sécurité n'ont rien vu venir — ils regardaient ailleurs.

Ce n'est pas un cas inventé. C'est le scénario médian pour quelqu'un qui sécurise sans matrice.

Le mauvais réflexe : copier la matrice du voisin

Quand on cherche « comment sécuriser son site », on tombe sur des frameworks conçus pour les banques, les hôpitaux ou les entreprises CAC 40. NIST, ISO 27001, SOC 2 — des référentiels sérieux, construits pour des organisations avec un RSSI à temps plein, une équipe de réponse à incident, et des contraintes réglementaires spécifiques.

Le problème : tu n'as pas leur surface d'attaque, leur public cible, leurs adversaires, ni leur capacité de réponse.

Copier leur matrice, c'est comme installer un système d'alarme de musée dans un appartement de 50 m². Trop complexe à configurer, trop coûteux à maintenir, et il se déclenchera en faux positif deux fois par semaine jusqu'à ce que tu l'éteignes définitivement.

La méthode officielle française s'appelle EBIOS Risk Manager — c'est ce que l'ANSSI recommande. On en prend l'esprit (identifier les acteurs, les cibles, les scénarios), mais pas la lourdeur des 5 ateliers formels conçus pour des projets ministériels.

Ce dont tu as besoin, c'est une matrice de risque adaptée à ton contexte : quelqu'un qui fait tourner un business en ligne entre 0 et quelques dizaines de milliers d'euros de revenus mensuels, avec une équipe de 1 à 5 personnes, et une tolérance aux incidents limitée mais pas nulle.

Construire ta matrice en 4 axes

Une matrice de risque utile croise deux questions : qui pourrait t'attaquer et pourquoi (acteurs × cibles), et quel serait le dégât si ça arrive (impact × probabilité).

Axe 1 — Les acteurs : qui voudrait s'en prendre à toi ?

Pas d'angélisme, mais pas de paranoïa non plus. Les acteurs réels se répartissent en 5 catégories, du plus probable au moins probable pour ta situation.

Script kiddies — des bots automatisés qui scannent internet en permanence à la recherche de portes mal fermées. Ils ne te visent pas personnellement : ils ratissent large. Si ton serveur expose un port SSH sur le port 22 avec un mot de passe faible, ils le trouveront. Dans ce cas, c'est une question de jours, pas de mois. Probabilité : quotidienne sur n'importe quelle IP publique.

Opportunistes (botnets, campagnes de credential stuffing) — des acteurs légèrement plus organisés qui exploitent les fuites de bases de données. Si ton email et son mot de passe sont apparus dans une fuite Have I Been Pwned, ils vont les tester automatiquement sur Stripe, sur ton panel d'hébergement, sur ton compte GitHub. Probabilité : mensuelle à annuelle selon ton exposition publique.

Ciblés (concurrent, ex-prestataire, ex-employé) — quelqu'un qui te connaît et qui a une raison de t'en vouloir ou de te voler quelque chose. Ils savent où tu opères, quels outils tu utilises, parfois ils ont eu accès à tes systèmes. Probabilité : faible, mais l'impact peut être maximal parce qu'ils savent quoi chercher.

Insiders (freelance, sous-traitant, associé) — pas forcément malveillant, souvent négligent. Le freelance qui copie tes clés API dans son propre .env de test, l'associé qui partage ses accès avec quelqu'un d'autre. L'insider ne cherche pas à te nuire ; il crée involontairement une surface d'accès que quelqu'un d'autre va exploiter. Probabilité : constante dès qu'il y a plus d'une personne dans le projet.

Étatiques — services de renseignement, APT (groupes de cyberattaque sponsorisés par un état). Pour 95 % des lecteurs de cet article, cet acteur est hors scope. Il devient pertinent si tu opères dans des secteurs sensibles (défense, santé critique, infrastructure), si tu as une relation contractuelle avec une institution gouvernementale, ou si ton MRR dépasse les six chiffres avec une présence internationale notable. Avant ça, les investir dans la défense anti-APT est de l'argent gaspillé.

Axe 2 — Les cibles : qu'est-ce qu'on peut te voler ?

Ce que tu as à défendre n'est pas homogène. Certaines cibles valent beaucoup pour un attaquant, d'autres valent peu. Classe les tiennes dans ces 5 catégories.

Argent direct — ton compte Stripe, tes accès PayPal, les clés API de tes processeurs de paiement. C'est la cible la plus recherchée parce que la conversion en liquide est immédiate. Un webhook Stripe non vérifié ou une clé API en clair est une cible de classe maximale.

Données client (PII) — noms, emails, adresses, données de paiement. Valeur pour un attaquant : revente sur des marchés underground, levier pour du chantage, ou matière première pour des campagnes de phishing. Valeur juridique pour toi : une fuite t'expose au RGPD (notification obligatoire en 72h, amende possible).

Réputation — ton domaine, ton site, tes comptes réseaux sociaux. Un attaquant qui prend le contrôle de ton Twitter ou qui défigure ton site peut diffuser du contenu frauduleux en ton nom, annihiler la confiance de ta communauté, et te coûter des semaines de gestion de crise même si l'incident technique dure 20 minutes.

Capacité à opérer — DDoS qui rend ton site inaccessible, ransomware qui chiffre tes fichiers, suppression de ta base de données. L'objectif n'est pas de te voler quelque chose mais de te bloquer. Pour un business en ligne dont les revenus dépendent de la disponibilité, même 48 heures d'interruption peuvent être catastrophiques.

Levier vers d'autres — ta boîte mail, ton compte GitHub, ton gestionnaire de mots de passe. Ces comptes ne valent rien directement, mais ils servent de point d'entrée vers tout le reste. Ton email, c'est la réinitialisation de tous tes autres comptes. Ton GitHub, c'est potentiellement les clés de production si le CI/CD est mal configuré.

Axe 3 — L'impact : quel serait le coût réel ?

NiveauDéfinitionExemples concrets
Mineur (moins de 500 €)Incident contenu, récupérable en quelques heuresSpam depuis ton domaine, un token expiré à réinitialiser
Significatif (moins de 10 k €)Interruption de service, perte de revenus sur quelques joursDDoS 48h, fuite email liste clients, accès panel non autorisé
Grave (moins de 100 k €)Fuite de données RGPD, fraude Stripe non détectée sur 30 joursExfiltration base clients, vol de revenus mensuel entier
Critique (mort du business)Perte de domaine, fuite de données massives, atteinte irréparable à la réputationTransfert de domaine, fuite de mots de passe utilisateurs en clair
JuridiqueAmende RGPD, mise en cause contractuelle, action en justiceNon-notification d'une fuite dans les 72h, non-conformité contractuelle B2B

Quand tu évalues l'impact, pense au coût total : perte de revenus pendant l'incident + coût de remédiation (ton temps ou prestataire) + coût juridique potentiel + perte de clients liée à la réputation.

Axe 4 — La probabilité : à quelle fréquence ça arrive dans ta verticale ?

NiveauDéfinitionExemple
QuotidienneÇa se passe en permanence, tu es exposé dès que tu as une IP publiqueScans bots SSH, credential stuffing
MensuelleIncidents réguliers dans la communauté, risque matérialisé chez des projets similairesPhishing ciblé, fuite d'outil tiers
AnnuelleÇa arrive, mais c'est documenté comme événement notableCompromission de supply chain npm, breach hébergeur
Jamais observée dans ta verticaleThéoriquement possible, pas documenté à ton niveau de tailleAPT étatique, zero-day sur ta stack spécifique non public

Combine impact et probabilité pour chaque scénario : un impact critique avec probabilité quotidienne = urgence maximale. Un impact critique avec probabilité jamais observée = tu peux attendre.

L'arbitrage 80/20 : couvrir l'essentiel sans t'épuiser

La règle de Pareto s'applique à la sécurité autant qu'ailleurs. 80 % des incidents qui arrivent à des projets de ta taille proviennent de 20 % des vecteurs. Ces vecteurs sont connus, documentés, et parfaitement couvrables avec des toolkits standards.

C'est exactement le périmètre de la phase 01 Cyberviseur. Les 5 domaines transversaux correspondent chacun à un cluster de menaces à probabilité élevée :

  • Secret — tes clés API, mots de passe machine, tokens. Le vecteur numéro un de compromission pour les projets solo et petites équipes. Cible : acteurs opportunistes et insiders. Tactique MITRE : TA0006 (Credential Access).
  • Auth — qui peut s'authentifier sur quoi, avec quel facteur. Couvre le credential stuffing, le phishing, les accès non révoqués de freelances passés. Tactique MITRE : TA0001 (Initial Access).
  • Zero-Trust — pas de confiance par défaut entre tes services, entre toi et tes prestataires, entre ton code et son environnement. Limite la propagation latérale quand un premier accès est compromis. Tactique MITRE : TA0008 (Lateral Movement).
  • Secured-Run — l'hygiène d'exploitation continue : patches, rotation des clés, audit log, vérification des dépendances. Cible les opportunistes qui exploitent des CVE publiques. Tactique MITRE : TA0042 (Resource Development, côté attaquant — tu te défends en réduisant la surface exposée).
  • Crisis — que se passe-t-il quand tout ça échoue quand même. Runbook, backup testable, rollback documenté, notification RGPD. Impact : réduction du coût de l'incident quand il se produit malgré tout.

Les 5 toolkits du bundle B01 Foundation couvrent exactement ces 5 domaines, dans l'ordre logique de construction d'une infra sécurisée.

Matrice exemple : 3 profils concrets

Voici comment la matrice se remplit concrètement pour trois profils types. C'est un point de départ, pas un copier-coller : ta situation réelle a des nuances que seul toi peux évaluer.

CritèreInfopreneur solo (PDF 47 €)Vibe-coder SaaS B2CFounder Seed en cours
Acteurs prioritairesOpportunistes, insiders (freelance ponctuel)Opportunistes, script kiddiesOpportunistes, ciblés (concurrents), insiders (équipe)
Cible principaleArgent direct (Stripe) + réputationDonnées clients + capacité à opérerDonnées clients + réputation + levier (email, GitHub)
Impact max redoutéGrave (fraude Stripe) + juridique (RGPD liste email)Critique (perte de données utilisateurs) + juridiqueCritique (incident pendant due diligence)
Probabilité dominanteMensuelle (credential stuffing)Quotidienne (scans bots) + mensuelleMensuelle à annuelle (ciblé)
SecretClé Stripe, clé API mailingClé DB, clé Stripe, clés services tiersTout + clés d'équipe, accès investisseurs
AuthMFA Stripe + panel hébergeurMFA tout + gestion accès utilisateursMFA tout + politique accès équipe formalisée
Zero-TrustPas de partage de clés avec freelanceSegmentation services, pas de token inter-services en clairPolitique d'accès documentée, revue trimestrielle
Secured-RunRotation annuelle des clés StripeAlertes CVE, patches mensuels, rotation clés trimestrielleAudit mensuel, dépendances auditées en CI/CD
CrisisBackup Stripe + liste clients hors-ligne + runbook 1 pageRestore drill mensuel + notification RGPD prêtePlan de réponse formalisé + contact juridique identifié
Exclusions légitimesDéfense anti-APT, SOC 24/7, red teamRed team, threat intel avancéeAPT étatiques (probablement)
Toolkits B01 à prioriserT-01-02 (DNS/TLS), T-01-05 (Secrets)T-01-01, T-01-03, T-01-04, T-01-05Tous les 5, dans l'ordre

Le profil infopreneur solo peut démarrer avec deux toolkits et avoir couvert 70 % de sa surface réelle. Le vibe-coder SaaS a besoin des cinq. Le founder en levée aussi — et souvent dans un délai contraint parce que les investisseurs vérifient.

Réviser ta matrice tous les 6 mois

Une matrice figée est une fausse sécurité. Ton modèle de menace change quand ton business change.

Quand réviser :

  • Tu passes du B2C au B2B — tes cibles deviennent des entreprises avec leurs propres politiques de sécurité et des exigences contractuelles.
  • Tu passes de 0 à 1 employé ou freelance régulier — l'axe insider devient actif.
  • Tu passes d'un produit gratuit à payant — Stripe et les données de paiement entrent dans ton périmètre.
  • Tu franchis un seuil de revenus significatif (10 k€, 50 k€, 100 k€ MRR) — tu deviens une cible plus intéressante pour des acteurs ciblés.
  • Tu intègres un nouveau service tiers avec accès à tes données clients.
  • Tu sors dans la presse ou sur un grand compte réseaux sociaux — la notoriété augmente temporairement la probabilité d'attaques opportunistes.

Comment réviser :

Reprends ta matrice ligne par ligne. Pour chaque scénario : est-ce que le profil de l'acteur a changé ? Est-ce que la cible est plus ou moins exposée ? Est-ce que l'impact serait différent aujourd'hui ? Est-ce que la probabilité a évolué (nouvelle CVE dans ton stack, nouvelle tendance d'attaque documentée) ?

Une révision sérieuse prend 2 heures. Elle peut te faire économiser des semaines de gestion de crise.

Ce que ta matrice exclut légitimement

La dernière fonction d'une matrice de risque, et peut-être la plus libératrice, c'est de t'autoriser explicitement à ne pas faire certaines choses.

Il est parfaitement rationnel de décider : « Je n'investirai pas dans la défense anti-APT avant 100 k€ de MRR. » Il est rationnel de décider : « Un audit red team n'est pas dans mon périmètre avant d'avoir une équipe dédiée. » Il est rationnel de décider : « Je ne vais pas déployer un SOC 24/7 — si un incident arrive à 3h du matin, le plan de crise prévoit que ça attend 8h. »

Ces décisions ne sont pas de la négligence. Ce sont des arbitrages documentés, pris en connaissance de cause. La différence entre la négligence et l'arbitrage, c'est que l'arbitrage est écrit, daté, et révisable.

Documenter tes exclusions a un deuxième avantage : si un incident se produit sur un risque que tu avais exclu, tu pourras expliquer la décision plutôt que de paraître impréparé. Pour tes clients, tes partenaires, et potentiellement pour un juge ou une autorité de contrôle, la différence compte.

En résumé

Une matrice de risque n'est pas un document technique réservé aux grandes entreprises. C'est l'outil de base pour décider quoi sécuriser, dans quel ordre, et avec quel budget — sans te ruiner en outils inutiles ni laisser béantes les vulnérabilités qui comptent vraiment.

Elle tient en 4 axes : qui peut t'attaquer (acteurs), qu'est-ce qu'ils peuvent prendre (cibles), quel serait le dégât (impact), à quelle fréquence ça arrive (probabilité).

Pour la grande majorité des lecteurs de cet article, la matrice pointe vers les mêmes 5 priorités : secrets bien gardés, authentification forte, zéro confiance par défaut entre services, hygiène d'exploitation régulière, plan de crise documenté. C'est exactement ce que couvrent les 5 toolkits du bundle B01 Foundation.

Tu n'as pas besoin de tout couvrir. Tu as besoin de couvrir les bonnes choses, dans le bon ordre, en sachant pourquoi tu as choisi d'ignorer le reste.


Passer à l'action : Bundle B01 Foundation — 97 € — les 5 toolkits techniques qui couvrent les 5 domaines identifiés par ta matrice (VPS hardened, DNS+TLS, Next.js sécurisé, repo+auto-deploy, gestion des secrets). Voir aussi le détail des toolkits implémentés : T-01-02 DNS+TLS · T-01-04 GitHub+Coolify · T-01-05 Secrets Infisical.

Article suivant : P-01-03 — Les 12 attaques que tu vas vraiment subir → — maintenant que tu as ta matrice, voici les scénarios concrets qui la remplissent.

Aller plus loin : P-01-04 — Méthodologie MITRE ATT&CK appliquée → — comment les tactiques TA0001, TA0006, TA0008 se matérialisent sur ton infrastructure.


Cet article fait partie de la formation phase 01 du parcours Cyberviseur, livrée avec le bundle B01 Foundation. Si tu veux suivre les prochains modules, inscris-toi à la newsletter — un email tous les 15 jours, jamais de spam, désinscription en un clic.