Rafiq IA Lab

IA-16 — IA dans l'infrastructure IT et la cybersécurité défensive

---

1. Titre du module

IA-16 — IA dans l'infrastructure IT et la cybersécurité défensive

Partie 4 — IA professionnelle, cybersécurité, infrastructure et IA locale

---

2. Objectif pédagogique

À la fin de ce module, l'apprenant doit être capable de :

• expliquer le rôle de l'IA dans la supervision et la cybersécurité défensive ;
• utiliser l'IA pour la détection d'anomalies, l'analyse de logs et la classification d'incidents ;
• s'appuyer sur l'IA pour rédiger des rapports de sécurité, aider au durcissement et à la veille ;
• comprendre des alertes et concepts : EDR, SIEM, SOAR, firewall nouvelle génération, détection comportementale, agents IA ;
• identifier les limites : faux positifs, faux négatifs, hallucinations, contexte incomplet ;
• appliquer les règles de sécurité des données : anonymiser les logs, retirer les secrets, garder une validation humaine ;
• rester strictement dans un cadre défensif, légal et éthique.

Prérequis : IA-05 (précision/rappel, faux positifs/négatifs), IA-09 (vérification), IA-10 (diagnostic) et IA-15 (IA locale pour données sensibles).

---

3. Niveau

Professionnel.

Module orienté usage en entreprise. Il combine analyse de logs, supervision et sécurité défensive. Cadre strict : ce module ne traite que de la défense (comprendre, détecter, durcir), jamais de l'attaque.

---

4. Durée estimée

---

5. Résumé clair et simple

Dans une infrastructure IT, on produit des quantités énormes de données : logs de serveurs, événements de sécurité, alertes de supervision. Un humain ne peut pas tout lire. L'IA aide à trier, résumer, expliquer et prioriser : elle fait ressortir l'important dans le bruit.

Concrètement, l'IA assiste sur plusieurs tâches défensives : repérer un comportement inhabituel (détection d'anomalies), analyser des logs (Apache, SSH, Windows…), classer des incidents par gravité, expliquer une alerte (par exemple d'un EDR ou d'un SIEM), aider à comprendre une règle de firewall, rédiger un rapport de sécurité, ou suggérer des mesures de durcissement. Elle est aussi utile pour la veille (résumer des bulletins, vulgariser une alerte).

Mais la cybersécurité est un domaine où l'erreur coûte cher. Deux types d'erreurs comptent particulièrement (rappel IA-05) : le faux positif (fausse alerte qui fait perdre du temps) et le faux négatif (vraie attaque non détectée — le plus grave). À cela s'ajoute le risque d'hallucination : l'IA peut inventer une explication ou une « solution » qui n'a aucun sens, voire qui affaiblit la sécurité. L'IA assiste l'analyste ; elle ne remplace ni les outils de sécurité, ni le jugement humain.

Enfin, les logs de sécurité sont parmi les données les plus sensibles : adresses IP internes, noms d'utilisateurs, chemins, parfois des secrets. La règle est absolue : anonymiser, retirer les secrets, et pour les données vraiment sensibles, privilégier une IA locale (IA-15) plutôt qu'un service cloud. Et tout reste encadré par un principe non négociable : on agit uniquement dans un cadre défensif, légal et éthique.

---

6. Compétences visées

À l'issue de ce module, l'apprenant saura :

• situer les usages défensifs de l'IA (supervision, détection, analyse, classification, rapport, durcissement, veille) ;
• faire analyser et résumer des logs par l'IA en toute sécurité ;
• comprendre des alertes EDR/SIEM et des concepts SOAR/firewall NG/détection comportementale ;
• raisonner sur faux positifs / faux négatifs selon l'enjeu de sécurité ;
• appliquer les règles d'anonymisation et de protection des secrets ;
• garder une validation humaine et un cadre strictement défensif et légal.

---

7. Notions clés à comprendre

