Les quatre premiers blocs répondaient à une question : comment empêcher une attaque de réussir. Ce chapitre en pose une autre, plus réaliste : que faire quand elle a réussi malgré tout ? La question n'est pas défaitiste. Aucune organisation n'empêche tous les incidents, et la maturité en sécurité ne se mesure pas au nombre d'attaques bloquées — invérifiable — mais au temps mis à détecter et à contenir celle qui passe. Les meilleures s'en tirent en heures ; la moyenne mondiale se compte encore en semaines.

La compétence de ce chapitre est autant une question de méthode et de sang-froid que de technique. La première erreur d'un incident n'est presque jamais technique : c'est une action précipitée qui détruit les preuves ou aggrave la situation.

Le cycle de réponse

Le modèle de référence (NIST SP 800-61) décompose la réponse en six phases. L'essentiel est de comprendre que ce n'est pas une liste mais une boucle : la dernière phase réalimente la première.

Deux phases sont systématiquement sous-estimées, et ce sont les deux extrémités.

La préparation décide de tout le reste. On ne peut pas analyser des journaux qu'on n'a pas collectés (chapitre 4), ni restaurer une sauvegarde qu'on n'a jamais testée, ni joindre en pleine nuit un contact qu'on n'a pas noté. La réponse à incident se joue en grande partie avant l'incident — c'est la même logique que le durcissement.

Le retour d'expérience referme la boucle. Un incident dont on ne tire aucune leçon se répétera à l'identique. Il ne s'agit pas de chercher un coupable — une culture qui punit fait taire ceux qui détectent — mais de corriger la cause racine : pourquoi ce point d'entrée existait, pourquoi il n'a pas été vu plus tôt.

Confiner sans détruire

C'est la décision la plus délicate, et le nœud de l'exercice de ce chapitre. Face à un poste compromis, le réflexe est de l'éteindre. C'est presque toujours une faute.

Éteindre coupe l'attaque, mais détruit la mémoire vive — et avec elle les clés de chiffrement, les processus en cours, les connexions réseau actives, et le maliciel qui n'existe parfois qu'en RAM sans jamais toucher le disque. On perd l'essentiel de ce qui aurait permis de comprendre.

La bonne action est d'isoler : couper le réseau — débrancher le câble, basculer le VLAN — en laissant la machine allumée. La propagation et l'exfiltration s'arrêtent, l'état est préservé. Débrancher le câble, pas la prise. Le confinement peut aussi être logique : désactiver un compte compromis, bloquer une adresse, révoquer un jeton (chapitre 3).

Collecter les preuves, et la chaîne de conservation

Une fois la machine isolée mais vivante, on collecte, dans l'ordre de volatilité : du plus fugace au plus durable. La mémoire vive d'abord, car elle disparaît à l'extinction ; puis l'état réseau ; puis l'image disque ; puis les journaux déjà centralisés.

Deux principes gouvernent la collecte, et ils sont non négociables si les preuves doivent un jour avoir une valeur — en interne comme devant un tribunal.

• Travailler sur des copies. On analyse une image, jamais l'original, dont on fige une empreinte cryptographique (chapitre 2) pour prouver qu'il n'a pas changé.
• Tenir la chaîne de conservation. Chaque preuve est tracée : quoi, quand, par qui, où stockée, à qui transmise, avec quelle empreinte. Une rupture de cette chaîne rend la preuve contestable — elle ne prouve plus rien, parce qu'on ne peut plus exclure qu'elle ait été modifiée entre-temps.

C'est ici que la journalisation du chapitre 4 rend son dû : des journaux centralisés, horodatés et à intégrité protégée, hors de portée de l'attaquant, sont la matière première de toute l'analyse. Un journal resté sur la machine compromise a probablement été effacé — l'effacement des traces est une étape standard de l'intrusion.

Analyser : journaux, artefacts, mémoire

L'analyse cherche à répondre à quatre questions : par où l'attaquant est entré, quand, jusqu'où il est allé, et ce qu'il a pris ou fait. C'est une reconstitution de la chaîne d'attaque du chapitre 1, à rebours.

Trois sources, complémentaires :

