Chapitre 1 — Pourquoi la sécurité de l'IA est différente

Premier billet de la tournée chapitre par chapitre de LLM Primer VII : Sécurité de l'IA. Le chapitre qui soutient que la sécurité IA n'est pas de la sécurité traditionnelle avec un adjectif ML collé devant — le substrat a changé, et chaque chapitre suivant découle de ce changement.

Pourquoi ce chapitre existe

Pendant trois décennies, l'ingénierie de la sécurité a reposé sur une fondation stable : le code et les données sont différents, les vulnérabilités sont des écarts entre le comportement spécifié et le comportement réel, et les correctifs les referment. Les grands modèles de langage brisent cette fondation d'une manière précise. Le comportement à défendre n'est pas encodé dans du code source mais dans des milliards de poids appris, exécutés contre des entrées qui mélangent instructions de confiance et contenu non fiable dans la même chaîne. La « vulnérabilité » n'est souvent pas un bug — c'est le modèle qui fait exactement ce pour quoi il a été entraîné, dans un contexte que les concepteurs n'avaient pas prévu. Il n'existe aucun correctif pour « le modèle a été trop serviable ». Il n'y a que la refonte, le réentraînement ou du confinement supplémentaire. Ce chapitre nomme les différences structurelles qui façonnent tout ce qui suit.

1.1 Le substrat a changé

La sécurité applicative traditionnelle fonctionne parce que le comportement est spécifié dans le code et les défauts sont localisables. L'injection SQL a un correctif structurel — les requêtes paramétrées — parce qu'il existe une distinction syntaxique entre requête et paramètre. Un modèle de langage n'a pas cette spécification. Il a un objectif d'entraînement et une distribution de poids, et son comportement sur une entrée donnée est émergent. Quand un modèle refuse une formulation et accepte l'autre, il n'y a pas de ligne à corriger. La question de sécurité passe de « y a-t-il un bug dans ce chemin de code » à « de quoi ce système est-il capable, et sous quelles conditions cette capacité devient-elle dangereuse ? » La sécurité traditionnelle supposait aussi le déterminisme comme référence ; ici la référence est probabiliste. Un filtre de sécurité qui réussit sur mille cas de test peut échouer sur le mille-et-unième parce que l'échantillonnage a tiré un chemin différent. Le défenseur raisonne en distributions et en intervalles de confiance, non en preuves d'inatteignabilité. L'OWASP Top 10 pour les applications LLM, révisé en 2025, est une tentative de nommer cette nouvelle couche — avec l'injection de prompt en LLM01 et la consommation illimitée en LLM10 — mais c'est un plancher au-dessus du plancher applicatif web existant, pas un remplacement.

1.2 La surface d'attaque s'élargit

Une application intégrant un LLM introduit des surfaces qui n'existaient pas auparavant. Le prompt lui-même est une concaténation d'instructions du développeur, de contexte récupéré, d'entrée utilisateur et de sorties d'outils — tous sous forme de tokens que le modèle lit sans frontière de confiance native. Si l'utilisateur peut influer sur une partie quelconque, il partage le même canal que le développeur. Le chemin de récupération est la deuxième nouvelle surface : chaque document indexé devient une entrée indirecte, et quiconque peut influer sur ce qui entre dans l'index peut influer sur ce que le modèle voit. Greshake et ses collègues ont nommé cela l'injection indirecte de prompt en 2023 et montré que le canal était à la fois réel et difficile à fermer. La frontière d'usage d'outils est la troisième : chaque outil accordé au modèle est un privilège dont les conséquences quittent le texte de réponse et atteignent des systèmes réels. Le pipeline d'entraînement est la quatrième, puisque toute donnée utilisée pour mettre à jour le modèle devient partie de la frontière de confiance. L'artefact du modèle est la cinquième — de grandes binaires dont la désérialisation, comme l'a démontré CVE-2024-3568, peut exécuter du code au chargement. Le traitement des sorties est la sixième, puisque le contenu généré par le modèle et transmis en aval est une entrée non fiable sous un autre nom. MITRE ATLAS catalogue les tactiques et techniques contre cette surface élargie.

1.3 Les modèles deviennent de l'infrastructure

Entre 2012 et 2022, les modèles étaient des fonctionnalités à l'intérieur des applications. Un système de recommandation qui échouait produisait de moins bonnes recommandations. Les grands modèles de langage, surtout avec l'usage d'outils, ont changé cela. Le modèle est de plus en plus la couche d'orchestration — lisant des documents, décidant quel outil appeler, rédigeant le message, générant le code qu'un autre composant exécute. C'est souvent le composant le plus puissant du système, et c'est aussi le plus malléable, piloté par des entrées en langage naturel que n'importe qui peut rédiger. Une base de données traditionnelle a des langages de requête et des contrôles d'accès ; un LLM agissant comme orchestrateur n'a aucune de ces contraintes intrinsèques, seulement celles que l'application environnante a ajoutées. C'est ce que signifie « infrastructure » ici : des composants porteurs dont la compromission se propage. L'infrastructure reçoit des SLO définis, une journalisation exhaustive, un contrôle du changement et une réponse aux incidents. La plupart des déploiements LLM en 2024 et 2025 n'avaient pas encore atteint cette maturité. Le cadrage infrastructure atteint aussi l'approvisionnement : quand une organisation intègre un service LLM managé dans sa pile, la discipline de mise à jour du modèle, les portes d'évaluation et les pratiques de divulgation du fournisseur deviennent partie du profil de risque de l'acheteur.

Ce que prépare le Chapitre 1

Le reste du livre est une réponse aux glissements structurels nommés ici. Le chapitre 2 introduit la modélisation des menaces adaptée aux systèmes LLM — les cadres STRIDE et PASTA tournés vers des actifs, des adversaires et des surfaces d'attaque qui n'apparaissent pas sur les diagrammes conventionnels. Le chapitre 3 travaille la dimension données sur tout son cycle de vie. Les chapitres 4 à 6 parcourent l'intérieur prompt-et-interaction : injection, filtrage et RAG. Les chapitres 7 à 9 parcourent la couche modèle. Les chapitres 10 à 12 parcourent l'architecture système autour. Les chapitres 13 à 15 ajoutent le périmètre réglementaire, l'IA responsable et l'organisation. Le chapitre 16 traite le fine-tuning comme sa propre surface de sécurité, et le chapitre 17 regarde les menaces qui se dessinent encore. Tout l'arc repose sur la prémisse que ce chapitre a établie : le substrat a changé, et la discipline doit changer avec lui.

Prochaine étape — Chapitre 2 : Modélisation des menaces pour les systèmes LLM. Les quatre questions de Shostack, STRIDE et PASTA contre les actifs LLM, et MITRE ATLAS comme catalogue de tactiques pour les adversaires que cette nouvelle surface attire.