Rendu_Securite_IoT-Jeep_Cherokee/SYNTHESIS_UPDATE.md

UPDATE BRIEF — Page de Synthèse "6 piliers de sécurité IoT"

Document complémentaire à PROJECT_BRIEF.md. Décrit la 6ème et dernière page du site, ainsi que les modifications mineures à apporter aux pages existantes pour la préparer.

À donner à Claude Code après que le site initial (5 pages) est en place.

---

0. Contexte

Le cours impose un framework canonique de 6 piliers de sécurité IoT. Le site doit se conclure sur une page de synthèse qui :

1. Présente ce framework officiel
2. Mappe chaque pilier aux échecs documentés dans les 5 pages précédentes (R1-R5, AMD-01 à 05, CVE-2015-5611, etc.)
3. Tire les leçons générales : la synthèse Jeep n'est qu'un cas particulier d'un modèle de raisonnement réutilisable.

Important : les contenus textuels existants ne changent pas. On ajoute uniquement :

• Un champ pillars[] à plusieurs entités (risques, AMDEC, problèmes, solutions)
• Des badges piliers discrets dans les pages existantes
• Une nouvelle page /synthese (ou onglet 06)

---

1. Référentiel canonique — Les 6 piliers

À utiliser verbatim, sans paraphraser, car c'est le framework du cours.

type RiskFamily = "Réseau" | "Sécurité" | "Humain" | "Logiciel";

type PillarKey =
  | "chiffrement"
  | "identites"
  | "segmentation"
  | "hardening"
  | "maj"
  | "supervision";

interface Pillar {
  key: PillarKey;
  label: string;
  icon: string;             // nom lucide-react
  color: string;            // hex
  riskFamilies: RiskFamily[];
  isTransversal: boolean;
  description: string;
}

const PILLARS: Pillar[] = [
  {
    key: "chiffrement",
    label: "Chiffrement",
    icon: "Lock",
    color: "#facc15",      // amber-400
    riskFamilies: ["Réseau", "Sécurité"],
    isTransversal: false,
    description:
      "Protection de la confidentialité et de l'intégrité des données en transit et au repos. TLS, chiffrement disque, gestion de clés (HSM/TPM), cryptographie à l'état de l'art.",
  },
  {
    key: "identites",
    label: "Identités et permissions",
    icon: "KeyRound",
    color: "#a78bfa",      // violet-400
    riskFamilies: ["Sécurité", "Humain"],
    isTransversal: false,
    description:
      "Identité unique et vérifiable pour chaque device, utilisateur et service. Authentification forte (mTLS, MFA, certificats), autorisations granulaires, suppression des credentials par défaut.",
  },
  {
    key: "segmentation",
    label: "Segmentation réseau",
    icon: "Network",
    color: "#22d3ee",      // cyan-400
    riskFamilies: ["Réseau", "Sécurité"],
    isTransversal: false,
    description:
      "Séparation logique des domaines de criticité. VLAN, zero-trust, gateways filtrantes, architecture en zones et conduits (IEC 62443 / ISO 21434). Empêcher la latéralité d'un attaquant après compromission.",
  },
  {
    key: "hardening",
    label: "Hardening (durcissement)",
    icon: "Shield",
    color: "#60a5fa",      // blue-400
    riskFamilies: ["Sécurité", "Humain", "Logiciel"],
    isTransversal: false,
    description:
      "Configuration sécurisée par défaut. Secure boot, signature de firmware, suppression des services non essentiels, principle of least functionality, désactivation des ports inutiles, durcissement OS et applications.",
  },
  {
    key: "maj",
    label: "Mises à jour sécurisées",
    icon: "RefreshCw",
    color: "#34d399",      // emerald-400
    riskFamilies: ["Logiciel", "Sécurité"],
    isTransversal: false,
    description:
      "Capacité à déployer rapidement et de manière vérifiable des patches sur l'ensemble de la flotte. OTA résistante (Uptane / TUF), signature des updates, rollback protection, gestion du cycle de vie.",
  },
  {
    key: "supervision",
    label: "Supervision",
    icon: "Eye",
    color: "#fb923c",      // orange-400
    riskFamilies: ["Réseau", "Sécurité", "Humain", "Logiciel"],
    isTransversal: true,   // ← SEULE COUCHE TRANSVERSALE
    description:
      "Détection, journalisation, monitoring et réponse à incident. SOC / V-SOC, IDS embarqué, télémétrie sécurité, threat intelligence partagée (ISAC), procédures d'incident testées. Couche transversale qui adresse toutes les familles de risques.",
  },
];

