“Les serrures empêchent les honnêtes gens de dévier. La gouvernance, c'est la paperasse qui prouve que vous avez bien posé les serrures.”
Modélisez délibérément les menaces de votre système d'IA
Avant les cadres, la pratique fondamentale : asseyez-vous et raisonnez sur votre système spécifique. Quels sont les actifs (données, capacités, réputation) ? Qui pourrait l'attaquer et pourquoi ? Où se trouvent les frontières de confiance ? Quelle est la pire chose qu'un modèle compromis pourrait faire ? Les méthodes classiques de modélisation des menaces comme STRIDE s'adaptent facilement à l'IA — vous ajoutez simplement les modes de défaillance du modèle à la liste.
Le résultat est une liste de risques prioritaires liés à votre architecture, qui vous indique où investir les défenses du chapitre précédent. Une liste de vérification générique vous dit ce qui est possible ; un modèle de menaces vous dit ce qui compte ici. Faites le modèle de menaces.
Les cadres à connaître
Vous n'avez pas besoin de mémoriser les normes, mais vous devriez connaître la carte, parce que les clients et les auditeurs s'y référeront :
- NIST AI Risk Management Framework — un cadre américain volontaire pour identifier et gérer les risques de l'IA tout au long du cycle de vie d'un système. Un point de référence courant ; en Europe, l'AI Act et les lignes directrices de la CNIL font autorité.
- OWASP Top 10 pour les applications LLM — la liste du praticien des vulnérabilités LLM les plus critiques ; correspond directement aux chapitres 2 à 5.
- MITRE ATLAS — une base de connaissances des tactiques adversariales réelles contre les systèmes d'IA, modélisée sur le cadre ATT&CK.
- SOC 2 — pas spécifique à l'IA, mais le rapport de confiance que les grandes entreprises européennes demandent ; vos fonctionnalités IA entrent dans son périmètre.
- Règles sectorielles et régionales — RGPD, exigences HDS pour la santé, DSP2 pour la finance, et l'AI Act ; CCPA/CPRA et HIPAA si vous touchez le marché américain.
Assurance : le prouver à quelqu'un d'autre
L'assurance est la preuve que votre sécurité existe et fonctionne. Pour un acheteur d'entreprise, « faites-nous confiance » n'est pas une réponse ; il doit le voir. Cela signifie des politiques (règles écrites sur la façon dont l'IA est construite et utilisée), des contrôles documentés (ce que vous faites et pourquoi), des pistes d'audit (les journaux et traces du chapitre 6, servant de preuves), et un historique de tests (vos découvertes d'équipe rouge et leurs correctifs).
C'est là que le positionnement de SDEN rejoint le travail technique : la conformité avec SOC 2 et le RGPD n'est pas une surcharge bureaucratique boulonnée à la fin — c'est le résultat naturel d'avoir bien fait le travail d'ingénierie et de l'avoir documenté. Un système construit avec les contrôles de ce cours produit les preuves presque comme sous-produit. Un système qui ne l'a pas fait ne peut pas les simuler.
La gouvernance comme processus vivant
La gouvernance échoue quand c'est un document rédigé une fois et classé. Les systèmes d'IA changent chaque semaine — nouveaux prompts, nouveaux modèles, nouveaux outils, nouvelles données — et chaque changement peut modifier le tableau des risques. La gouvernance doit être un processus qui suit le rythme : une étape de révision des changements qui demande « cela affecte-t-il nos risques ou nos contrôles », une réévaluation périodique, et une responsabilité claire pour que la sécurité ne soit pas la tâche de tout le monde et donc de personne.
- Responsabilité — une personne ou une équipe nommée responsable de la sécurité de l'IA, pas un diffus « nous y tenons tous ».
- Révision des changements — les changements de modèle, de prompt, d'outil et de données passent par une vérification légère des risques, pas seulement une évaluation de la qualité.
- Réévaluation périodique — le modèle de menaces et les contrôles sont révisés selon un calendrier, pas seulement après un incident.
- Réponse aux incidents — un plan éprouvé pour quand quelque chose passe, incluant qui décide de retirer la fonctionnalité.
- Gestion des fournisseurs — les décisions de confiance envers les fournisseurs et les outils du chapitre 5, suivies et révisées.
Par où aller à partir d'ici
Vous avez maintenant l'arc complet : la nouvelle surface d'attaque, les menaces qui y résident, les défenses en couches qui fonctionnent, et la gouvernance qui les prouve et les pérennise. Le fil directeur est simple — vous ne pouvez pas faire confiance au modèle, donc vous le contraignez, le surveillez et le documentez. Associez ceci au cours sur la construction avec l'IA pour l'ingénierie, et le travail de sécurité de SDEN est exactement cette discipline appliquée à des systèmes réels sous des obligations réelles.
En une ligne chacun
- Modélisez les menaces de votre système spécifique (STRIDE plus les modes de défaillance des LLM) — une liste générique dit ce qui est possible ; un modèle de menaces dit ce qui compte ici.
- Connaissez la carte des cadres — NIST AI RMF, OWASP LLM Top 10, MITRE ATLAS, SOC 2 — comme structure partagée, pas comme substitut aux vrais contrôles.
- L'assurance consiste à le prouver avec des politiques, des contrôles documentés, des pistes d'audit et un historique de tests — le sous-produit naturel d'une ingénierie bien faite.
- La gouvernance doit être un processus vivant : responsabilité claire, révision des changements, réévaluation périodique et plan d'incident éprouvé.