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 ?
| Niveau | Définition | Exemples concrets |
|---|---|---|
| Mineur (moins de 500 €) | Incident contenu, récupérable en quelques heures | Spam depuis ton domaine, un token expiré à réinitialiser |
| Significatif (moins de 10 k €) | Interruption de service, perte de revenus sur quelques jours | DDoS 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 jours | Exfiltration base clients, vol de revenus mensuel entier |
| Critique (mort du business) | Perte de domaine, fuite de données massives, atteinte irréparable à la réputation | Transfert de domaine, fuite de mots de passe utilisateurs en clair |
| Juridique | Amende RGPD, mise en cause contractuelle, action en justice | Non-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 ?
| Niveau | Définition | Exemple |
|---|---|---|
| Quotidienne | Ça se passe en permanence, tu es exposé dès que tu as une IP publique | Scans bots SSH, credential stuffing |
| Mensuelle | Incidents réguliers dans la communauté, risque matérialisé chez des projets similaires | Phishing ciblé, fuite d'outil tiers |
| Annuelle | Ça arrive, mais c'est documenté comme événement notable | Compromission de supply chain npm, breach hébergeur |
| Jamais observée dans ta verticale | Théoriquement possible, pas documenté à ton niveau de taille | APT é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ère | Infopreneur solo (PDF 47 €) | Vibe-coder SaaS B2C | Founder Seed en cours |
|---|---|---|---|
| Acteurs prioritaires | Opportunistes, insiders (freelance ponctuel) | Opportunistes, script kiddies | Opportunistes, ciblés (concurrents), insiders (équipe) |
| Cible principale | Argent direct (Stripe) + réputation | Données clients + capacité à opérer | Données clients + réputation + levier (email, GitHub) |
| Impact max redouté | Grave (fraude Stripe) + juridique (RGPD liste email) | Critique (perte de données utilisateurs) + juridique | Critique (incident pendant due diligence) |
| Probabilité dominante | Mensuelle (credential stuffing) | Quotidienne (scans bots) + mensuelle | Mensuelle à annuelle (ciblé) |
| Secret | Clé Stripe, clé API mailing | Clé DB, clé Stripe, clés services tiers | Tout + clés d'équipe, accès investisseurs |
| Auth | MFA Stripe + panel hébergeur | MFA tout + gestion accès utilisateurs | MFA tout + politique accès équipe formalisée |
| Zero-Trust | Pas de partage de clés avec freelance | Segmentation services, pas de token inter-services en clair | Politique d'accès documentée, revue trimestrielle |
| Secured-Run | Rotation annuelle des clés Stripe | Alertes CVE, patches mensuels, rotation clés trimestrielle | Audit mensuel, dépendances auditées en CI/CD |
| Crisis | Backup Stripe + liste clients hors-ligne + runbook 1 page | Restore drill mensuel + notification RGPD prête | Plan de réponse formalisé + contact juridique identifié |
| Exclusions légitimes | Défense anti-APT, SOC 24/7, red team | Red team, threat intel avancée | APT étatiques (probablement) |
| Toolkits B01 à prioriser | T-01-02 (DNS/TLS), T-01-05 (Secrets) | T-01-01, T-01-03, T-01-04, T-01-05 | Tous 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.