Empoisonnement de l’IA par injection : comment ISO 42001 aide à protéger votre entreprise

Sécurité de l’IA : pourquoi les attaques par injection représentent-elles un risque pour l’entreprise ?

Une IA générative peut sembler parfaitement maîtrisée jusqu’au jour où quelqu’un parvient à lui faire faire exactement ce qu’elle ne devrait pas faire.

C’est tout le problème de l’injection de prompt dans une intelligence artificielle. L’attaquant formule ou introduit des instructions destinées à influencer le comportement du modèle, à contourner certaines consignes ou à provoquer une réponse qui n’était pas prévue.

Et l’attaque n’arrive pas forcément directement par la fenêtre de conversation.

Avec une injection indirecte de prompt dans un système IA, l’instruction malveillante peut se trouver dans un contenu auquel l’IA accède : document, page web ou autre source de données.

Imaginez un collaborateur consciencieux qui reçoit un dossier apparemment légitime contenant, entre deux pages, l’ordre secret d’ignorer toutes les règles de son entreprise. C’est, de façon simplifiée, le type de problème auquel une IA connectée à des sources externes peut être confrontée.

Pour une entreprise, la question n’est donc plus seulement : « Notre IA fonctionne-t-elle correctement ? »

Elle devient : « Que se passe-t-il lorsqu’un tiers cherche volontairement à détourner son fonctionnement ? »

Protection des systèmes IA : quels risques juridiques et réputationnels faut-il anticiper ?

Le cas Eurostar permet de rendre ce risque concret.

En 2025, des chercheurs de Pen Test Partners ont étudié le chatbot public d’Eurostar dans le cadre du programme de divulgation de vulnérabilités de l’entreprise.

Leurs recherches ont mis en évidence quatre problèmes de sécurité, parmi lesquels un contournement des garde-fous et une divulgation d’informations par prompt injection. Après avoir contourné certaines protections, les chercheurs ont notamment réussi à obtenir des informations sur le modèle puis à extraire le system prompt du chatbot.

Ils ont également démontré une possibilité d’injection HTML dans les réponses du système.

Il faut cependant apporter une précision essentielle : il ne s’agissait pas d’une cyberattaque malveillante contre Eurostar, mais de vulnérabilités exploitées dans le cadre d’un test de sécurité autorisé. Les chercheurs précisent également que leurs essais n’ont pas exposé les données d’autres utilisateurs.

Ce cas reste particulièrement intéressant pour une entreprise : une vulnérabilité aux attaques par injection de prompt peut révéler des informations sur le fonctionnement d’un système et, combinée à d’autres faiblesses, ouvrir la voie à des scénarios plus problématiques.

Une vulnérabilité technique ne reste d’ailleurs pas nécessairement un problème technique.

Supposons qu’un chatbot soit manipulé et fournisse une information confidentielle, produise un contenu préjudiciable ou oriente un utilisateur vers une destination malveillante.

Très vite, plusieurs questions apparaissent : quelles données étaient accessibles au système ? Les risques avaient-ils été évalués ? Des mesures de contrôle existaient-elles ? Qui surveillait le système après sa mise en production ?

C’est ici que les risques de sécurité liés aux IA génératives rejoignent les risques juridiques, organisationnels et réputationnels.

L’expérience de DPD au Royaume-Uni, en 2024, offre une illustration particulièrement parlante du risque d’image.

Après avoir rencontré des difficultés avec le chatbot du transporteur, un utilisateur a expérimenté différentes instructions et réussi à lui faire produire des propos grossiers et à critiquer DPD. Les résultats ont été publiés sur les réseaux sociaux et ont largement circulé. L’entreprise a ensuite désactivé la partie de son chatbot utilisant l’IA concernée.

Ce cas ne doit pas être présenté comme la preuve d’une fuite de données ni nécessairement comme une prompt injection sophistiquée. Il montre en revanche parfaitement ce qui peut arriver lorsque des utilisateurs parviennent à détourner le comportement attendu d’une IA accessible au public.