Familles de risques (à utiliser comme tags) :

• Réseau — vulnérabilités liées à la connectivité, au transport, à l'isolation
• Sécurité — vulnérabilités au sens cybersécurité technique stricte
• Humain — erreurs de configuration, ingénierie sociale, faute opérationnelle
• Logiciel — bugs, vulnérabilités applicatives, défauts de conception

---

2. Modifications des structures de données existantes

2.1 Ajout du champ pillars à 3 types

Modifier les interfaces TypeScript existantes :

interface Risk {
  // ... champs existants
  pillars: PillarKey[];     // ← AJOUT (1 à 3 piliers par risque)
}

interface AMDECRow {
  // ... champs existants
  pillars: PillarKey[];     // ← AJOUT (1 à 3 piliers par mode)
}

interface NamedItem {       // utilisé pour les solutions du Dossier
  // ... champs existants
  pillars?: PillarKey[];    // ← AJOUT optionnel
}

2.2 Tagging des risques (Page 2)

Modifier le fichier src/data/jeep.ts pour ajouter pillars à chaque risque :

Risque	Pillars	Justification
R1 Énumération flotte Sprint	["segmentation"]	L'attaque est rendue possible par l'absence d'isolation réseau Sprint
R2 RCE D-Bus port 6667	["identites", "hardening"]	Absence d'authentification (identités) + service exposé sur 0.0.0.0 (hardening)
R3 Reflashing V850 non signé	["hardening"]	Absence de secure boot et de signature firmware
R4 Contrôle freins/direction	["segmentation", "identites"]	Pas de gateway CAN (segmentation) + trames CAN non authentifiées (identités)
R5 Désactivation frein parking	["hardening", "supervision"]	Persistance non détectée + firmware non protégé

2.3 Tagging des modes AMDEC (Page 3)

ID	Composant	Pillars
AMD-01 APN Sprint sans isolation	["segmentation"]
AMD-02 Service D-Bus port 6667	["hardening", "identites", "chiffrement"]
AMD-03 V850 firmware non signé	["hardening"]
AMD-04 Architecture réseau interne plate	["segmentation"]
AMD-05 CAN bus sans authentification	["identites", "segmentation"]

2.4 Tagging optionnel des solutions du dossier (Page 1)

Solution	Pillars
Segmentation réseau interne (gateway CAN)	["segmentation"]
Firmware signé partout	["hardening"]
OTA sécurisées (Uptane)	["maj"]
Isolation au niveau opérateur	["segmentation"]
ISO/SAE 21434 & UNECE R155	["supervision", "hardening"]

---

3. Modifications mineures dans les pages existantes

3.1 Ajout d'un composant <PillarBadge> réutilisable

// src/components/ui/PillarBadge.tsx
"use client";

import { Lock, KeyRound, Network, Shield, RefreshCw, Eye } from "lucide-react";
import { PILLARS, PillarKey } from "@/data/pillars";

const ICONS = { Lock, KeyRound, Network, Shield, RefreshCw, Eye };

interface PillarBadgeProps {
  pillar: PillarKey;
  size?: "xs" | "sm";
  showLabel?: boolean;
}

export function PillarBadge({ pillar, size = "xs", showLabel = false }: PillarBadgeProps) {
  const p = PILLARS.find((x) => x.key === pillar);
  if (!p) return null;
  const Icon = ICONS[p.icon as keyof typeof ICONS];
  return (
    <span
      className="inline-flex items-center gap-1 px-1.5 py-0.5 border font-mono tracking-wider"
      style={{
        borderColor: p.color + "60",
        color: p.color,
        background: p.color + "12",
        fontSize: size === "xs" ? "9px" : "10px",
      }}
      title={p.label}
    >
      <Icon size={size === "xs" ? 9 : 11} />
      {showLabel && <span>{p.label.toUpperCase()}</span>}
    </span>
  );
}

3.2 Affichage des badges piliers

Page 2 — Risques : afficher les <PillarBadge> à côté du titre de chaque risque (à droite de R1, R2…), sans label (icône uniquement, tooltip au hover).

Page 3 — AMDEC : idem dans l'en-tête de chaque AMDECRow, à côté de l'ID AMD-01.

Page 1 — Dossier (solutions) : badge pilier en bas à droite de chaque <SolutionCard>.

Ces badges sont purement informatifs dans les pages existantes — ils annoncent la grille de lecture qui sera développée dans la synthèse finale.