• Supervision (monitoring) : surveillance de l'état et de l'activité des systèmes/réseaux.
• Détection d'anomalies : repérer ce qui sort du comportement « normal » (rappel IA-02, apprentissage non supervisé).
• Analyse de logs : extraire l'important d'un grand volume de journaux.
• Classification d'incidents : ranger les incidents par type et gravité.
• Durcissement (hardening) : renforcer la sécurité d'un système (réduire la surface d'attaque).
• Veille : suivre les nouvelles menaces, vulnérabilités et bonnes pratiques.
• EDR (Endpoint Detection and Response) : solution de détection et réponse sur les postes/serveurs.
• SIEM (Security Information and Event Management) : collecte et corrèle les événements de sécurité de toute l'infra.
• SOAR (Security Orchestration, Automation and Response) : automatise et orchestre la réponse aux incidents.
• Firewall nouvelle génération (NGFW) : pare-feu avancé (inspection applicative, etc.).
• Détection comportementale : repérer une menace par son comportement plutôt que par une signature connue.
• Faux positif / faux négatif : fausse alerte / menace non détectée (rappel IA-05).
• Cadre défensif : usage limité à la protection, la détection et la réponse — jamais l'attaque.

---

8. Cours complet structuré

8.1 — Le rôle de l'IA en supervision et sécurité défensive

L'infrastructure génère trop de données pour une lecture humaine exhaustive. L'IA aide à :

• trier et prioriser : faire remonter ce qui compte ;
• résumer : condenser des milliers de lignes ;
• expliquer : rendre une alerte technique compréhensible ;
• proposer : suggérer des pistes de vérification ou de durcissement.

Important : beaucoup d'outils de sécurité (EDR, SIEM, NGFW) intègrent déjà des mécanismes de détection (parfois à base de ML, rappel IA-02). L'IA générative (LLM) que vous utilisez en complément sert surtout à comprendre, résumer et rédiger — pas à remplacer ces outils.

8.2 — Détection d'anomalies

Repérer ce qui sort du « normal » est un usage classique du ML (apprentissage non supervisé, IA-02) : pic de connexions inhabituel, horaire atypique, volume anormal. L'IA signale ; l'analyste confirme s'il s'agit d'une vraie menace ou d'un faux positif.

La détection d'anomalies génère souvent beaucoup de faux positifs. Sans analyste pour trier, elle devient du bruit. L'humain reste central.

8.3 — Analyse de logs avec l'IA

L'IA est très utile pour dégrossir des logs, à condition d'anonymiser (8.7). Bonnes demandes :

• « Résume ces événements et classe-les par gravité. »
• « Repère les anomalies ou tentatives suspectes. »
• « Explique cette ligne de log. »
• « Indique ce qui mérite une vérification approfondie. »

Mais : lisez les logs réels vous-même (IA-09) — ils font foi. L'IA peut mal interpréter ou inventer une explication.

8.4 — Classification d'incidents et rapports de sécurité

• Classification : l'IA aide à ranger les incidents par type/gravité, pour prioriser le traitement. Les cas critiques passent par une validation humaine.
• Rapports de sécurité : l'IA aide à structurer et rédiger un rapport (contexte, faits, impact, mesures, recommandations) à partir de vos constats. Vous vérifiez les faits (l'IA ne doit pas inventer).

8.5 — Aide au durcissement et à la veille

• Durcissement : l'IA peut rappeler des principes de durcissement (réduire la surface d'attaque, principe du moindre privilège, mises à jour). Recoupez toujours avec les guides officiels (éditeur, référentiels reconnus) et testez en lab.
• Veille : l'IA aide à résumer des bulletins de sécurité ou à vulgariser une alerte. Mais pour les vulnérabilités précises (références, correctifs), recoupez avec les sources officielles (éditeur, bases officielles, CERT) — l'IA peut citer une référence inexistante (IA-09).

Méfiance absolue : une « solution » proposée par l'IA qui affaiblit la sécurité (désactiver un pare-feu, ouvrir un accès large « pour que ça marche ») est une fausse bonne pratique à rejeter (rappel IA-09).

8.6 — Comprendre les alertes et les concepts (EDR, SIEM, SOAR, NGFW…)

L'IA est précieuse pour expliquer ces concepts et vulgariser des alertes :

