Sécuriser vos workflows d’IA avant qu’ils touchent aux données

Dans le rapport IBM Cost of a Data Breach 2025, 13 % des organisations ont déclaré des brèches touchant des modèles ou des applications d’IA, et 97 % de ces organisations n’avaient pas de contrôles d’accès à l’IA appropriés.¹ Le second chiffre ne concerne que les organisations victimes d’une brèche : il ne dit donc rien de la fréquence des contrôles manquants ailleurs. Il montre en revanche ce que ces brèches avaient en commun. L’étude a été réalisée par le Ponemon Institute, parrainée et analysée par IBM, et portait sur 600 organisations touchées par une brèche entre mars 2024 et février 2025.¹

Cela concerne toute entreprise qui relie un modèle de langage à des factures, des contrats, des fiches clients ou une boîte de réception. Un tel workflow reçoit du texte de l’extérieur, le transmet à un modèle et agit sur la réponse, et chacune de ces étapes est une surface d’attaque. Cet article s’appuie sur le OWASP Top 10 for LLM Applications 2025 pour nommer quatre modes de défaillance,² rattache les contrôles correspondants au cadre de gestion des risques de l’IA du NIST et à son profil pour l’IA générative, et se termine par une liste de contrôle à remettre à l’équipe qui construit le workflow.

Quatre modes de défaillance à anticiper dès la conception

La liste OWASP 2025 compte dix entrées, de LLM01 Prompt Injection à LLM10 Unbounded Consumption.² Quatre d’entre elles concernent les workflows qui lisent des documents puis agissent : LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM05 Improper Output Handling et LLM06 Excessive Agency. Cette sélection est la nôtre, selon le type de workflow traité ici. Les six autres, dont la chaîne d’approvisionnement et la consommation non bornée, méritent une revue à part.

Injection de prompt (LLM01)

Une injection de prompt est un texte qui modifie le comportement d’un modèle d’une manière que son exploitant n’avait pas prévue. Dans un workflow de back-office, ce texte peut se trouver dans un PDF de facture, un courriel de fournisseur ou une page web que le système récupère. OWASP relève qu’un contenu injecté n’a pas besoin d’être lisible par un humain pour être traité par le modèle, et que la génération augmentée par récupération et le réglage fin ne suffisent pas à atténuer entièrement le problème.³ Sa page consacrée à ce risque est sans détour sur la prévention :

it is unclear if there are fool-proof methods of prevention for prompt injection

Les mesures qu’OWASP énumère visent donc à limiter les dégâts. Il s’agit de contraindre le comportement du modèle, de définir et de valider les formats de sortie, de filtrer les entrées et les sorties, d’appliquer le moindre privilège, d’exiger une approbation humaine pour les actions à haut risque, de séparer le contenu non fiable des instructions et de tester avec des scénarios adverses.³

Divulgation d’informations sensibles (LLM02)

Les exemples de fuites donnés par OWASP sont les données personnelles, les informations financières, les dossiers de santé, les données confidentielles d’entreprise, les identifiants et les documents juridiques.⁴ Pour un workflow de finance ou de RH, cette liste ressemble à une description de la boîte de réception. Parmi les mesures : assainir les données avant qu’elles n’atteignent le modèle, valider les entrées, appliquer le moindre privilège, restreindre les sources de données, sensibiliser les utilisateurs et être transparent sur la durée de conservation des données.⁴ En pratique, si la tâche n’a besoin que du nom du fournisseur et du total de la facture, les coordonnées bancaires ne doivent jamais figurer dans le prompt.

Agentivité excessive (LLM06)

L’agentivité excessive est le risque qu’un modèle puisse entreprendre des actions dommageables parce que sa sortie était inattendue, ambiguë ou manipulée.⁵ Le remède d’OWASP consiste à réduire au minimum les extensions, les fonctions et les permissions du modèle, par exemple un accès en lecture seule à une table de produits quand la tâche est seulement de la lire, et à éviter les extensions ouvertes comme un shell.⁵ Un modèle qui rédige une approbation de paiement est un générateur de texte. Celui qui peut libérer le paiement est un acteur, et il exige un autre niveau de contrôle.

Traitement inadéquat des sorties (LLM05)

Ce risque tient à une validation ou un assainissement insuffisants de la sortie du modèle avant qu’elle soit transmise à d’autres systèmes. OWASP indique que les conséquences peuvent aller du cross-site scripting au cross-site request forgery, au server-side request forgery, à l’élévation de privilèges et à l’exécution de code à distance.⁶ Sa consigne est de traiter le modèle comme un utilisateur non fiable : valider sa sortie, l’encoder selon le contexte où elle sera utilisée, employer des requêtes paramétrées et journaliser ce qui se passe.⁶ Un modèle qui écrit dans un champ d’ERP ou dans une requête de base de données est une source d’entrées non fiables, aussi courtoise que soit sa prose.

