Depuis longtemps, nous avons appris à considérer les pièces jointes comme potentiellement dangereuses. Avec l’intelligence artificielle, il faut désormais envisager qu’un document parfaitement légitime puisse aussi chercher à influencer le système qui le lit. Un PDF peut ne contenir aucun malware, aucune macro, aucun exécutable et pourtant intégrer des instructions destinées à modifier le comportement d’une IA.

Un sujet qui modifie sensiblement la surface du risque, pour ne pas dire qu'il en créer une nouvelle. 

Quand ce que l’IA lit devient une surface d’attaque

Pendant longtemps, les risques liés à l’intelligence artificielle ont surtout été envisagés du côté de ses réponses : "hallucinations", résultats erronés, données sensibles divulguées ou décisions mal interprétées. Mais une autre problématique prend progressivement de l’ampleur. Elle ne concerne plus seulement ce que l’IA produit, mais aussi ce qu’on lui donne à lire.

Le 6 août 2026, une décision rendue par la Superior Court du district judiciaire d’Ansonia/Milford, dans le Connecticut, aux États-Unis, en a fourni un exemple concret. 

Dans l’affaire Elliott v. New York Bariatric Group, Matthew Elliott, un particulier qui assurait lui-même sa défense, avait intégré dans plusieurs documents déposés auprès du tribunal des instructions destinées à une éventuelle intelligence artificielle chargée de les analyser. Le texte était rédigé en caractères minuscules et blancs, de manière à être pratiquement invisible pour une personne lisant normalement le document, tout en restant lisible par un logiciel traitant son contenu. Les instructions demandaient à tout modèle d’intelligence artificielle qui analyserait les pièces de produire une réponse favorable à la position d’Elliott et de considérer une précédente décision du greffier comme une erreur à corriger en sa faveur.

Le tribunal n’utilisait pourtant pas d’intelligence artificielle pour examiner les documents. L’injection n’a donc eu aucun impact sur la décision rendue. Mais les instructions dissimulées pouvaient viser tout outil d’IA qu’un autre lecteur du document, notamment la partie adverse ou ses conseils, aurait utilisé pour l’analyser.

L’affaire ne s’est par ailleurs pas limitée à un seul dépôt. Malgré un avertissement du tribunal concernant la présence de contenus dissimulés, Elliott a continué à cacher des messages dans de nouvelles écritures. Cette récidive a pesé dans la décision du juge Walter M. Spader Jr., qui lui a finalement retiré le droit de déposer ses documents par voie électronique. 

Ses futurs dépôts devaient désormais être effectués au format papier. Le juge n’a ni rejeté son affaire ni empêché Elliott de poursuivre la procédure : la sanction porte uniquement sur le mode de dépôt. Cette affaire illustre un changement important : un document peut désormais être conçu non seulement pour être lu par une personne, mais aussi pour influencer un l'analysera à sa place.

Une instruction cachée dans un contenu légitime

Cette technique porte le nom de prompt injection. Dans sa forme la plus simple, un utilisateur cherche directement à convaincre un modèle d’ignorer certaines instructions pour en suivre de nouvelles. L’injection indirecte fonctionne différemment. L’auteur de l’attaque ne dialogue pas nécessairement avec l’IA qu’il souhaite influencer. Il place ses instructions dans une source externe que le système consultera plus tard : un document PDF, une page Web, un email, une invitation d’agenda, un ticket de support ou encore une ligne de journalisation. Lorsqu’un utilisateur demande ensuite à une IA de résumer ou d’analyser ce contenu, le modèle reçoit à la fois les informations qu’il doit traiter et les éventuelles instructions insérées à l’intérieur. C’est cette difficulté à distinguer le contenu à analyser des instructions à suivre qui constitue le cœur du problème.

Dans l’affaire Elliott v. New York Bariatric Group, la technique reposait sur du texte blanc dissimulé dans le document. Mais cette méthode n’est qu’une possibilité parmi d’autres. Une note publiée par la Cloud Security Alliance en avril 2026 synthétise plusieurs observations de terrain réalisées notamment par Google, Forcepoint X-Labs et Unit 42 sur des injections indirectes placées dans des pages Web et différents contenus destinés à être ingérés par des systèmes d’IA. Dans une étude portant sur plusieurs versions de Common Crawl, dont les archives mensuelles contiennent entre 2 et 3 milliards de pages, Google a observé une augmentation relative de 32 % de la proportion de pages contenant des injections indirectes malveillantes entre novembre 2025 et février 2026.

Du tribunal à l’entreprise

Le risque ne se limite évidemment pas au monde judiciaire. Les organisations utilisent désormais l'IA pour analyser une quantité croissante de contenus provenant de l’extérieur : CV, contrats, factures, rapports d’audit, documents fournisseurs, emails, pages Web ou encore tickets de support. À partir du moment où ces contenus sont confiés à une IA, ils deviennent également des entrées susceptibles d’influencer son comportement.

Un CV peut contenir une instruction destinée à un outil de présélection. Un document commercial peut tenter d’orienter le résumé produit par un assistant. Une page Web consultée par un agent peut chercher à modifier son comportement. Un rapport transmis par un tiers peut tenter d’influencer l’analyse qui en sera faite.