• EDR : détection/réponse sur les postes et serveurs (endpoints). L'IA peut expliquer ce qu'une alerte EDR signifie en clair.
• SIEM : centralise et corrèle les événements de sécurité de toute l'infra. L'IA peut aider à comprendre un événement corrélé.
• SOAR : automatise et orchestre la réponse (playbooks). À manier avec un fort contrôle humain (automatisation, IA-13).
• Firewall nouvelle génération (NGFW) : pare-feu avancé ; l'IA peut aider à comprendre une règle existante (vous vérifiez sur l'équipement réel).
• Détection comportementale : repérer une menace par son comportement (utile contre les menaces inconnues).
• Agents IA : des systèmes plus autonomes commencent à apparaître en sécurité ; puissants mais risqués, ils exigent des garde-fous stricts (approfondi en IA-21).

L'IA aide surtout à comprendre ces outils et leurs alertes. Le paramétrage et la décision restent du ressort de l'analyste, dans les outils eux-mêmes.

8.7 — Règles de sécurité des données (impératif)

Les logs et événements de sécurité sont très sensibles. Avant tout envoi à une IA, surtout cloud :

• anonymiser : remplacer/masquer IP internes complètes, noms d'utilisateurs, noms d'hôtes, chemins identifiants ;
• retirer les secrets : jamais de mots de passe, clés, tokens, certificats ;
• minimiser : n'envoyer qu'un extrait pertinent, pas tout ;
• préférer l'IA locale (IA-15) pour les données réellement sensibles, afin qu'elles ne sortent pas ;
• garder une validation humaine sur toute décision de sécurité.

Ces aspects (RGPD, données sensibles, confidentialité) sont approfondis au module IA-17.

8.8 — Limites et cadre strict

• Faux positifs / faux négatifs (IA-05) : en défense, le faux négatif (rater une attaque) est souvent le plus grave → on privilégie le rappel, tout en gérant le volume de fausses alertes.
• Hallucinations : l'IA peut inventer une explication, une référence (CVE) ou une « solution » dangereuse.
• Contexte incomplet : sans le contexte réel de votre infra, l'IA peut se tromper lourdement.
• Cadre défensif, légal et éthique : ce module ne couvre que la défense. On ne demande pas à l'IA d'aider à attaquer, contourner des protections ou exploiter des failles. Toute action doit être autorisée, légale et menée sur vos systèmes (ou avec autorisation explicite).

Principe : l'IA est un assistant d'analyste défensif. Elle accélère la compréhension, jamais elle ne décide seule d'une réponse de sécurité.

---

9. Exemples concrets liés au monde IT

Pour chaque cas, anonymiser avant l'IA (8.7) ; vérifier ensuite (IA-09).

1. Analyse de logs Apache/Nginx. Repérer des codes d'erreur récurrents ou un pic de requêtes suspectes ; l'IA résume, vous confirmez dans les logs réels.
2. Analyse de logs SSH. Faire ressortir des tentatives de connexion échouées répétées (anonymisées) ; l'IA explique, vous décidez des mesures (ex. renforcer l'authentification) — recoupé avec les bonnes pratiques officielles.
3. Analyse de logs Windows. Comprendre des ID d'événements de sécurité ; l'IA vulgarise, vous vérifiez l'ID dans la doc officielle.
4. Détection d'activité suspecte. Une anomalie est signalée par la supervision ; l'IA aide à formuler des hypothèses, l'analyste tranche.
5. Explication d'une alerte EDR. L'IA traduit une alerte technique en langage clair et propose des vérifications ; la réponse reste décidée par l'humain.
6. Comprendre une règle de firewall. L'IA explique ce que fait une règle existante ; vous vérifiez sur l'équipement et la doc constructeur.
7. Analyse d'un événement SIEM. L'IA aide à interpréter un événement corrélé ; vous validez avec le contexte réel.
8. Rapport d'incident. À partir de vos constats, l'IA structure un rapport clair (faits, impact, mesures) ; vous vérifiez l'exactitude.

Constante : l'IA éclaire ; les outils de sécurité détectent, et l'analyste décide.

---

10. Cas pratique guidé