D’où viennent les contrôles

Le profil du NIST pour l’IA générative (AI 600-1, juillet 2024) accompagne le cadre de gestion des risques de l’IA, dont les fonctions sont Govern, Map, Measure et Manage.⁷ Il range la sécurité de l’information parmi les risques propres à l’IA générative et indique que celle-ci élargit la surface d’attaque, car les systèmes sont eux-mêmes exposés à des attaques comme l’injection de prompt et l’empoisonnement des données.⁷ Il décrit aussi l’injection indirecte, où l’attaquant place des prompts dans des données que le système est susceptible de récupérer, et précise que des chercheurs ont démontré le vol de données propriétaires ou l’exécution de code malveillant à distance par ce moyen.⁷

Trois actions du profil se traduisent directement en liste de contrôle. GOVERN 1.6 demande un inventaire des systèmes d’IA. GV-1.5-002 porte sur les processus de réponse aux incidents et de divulgation des incidents. GOVERN 6.1 traite des risques liés aux tiers.⁷ Le rattachement de ces actions à la liste ci-dessous est de notre fait, et le profil ne prescrit pas les contrôles de cet article.

Ce que coûte une défaillance, et ce que les chiffres ne disent pas

IBM chiffre le coût moyen mondial d’une brèche à 4,44 millions de dollars, première baisse en cinq ans.¹ Selon IBM, les organisations très exposées à l’IA fantôme ont payé en moyenne 670 000 dollars de plus par brèche que celles qui l’étaient peu ou pas ; une organisation sur cinq a déclaré une brèche due à l’IA fantôme ; et 63 % des organisations touchées n’avaient pas de politique de gouvernance de l’IA ou la préparaient encore.¹

Le même communiqué contient un constat qui va dans l’autre sens : les organisations qui utilisaient largement l’IA et l’automatisation en sécurité ont économisé en moyenne 1,9 million de dollars de coûts de brèche et raccourci le cycle de vie de la brèche de 80 jours en moyenne.¹ L’IA aide aussi les défenseurs : la position raisonnable consiste à sécuriser les workflows et à utiliser ces outils.

Ce que ces contrôles ne règlent pas

Vu la déclaration d’OWASP sur l’injection de prompt, aucun contrôle de cet article n’offre de garantie. Le moindre privilège, la validation des sorties et l’approbation humaine plafonnent ce qu’une attaque réussie peut faire. Ils n’empêchent pas la tentative.

Les contrôles ont aussi un prix. L’approbation humaine ajoute du temps de traitement à chaque action qu’elle couvre, et des permissions étroites laissent certaines tâches en manuel. C’est notre raisonnement et non un chiffre mesuré des sources ci-dessus, mais c’est pourquoi l’ordre raisonnable est d’appliquer les contrôles les plus stricts aux workflows qui déplacent de l’argent, modifient des enregistrements ou envoient des messages hors de l’entreprise, et des contrôles plus légers aux synthèses en lecture seule.

Une liste de contrôle avant la mise en service

Chaque étape ci-dessous nomme le risque ou l’action NIST qu’elle traite. Aucune n’exige un nouvel outil pour démarrer.

1. Inventoriez chaque workflow qui envoie des données de l’entreprise à un modèle, y compris ceux hébergés par un éditeur, et nommez un responsable pour chacun (GOVERN 1.6).
2. Listez les données que voit chaque workflow et retirez les champs inutiles à la tâche avant l’appel ; demandez à chaque éditeur combien de temps les prompts sont conservés (LLM02, GOVERN 6.1).
3. Traitez chaque document, courriel et page web lu par le workflow comme non fiable, séparez-le des instructions et testez avec des échantillons adverses avant le lancement (LLM01).
4. Donnez au workflow les permissions les plus étroites : lecture seule sauf si écrire est la tâche, et aucun outil ouvert comme un shell (LLM06).
5. Validez la sortie du modèle selon un format fixe avant qu’elle atteigne une base de données, un champ d’ERP ou un message sortant, et utilisez des requêtes paramétrées (LLM05).
6. Exigez une approbation humaine pour les paiements, les modifications de contrats et les messages externes, journalisez chaque appel, et consignez par écrit qui répond à un incident et qui prévient qui (GV-1.5-002).

Si vous ne savez pas encore lesquels de vos workflows valent la peine d’être automatisés, le pré-audit gratuit est un court questionnaire qui renvoie une première estimation des endroits où l’IA pourrait réduire vos coûts. Ce n’est pas une évaluation de sécurité.