Plan du cours
Module 1 — Comment les applications IA tombent en panne
Lab : aucun — parcours de l'architecture et discussion
Le modèle mental du constructeur concernant la surface d'attaque.
Sujets :
- Architectures LLM, RAG et agents du côté développeur
- Le cycle de vie requête/réponse d'une fonctionnalité IA
- Flux de prompt : messages système, développeur, utilisateur et outil
- Où les données non fiables entrent (et ré-entrent) dans le modèle
- Les limites de confiance qu'un développeur possède versus hérite
- Pourquoi les attaques IA sont sémantiques, pas syntaxiques
- Capter le OWASP LLM Top 10 au code que vous écrivez
Point clé : Chaque endroit où du texte non fiable atteint le modèle — ou la sortie du modèle atteint votre code — est une frontière que vous possédez.
Module 2 — Injection de prompt pour les constructeurs
Lab : Lab 01 — 01-Prompt-Injection
Le « moment injection SQL » pour l'IA — mais vous ne pouvez pas totalement vous y échapper.
Sujets :
- Injection de prompt directe vs indirecte
- Instructions cachées dans les documents, pages web, sorties d'outils
- Jailbreaks et confusion de rôle
- Pourquoi la séparation instruction/donnée est importante
- Conception défensive des prompts (délimiteurs, structure, autorité minimale)
- Pourquoi la prévention est partielle — concevoir pour le confinement
Pratique :
- Attaquez votre propre chatbot
- Contournez un filtre naïf
- Restructurez le prompt pour réduire le rayon d'explosion
Module 3 — Traiter la sortie du modèle comme non fiable
Lab : Lab 02 — 02-Output-Handling
La classe de bugs que les développeurs sous-estiment le plus.
Sujets :
- La sortie du modèle comme entrée non fiable pour le reste de l'app
- Gestion insecure de la sortie (LLM02) : XSS, SSRF, injection commande/SQL en aval
- Ne jamais eval/exec/rendre brut la sortie du modèle
- Sorties structurées et validation de schéma
- Encodage de la sortie et listes autorisées
- Rendement sûr dans les contextes web/UI
Pratique :
- Trouvez et corrigez une vulnérabilité de gestion insecure de la sortie
- Imposez un schéma JSON sur les réponses du modèle
Module 4 — Sécurité RAG
Lab : Lab 03 — 03-RAG-Security
L'une des nouvelles surfaces d'attaque les plus importantes — et elle est de votre responsabilité.
Sujets :
- Menaces sur la base de vecteurs et la récupération
- Sanitisation de l'ingestion
- Provenance des documents et notation de confiance
- Mise en scope de la récupération et isolement des métadonnées
- Instructions cachées dans le contenu récupéré (injection indirecte)
- Exfiltration de données via la récupération
Pratique : empoisonnez un pipeline RAG avec un document malveillant — ajoutez la sanitisation d'ingestion et la mise en scope de la récupération pour le défendre.
Module 5 — Sécurité des Agents & Outils
Lab : Lab 04 — 04-Agent-Safety
Où un bug devient une action.
Sujets :
- Agence excessive (LLM06) et abus d'outils
- Moindre privilège pour les agents
- Listes autorisées d'outils et validation des arguments
- Portes d'approbation et humain dans la boucle
- Sandboxing de l'exécution des outils
- Identifiants limités en portée et à courte durée de vie pour les agents
- Limitation des boucles autonomes et du chaînage
Pratique :
- Sécurisez un agent sur-autorisé
- Ajoutez une liste autorisée + une porte d'approbation à un outil dangereux
Module 6 — Secrets, Identité & Coûts
Lab : Lab 05 — 05-Secrets-and-Cost
Les erreurs opérationnelles qui blessent le plus vite.
Sujets :
- Gestion des clés API et secrets (jamais dans les prompts, le code ou les journaux)
- Authentification et autorisation par utilisateur pour les fonctionnalités IA
- Propagation de l'identité utilisateur vers les outils et la récupération
- Déni de portefeuille : consommation illimitée de tokens/coûts
- Limites de débit, budgets de tokens et temps d'attente
- Journalisation sans fuir de secrets ou de PII
Pratique :
- Retirez les secrets du chemin prompt/code
- Ajoutez des limites de débit par utilisateur et un budget de tokens/coûts
Module 7 — Bibliothèques de Garde-fous (Guardrails)
Lab : Lab 06 — 06-Guardrails
Acheter vs. construire pour la sécurité entrée/sortie.
Sujets :
- Ce que font les frameworks de garde-fous (et ce qu'ils ne font pas)
- Garde-fous d'entrée : classeurs d'injection/PII/thème
- Garde-fous de sortie : validation, filtrage, vérifications d'ancrage
- Quand un garde-fou est approprié vs. votre propre contrôle déterministe
- Couchage des garde-fous avec les contrôles des modules précédents
- Performance, faux positifs et modes de défaillance
Pratique :
- Ajoutez une couche de garde-fou entrée/sortie à une fonctionnalité IA
- Mesurez ce qu'elle capture et ce qu'elle manque
Module 8 — Red-Teaming de votre propre application
Lab : Lab 07 — 07-Red-Teaming
Déployez-la comme si un attaquant l'avait déjà.
Sujets :
- Construction d'une suite d'abus/tests pour les fonctionnalités IA
- Tests automatisés d'injection de prompt et jailbreak
- Re-testing des garde-fous et politiques en regression
- Exécution des contrôles de sécurité IA dans CI
- Chaîne d'approvisionnement des modèles et dépendances (provenance, pinning)
- Une liste de contrôle de pré-déploiement pour les fonctionnalités IA
Pratique :
- Écrivez des tests red-team automatisés pour une fonctionnalité IA
- Connectez-les à un contrôle CI
Module 9 — Notation de la Sécurité IA : Le Cadre SAIS-100
Lab : aucun — exercice de notation (utilise l'application Capstone)
Tout ce que vous avez construit en un score répétable.
Sujets :
- Le Hexagone de Sécurité IA : six questions au lieu de « est-ce sécurisé ? »
- Les six catégories notées (Données, Prompt, Agent, Chaîne d'approvisionnement, Détection, Gouvernance)
- La grille de notation sur 100 points et ses pondérations
- Bandes de verdict et la règle deoverride unique par catégorie
- L'échelle Elephant Secure AI Score (SAIS-100) comme cadre ré-brandé et ré-exécutable
- La notation avant/après durcissement comme métrique
Pratique :
- Notez l'application Capstone sur l'échelle de 100 points
- Identifiez le seul changement qui augmente le plus la note
Point clé : Les trois catégories les plus pondérées correspondent aux limites de confiance qu'un développeur possède — donc la note mesure exactement ce que ce cours a enseigné.
Capstone
Les étudiants durcissent une application IA délibérément vulnérable de bout en bout.
L'application de départ contient :
- un prompt injectable
- une gestion insecure de la sortie
- un pipeline RAG non mis en scope
- un agent sur-autorisé
- des secrets dans le chemin du prompt
- aucune limite de coût
Les étudiants appliquent le cours :
- restructurent les prompts pour le confinement
- valident et encode la sortie du modèle
- sanitise et met en scope la récupération
- appliquent le moindre privilège et les portes d'approbation à l'agent
- déplacent les secrets vers l'extérieur et ajoutent des limites de coût/débit
- ajoutent des garde-fous et des tests red-team automatisés
Livrable : une application durcie plus une auto-évaluation courte du OWASP LLM Top 10.
Cartographie Modules - Labs
Les labs s'exécutent dans l'ordre des labs, qui suit l'ordre des modules. Le cours a 9 modules et 7 labs : le Module 1 est un parcours de l'architecture/discussion et le Module 9 est un exercice de notation, donc aucun n'a son propre dossier de lab.
- Lab 01 - 01-Prompt-Injection : Attaquez votre chatbot & concevez pour le confinement (Module 2)
- Lab 02 - 02-Output-Handling : Corrigez un bug de gestion insecure de la sortie (Module 3)
- Lab 03 - 03-RAG-Security : Em poisonnez puis défendez un pipeline RAG (Module 4)
- Lab 04 - 04-Agent-Safety : Sécurisez un agent sur-autorisé (Module 5)
- Lab 05 - 05-Secrets-and-Cost : Sécurisez les clés + ajoutez des garde-fous de coût (Module 6)
- Lab 06 - 06-Guardrails : Ajoutez une couche de garde-fou entrée/sortie (Module 7)
- Lab 07 - 07-Red-Teaming : Tests red-team automatisés dans CI (Module 8)
Le Module 1 (Comment les applications IA tombent en panne) n'a pas de lab — il s'exécute comme un parcours de l'architecture et discussion. Le Module 9 (Notation de la Sécurité IA) n'a pas de dossier de lab — il s'exécute comme un exercice de notation contre l'application Capstone.
Pré requis
- Niveau de compétence : Intermédiaire.
- Les étudiants doivent être à l'aise avec : la construction et la consommation d'APIs REST, un langage script (les labs utilisent Python), l'authentification applicative de base, git, et le CLI.
- Aucun background en apprentissage automatique n'est requis — il s'agit d'un cours de sécurité applicative pour ceux qui construisent avec des LLMs, pas pour ceux qui les entraînent.
Audience cible
- Ingénieurs logiciels / back-end développant des fonctionnalités LLM
- Développeurs full-stack et API
- Ingénieurs d'applications IA/ML
- Ingénieurs plateforme déployant des copilotes et agents
- Chefs techniques et ingénieurs seniors responsables des fonctionnalités IA
Nos clients témoignent (2)
J'ai vraiment apprécié d'apprendre sur les attaques par IA et les outils disponibles pour commencer à pratiquer et à utiliser activement pour les tests de sécurité. J'ai acquis beaucoup de connaissances que je n'avais pas au début, et le cours a répondu à mes attentes. Ma partie préférée de la formation était le navigateur Comet, et j'ai été impressionné par ce qu'il pouvait faire. C'est assurément quelque chose que je vais explorer davantage. Globalement, c'était un excellent cours et j'ai beaucoup apprécié d'apprendre le Top 10 OWASP GenAI.
Patrick Collins - Optum
Formation - OWASP GenAI Security
Traduction automatique
Les connaissances professionnelles et la manière dont il les a présentées devant nous
Miroslav Nachev - PUBLIC COURSE
Formation - Cybersecurity in AI Systems
Traduction automatique