Aller au contenu
Chapitre 01 · 10 min

La nouvelle surface d'attaque

Les systèmes d'IA brisent le postulat sur lequel repose toute la sécurité : celui qui permet de séparer les instructions des données. Dès qu'un modèle traite les deux comme un même flux de texte, une génération de sagesse chèrement acquise en sécurité doit être repensée. Ce chapitre explique pourquoi.

The trust boundary an LLM erasesIn a normal app, data and instructions are separate. In an LLM app, the prompt mixes trusted instructions with untrusted user and document text in the same channel, so the model cannot tell a command from content.ONE PROMPT, ONE CHANNELtrustedsystem rulesuntrusteduser inputuntrustedretrieved textthe model reads all three as one stream — it cannot see the dashed lines

“Vous avez engagé un assistant brillant qui croit tout ce qu'il lit — et vous lui avez remis les clés.”

La frontière qui s'efface

Dans une application ordinaire, le code est du code et les données sont des données. Une requête SQL est un ensemble d'instructions ; le nom de l'utilisateur est une donnée. Des décennies de pratique en sécurité — validation des entrées, requêtes paramétrées, échappement — existent pour maintenir cette ligne nette. Toute la discipline de la défense contre les injections vise à empêcher les données de devenir des instructions.

Un modèle de langage efface cette ligne. Le prompt est un seul flux de texte contenant vos instructions, les entrées de l'utilisateur et tout document récupéré — et le modèle lit l'ensemble comme des instructions qu'il pourrait suivre. Il n'existe aucune syntaxe qui dise « cette partie est une donnée, ne lui obéis pas ». Le modèle décide ce qu'il traite comme une commande, et il décide mal sous pression.

The trust boundary an LLM erasesIn a normal app, data and instructions are separate. In an LLM app, the prompt mixes trusted instructions with untrusted user and document text in the same channel, so the model cannot tell a command from content.ONE PROMPT, ONE CHANNELtrustedsystem rulesuntrusteduser inputuntrustedretrieved textthe model reads all three as one stream — it cannot see the dashed lines
Les règles de confiance, les entrées non fiables de l'utilisateur et le texte récupéré non fiable arrivent dans un même canal. Le modèle ne voit pas les lignes pointillées.

Les frontières de confiance, redessinées

La sécurité commence par une question : à quoi faites-vous confiance, et où le fiable rencontre-t-il le non fiable ? Avec un LLM, la réponse honnête est inconfortable. Tout ce que le modèle lit — messages de l'utilisateur, documents récupérés, sorties d'outils, contenu d'une page web qu'il a parcourue — est non fiable et pourrait porter des instructions. Et tout ce que le modèle peut faire — appeler des outils, retourner des données, déclencher des actions — est une capacité qu'un attaquant peut tenter d'emprunter.

Pourquoi l'ancienne stratégie ne suffit plus

La sécurité applicative traditionnelle s'applique toujours — l'authentification, l'autorisation, le chiffrement et le reste demeurent nécessaires. Mais elle a été conçue pour des systèmes déterministes dotés de grammaires d'entrée claires. Un LLM n'a pas de grammaire d'entrée ; une « entrée valide », c'est n'importe quel texte dans n'importe quelle langue, y compris du texte conçu pour manipuler le modèle. On ne peut pas écrire une expression régulière pour la malveillance exprimée en français courant.

La sécurité de l'IA est donc additive, non un remplacement. Vous conservez tout ce que vous faites déjà, et vous ajoutez une couche pour les modes de défaillance propres au modèle : le suivi d'instructions provenant de contenu non fiable, la divulgation de ce qu'on lui a confié, le fait d'être convaincu de contourner ses garde-fous, et les actions dépassant ce que vous aviez prévu. Les cinq prochains chapitres traitent de ces modes de défaillance ; le dernier porte sur la gouvernance de l'ensemble.

Une carte de ce qui peut tourner mal

La communauté s'est ralliée autour d'une taxonomie approximative — le OWASP Top 10 pour les applications LLM en est la version la plus citée, et mérite d'être lue en entier. Les risques principaux se regroupent en quelques familles :

  • Injection de prompt — du contenu non fiable détourne les instructions du modèle (chapitre 2).
  • Divulgation d'informations sensibles — le modèle divulgue des données qu'on lui a fournies ou sur lesquelles il a été entraîné (chapitre 3).
  • Contournements et abus — le modèle est guidé au-delà de ses garde-fous de sécurité (chapitre 4).
  • Risques liés à la chaîne d'approvisionnement — données empoisonnées, modèles compromis, paquets et outils malveillants (chapitre 5).
  • Agentivité excessive — le modèle est autorisé à faire plus qu'il ne devrait en toute sécurité (thème transversal).

Aucun de ces risques n'est exotique. Ce sont les conséquences prévisibles d'un système qui suit des instructions en langage naturel et que vous avez relié à des capacités réelles. Les comprendre constitue l'essentiel de la défense.

En une ligne chacun

  • Les LLM effacent la frontière instructions/données sur laquelle repose la sécurité classique — tout ce qui se trouve dans le prompt est lu comme des instructions potentielles.
  • Traitez chaque jeton que le modèle lit comme non fiable, et chaque action qu'il peut accomplir comme potentiellement détournée.
  • La sécurité de l'IA est additive : conservez toute la sécurité applicative traditionnelle, et ajoutez une couche pour les modes de défaillance propres au modèle.
  • Les taxonomies standards (OWASP LLM Top 10, MITRE ATLAS) sont une carte utile, non une défense — elles orientent votre modélisation des menaces, elles ne la remplacent pas.

Où aller ensuite

La nouvelle surface d'attaque · Cours d'IA · SDEN