---

4. NOUVELLE PAGE 6 — Synthèse 6 piliers

4.1 Route

/synthese  ou  /pilliers  (au choix, je préfère /synthese)

4.2 Onglet de navigation

Ajouter en 6ème position dans la <NavTabs> :

06 · Synthèse  ·  [6 piliers]

4.3 Structure de la page

┌────────────────────────────────────────────────────────┐
│ BRIEFING : "Synthèse 6 piliers et familles de risques"│
│   Phrase intro + 4 familles de risques en cartes      │
├────────────────────────────────────────────────────────┤
│ DIAGRAMME : les 6 piliers (visualisation)             │
│   5 piliers en cercle + Supervision au centre/à part  │
├────────────────────────────────────────────────────────┤
│ POUR CHAQUE PILIER (6 sections expandables) :         │
│   - Titre + icône + couleur                           │
│   - Familles de risques adressées (chips)             │
│   - "Statut chez Jeep" : verdict + score qualitatif   │
│   - Items liés (R1-R5, AMD-01..05) en chips cliquables│
│   - Leçon retenue                                     │
├────────────────────────────────────────────────────────┤
│ TABLEAU DE COUVERTURE                                  │
│   Une matrice piliers × items (X marque l'échec)      │
├────────────────────────────────────────────────────────┤
│ ENCADRÉ FINAL : Supervision est transversale          │
│   Pourquoi c'est important pédagogiquement            │
└────────────────────────────────────────────────────────┘

4.4 Contenu narratif — verbatim à utiliser

Briefing intro

Synthèse — 6 piliers de sécurité IoT et familles de risques

Chaque pilier adresse des familles de risques spécifiques. La supervision est la seule couche transversale du modèle : elle adresse les 4 familles à la fois (Réseau, Sécurité, Humain, Logiciel).

Cette page tire les leçons générales du cas Jeep Cherokee 2015 en mappant chaque vulnérabilité identifiée (dans les 5 pages précédentes) à l'un des 6 piliers manquants. C'est la grille de lecture qui transforme une étude de cas particulière en outil d'analyse réutilisable.

Familles de risques (4 cartes en haut)

┌─ RÉSEAU ─────────┐  ┌─ SÉCURITÉ ────────┐
│ Connectivité,     │  │ Cybersécurité     │
│ transport, RFC,   │  │ technique stricte │
│ isolation L2/L3   │  │ (auth, crypto,    │
│                   │  │ exploits)         │
└──────────────────┘  └───────────────────┘

┌─ HUMAIN ──────────┐  ┌─ LOGICIEL ────────┐
│ Erreurs de config,│  │ Bugs, vulns       │
│ ingénierie sociale│  │ applicatives,     │
│ faute opérationnel│  │ défauts conception│
└──────────────────┘  └───────────────────┘

Pilier 1 — Chiffrement

Familles adressées : Réseau, Sécurité Statut chez Jeep : ❌ Défaillant

Le service D-Bus exposé sur le port 6667 communiquait sans aucun chiffrement ni authentification depuis le réseau cellulaire Sprint. Les communications internes au véhicule (CAN bus, SPI vers le V850) étaient également en clair, par conception. La cryptographie n'était utilisée nulle part dans la chaîne d'attaque exploitée.

Items liés : R2 · AMD-02

Leçon retenue : Tout port ouvert sur Internet doit imposer du TLS mutuel. Toute communication entre composants critiques doit être chiffrée et authentifiée, même au sein d'un système supposé fermé (le CAN bus n'est plus fermé dès qu'il y a un modem cellulaire à proximité).

---

Pilier 2 — Identités et permissions

Familles adressées : Sécurité, Humain Statut chez Jeep : ❌ Défaillant

Le CVE-2015-5611 est littéralement intitulé "Missing Authorization". Le service D-Bus accepte des connexions non authentifiées (CVSS v2 : Au:N, v3 : PR:N). Le V850 accepte le reflashing sans vérifier l'identité du flasher. Les trames CAN ne portent aucune authentification — n'importe quel ECU compromis peut envoyer n'importe quelle commande à n'importe quel autre ECU.

Items liés : R2 · R4 · AMD-02 · AMD-05 · CVE-2015-5611

Leçon retenue : Le principe de moindre privilège n'est pas un concept SI seulement — il s'applique au hardware embarqué. Chaque actuateur du véhicule devrait n'accepter de commandes que de l'ECU légitimement habilité à le piloter, et cette habilitation doit être cryptographiquement vérifiable (cf. SecOC dans AUTOSAR).

---

Pilier 3 — Segmentation réseau

Familles adressées : Réseau, Sécurité Statut chez Jeep : ❌ Défaillant (le plus défaillant de tous)

Aucune isolation L2/L3 entre clients Sprint : 1.4M véhicules mutuellement adressables depuis n'importe quel téléphone du même opérateur. Architecture réseau interne au véhicule strictement plate, sans gateway filtrante entre l'infotainment (Uconnect) et le CAN bus de sécurité fonctionnelle (freins, direction). C'est ce pilier dont l'absence rend l'attaque exploitable à l'échelle.

Items liés : R1 · R4 · AMD-01 · AMD-04 · AMD-05

Leçon retenue : La segmentation est la mesure qui contient le rayon d'explosion d'une compromission. Sa rentabilité défensive est exceptionnelle : un seul investissement architectural neutralise potentiellement des dizaines d'attaques. C'est aussi la mesure que les frameworks récents (ISO 21434, IEC 62443) mettent au cœur de l'architecture.

---

Pilier 4 — Hardening (durcissement)

Familles adressées : Sécurité, Humain, Logiciel Statut chez Jeep : ❌ Défaillant

Service D-Bus configuré pour écouter sur 0.0.0.0 au lieu de 127.0.0.1 (configuration par défaut conservée en production). Microcontrôleur V850 acceptant n'importe quel firmware via SPI, sans secure boot ni vérification cryptographique. Les défauts de hardening sont cumulatifs — chacun ouvre une porte, et leur addition forme la chaîne d'attaque.

Items liés : R2 · R3 · R5 · AMD-02 · AMD-03

Leçon retenue : Le hardening est un travail ingrat mais payant : il consiste à appliquer le principle of least functionality partout. Désactiver chaque service non utilisé, fermer chaque port non requis, signer chaque binaire, n'accepter aucune configuration par défaut. Un système non durci offre 100 chemins d'attaque ; un système durci en offre 5 — et chacun nécessite réellement une vulnérabilité.

---

Pilier 5 — Mises à jour sécurisées

Familles adressées : Logiciel, Sécurité Statut chez Jeep : ❌ Critique — Absent

Pas de capacité OTA chez FCA en 2015. La remediation a nécessité un rappel physique de 1.4M véhicules via clés USB postales (juillet → septembre 2015). C'est ce pilier dont l'absence a transformé une vulnérabilité technique en désastre opérationnel — sans OTA, le RTO de la flotte explose à ~6 mois.

Items liés : Page Continuité (composant critique = infrastructure OTA)

Leçon retenue : Un système IoT sans capacité de mise à jour à distance sécurisée est, à terme, un système vulnérable. La capacité de patcher rapidement est une propriété de continuité d'activité avant d'être une propriété de sécurité. Standards à adopter : Uptane (automotive), TUF (générique).

---

Pilier 6 — Supervision

Familles adressées : Réseau, Sécurité, Humain, Logiciel (les 4) Statut chez Jeep : ❌ Absent Particularité : 🌐 Couche transversale

C'est le seul pilier qui adresse toutes les familles de risques à la fois. En 2015, aucune télémétrie de sécurité côté véhicule, aucun V-SOC chez FCA, aucune procédure de détection. Les chercheurs Miller & Valasek ont prévenu FCA volontairement — sans cette divulgation responsable, l'industrie aurait peut-être attendu un incident mortel pour réagir. L'Auto-ISAC (plateforme de partage d'IoC entre constructeurs) a été créé en août 2015, en réaction à cet incident.