Ce raisonnement se transpose ainsi directement au monde de l’entreprise : Tout contenu externe analysé par une IA constitue une entrée qui doit être considérée avec prudence. La question n’est donc plus uniquement de savoir si un document contient un programme malveillant. Un fichier techniquement sain peut également transporter des instructions destinées non pas au système d’exploitation, mais au modèle chargé de l’interpréter.

Le risque augmente mécaniquement avec les agents IA

Les conséquences peuvent sembler limitées lorsque l’intelligence artificielle ne fait que produire un résumé. Une injection réussie peut alors provoquer une interprétation biaisée, masquer certaines informations ou orienter une conclusion. La situation change lorsque le modèle dispose également de capacités d’action.

De nombreux assistants sont désormais connectés à des messageries, des espaces documentaires, des outils métiers, des dépôts de code ou différentes applications SaaS. Certains agents peuvent rechercher des informations, envoyer des messages, modifier des fichiers ou déclencher des opérations à partir des contenus qu’ils analysent.

Dans ce contexte, une instruction injectée dans une source externe peut chercher à exploiter les droits accordés à l’agent. C’est ce passage de lire à agir qui modifie profondément le niveau de risque.

Les observations compilées par la Cloud Security Alliance montrent que l’injection indirecte n’est plus uniquement étudiée dans le cadre de démonstrations théoriques. Des charges visant notamment à déclencher des paiements, à provoquer l’exécution de commandes ou à récupérer des informations sensibles telles que des clés d’API ont été documentées en 2026. Plus un agent dispose d’autonomie et de droits sur le système d’information, plus les conséquences d’une manipulation réussie peuvent être importantes.

Un problème qui ne se résume pas au texte invisible

Il serait tentant de répondre à ce risque en recherchant simplement du texte blanc, des caractères invisibles ou des éléments dissimulés dans les documents. Ces contrôles peuvent être utiles, mais ils ne suffisent pas.

La véritable faiblesse ne réside pas dans la couleur du texte. Elle réside dans la capacité d’un contenu externe à introduire des instructions dans le cadre utilisé par le modèle. Une instruction peut donc être parfaitement visible et malveillante.

La réponse doit être pensée comme une problématique de sécurité plus globale. Tout contenu provenant de l’extérieur et destiné à être traité par une intelligence artificielle doit être considéré comme une entrée potentiellement non fiable.

Le recensement de ses sources externes qui alimentent les IA d'un groupe industriel, doit intéresser au plus au point ses assureurs dans le cadre de l'évaluation du risque. 

L’ANSSI évoquait déjà cette problématique dans ses recommandations de sécurité pour les systèmes d’IA générative publiées en avril 2024. Elle mentionne explicitement les risques d’injection de requête indirecte pouvant provenir, par exemple, du contenu d’un email reçu ou d’une page Web issue d’une recherche. Elle recommande également de protéger les systèmes d’IA en filtrant les entrées et les sorties des utilisateurs et de maîtriser leurs interactions avec les autres applications métier.

Comment se protéger, quelles mesures mettre en place ?

La première étape consiste à identifier les systèmes d’IA qui ingèrent automatiquement des contenus provenant de sources externes. Pour chacun d’entre eux, l’organisation doit connaître les données auxquelles ils ont accès, les outils qu’ils peuvent utiliser et les actions qu’ils sont capables d’effectuer. Le principe du moindre privilège reste essentiel.

Un agent chargé de résumer des documents ne devrait pas disposer, sans nécessité, de permissions lui permettant d’envoyer des emails, de modifier des données ou d’exécuter des actions sur le système d’information. Les actions sensibles doivent également conserver un mécanisme de validation humaine. Les interactions entre l’IA et les applications métier doivent être contrôlées et journalisées afin de pouvoir détecter un comportement inhabituel ou une tentative de manipulation.

Ces principes rejoignent directement plusieurs recommandations de l’ANSSI. La recommandation R25 préconise de protéger le système d’IA en filtrant les entrées et les sorties des utilisateurs, tandis que la R26 porte sur la maîtrise et la sécurisation des interactions avec les autres applications métier. La recommandation R9 préconise de proscrire l’usage automatisé de systèmes d’IA pour des actions critiques sur le SI. 

La R27 recommande de limiter les actions automatiques lorsqu’un système d’IA traite des entrées non maîtrisées, tandis que la R29 porte sur la journalisation de l’ensemble des traitements réalisés au sein du système. Enfin, les résultats produits par une intelligence artificielle à partir de documents externes ne doivent pas être considérés comme intrinsèquement fiables. Un résumé cohérent peut être biaisé. Une analyse convaincante peut avoir été influencée par le contenu qu’elle devait simplement examiner.

Autant de points importants qu'un souscripteur avisé pourra vérifier auprès de son assuré. 

Pendant des années, la cybersécurité nous a appris à nous demander ce qu’un fichier pouvait exécuter. Avec l’intégration croissante de l’intelligence artificielle dans les processus métiers, une nouvelle question devient nécessaire : que peut-il faire exécuter à l’IA qui le lit ?