Objectif : analyser un extrait de logs SSH avec l'IA, en restant défensif et en protégeant les données.

Contexte. Vous observez de nombreuses tentatives de connexion échouées sur un serveur Linux exposé. Vous voulez comprendre et réagir — en défense.

Étape 1 — Préparer et anonymiser. Extrayez un échantillon pertinent du log d'authentification. Anonymisez : remplacez les IP internes complètes et les noms d'utilisateurs réels par des valeurs neutres. Retirez tout secret. (Pour des données vraiment sensibles, utilisez une IA locale — IA-15.)

Étape 2 — Demander une analyse défensive. Prompt : « Tu es analyste SOC en posture défensive. Voici un extrait de log SSH anonymisé : […]. 1) Résume ce qui se passe. 2) Indique s'il s'agit possiblement de tentatives d'accès par force. 3) Propose des mesures défensives et des vérifications. 4) Reste strictement dans un cadre défensif et légal. 5) Liste tes incertitudes. »

Étape 3 — Évaluer les pistes défensives. L'IA proposera typiquement : renforcer l'authentification, limiter l'exposition du service, surveiller les sources, appliquer les bonnes pratiques de durcissement. Recoupez chaque mesure avec les guides officiels ; rejetez toute suggestion qui affaiblirait la sécurité.

Étape 4 — Vérifier dans les logs réels. Confirmez les faits dans vos vrais logs (volumes, sources, horaires). L'IA peut avoir mal interprété l'échantillon.

Étape 5 — Décider et tracer. Décidez des mesures (validation humaine), testez en lab si nécessaire, journalisez la décision. Rédigez éventuellement un court rapport avec l'IA (faits vérifiés uniquement).

Résultat du cas pratique : une analyse défensive assistée par IA, avec données protégées, mesures recoupées et décision humaine tracée.

---

11. Exercice pratique à faire seul

Consigne. Choisissez un type de logs/alertes (Apache, SSH, Windows, ou une alerte EDR/SIEM). Préparez une analyse défensive assistée par IA :

1. Décrivez comment vous anonymisez l'extrait (qu'enlevez-vous ?).
2. Rédigez un prompt imposant le cadre défensif et demandant : résumé, anomalies, mesures défensives, vérifications, incertitudes.
3. Indiquez où vous vérifierez les faits (logs réels, doc officielle, sources de sécurité).
4. Précisez 2 mesures de durcissement que vous recouperiez avant d'appliquer.
5. Identifiez 1 faux positif possible et 1 faux négatif possible dans ce contexte.
6. Indiquez quand vous utiliseriez une IA locale plutôt que le cloud.

Contexte. Vous adoptez la posture d'un analyste défensif assisté par IA, soucieux des données.

Résultat attendu. Un plan d'analyse défensive complet.

Critères de réussite :

• l'anonymisation est explicite et complète ;
• le prompt impose le cadre défensif et demande des incertitudes ;
• les sources de vérification sont réalistes ;
• les mesures de durcissement sont à recouper ;
• faux positif et faux négatif sont identifiés ;
• le recours à l'IA locale est justifié pour les données sensibles.

---

12. Quiz de 10 questions QCM

Une seule bonne réponse par question.

Q1. Quel est le rôle principal de l'IA (LLM) en sécurité défensive ?

• A. Remplacer les outils de sécurité (EDR, SIEM)
• B. Aider à comprendre, résumer, prioriser et rédiger
• C. Décider seule des réponses aux incidents
• D. Attaquer les systèmes adverses

Q2. En cybersécurité défensive, quel type d'erreur est souvent le plus grave ?

• A. Le faux positif (fausse alerte)
• B. Le faux négatif (vraie attaque non détectée)
• C. Le vrai positif
• D. Le vrai négatif

Q3. Que signifie EDR ?

• A. Endpoint Detection and Response (détection/réponse sur les postes et serveurs)
• B. External Data Recovery
• C. Encrypted Data Router
• D. Error Detection Report

Q4. Que fait un SIEM ?

• A. Il génère des mots de passe
• B. Il collecte et corrèle les événements de sécurité de l'infrastructure
• C. Il remplace le firewall
• D. Il héberge des sites web