Items liés : Tous (transversal). En particulier, scores AMDEC élevés en D (détection) : AMD-03 (D=8), AMD-04 (D=7), AMD-05 (D=8) — autant de défaillances invisibles avant impact.

Leçon retenue : La supervision est la condition de possibilité de tous les autres piliers. Sans elle, on ne sait pas que les autres piliers échouent — et donc on ne corrige rien. C'est aussi pourquoi elle est transversale dans le modèle : elle compense partiellement la défaillance ponctuelle des autres piliers en permettant la détection rapide et la réponse à incident.

4.5 Tableau de couverture (visualisation matricielle)

À afficher en bas de la page, avant la conclusion. Matrice piliers × items, où une croix indique que cet item illustre l'échec de ce pilier chez Jeep.

	R1	R2	R3	R4	R5	AMD-01	AMD-02	AMD-03	AMD-04	AMD-05	CVE
Chiffrement		✕					✕
Identités		✕		✕			✕			✕	✕
Segmentation	✕			✕		✕			✕	✕
Hardening		✕	✕		✕		✕	✕
MAJ
Supervision	✕	✕	✕	✕	✕	✕	✕	✕	✕	✕	✕

Observation visuelle attendue : la ligne Supervision est entièrement cochée (couche transversale = défaillance générale). La ligne MAJ est vide dans ce tableau parce que c'est un pilier organisationnel constructeur, pas un défaut visible dans un risque ou un mode de défaillance précis — il est traité séparément dans la page Continuité.