• Les journaux — le point de départ, s'ils ont été collectés. Le SIEM (chapitre 6) les corrèle : une authentification échouée est banale, mais cent échecs suivis d'une réussite, d'une création de compte, puis d'un transfert sortant dessinent l'intrusion complète.
• Les artefacts du système — ce que l'activité laisse sur le disque : traces d'exécution de programmes, tâches planifiées, clés de démarrage, historique de commandes, journaux applicatifs. C'est là que se lisent la persistance et l'escalade des chapitres 4 et 3.
• La mémoire — l'analyse (par exemple avec Volatility) révèle ce que le disque ne montre pas : processus cachés, code injecté, connexions actives, clés en clair. C'est précisément ce qu'une extinction aurait effacé, et la raison de tout ce qui précède.

L'objectif concret de l'analyse est de produire des indicateurs de compromission — empreintes, adresses IP, noms de domaine, comptes — qui permettent de chercher la même menace ailleurs dans le système d'information. Un poste compromis est rarement seul : le confinement n'est réellement complet qu'après avoir mesuré l'étendue par ces indicateurs.

Le rapport d'incident

L'analyse la plus fine ne vaut que si elle est communiquée — c'est le pont vers le chapitre 10 et la gouvernance. Un rapport d'incident sert trois publics à la fois, et un bon rapport les distingue nettement :

• la direction, qui a besoin de l'impact, du périmètre et des décisions à prendre — pas de détails techniques ;
• les techniciens, qui ont besoin de la chronologie précise, des indicateurs et des correctifs ;
• le juridique et la conformité, qui ont besoin des faits datés, des preuves et des éléments déclenchant d'éventuelles obligations de notification — celles du RGPD, dans un délai serré, que le chapitre 10 détaille.

Un bon rapport est factuel et daté : ce qui est établi, ce qui est probable, ce qui est inconnu, sans confondre les trois. Sa dernière section — les recommandations — est ce qui transforme un incident subi en amélioration durable, et referme la boucle du cycle.

À vous

L'exercice place la décision au bon endroit : elle n'est pas technique mais d'ordre. Un poste est compromis, sept actions sont sur la table dans le désordre. Rendez la bonne séquence — et surtout, justifiez pourquoi « éteindre le poste » n'est pas la bonne première réaction, alors qu'elle couperait pourtant l'attaque.

C'est le réflexe que ce chapitre vise à corriger : en réponse à incident, la préservation des preuves et l'ordre des actions priment sur la vitesse de coupure.

// 8 h 47. Un poste comptable présente une consommation CPU anormale et une
// connexion sortante inhabituelle. Vous êtes de permanence. Sept actions
// possibles sont sur la table, dans le DÉSORDRE.

const ACTIONS = {
  A: "Éteindre le poste immédiatement pour couper l'attaque",
  B: "Isoler le poste du réseau (câble/VLAN) sans l'éteindre",
  C: "Capturer la mémoire vive (RAM) et une image disque du poste",
  D: "Prévenir le responsable et consigner l'heure de chaque action",
  E: "Rechercher les mêmes indicateurs (IP, empreintes) sur les autres postes",
  F: "Réinstaller le poste et le rendre à l'utilisateur",
  G: "Rédiger le retour d'expérience et corriger la cause racine",
};

// Le cycle de réponse à incident (NIST) :
//   préparation → détection → confinement → éradication → rétablissement →
//   retour d'expérience
//
// ── À VOUS ──────────────────────────────────────────────────────────────────
// Rendez l'ordre correct des actions (ex. ["D","B",...]). Deux pièges :
//   - l'ordre entre A, B et C n'est pas indifférent ;
//   - une action doit ACCOMPAGNER toutes les autres, pas s'insérer une fois.

const ordre = []; // à compléter

// ── Vérification ────────────────────────────────────────────────────────────
const CORRECT = ["D", "B", "C", "E", "F", "G"];
console.log("Votre ordre :", ordre.join(" → "));
console.log("Attendu     :", CORRECT.join(" → "));
const ok = ordre.length === CORRECT.length && ordre.every((x, i) => x === CORRECT[i]);
console.log(ok ? "✓ correct" : "✗ à revoir — et surtout : pourquoi PAS A ?");

// Ordre correct : D, B, C, E, F, G — et A est un PIÈGE.
const ordre = ["D", "B", "C", "E", "F", "G"];