Pas besoin d’une spectaculaire fuite de millions de données pour provoquer un problème d’image. Quelques réponses incontrôlées peuvent suffire à transformer un outil destiné à améliorer l’expérience client en sujet médiatique embarrassant.

C’est pourquoi la gouvernance des risques liés à l’intelligence artificielle doit aller au-delà de la seule performance du modèle.

L’entreprise doit s’intéresser à son contexte d’utilisation, aux données auxquelles il accède, aux comportements indésirables envisageables, aux contrôles mis en place et à la manière dont un incident sera détecté et traité.

Cybersécurité de l’intelligence artificielle : comment une injection malveillante peut-elle mettre l’entreprise en difficulté ?

La Suisse fournit justement un exemple intéressant de cette évolution.

Dans son rapport consacré à son premier contrôle d’une application d’intelligence artificielle, l’autorité de protection des données du canton de Zurich a explicitement identifié les attaques par prompt injection parmi les risques techniques propres aux systèmes d’IA.

L’autorité explique que des utilisateurs peuvent chercher, au moyen d'entrées ciblées, à influencer ou détourner le système, notamment afin de lui faire produire des contenus indésirables, effectuer des tâches étrangères à sa finalité ou contourner ses mécanismes de protection.

Attention, là encore, à la nuance : le document zurichois ne rapporte pas une attaque par prompt injection effectivement subie par l’application contrôlée. Il démontre en revanche qu’une autorité suisse de protection des données considère désormais ce scénario comme un risque technique devant être pris en compte dans l’analyse d’un système d’IA.

Le signal envoyé aux entreprises est important.

La prévention des attaques par injection de prompt ne relève plus uniquement d’une discussion entre spécialistes de cybersécurité. Elle s’inscrit dans une réflexion plus large sur la protection des données, la transparence, la traçabilité et la maîtrise des systèmes d’IA.

Une entreprise doit donc pouvoir répondre à des questions très concrètes : comment détecter une attaque par injection de prompt ? Comment protéger un LLM contre les prompt injections ? Quelles bonnes pratiques permettent de sécuriser une IA générative ?

Et surtout : peut-elle démontrer que ces questions ont été posées avant l’incident ?

C’est précisément à cet endroit que la gestion des risques IA avec ISO 42001 devient intéressante.

La norme ne constitue pas une baguette magique capable d’empêcher chaque attaque. Elle apporte autre chose : un cadre de management permettant à l’organisation de structurer la gouvernance de ses systèmes d’IA, l’évaluation des risques, les responsabilités et les mécanismes de contrôle.

Autrement dit, la cybersécurité constitue une partie du problème. La capacité de l’entreprise à démontrer qu’elle maîtrise ses usages de l’IA constitue l’autre partie.

Gestion des risques IA : comment ISO 42001 permet-elle de structurer les bonnes pratiques ?

Face à une attaque par injection de prompt IA, le premier réflexe consiste souvent à chercher une solution technique : filtrer les entrées, renforcer les contrôles, limiter les accès ou tester davantage le modèle.

Ces mesures comptent.

Mais elles ne répondent pas à une question essentielle : qui s’assure qu’elles sont effectivement définies, appliquées, contrôlées et améliorées dans le temps ?

C’est là que l’approche d’ISO/IEC 42001 prend tout son intérêt.

La norme établit un système de management de l’intelligence artificielle. Son objectif n’est pas de promettre une IA invulnérable. Elle permet à l’organisation de mettre en place une démarche structurée pour encadrer le développement, la fourniture ou l’utilisation de systèmes d’IA.

La nuance est importante.

Prenons l’exemple d’une entreprise qui déploie un assistant IA connecté à sa documentation interne. Elle peut installer plusieurs protections contre l’injection indirecte de prompt.