4.6 Conclusion finale (encadré marquant)

Pourquoi 5 piliers + 1 transversal, et pas 6 piliers à plat ?

Le modèle place volontairement la Supervision à part : c'est le seul pilier qui adresse simultanément les 4 familles de risques (Réseau, Sécurité, Humain, Logiciel). C'est aussi le seul pilier réactif — les cinq autres sont des mesures préventives. La supervision ne prévient pas une attaque, mais elle la détecte et permet d'y répondre.

Dans le cas Jeep, les 6 piliers étaient simultanément défaillants — c'est pourquoi l'attaque a pu réussir, persister 9 mois sans détection (entre la divulgation responsable à FCA et la publication à Black Hat), et coûter ~100M$ à remedier. Une organisation qui investirait correctement dans ne serait-ce qu'un seul des piliers — par exemple la supervision seule — aurait probablement détecté Miller & Valasek dès leurs premiers scans Sprint et stoppé l'incident bien avant 1.4M de véhicules rappelés.

Grille de lecture portable : ce modèle à 6 piliers se réapplique à n'importe quel système IoT — capteurs industriels, objets connectés grand public, infrastructure smart city, IoMT médical. C'est l'aboutissement pédagogique du dossier Jeep : un cas particulier transformé en méthode d'analyse réutilisable.

---

5. Composants UI à créer pour la page Synthèse

5.1 Composants principaux

// src/components/pillars/PillarsDiagram.tsx
// SVG hexagonal — 5 piliers autour, Supervision au centre (transversale)
// Hover sur un pilier → highlight + tooltip
// Recommandé: SVG inline avec viewBox, animation simple au hover

// src/components/pillars/PillarSection.tsx
// Section expandable par pilier
// En-tête: icône colorée + titre + chips familles + statut
// Body: narratif + chips items liés (R1, AMD-XX) + leçon

// src/components/pillars/CoverageMatrix.tsx
// Tableau piliers × items
// Cellules cochées (✕) avec couleur du pilier en background
// Possibilité de hover sur une cellule pour voir le détail

// src/components/pillars/RiskFamilyCard.tsx
// Carte d'une famille de risques (Réseau, Sécurité, Humain, Logiciel)
// 4 cartes en grille en haut de page

5.2 Architecture de fichiers

src/
├── app/
│   └── synthese/page.tsx       ← nouvelle route
├── components/
│   ├── pillars/
│   │   ├── PillarsDiagram.tsx
│   │   ├── PillarSection.tsx
│   │   ├── CoverageMatrix.tsx
│   │   └── RiskFamilyCard.tsx
│   └── ui/
│       └── PillarBadge.tsx     ← réutilisable dans toutes les pages
├── data/
│   ├── pillars.ts              ← PILLARS array + types
│   └── jeep.ts                 ← ajout du champ pillars[]
└── types/
    └── pillars.ts              ← PillarKey, RiskFamily, Pillar

5.3 Suggestion pour le diagramme central

Approche recommandée : hexagone SVG avec les 5 piliers préventifs en sommets (5 sur 6 sommets occupés), et la Supervision matérialisée par un anneau extérieur entourant l'ensemble — visuellement, elle « englobe » les autres.

Alternative plus simple : grille de 6 cartes (3×2), la carte Supervision marquée d'un badge spécial TRANSVERSAL et reliée visuellement aux autres par des lignes pointillées.

Choisis selon la complexité acceptable. La grille fonctionne très bien et reste lisible sur mobile ; le SVG hexagonal est plus impressionnant mais plus de boulot à rendre propre en responsive.

---

6. Données supplémentaires à ajouter dans jeep.ts