// ── Pourquoi cet ordre ─────────────────────────────────────────────────────
//
// D en PREMIER, et en continu. Prévenir et CONSIGNER n'est pas une étape
// isolée : chaque action, avec son heure et son auteur, alimente la chaîne
// de conservation. Un incident non documenté au fil de l'eau est
// irrécupérable — pour l'analyse comme pour une éventuelle procédure.
//
// B avant C avant A. C'est le cœur de l'exercice :
//   - ISOLER (B) stoppe l'exfiltration et le déplacement latéral SANS
//     détruire l'état : le poste reste allumé, la mémoire intacte.
//   - ÉTEINDRE (A) couperait aussi l'attaque, mais DÉTRUIRAIT la mémoire
//     vive : clés de chiffrement, processus en cours, connexions,
//     éventuel maliciel qui ne vit qu'en RAM. On perd l'essentiel des
//     preuves. C'est l'erreur réflexe la plus commune.
//   - CAPTURER (C) : la RAM D'ABORD (elle est volatile), puis le disque.
//     C'est l'ordre de volatilité — on collecte du plus fugace au plus
//     durable.
//
// E : chercher les indicateurs (IP, empreintes) AILLEURS. Un poste touché
// est rarement seul ; le confinement n'est complet que si l'on a mesuré
// l'étendue réelle. C'est l'articulation avec le chapitre 1 : on reconstitue
// la chaîne d'attaque pour savoir jusqu'où elle est allée.
//
// F : rétablir — mais seulement APRÈS éradication de la cause. Réinstaller un
// poste sans avoir compris ni fermé le point d'entrée, c'est se faire
// recompromettre par le même chemin.
//
// G : le retour d'expérience n'est pas une formalité. C'est lui qui referme
// la boucle du cycle (retour vers "préparation") : corriger la cause racine,
// pour que l'incident suivant du même type n'ait pas lieu. Un incident dont
// on ne tire aucune leçon se répétera.
//
// La règle à retenir : en réponse à incident, l'ORDRE et la PRÉSERVATION des
// preuves priment sur la vitesse de coupure. Débrancher le câble, pas la
// prise.

Ce que la suite en fait

Ce chapitre a traité l'incident individuel : le détecter, le contenir, l'analyser, en tirer les leçons. Le chapitre 10 change d'échelle. Il pose la question qui précède logiquement tout incident, mais qu'on ne comprend qu'après en avoir vécu — sur DVWA, en TP — plusieurs : comment décider, à l'avance et à l'échelle de l'organisation, ce qu'on protège, contre quoi, et avec quels moyens ?

Les obligations de notification effleurées ici y deviennent un cadre juridique complet ; le retour d'expérience s'y élargit en continuité d'activité ; et le facteur humain — souvent le point d'entrée réel de l'incident que vous venez d'analyser — y prend la place centrale qu'il mérite.

À retenir

Nous voici au bout du parcours, et à l'endroit qui n'avait aucun sens au début. Une analyse de risque présentée au premier cours aurait été un exercice de vocabulaire ; présentée ici, après que vous avez exploité de vos mains une injection SQL et un dépassement de tampon, après avoir monté un homme du milieu et analysé un incident, elle range enfin quelque chose de concret. C'est la raison pour laquelle ce bloc ferme le semestre.

Le changement de perspective est complet. Les neuf chapitres précédents raisonnaient technique : une faille, un correctif. Celui-ci raisonne organisation : des moyens finis, des risques innombrables, et des décisions qui appartiennent au métier, pas à l'équipe de sécurité. Deux idées le traversent, et ce sont les plus importantes du cours :

La sécurité est un processus, pas un produit — et pas un état qu'on atteindrait une fois. Et son maillon décisif est presque toujours humain.

Analyser le risque : EBIOS, ISO 27005

Le chapitre 1 a posé la grille — actif, vulnérabilité, menace, risque — et la formule risque ≈ vraisemblance × gravité. Les méthodes d'analyse de risque organisent cette estimation pour qu'elle soit reproductible et défendable, plutôt que laissée à l'intuition.

EBIOS Risk Manager (ANSSI) et ISO 27005 partagent la même démarche : recenser les actifs et leur valeur, identifier les menaces et les scénarios qui les réalisent, estimer vraisemblance et gravité sur des échelles à quatre niveaux, en déduire un niveau de risque, puis décider d'un traitement. EBIOS insiste particulièrement sur les scénarios stratégiques — qui vous en veut, avec quels moyens, pour atteindre quoi — ce qui reconnecte l'analyse aux profils d'attaquants du chapitre 1.