Mais que se passe-t-il six mois plus tard lorsqu’une nouvelle source de données est connectée ? Lorsque le modèle change ? Lorsqu’un nouveau prestataire intervient ? Ou lorsqu’un usage qui n’avait jamais été envisagé apparaît ?

Une protection technique est une photographie à un instant donné. Un système de management cherche, lui, à faire vivre la maîtrise du risque dans le temps.

C’est notamment ce qui rend ISO 42001 et la prévention des risques IA intéressantes pour les directions qui ne veulent pas découvrir leurs faiblesses le jour où un incident éclate.

La démarche conduit l’organisation à regarder l’IA dans son environnement réel : ses objectifs, ses parties prenantes, ses responsabilités, ses risques, ses impacts et les contrôles nécessaires.

Pour une entreprise exposée aux risques d’injection de prompt, cela change la perspective.

La question n’est plus uniquement de savoir si une attaque est techniquement possible. Il faut déterminer quelles conséquences elle pourrait entraîner et comment l’organisation entend les maîtriser.

Accès indu à des informations, comportement inattendu du système, production de contenus problématiques, atteinte à la confidentialité ou perturbation d’un processus métier : chaque scénario mérite d’être évalué en fonction du contexte.

Le cas zurichois évoqué précédemment prend alors tout son sens. Lorsqu’une autorité de protection des données considère la prompt injection parmi les risques techniques d’une application d’IA, l’entreprise a intérêt à pouvoir montrer que ce type de menace ne constitue pas un angle mort de sa gouvernance.

ISO 42001 ne garantit donc pas qu’une injection n’aura jamais lieu. Elle aide l’organisation à structurer la manière dont les risques liés à ses systèmes d’IA sont identifiés, évalués, traités et suivis.

Pour une direction, cette différence est fondamentale.

Gouvernance de l’intelligence artificielle : comment ISO 42001 aide-t-elle à sécuriser durablement vos usages ?

Imaginez deux entreprises confrontées au même incident.

Dans la première, personne ne sait précisément qui est responsable du système d’IA. La documentation est incomplète. Les risques ont été discutés lors du lancement du projet, mais sans véritable suivi. Un fournisseur externe intervient sur une partie du dispositif et les responsabilités sont difficiles à reconstituer.

Dans la seconde, les rôles sont définis. Les risques liés au système sont évalués. Des processus de contrôle existent. Les incidents et évolutions peuvent alimenter une logique d’amélioration continue.

La vulnérabilité technique initiale peut être identique. La capacité à gérer ses conséquences ne l’est pas.

C’est ici que la gouvernance de l’intelligence artificielle devient également un sujet de direction.

Une démarche ISO/IEC 42001 peut notamment conduire l’entreprise à formaliser son cadre de gouvernance, à attribuer des responsabilités, à intégrer l’évaluation des risques et impacts dans le cycle de vie des systèmes d’IA et à déterminer les contrôles adaptés à ses usages.

Cette structuration est particulièrement pertinente lorsqu’un système utilise un LLM connecté à des données ou outils de l’entreprise.

Protéger un LLM contre les prompt injections ne consiste pas seulement à empêcher une mauvaise instruction d’entrer. Il faut également réfléchir à ce que le système est autorisé à consulter, à restituer ou à déclencher si une protection échoue.

C’est le principe des couches de protection.

Une porte blindée est utile. Mais on ne dépose pas pour autant toutes les informations sensibles de l’entreprise juste derrière cette porte.

Il en va de même avec l’IA.

Limiter les privilèges, contrôler les accès aux données, tester les comportements du système, surveiller les incidents et réexaminer les risques lorsque l’environnement évolue participent d’une utilisation responsable de l’IA.

Les mesures exactes doivent naturellement être déterminées selon le contexte et les risques propres à chaque organisation.

Cette approche présente aussi un intérêt lorsque survient une question beaucoup moins technique :

« Pouvez-vous démontrer ce que vous aviez mis en place ? »