Q5. Avant d'envoyer des logs de sécurité à une IA cloud, il faut :

• A. Ajouter les mots de passe pour le contexte
• B. Anonymiser, retirer les secrets et minimiser
• C. Envoyer tout le fichier sans modification
• D. Ne rien faire

Q6. Une suggestion de l'IA qui propose de désactiver une protection « pour que ça marche » :

• A. Doit être appliquée immédiatement
• B. Est une fausse bonne pratique à rejeter et recouper
• C. Est toujours correcte
• D. Améliore la sécurité

Q7. Pour une donnée de sécurité réellement sensible, quelle option limite le mieux la fuite ?

• A. Un service cloud public
• B. Une IA locale (les données ne sortent pas)
• C. Un forum public
• D. Un email non chiffré

Q8. Qui doit décider de la réponse à un incident de sécurité ?

• A. L'IA seule
• B. L'analyste humain (validation humaine), l'IA assistant
• C. Personne
• D. Un agent totalement autonome sans contrôle

Q9. Que recouper pour une vulnérabilité précise (référence, correctif) ?

• A. Une réponse d'IA non vérifiée
• B. Les sources officielles (éditeur, bases officielles, CERT)
• C. Une rumeur
• D. Rien

Q10. Quel cadre ce module impose-t-il ?

• A. Offensif et sans limite
• B. Strictement défensif, légal et éthique
• C. Sans aucune règle
• D. Anonyme et illégal

---

13. Réponses corrigées du quiz avec explications

Q1 → B. L'IA (LLM) aide à comprendre, résumer, prioriser, rédiger. Elle ne remplace pas les outils (A) ni ne décide seule (C) ; l'attaque (D) est hors cadre.

Q2 → B. Le faux négatif (attaque non détectée) est souvent le plus grave → on privilégie le rappel (IA-05). A est gênant mais moins critique ; C et D ne sont pas des erreurs.

Q3 → A. EDR = Endpoint Detection and Response. Les autres sont inventées.

Q4 → B. Le SIEM collecte et corrèle les événements de sécurité. A, C et D sont faux.

Q5 → B. On anonymise, retire les secrets et minimise. A est dangereux, C expose tout, D ignore le risque.

Q6 → B. Affaiblir une protection est une fausse bonne pratique à rejeter et recouper. A, C et D sont dangereux.

Q7 → B. L'IA locale garde les données chez vous (IA-15). A, C et D exposent les données.

Q8 → B. L'analyste humain décide ; l'IA assiste. A et D sont dangereux, C est faux.

Q9 → B. On recoupe avec les sources officielles. A, C et D ne sont pas fiables.

Q10 → B. Cadre strictement défensif, légal et éthique. Les autres réponses sont inacceptables.

Barème indicatif : 8/10 ou plus = notions acquises. 5 à 7 = relisez les sections 8.7 et 8.8. Moins de 5 = reprenez le cours et rejouez le cas pratique.

---

14. Flashcards de révision

Carte 1 Q : Rôle de l'IA (LLM) en sécurité défensive ? R : Aider à comprendre, résumer, prioriser, rédiger — sans remplacer les outils ni l'analyste.

Carte 2 Q : Faux positif vs faux négatif en sécurité ? R : Faux positif = fausse alerte ; faux négatif = vraie attaque non détectée (souvent le plus grave).

Carte 3 Q : Que signifie EDR ? R : Endpoint Detection and Response : détection/réponse sur les postes et serveurs.

Carte 4 Q : Que fait un SIEM ? R : Il collecte et corrèle les événements de sécurité de toute l'infrastructure.

Carte 5 Q : Que fait un SOAR ? R : Il orchestre et automatise la réponse aux incidents (playbooks) — avec contrôle humain.

Carte 6 Q : Détection comportementale ? R : Repérer une menace par son comportement plutôt que par une signature connue.

Carte 7 Q : Avant d'envoyer des logs à une IA cloud ? R : Anonymiser, retirer les secrets, minimiser ; préférer l'IA locale si sensible.