Le point à retenir n'est pas la méthode mais son produit : un registre des risques priorisé, et pour chacun l'un de quatre traitements possibles :

Trois nuances décident de tout, et elles sont l'objet de l'exercice de ce chapitre.

On priorise par le risque, jamais par la gravité technique. Une injection SQL sur un site vitrine sans données passe après le départ mal géré d'un administrateur — même si la première a un « score » plus impressionnant. Le contexte commande, exactement comme au chapitre 1.

Le transfert ne transfère pas tout. Une assurance couvre l'impact financier, pas l'atteinte à la réputation ni la responsabilité juridique. On reste responsable de ses données.

Accepter est une décision légitime — l'ignorer ne l'est pas. Le risque zéro n'existe pas ; après traitement, il reste toujours un risque résiduel. L'accepter en connaissance de cause, par une décision signée de la direction, est du bon management. Ne pas le voir est une faute. Le rôle du responsable sécurité est d'éclairer cette décision, pas de la prendre seul — la sécurité arbitre entre des propriétés qui s'opposent (chapitre 1), et cet arbitrage appartient au métier.

Piloter : ISO 27001 et la politique de sécurité

Là où EBIOS analyse, ISO 27001 organise. C'est la norme internationale du système de management de la sécurité de l'information (SMSI), et sa logique tient dans une boucle d'amélioration continue — planifier, déployer, contrôler, corriger — la même que le cycle de réponse à incident du chapitre 9, appliquée à toute la sécurité.

Concrètement, elle exige une politique de sécurité : un ensemble de règles écrites, approuvées par la direction, qui disent ce qui est attendu — usage acceptable, gestion des accès (chapitre 3), classification des données, réponse à incident (chapitre 9), relations avec les tiers (chaîne d'approvisionnement, chapitre 8). Une politique n'a de valeur que si elle est vécue : appliquée, contrôlée, révisée. Un classeur de politiques que personne ne lit est un risque de plus, pas une mesure — il donne l'illusion de la maîtrise.

Le SBOM du chapitre 8 et la revue des habilitations du chapitre 3 trouvent ici leur place : ce sont des instruments de gouvernance autant que des mesures techniques. La sécurité à l'échelle, c'est d'abord savoir ce qu'on a — inventaire des actifs, des composants, des accès — avant de savoir le protéger.

RGPD et obligations de notification

La sécurité rencontre le droit dès qu'il y a des données personnelles. Le RGPD — et, dans plusieurs États africains, des lois nationales de protection des données inspirées des mêmes principes et de la convention de Malabo (chapitre 1) — impose des obligations qui changent la manière de concevoir un système.

Les principes structurants pour un informaticien :

• minimisation : ne collecter que le nécessaire — c'est aussi de la réduction de surface d'attaque (chapitre 1) : la donnée qu'on n'a pas collectée ne peut pas fuir ;
• finalité : n'utiliser la donnée que pour l'usage annoncé ;
• sécurité : protéger par des mesures appropriées — tout ce cours ;
• protection dès la conception et par défaut : la sécurité et la vie privée pensées au départ, pas ajoutées après.

L'obligation qui a le plus d'effet opérationnel est la notification de violation de données. En cas de fuite touchant des données personnelles, le responsable de traitement doit notifier l'autorité de contrôle dans les 72 heures, et informer les personnes concernées si le risque pour elles est élevé. Cette horloge de 72 heures fait le lien direct avec le chapitre 9 : sans détection ni capacité d'analyse, on ne peut ni qualifier la violation, ni tenir le délai. C'est une contrainte de gouvernance qui exige une capacité technique — et l'un des meilleurs arguments pour financer la détection.

Continuité et reprise d'activité

Toutes les mesures précédentes visent à empêcher ou à limiter. La continuité d'activité répond à une autre question : comment continue-t-on à fonctionner quand un sinistre survient malgré tout — rançongiciel, incendie, panne majeure, indisponibilité d'un fournisseur ?

Deux notions se mesurent et se décident à l'avance, avec le métier :

• le RTO (Recovery Time Objective) : en combien de temps le service doit être rétabli ;
• le RPO (Recovery Point Objective) : quelle quantité de données on accepte de perdre — ce qui dicte la fréquence des sauvegardes.

Le rançongiciel — menace dominante, croisée à chaque bloc — a fait de la sauvegarde la mesure de survie par excellence. Mais une sauvegarde n'est utile que si elle est hors ligne ou immuable (un rançongiciel chiffre aussi les sauvegardes accessibles depuis le réseau) et surtout testée : d'innombrables organisations ont découvert le jour du sinistre que leurs sauvegardes étaient incomplètes, corrompues ou irrestaurables. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie — c'est le prolongement direct de la « préparation » du chapitre 9.

Le facteur humain

On arrive au maillon décisif, et il n'est pas technique. La grande majorité des incidents commencent par une action humaine : un lien cliqué, une pièce jointe ouverte, un mot de passe réutilisé, une clé USB ramassée sur un parking. Colonial Pipeline (chapitre 3), c'était un mot de passe. Le rançongiciel type commence par un hameçonnage.

L'ingénierie sociale exploite non pas la technique mais la psychologie : l'autorité (« le directeur exige un virement immédiat »), l'urgence (« votre compte sera fermé dans l'heure »), la confiance, la peur, la serviabilité. Ses formes : l'hameçonnage de masse, le harponnage ciblé sur une personne précise, la fraude au président qui a coûté des millions à de grandes entreprises, l'appât physique. Aucune de ces attaques ne casse un chiffrement ou n'exploite une faille logicielle — elles contournent toute la technique en s'adressant à la personne.

