Un système d’IA en production combine rarement un seul composant : LLM, RAG et bases vectorielles, function calling, agents orchestrés via MCP, infrastructure de MLOps et de model ser
ving. Chaque brique ajoutée élargit la surface d’attaque disponible, et la plupart des incidents documentés en 2025-2026 se logent précisément dans les zones d’assemblage entre ces briques, plus que dans le modèle de langage lui-même. Ce guide parcourt cinq briques d’architecture dans l’ordre où elles s’empilent généralement, avec pour chacune le ou les vecteurs de risque qui lui sont spécifiquement associés.
LLM : prompt injection, jailbreak et fuite du prompt système
Le modèle de langage lui-même constitue la brique la plus mature du point de vue sécurité, précisément parce qu’elle concentre le plus d’attention de recherche. Trois vecteurs la ciblent directement. L’infiltration de requête (prompt injection en anglais) insère des instructions malveillantes dans l’entrée traitée par le modèle, directement ou via un document consulté ; c’est le vecteur le plus documenté du moment, une majorité de déploiements en production y étant exposés d’une façon ou d’une autre. Le jailbreak vise à contourner les garde-fous d’alignement pour produire un contenu normalement refusé. La fuite du prompt système cible les instructions internes qui configurent le comportement d’une application, dont l’extraction peut révéler une logique métier ou faciliter une attaque plus ciblée.
Ces trois vecteurs partagent un point commun : ils ne disposent pas de parade absolue, la nature probabiliste d’un LLM rendant la protection, une question de réduction de surface et de détection continue plutôt que d’élimination complète.
RAG et bases vectorielles : le RAG poisoning
Le RAG enrichit les réponses d’un modèle avec des documents récupérés dans une base vectorielle au moment de la requête, un composant critique : souvent copie de données déjà sensibles ailleurs, avec une protection historiquement inférieure. Le risque associé, le RAG poisoning, consiste à injecter des documents malveillants dans cette base : des travaux récents démontrent qu’un nombre très réduit de documents empoisonnés suffit à influencer significativement les réponses générées, même dans un index de plusieurs millions de documents légitimes. Toute base alimentée par des sources non gouvernées (tickets clients, wiki interne, contenu scrapé) doit être traitée comme un canal d’injection indirecte à part entière.
Le chiffrement au repos et en transit, ainsi qu’un alignement de la durée de rétention des documents indexés sur celle des sources d’origine, restent des mesures de base souvent négligées en phase de prototype.
MCP, function calling et agents : permissions héritées et empoisonnement en amont
Le function calling permet à un modèle d’agir au-delà du texte ; le protocole MCP standardise cette connexion aux outils. Le principe de risque le plus structurant tient en une phrase : un agent IA agit avec ses propres permissions, et toute manipulation réussie, par exemple une injection de prompt indirecte dissimuléne dans un document consulté lui fait hériter de cette élévation de privilèges. C’est pourquoi la gestion des accès et identités IA devient une brique de sécurité à part entière dès qu’un agent dispose d’outils. Une CVE documentée début 2026 (CVE- 2026-4270 dans awslabs.aws) sur un serveur MCP largement utilisé illustre le schéma : une faille dans les restrictions d’accès aux fichiers exposait du contenu local arbitraire sans aucune compromission du modèle.
Les agents autonomes cumulent ce risque et y ajoutent la dérive d’objectif (sub-goal hijacking) ainsi qu’un risque de chaîne d’approvisionnement propre à leur écosystème : début 2026, un incident emblématique a illustré ce risque avec la marketplace Clawhub d’Openclaw a été touchée par une campagne de compétences (« skills ») malveillantes. Des chercheurs ont identifié 341 skills malveillants parmi 2 857 analysées, plusieurs servant à installer ou distribuer Atomic macOS stealer (AMOS), en se faisant passer pour des outils légitimes et en abusant de la confiance des utilisateurs ayant installé ces compléments. En amont de ces briques, le model poisoning vise le processus d’entraînement ou de fine-tuning lui-même, pour introduire un comportement caché dans le modèle final.
Infrastructure et modèle : extraction, inversion et slopsquatting
Sous les briques applicatives se trouvent le MLOps, le model serving et, pour la souveraineté, le self-hosted LLM. Deux vecteurs ciblent ici le modèle une fois entraîné : le model extraction, qui reconstitue une approximation du modèle via des requêtes répétées à son API, un risque de propriété intellectuelle, et le model inversion, qui reconstruit des informations sur les données d’entraînement à partir des réponses, un risque direct pour la confidentialité si ces données étaient sensibles.
Un vecteur plus récent touche la chaîne de développement associé à ces briques : le slopsquatting exploite le fait qu’un modèle générant du code mentionne parfois des noms de paquets qui n’existent pas
(20% des générations selon une étude réalisée par 3 universités), qu’un attaquant enregistre ensuite sur un registre public pour piéger les développeurs.
Deepfake, phishing IA et exfiltration : quand la cible est l’architecture elle-même
Deux familles de vecteurs ne ciblent aucune brique technique interne : le deepfake et le phishing assisté par IA utilisent l’IA comme arme contre l’entreprise depuis l’extérieur, sans nécessiter la moindre compromission de son système d’information. L’exfiltration de données, enfin, traverse toutes les briques précédentes ( saisie directe, réponse générée révélant un contenu confidentiel, ou agent disposant d’un accès excessif ) ce qui en fait moins un vecteur isolé qu’une conséquence possible de chacune des briques mal sécurisées ci-dessus.
Un seul référentiel pour prioriser : OWASP LLM Top 10
Ces briques et vecteurs recoupent largement les dix catégories de l’OWASP LLM Top 10, la grille la plus adoptée pour structurer un audit. Son intérêt pratique : répartir l’effort par équipe responsable (sécurité applicative pour le prompt injection, équipe data pour l’empoisonnement RAG, équipe plateforme pour la chaîne d’approvisionnement et le serving ) plutôt que traiter dix catégories comme une liste plate. Le facteur aggravant commun à l’ensemble de ces vecteurs reste la confiance humaine excessive envers les sorties d’un système d’IA : une part significative de la réduction de risque ne nécessite pas d’expertise en machine learning, mais l’application rigoureuse de principes déjà connus (moindre privilège, validation des entrées, vérification humaine) sur les actions à fort impact.
Questions fréquentes sur la sécurité des architectures IA
Faut-il sécuriser toutes les briques avec la même intensité ?
Un LLM récent et bien aligné suffit-il à limiter ces risques ?
Sécuriser votre architecture IA de bout en bout
Nos experts évaluent chaque brique de votre architecture et les vecteurs de risque associés, de la cartographie au pentest.
Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.