// Ajouter à l'objet CASES.jeep
synthesis: {
  pillarsStatus: {
    chiffrement: {
      status: "failed",  // "failed" | "partial" | "ok"
      severity: "major",
      relatedItems: ["R2", "AMD-02"],
      lesson: "Tout port ouvert sur Internet doit imposer du TLS mutuel...",
    },
    identites: {
      status: "failed",
      severity: "critical",
      relatedItems: ["R2", "R4", "AMD-02", "AMD-05", "CVE-2015-5611"],
      lesson: "Le principe de moindre privilège n'est pas un concept SI seulement...",
    },
    segmentation: {
      status: "failed",
      severity: "critical",
      relatedItems: ["R1", "R4", "AMD-01", "AMD-04", "AMD-05"],
      lesson: "La segmentation est la mesure qui contient le rayon d'explosion...",
    },
    hardening: {
      status: "failed",
      severity: "major",
      relatedItems: ["R2", "R3", "R5", "AMD-02", "AMD-03"],
      lesson: "Le hardening est un travail ingrat mais payant...",
    },
    maj: {
      status: "absent",  // ce n'est pas "défaillant", c'est carrément absent
      severity: "critical",
      relatedItems: [], // pas d'item AMDEC/Risk, traité dans la page Continuité
      relatedPage: "/continuite",
      lesson: "Un système IoT sans capacité de mise à jour à distance...",
    },
    supervision: {
      status: "failed",
      severity: "critical",
      isTransversal: true,
      relatedItems: "all",  // ← cas spécial, voir la matrice
      lesson: "La supervision est la condition de possibilité des autres piliers...",
    },
  },
}

---

7. Mise à jour de la checklist finale

Ajouter ces vérifications à la checklist du PROJECT_BRIEF.md :

• Route /synthese fonctionnelle (6ème onglet)
• PILLARS constant exporté avec les 6 piliers exacts du cours
• supervision marqué isTransversal: true dans les données
• Champ pillars ajouté à chaque risque (R1-R5) avec les bonnes valeurs (voir §2.2)
• Champ pillars ajouté à chaque AMDEC row (AMD-01 à 05) avec les bonnes valeurs (voir §2.3)
• <PillarBadge> affiché à côté de chaque risque (page 2) et chaque ligne AMDEC (page 3)
• Page Synthèse : briefing intro + 4 familles de risques en cartes
• Page Synthèse : diagramme central des 6 piliers (avec Supervision distinguée)
• Page Synthèse : 6 sections expandables (une par pilier) avec contenu narratif verbatim
• Page Synthèse : tableau de couverture piliers × items (matrice)
• Page Synthèse : conclusion finale dans un encadré marquant
• Chips items (R1, AMD-XX) cliquables → renvoient vers la page correspondante avec ancre
• Tooltip au survol de chaque PillarBadge (label complet)

---

8. Notes finales pour Claude Code

À faire en priorité

• Implémenter d'abord pillars.ts (data + types) et PillarBadge.tsx (composant réutilisable)
• Puis injecter le tagging dans jeep.ts pour les risques et AMDEC
• Ajouter le <PillarBadge> dans les pages existantes (page 2 et 3) — minimaliste, pas d'invasion visuelle
• En dernier, créer la page /synthese avec son contenu complet

À ne pas faire

• ❌ Ne pas modifier les hypothèses, mitigations, scores existants — on ne fait qu'ajouter les piliers
• ❌ Ne pas inventer d'autre pilier — il y en a exactement 6, ceux du cours
• ❌ Ne pas traduire les libellés des piliers en anglais (le contenu est en français)
• ❌ Ne pas ajouter de pilier en sus type "Privacy" ou "Supply chain" — ce n'est pas le framework du cours
• ❌ Ne pas marquer la MAJ comme défaillante sur la matrice de couverture page 2/3 — elle est absente, pas défaillante. Le tableau de couverture le reflète (ligne MAJ vide)

Si Claude Code propose des améliorations

Réponses pré-cadrées que tu peux donner :

• "On peut ajouter d'autres piliers ?" → Non, le framework est figé à 6.
• "On peut faire la diagramme animé ?" → Animation simple ok (fade-in, hover), mais pas de framework type Framer Motion.
• "On change la couleur d'un pilier ?" → Tu peux ajuster les hex pour que ça matche un design system existant, mais conserve une couleur distincte par pilier.
• "On fusionne Hardening et Chiffrement ?" → Non, ce sont deux piliers distincts dans le framework du cours.

---

Fin de l'update brief. Une fois ces ajouts terminés, le site couvre l'intégralité du framework pédagogique du cours (Dossier → Risques → AMDEC → CVE → Continuité → Synthèse 6 piliers).