La défense se construit à deux niveaux, et l'ordre importe :

1. Technique d'abord. On ne demande pas aux gens d'être parfaits, on rend l'erreur moins grave. Le MFA résistant au hameçonnage (chapitre 3) neutralise la réutilisation et le vol de mot de passe. Le filtrage de la messagerie arrête l'essentiel du volume. Le moindre privilège (chapitre 3) limite ce qu'un compte hameçonné peut faire.
2. Humain ensuite. La sensibilisation régulière et concrète — exercices d'hameçonnage, consignes claires — élève le niveau, à condition d'être bienveillante. Une culture qui punit celui qui a cliqué obtient l'inverse de ce qu'elle cherche : les gens cachent leurs erreurs, et l'incident est détecté trop tard. Ce qu'on veut, c'est qu'un employé qui a cliqué par erreur le signale dans la minute — c'est ce signalement qui sauve, pas la culpabilité. C'est le même principe que le retour d'expérience sans blâme du chapitre 9.

À vous

Le dernier exercice du cours vous met dans le fauteuil du responsable sécurité. Budget fini, cinq risques issus d'un atelier EBIOS. Calculez le niveau de chacun, priorisez, allouez le budget, et nommez le traitement retenu pour chaque risque.

Observez lequel offre le meilleur rapport — et de quelle nature il est. Ce n'est pas un hasard si la mesure la plus rentable du registre n'est pas technique : c'est là toute la leçon du bloc V, et la conclusion de ce cours.

// Vous êtes RSSI d'une PME. Votre budget de sécurité annuel est de 30 k€.
// Cinq risques identifiés lors de l'atelier EBIOS. À vous de décider où il va.
//
// Échelles à 4 niveaux (pas d'euros à la décimale : c'est une grille de
// discussion, pas un calcul comptable — cf. chapitre 1).
//   vraisemblance : 1 improbable ... 4 quasi certain
//   gravité       : 1 mineure    ... 4 catastrophique

const RISQUES = [
  { id: "R1", nom: "Rançongiciel via hameçonnage",       v: 4, g: 4, cout: 8,  mesure: "MFA + sensibilisation + sauvegardes hors ligne testées" },
  { id: "R2", nom: "Vol du portable d'un commercial",     v: 3, g: 2, cout: 2,  mesure: "chiffrement de disque (BitLocker/LUKS)" },
  { id: "R3", nom: "Injection SQL sur le site vitrine",   v: 2, g: 1, cout: 6,  mesure: "réécriture en requêtes préparées + WAF" },
  { id: "R4", nom: "Panne du serveur de paie (matériel)", v: 2, g: 3, cout: 5,  mesure: "redondance + plan de reprise" },
  { id: "R5", nom: "Départ d'un admin avec ses accès",    v: 3, g: 4, cout: 1,  mesure: "revue des habilitations + procédure de départ" },
];

