La semaine derni\u00e8re, nous avons examin\u00e9 pourquoi l’injection indirecte de commandes (indirect prompt injection) est devenue l’un des risques les plus urgents pour les \u00e9quipes de s\u00e9curit\u00e9 en 2026, class\u00e9e par l’OWASP comme le risque num\u00e9ro un pour les applications LLM et d’intelligence artificielle g\u00e9n\u00e9rative, et d\u00e9j\u00e0 li\u00e9e \u00e0 des incidents confirm\u00e9s d’exfiltration de donn\u00e9es, de paiements non autoris\u00e9s et m\u00eame d’ex\u00e9cution de code \u00e0 distance. La question naturelle qui suit est de savoir quoi faire concr\u00e8tement.<\/p>\n
La bonne nouvelle, c’est qu’il ne s’agit pas d’un probl\u00e8me insoluble. C’est un probl\u00e8me nouveau, qui exige un \u00e9tat d’esprit diff\u00e9rent de celui de la s\u00e9curit\u00e9 applicative traditionnelle, mais un ensemble croissant de recommandations concr\u00e8tes \u00e9mane d’organisations comme l’OWASP et OpenAI sur la mani\u00e8re de concevoir et d’exploiter des agents d’IA capables de r\u00e9sister \u00e0 une attaque. Voici cinq pratiques qu’il vaut la peine de mettre en place d\u00e8s maintenant.<\/p>\n
Le chercheur Simon Willison a d\u00e9crit un sch\u00e9ma qu’il appelle la \u00ab trifecta l\u00e9tale \u00bb, et il constitue un cadre utile pour toute \u00e9quipe de s\u00e9curit\u00e9 \u00e9valuant des agents d’IA. Un agent devient v\u00e9ritablement dangereux lorsqu’il combine trois \u00e9l\u00e9ments \u00e0 la fois : l’acc\u00e8s \u00e0 des donn\u00e9es priv\u00e9es, l’exposition \u00e0 du contenu externe non fiable, comme des courriels ou des pages web, et la capacit\u00e9 de communiquer vers l’ext\u00e9rieur, que ce soit en envoyant des donn\u00e9es, en appelant une API ou en affichant un lien. Chacun de ces \u00e9l\u00e9ments pris isol\u00e9ment reste g\u00e9rable. R\u00e9unis, ils signifient qu’un attaquant capable d’ins\u00e9rer des instructions dans le contenu que votre agent lit pourrait repartir avec tout ce que cet agent peut voir.<\/p>\n
Avant de mettre un agent en production, posez-vous une question simple : poss\u00e8de-t-il ces trois capacit\u00e9s \u00e0 la fois ? Si c’est le cas, traitez-le comme un syst\u00e8me \u00e0 haut risque n\u00e9cessitant les contr\u00f4les d\u00e9crits ci-dessous, et non comme une application standard qui re\u00e7oit une revue de routine avant d’\u00eatre d\u00e9ploy\u00e9e.<\/p>\n
Attribuez aux agents des identifiants limit\u00e9s \u00e0 leur p\u00e9rim\u00e8tre plut\u00f4t qu’un acc\u00e8s \u00e9tendu aux syst\u00e8mes qu’ils touchent, et imposez de v\u00e9ritables limites aux actions \u00e0 fort impact comme les paiements, les suppressions et l’ex\u00e9cution de code. Pensez-y comme vous le feriez pour un nouvel employ\u00e9. Un repr\u00e9sentant du service client humain dispose g\u00e9n\u00e9ralement d’un plafond de remboursement et doit obtenir une validation au-del\u00e0. Vos agents d’IA m\u00e9ritent la m\u00eame rigueur. Si un agent n’a pas besoin de pouvoir supprimer des enregistrements ou d\u00e9placer des fonds, il ne devrait tout simplement pas en avoir la capacit\u00e9.<\/p>\n
Une part importante des attaques par injection de commandes observ\u00e9es dans le monde r\u00e9el fonctionne parce qu’il n’existe aucune fronti\u00e8re claire entre ce qu’un syst\u00e8me a re\u00e7u comme instruction et ce qu’il lit par ailleurs en l’ex\u00e9cutant. Concevez vos prompts de fa\u00e7on \u00e0 ce que le contenu externe (pages web, documents, courriels, journaux d’activit\u00e9) soit clairement s\u00e9par\u00e9 des instructions au niveau du syst\u00e8me, et ajoutez le filtrage des entr\u00e9es et des sorties comme une couche suppl\u00e9mentaire, non comme votre seule ligne de d\u00e9fense. Le filtrage rep\u00e8re les sch\u00e9mas connus. La s\u00e9paration structurelle est ce qui vous prot\u00e8ge contre ceux que personne n’a encore vus.<\/p>\n
Toute action ayant de r\u00e9elles cons\u00e9quences financi\u00e8res, op\u00e9rationnelles ou de perte de donn\u00e9es doit passer par une validation humaine avant son ex\u00e9cution. Il ne s’agit pas de ralentir vos \u00e9quipes sur tous les fronts. Il s’agit d’\u00eatre pr\u00e9cis sur les actions pouvant s’ex\u00e9cuter de mani\u00e8re autonome et celles qui m\u00e9ritent un second regard, la m\u00eame distinction que vous appliqueriez d\u00e9j\u00e0 \u00e0 une demande de virement bancaire ou \u00e0 une modification d’une base de donn\u00e9es de production.<\/p>\n
C’est la pratique que la plupart des organisations n’ont pas encore mise en place, et c’est celle qui compte le plus. Les analyses de vuln\u00e9rabilit\u00e9s standards et les revues de code ne d\u00e9tecteront pas l’injection de commandes, car la faille r\u00e9side dans la fa\u00e7on dont le syst\u00e8me traite le contenu, et non dans une portion de code dot\u00e9e d’une signature connue. C’est pr\u00e9cis\u00e9ment pour cette raison que l’injection de commandes peut occuper la premi\u00e8re place des pr\u00e9occupations des experts en s\u00e9curit\u00e9 tout en apparaissant beaucoup plus rarement dans les registres traditionnels d’incidents et de vuln\u00e9rabilit\u00e9s : les outils que la plupart des programmes utilisent d\u00e9j\u00e0 n’ont jamais \u00e9t\u00e9 con\u00e7us pour la d\u00e9tecter.<\/p>\n
La seule fa\u00e7on fiable de savoir si vos agents r\u00e9sistent r\u00e9ellement est de les tester comme le ferait un attaquant, en traitant le mod\u00e8le lui-m\u00eame comme une partie non fiable et en examinant les int\u00e9grations d’outils, les permissions et l’acc\u00e8s aux donn\u00e9es qui le sous-tendent, et pas seulement les r\u00e9ponses du mod\u00e8le prises isol\u00e9ment. C’est exactement l\u00e0 que les tests d’intrusion sp\u00e9cialis\u00e9s en IA et LLM font toute la diff\u00e9rence. Les tests de s\u00e9curit\u00e9 pour l’IA g\u00e9n\u00e9rative et les LLM d’Orenda sont con\u00e7us pr\u00e9cis\u00e9ment autour de ce mod\u00e8le de menace, en \u00e9valuant comment un agent se comporte face \u00e0 un contenu manipul\u00e9 et o\u00f9 ses permissions et int\u00e9grations d’outils pourraient \u00eatre d\u00e9tourn\u00e9es. Associ\u00e9s \u00e0 des exercices de red team et \u00e0 une gestion continue des vuln\u00e9rabilit\u00e9s, ils vous apportent une r\u00e9ponse r\u00e9elle, fond\u00e9e sur des preuves plut\u00f4t que sur des suppositions, \u00e0 la question que tout RSSI d\u00e9ployant des agents d’IA devrait se poser : si quelqu’un tentait cela contre nous aujourd’hui, est-ce que cela fonctionnerait ?<\/p>\n
Aucune de ces cinq pratiques n’exige de ralentir vos initiatives en mati\u00e8re d’IA. Elles exigent que vous les construisiez avec la m\u00eame rigueur que celle que vous appliquez d\u00e9j\u00e0 \u00e0 vos r\u00e9seaux, vos applications et vos environnements cloud : savoir ce que vous exposez, limiter ce qui peut mal tourner, et tester r\u00e9guli\u00e8rement face \u00e0 de v\u00e9ritables techniques d’attaque plut\u00f4t que de supposer que tout va bien simplement parce que rien ne s’est encore produit.<\/p>\n","protected":false},"excerpt":{"rendered":"
La semaine derni\u00e8re, nous avons examin\u00e9 pourquoi l’injection indirecte de commandes (indirect prompt injection) est devenue l’un des risques les plus urgents pour les \u00e9quipes de s\u00e9curit\u00e9 en 2026, class\u00e9e par l’OWASP comme le risque num\u00e9ro un pour les applications LLM et d’intelligence artificielle g\u00e9n\u00e9rative, et d\u00e9j\u00e0 li\u00e9e \u00e0 des incidents confirm\u00e9s d’exfiltration de donn\u00e9es, […]<\/p>\n","protected":false},"author":1,"featured_media":3596,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[37,42],"tags":[],"class_list":["post-3607","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-meilleurs-pratiques","category-securite-de-linformation","has-post-title","has-post-date","has-post-category","has-post-tag","has-post-comment","has-post-author",""],"yoast_head":"\n