Carte 8 Q : Que faire d'une « solution » qui affaiblit la sécurité ? R : La rejeter : c'est une fausse bonne pratique ; recouper avec les sources officielles.

Carte 9 Q : Qui décide de la réponse à un incident ? R : L'analyste humain ; l'IA reste un assistant.

Carte 10 Q : Où recouper une vulnérabilité précise ? R : Sources officielles : éditeur, bases officielles, CERT.

Carte 11 Q : Cadre imposé du module ? R : Strictement défensif, légal et éthique.

Carte 12 Q : L'IA remplace-t-elle l'EDR/SIEM ? R : Non : elle aide à comprendre leurs alertes ; les outils détectent, l'analyste décide.

---

15. Erreurs fréquentes

• Envoyer des logs non anonymisés (IP internes, identifiants, secrets) à une IA cloud.
• Croire l'explication de l'IA sans vérifier les logs réels.
• Appliquer une « solution » qui affaiblit la sécurité (fausse bonne pratique).
• Se fier à une référence (CVE) citée par l'IA sans la recouper.
• Laisser l'IA décider d'une réponse à incident sans validation humaine.
• Ignorer le compromis faux positifs / faux négatifs propre à la sécurité.
• Prendre l'IA pour un outil de détection alors qu'elle aide surtout à comprendre/rédiger.
• Sortir du cadre défensif (toute aide à l'attaque est exclue).

---

16. Bonnes pratiques

• Anonymiser, retirer les secrets, minimiser avant toute analyse par IA.
• Préférer l'IA locale (IA-15) pour les logs et données réellement sensibles.
• Vérifier dans les logs réels et recouper avec les sources officielles (IA-09).
• Rejeter toute suggestion affaiblissant la sécurité.
• Garder une validation humaine sur toute décision de sécurité.
• Gérer le compromis faux positifs / faux négatifs selon l'enjeu (privilégier le rappel sur les menaces).
• Journaliser analyses et décisions (traçabilité).
• Rester strictement défensif, légal et éthique.

---

17. Point vigilance : limites, risques, sécurité et vérification humaine

Bloc obligatoire à lire attentivement.

Ce qu'il faut vérifier :

• les faits dans les logs réels (l'IA peut mal interpréter) ;
• les références de sécurité (CVE, correctifs) via les sources officielles ;
• la pertinence des mesures de durcissement avant application (recoupement + lab) ;
• le compromis faux positifs / faux négatifs adapté à l'enjeu.

Ce qu'il ne faut pas faire :

• envoyer des logs non anonymisés ou des secrets à une IA (surtout cloud) ;
• appliquer une « solution » qui affaiblit la sécurité ;
• laisser l'IA décider seule d'une réponse à incident ;
• sortir du cadre défensif et légal.

Risques de mauvaise utilisation :

• faux négatif (attaque manquée) si l'on se fie trop à l'IA ;
• décision de sécurité fondée sur une hallucination ;
• fuite de données sensibles via des logs envoyés au cloud.

Risques de confidentialité :

• les logs de sécurité contiennent des données très sensibles (IP, identifiants, parfois secrets) ;
• privilégier l'IA locale et l'anonymisation ; RGPD et données sensibles : module IA-17 ; gouvernance : IA-18.

Limites de l'IA en sécurité :

• elle n'a pas le contexte réel de votre infra ;
• elle hallucine (explications, références, « solutions ») ;
• elle complète, mais ne remplace pas, les outils (EDR, SIEM, NGFW) ni l'analyste.

Cas où une validation humaine est indispensable :

• toute décision de réponse à incident ;
• toute mesure de durcissement avant application en production ;
• toute classification d'un incident potentiellement critique.

Principe à retenir : l'IA est un assistant d'analyste défensif : elle éclaire, résume et rédige ; les outils détectent, l'humain décide, dans un cadre défensif, légal et éthique. Données : anonymiser, IA locale si sensible, validation humaine.

---

18. Mini-projet de fin de module

Titre : « Mon assistant d'analyse défensive »

Objectif. Construire une méthode et des gabarits pour analyser logs et alertes avec l'IA, de façon défensive, sûre et traçable.

Contexte. Vous outillez votre pratique d'analyse défensive assistée par IA. Tout repose sur des données anonymisées ou de lab. Aucune action offensive.

Prérequis. IA-05 (faux positifs/négatifs), IA-09 (vérification), IA-15 (IA locale).

Étapes :

1. Choisir 3 types de logs/alertes (ex. SSH, Windows, alerte EDR).
2. Définir une règle d'anonymisation commune (que retirer/masquer systématiquement).
3. Créer 3 gabarits de prompt imposant le cadre défensif, demandant : résumé, anomalies, mesures défensives, vérifications, incertitudes.
4. Pour chaque type, lister les sources de vérification (logs réels, doc officielle, sources de sécurité).
5. Définir le compromis faux positifs / faux négatifs attendu et le point de validation humaine.
6. Décider quand utiliser l'IA locale (données sensibles).
7. Prévoir la journalisation des analyses et décisions.

Résultat attendu. Une méthode + 3 gabarits d'analyse défensive, sûrs et traçables.

Critères de réussite :

• règle d'anonymisation claire ;
• gabarits imposant le cadre défensif et demandant les incertitudes ;
• sources de vérification réalistes ;
• compromis faux positifs/négatifs explicité ;
• recours à l'IA locale justifié ;
• validation humaine et journalisation prévues.

Amélioration possible. Reliez ces gabarits à un workflow (IA-13) qui enrichit une alerte par IA et l'envoie à l'équipe — sans action automatique sur les cas critiques, toujours avec validation humaine.

---

19. Ressources gratuites recommandées

Ne recommander que des ressources gratuites ou accessibles gratuitement. Toute ressource dont la gratuité ou la disponibilité n'est pas certaine est signalée par la mention « À vérifier avant publication. »

• ANSSI (France) — cyber.gouv.fr — guides gratuits et officiels de bonnes pratiques et de durcissement (références fiables pour recouper les mesures). À vérifier avant publication (vérifier le lien et les guides au moment de publier).
• Sources officielles de vulnérabilités / CERT — bases officielles de CVE et alertes de CERT nationaux — pour recouper une vulnérabilité ou un correctif. À vérifier avant publication (choisir des sources officielles à jour).
• Documentation officielle des éditeurs de sécurité (EDR, SIEM, firewall) et Microsoft Learn (IDs d'événements Windows) — pour vérifier alertes et règles. À vérifier avant publication (liens variables).
• IA locale (Ollama, LM Studio — voir IA-15) — pour analyser des logs sensibles sans les envoyer dans le cloud. À vérifier avant publication (voir conditions dans IA-15).
• Pages de manuel et aide intégrée (man, journaux système) — gratuites, pour comprendre et vérifier les logs réels. (Gratuit, disponible localement.)

Remarque : pour les contenus de cybersécurité, privilégiez toujours les sources officielles et restez dans un cadre défensif et légal. Ce module ne promet aucune certification.

---

20. Résumé final du module

• L'IA aide à trier, résumer, expliquer et prioriser dans une infrastructure qui produit trop de données pour une lecture humaine.
• Usages défensifs : détection d'anomalies, analyse de logs (Apache, SSH, Windows), classification d'incidents, rapports de sécurité, durcissement, veille.
• Concepts clés : EDR (postes/serveurs), SIEM (corrélation), SOAR (orchestration), NGFW, détection comportementale, agents IA (IA-21).
• Limites : faux positifs / faux négatifs (le faux négatif est souvent le plus grave → privilégier le rappel), hallucinations, contexte incomplet.
• Règles de données impératives : anonymiser, retirer les secrets, minimiser, préférer l'IA locale (IA-15) pour le sensible, valider humainement.
• Cadre non négociable : défensif, légal et éthique. L'IA est un assistant d'analyste : les outils détectent, l'humain décide. Confidentialité/RGPD : IA-17 ; gouvernance : IA-18.

---

21. Validation demandée avant le module suivant

Validation demandée avant le module suivant

Souhaites-tu que je passe au module suivant ou que je corrige/améliore ce module d'abord ?

(Module suivant prévu : IA-17 — Limites, risques, hallucinations, éthique et sécurité des données.)