// ── À VOUS ──────────────────────────────────────────────────────────────────
// 1. niveau() : le niveau de risque = vraisemblance × gravité (1 à 16).
// 2. Triez les risques du plus élevé au plus faible.
// 3. Choisissez les mesures à financer sans dépasser 30 k€, et pour chaque
//    risque NON financé, nommez le traitement retenu :
//       éviter / réduire / transférer (assurance) / accepter.

function niveau(r) {
  return 0; // à compléter
}

const BUDGET = 30;
// à compléter : tri, sélection, décision de traitement.

// ── Affichage ────────────────────────────────────────────────────────────────
for (const r of RISQUES) {
  console.log(r.id + " " + r.nom.padEnd(38) + " niveau=" + niveau(r) + " coût=" + r.cout + "k€");
}

function niveau(r) {
  return r.v * r.g;
}

// Niveaux : R1=16, R5=12, R4=6, R2=6, R3=2.
const tries = [...RISQUES].sort((a, b) => niveau(b) - niveau(a));

let reste = 30;
const finances = [];
for (const r of tries) {
  if (r.cout <= reste) { finances.push(r.id); reste -= r.cout; }
}
// Financés dans l'ordre du risque : R1 (8) → R5 (1) → R4 (5) → R2 (2) → R3 (6).
// Total = 22 k€, il reste 8 k€. R3 (2) passerait aussi : total 24 k€.

// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. On priorise par le RISQUE (v × g), pas par la gravité seule ni par le
//    coût. R1 est traité en premier parce qu'il est à la fois très probable
//    et catastrophique — c'est le rançongiciel, la menace dominante.
//
// 2. R5 (départ d'un admin) est le meilleur rapport du registre : niveau 12
//    pour 1 k€. La mesure n'est pas technique — c'est une PROCÉDURE et une
//    revue d'habilitations (chapitre 3). Les mesures organisationnelles sont
//    souvent les plus rentables, et c'est le message central de la
//    gouvernance : la sécurité n'est pas un problème qu'on achète.
//
// 3. R3 (injection SQL) a beau être « la faille n°1 du web » (chapitre 7),
//    son niveau de risque ici est le plus BAS : site vitrine sans données,
//    peu exposé. Le score technique ne dicte pas la priorité — le contexte,
//    si. C'est exactement la leçon du chapitre 1, appliquée à un budget réel.
//
// 4. Les quatre traitements possibles d'un risque :
//    - ÉVITER : supprimer l'activité qui le porte (fermer le service exposé).
//    - RÉDUIRE : les mesures ci-dessus (le cas général).
//    - TRANSFÉRER : une cyber-assurance pour R4, par exemple — on paie un
//      tiers pour porter l'impact financier. Ne transfère pas la
//      responsabilité, ni l'atteinte à la réputation.
//    - ACCEPTER : consigner formellement qu'on vit avec le risque résiduel,
//      décision SIGNÉE par la direction. Accepter un risque est une décision
//      métier légitime — l'ignorer ne l'est pas.
//
// Le risque ZÉRO n'existe pas : après traitement, il reste toujours un risque
// résiduel, et c'est à la direction de l'accepter en connaissance de cause.
// Le rôle du RSSI est d'éclairer cette décision, pas de la prendre seul.

Ce que ce cours vous laisse

Vous avez traversé la discipline une fois en entier : des menaces à la cryptographie appliquée, des systèmes aux réseaux, des applications à la mémoire, de la réponse à incident à la gouvernance. C'était l'objectif — une première exposition complète, où chaque chapitre s'est arrêté là où commencerait un cours dédié.

Trois idées survivent à l'oubli des détails, et méritent de rester :

• La sécurité se raisonne par le risque, pas par la gravité technique. Le contexte commande toujours la priorité.
• La défense se pense en profondeur. Aucune barrière n'est parfaite ; l'attaquant doit réussir toutes les étapes, le défenseur n'a qu'à en casser une. On multiplie les couches, on suppose que chacune cédera.
• Le maillon décisif est humain, et la sécurité est un processus continu, jamais un état acquis.

Le master approfondira, chapitre par chapitre, ce que vous n'avez ici que traversé — la cryptographie du chapitre 2 y devient deux UE entières. Mais la grille de lecture, elle, ne changera plus : c'est celle que ce cours vous a donnée.

À retenir