Après un incident, affirmer que l’entreprise prenait la sécurité au sérieux ne suffit pas toujours.

La documentation des processus, des responsabilités, des évaluations et des contrôles peut devenir déterminante pour expliquer comment le risque était gouverné.

C’est pourquoi ISO 42001 et la conformité réglementaire de l’IA ne doivent pas être confondues.

Une certification ISO/IEC 42001 ne signifie pas automatiquement qu’une organisation respecte toutes les obligations juridiques applicables à chacun de ses systèmes d’IA. Elle fournit en revanche un cadre de management qui peut aider l’entreprise à organiser sa gouvernance et à intégrer ses exigences applicables dans ses processus.

Pour une direction, la vraie question devient donc moins :

« Pouvons-nous empêcher toutes les attaques ? »

Aucune organisation sérieuse ne peut promettre cela.

La question est plutôt :

« Pouvons-nous démontrer que nous avons identifié nos risques liés à l’IA et organisé leur maîtrise dans la durée ? »

C’est là que la démarche ISO/IEC 42001 peut prendre une dimension stratégique : transformer une succession de mesures techniques isolées en un système de management cohérent, pilotable et améliorable.

Et lorsque l’IA devient progressivement un outil métier comme les autres, cette capacité à démontrer sa maîtrise peut contribuer à protéger bien plus que le système lui-même : les données, la confiance des clients, la réputation et, finalement, l’entreprise.

Conclusion : de la sécurité technique à une véritable maîtrise des risques IA

L’empoisonnement de l’IA par injection met en lumière une réalité que les entreprises ne peuvent plus ignorer : adopter l’intelligence artificielle, c’est aussi accepter de gouverner de nouveaux risques.

Les exemples européens et suisses le montrent. Une attaque par injection de prompt, un comportement détourné ou une faiblesse insuffisamment anticipée peuvent rapidement dépasser le cadre informatique. La sécurité des données, la conformité, la responsabilité de l’entreprise et sa réputation peuvent alors être concernées.

La réponse ne peut donc pas reposer sur une protection technique unique.

Il faut identifier les risques, déterminer les responsabilités, contrôler les accès et les usages, documenter les décisions, surveiller les systèmes et réévaluer les mesures lorsque l’environnement évolue.

C’est précisément l’intérêt d’une gestion des risques IA avec ISO 42001.

La norme ne promet pas une intelligence artificielle impossible à attaquer et ne remplace pas les obligations juridiques applicables. Elle fournit un cadre pour transformer des bonnes pratiques parfois dispersées en un système de management de l’IA structuré et améliorable dans le temps.

Pour l’entreprise, l’enjeu est finalement simple : ne pas attendre l’incident pour découvrir comment son intelligence artificielle est gouvernée.

Vous déployez déjà des solutions d’IA ou envisagez de le faire ? Évaluer votre organisation au regard d’ISO/IEC 42001 peut constituer une première étape pour identifier vos écarts, structurer votre gouvernance et mieux maîtriser les risques avant qu’ils ne deviennent des problèmes juridiques ou d’image.

Sources des cas cités

Eurostar — Pen Test Partners, “Eurostar AI vulnerability: when a chatbot goes off the rails”, 22 décembre 2025. Les chercheurs documentent le contournement des garde-fous, la divulgation du system prompt par prompt injection et l’injection HTML, ainsi que le cadre autorisé du test.

DPD — The Guardian, “DPD AI chatbot swears, calls itself ‘useless’ and criticises delivery firm”, 20 janvier 2024. L'article relate le détournement du chatbot, sa diffusion sur les réseaux sociaux et la désactivation ultérieure de la fonction IA concernée.

Suisse — Datenschutzbeauftragte des Kantons Zürich, “Erste Kontrolle einer KI-Applikation”. L'autorité zurichoise cite explicitement les attaques par prompt injection parmi les risques techniques des systèmes d’IA et les associe notamment au contournement des mécanismes de protection.