Comment les attaques d'exécution transforment l'IA rentable en trous noirs budgétaires

Cet article fait partie du numéro spécial de VentureBeat, « Le coût réel de l'IA : performances, efficacité et retour sur investissement à grande échelle ». Pour en savoir plus, consultez ce numéro spécial.
Les promesses de l'IA sont indéniables, mais ses coûts de sécurité exorbitants au niveau de la couche d'inférence le sont tout autant. Les nouvelles attaques ciblant le côté opérationnel de l'IA gonflent discrètement les budgets, compromettent la conformité réglementaire et érodent la confiance des clients, menaçant ainsi le retour sur investissement (ROI) et le coût total de possession des déploiements d'IA en entreprise.
L'IA a captivé les entreprises par son potentiel d'analyses révolutionnaires et de gains d'efficacité. Pourtant, alors que les organisations s'empressent d'opérationnaliser leurs modèles, une réalité inquiétante émerge : la phase d'inférence, où l'IA traduit l'investissement en valeur commerciale en temps réel, est menacée. Ce moment critique fait grimper le coût total de possession (TCO) à un niveau que les analyses de rentabilité initiales n'avaient pas anticipé.
Les responsables de la sécurité et les directeurs financiers qui ont approuvé des projets d'IA pour leurs avantages transformateurs sont désormais confrontés aux coûts cachés liés à la défense de ces systèmes. Les adversaires ont découvert que l'inférence est le point de départ de l'IA pour une entreprise, et c'est précisément là qu'ils peuvent infliger le plus de dégâts. Il en résulte une inflation des coûts en cascade : le confinement des failles peut dépasser 5 millions de dollars par incident dans les secteurs réglementés, les mises à niveau de conformité se chiffrent en centaines de milliers de dollars et les failles de confiance peuvent entraîner des pertes boursières ou des annulations de contrats qui anéantissent le retour sur investissement prévu de l'IA. Sans maîtrise des coûts dès l'inférence, l'IA devient un facteur budgétaire imprévisible et incontrôlable.
L'inférence de l'IA devient rapidement le « prochain risque interne », a déclaré Cristian Rodriguez, directeur technique de terrain pour les Amériques chez CrowdStrike , au public du RSAC 2025 .
D'autres leaders technologiques partagent ce point de vue et constatent un angle mort courant dans la stratégie d'entreprise. Vineet Arora, directeur technique chez WinWire , note que de nombreuses organisations « se concentrent intensément sur la sécurisation de l'infrastructure autour de l'IA, négligeant par inadvertance l'inférence ». Cet oubli, explique-t-il, « conduit à sous-estimer les coûts des systèmes de surveillance continue, de l'analyse des menaces en temps réel et des mécanismes de correctifs rapides ».
Un autre angle mort critique, selon Steffen Schreier, vice-président principal des produits et du portefeuille chez Telesign , est « l’hypothèse selon laquelle les modèles tiers sont soigneusement examinés et intrinsèquement sûrs à déployer ».
Il a averti qu'en réalité, « ces modèles n'ont souvent pas été évalués au regard des menaces spécifiques à chaque organisation ni de ses besoins de conformité », ce qui peut conduire à des résultats nuisibles ou non conformes, érodant ainsi la confiance envers la marque. Schreier a expliqué à VentureBeat que « les vulnérabilités liées à l'inférence, comme l'injection rapide, la manipulation de résultats ou la fuite de contexte, peuvent être exploitées par des attaquants pour produire des résultats nuisibles, biaisés ou non conformes. Cela présente de graves risques, en particulier dans les secteurs réglementés, et peut rapidement éroder la confiance envers la marque. »
Lorsque l'inférence est compromise, les conséquences se font sentir sur plusieurs fronts du coût total de possession. Les budgets de cybersécurité explosent, la conformité réglementaire est compromise et la confiance des clients s'érode. Le sentiment des dirigeants reflète cette préoccupation croissante. Dans l'enquête de CrowdStrike sur l'état de l'IA dans la cybersécurité , seuls 39 % des répondants estiment que les avantages de l'IA générative dépassent clairement les risques, tandis que 40 % les jugent comparables. Cette ambivalence met en évidence un constat essentiel : les contrôles de sécurité et de confidentialité sont devenus des exigences majeures pour les initiatives d'IA de nouvelle génération, avec un pourcentage impressionnant de 90 % des organisations mettant en œuvre ou développant désormais des politiques pour encadrer l'adoption de l'IA. Les principales préoccupations ne sont plus abstraites ; 26 % citent l'exposition des données sensibles et 25 % craignent les attaques adverses comme risques majeurs.

Les responsables de la sécurité affichent des sentiments mitigés concernant la sécurité globale de l'IA de nouvelle génération, les principales préoccupations étant centrées sur l'exposition de données sensibles aux LLM (26 %) et les attaques adverses sur les outils d'IA (25 %).
La surface d'attaque unique exposée par les modèles d'IA en cours d'exécution est explorée de manière intensive par les adversaires. Pour s'en prémunir, Schreier conseille : « Il est essentiel de traiter chaque entrée comme une attaque hostile potentielle. » Des cadres comme le Top 10 de l'OWASP pour les applications de modèles de langages étendus (LLM) répertorient ces menaces, qui ne sont plus théoriques, mais des vecteurs d'attaque actifs impactant l'entreprise :
- Injection rapide (LLM01) et gestion non sécurisée des sorties (LLM02) : Les attaquants manipulent les modèles via les entrées ou les sorties. Des entrées malveillantes peuvent amener le modèle à ignorer des instructions ou à divulguer du code propriétaire. Une gestion non sécurisée des sorties se produit lorsqu'une application fait aveuglément confiance aux réponses de l'IA, permettant ainsi aux attaquants d'injecter des scripts malveillants dans les systèmes en aval.
- Empoisonnement des données d'entraînement (LLM03) et empoisonnement des modèles : les attaquants corrompent les données d'entraînement en introduisant des échantillons contaminés et en installant des déclencheurs cachés. Par la suite, une entrée anodine peut déclencher des sorties malveillantes.
- Déni de service du modèle (LLM04) : les adversaires peuvent submerger les modèles d'IA avec des entrées complexes, consommant des ressources excessives pour les ralentir ou les faire planter, entraînant une perte de revenus directe.
- Vulnérabilités de la chaîne d'approvisionnement et des plugins (LLM05 et LLM07) : L'écosystème de l'IA repose sur des composants partagés. Par exemple, une vulnérabilité dans l'outil Flowise LLM a exposé des tableaux de bord d'IA privés et des données sensibles, notamment des jetons GitHub et des clés API OpenAI, sur 438 serveurs.
- Divulgation d'informations sensibles (LLM06) : des requêtes intelligentes peuvent extraire des informations confidentielles d'un modèle d'IA si elles faisaient partie de ses données de formation ou sont présentes dans le contexte actuel.
- Agence excessive (LLM08) et dépendance excessive (LLM09) : Accorder à un agent IA des autorisations non contrôlées pour exécuter des transactions ou modifier des bases de données est une recette pour un désastre en cas de manipulation.
- Vol de modèles (LLM10) : Les modèles propriétaires d'une organisation peuvent être volés par le biais de techniques d'extraction sophistiquées, ce qui constitue une attaque directe contre son avantage concurrentiel.
Ces menaces reposent sur des failles de sécurité fondamentales. Les pirates se connectent souvent avec des identifiants divulgués. Début 2024, 35 % des intrusions dans le cloud impliquaient des identifiants d'utilisateur valides, et les nouvelles tentatives d'attaques cloud non attribuées ont augmenté de 26 %, selon le rapport mondial sur les menaces 2025 de CrowdStrike . Une campagne de deepfake a donné lieu à un transfert frauduleux de 25,6 millions de dollars , tandis que les e-mails de phishing générés par l'IA ont affiché un taux de clic de 54 %, soit plus de quatre fois supérieur à ceux rédigés par des humains.

Le cadre OWASP illustre comment divers vecteurs d'attaque LLM ciblent différents composants d'une application d'IA, de l'injection rapide dans l'interface utilisateur à l'empoisonnement des données dans les modèles de formation et à la divulgation d'informations sensibles à partir du magasin de données.
Sécuriser l'IA nécessite un retour rigoureux aux fondamentaux de la sécurité , mais avec une approche moderne. « Je pense que nous devons prendre du recul et nous assurer que les fondements et les fondamentaux de la sécurité restent applicables », a soutenu Rodriguez. « La même approche serait appliquée à la sécurisation d'un système d'exploitation, tout comme celle appliquée à la sécurisation d'un modèle d'IA. »
Cela implique de mettre en œuvre une protection unifiée sur tous les chemins d'attaque, avec une gouvernance rigoureuse des données, une gestion robuste de la posture de sécurité cloud (CSPM) et une sécurité axée sur l'identité grâce à la gestion des droits d'accès à l'infrastructure cloud (CIEM) pour sécuriser les environnements cloud où résident la plupart des charges de travail d'IA. L'identité devenant le nouveau périmètre, les systèmes d'IA doivent être régis par les mêmes contrôles d'accès et protections d'exécution stricts que tout autre actif cloud critique pour l'entreprise.
L'IA fantôme , ou l'utilisation non autorisée d'outils d'IA par les employés, crée une surface d'attaque massive et inconnue. Un analyste financier utilisant un LLM en ligne gratuit pour des documents confidentiels peut divulguer par inadvertance des données propriétaires. Comme l'a averti Rodriguez, les requêtes adressées aux modèles publics peuvent « devenir les réponses d'autrui ». Pour y remédier, il faut combiner une politique claire, la formation des employés et des contrôles techniques tels que la gestion de la posture de sécurité de l'IA (AI-SPM) afin de détecter et d'évaluer tous les actifs d'IA, autorisés ou non.
Alors que les adversaires ont instrumentalisé l'IA, la tendance commence à s'inverser. Comme l'observe Mike Riemer, RSSI terrain chez Ivanti , les défenseurs commencent à « exploiter pleinement le potentiel de l'IA à des fins de cybersécurité pour analyser de vastes quantités de données collectées auprès de divers systèmes ». Cette attitude proactive est essentielle pour bâtir une défense robuste, qui nécessite plusieurs stratégies clés :
Budgétiser la sécurité de l'inférence dès le départ : Selon Arora, la première étape consiste à procéder à une « évaluation complète des risques ». Il conseille de cartographier l'ensemble du pipeline d'inférence afin d'identifier chaque flux de données et chaque vulnérabilité. « En reliant ces risques aux impacts financiers potentiels », explique-t-il, « nous pouvons mieux quantifier le coût d'une faille de sécurité » et établir un budget réaliste.
Pour structurer cela de manière plus systématique, les RSSI et les directeurs financiers devraient commencer par un modèle de retour sur investissement ajusté au risque. Une approche :
Retour sur investissement en matière de sécurité = (coût estimé de la violation × probabilité de risque annuelle) – investissement total en matière de sécurité
Par exemple, si une attaque par inférence LLM pouvait entraîner une perte de 5 millions de dollars et que la probabilité était de 10 %, la perte attendue serait de 500 000 dollars. Un investissement de 350 000 dollars dans des défenses au stade de l'inférence générerait un gain net de 150 000 dollars en évitant les risques. Ce modèle permet une budgétisation basée sur des scénarios directement liés aux résultats financiers.
Les entreprises qui allouent moins de 8 à 12 % de leur budget de projets d'IA à la sécurité de l'étape d'inférence sont souvent déstabilisées ultérieurement par les coûts de reprise après violation et de conformité . Le DSI d'un prestataire de soins de santé du Fortune 500, interrogé par VentureBeat sous couvert d'anonymat, alloue désormais 15 % de son budget total d'IA de génération à la gestion des risques post-formation, incluant la surveillance de l'exécution, les plateformes IA-SPM et les audits de conformité. Un modèle budgétaire pratique devrait répartir les coûts sur quatre centres de coûts : la surveillance de l'exécution (35 %), la simulation antagoniste (25 %), les outils de conformité (20 %) et l'analyse du comportement des utilisateurs (20 %).
Voici un exemple d'instantané d'allocation pour un déploiement d'IA d'entreprise de 2 millions de dollars, basé sur les entretiens en cours de VentureBeat avec des directeurs financiers, des DSI et des RSSI budgétisant activement pour soutenir des projets d'IA :
Catégorie budget | Allocation | Exemple de cas d'utilisation |
---|---|---|
Surveillance de l'exécution | 300 000 $ | Détection d'anomalies comportementales (pics API) |
Simulation contradictoire | 200 000 $ | Exercices de l'équipe rouge pour sonder l'injection rapide |
Outils de conformité | 150 000 $ | Alignement sur la loi européenne sur l'IA et validations des inférences SOC 2 |
Analyse du comportement des utilisateurs | 150 000 $ | Détecter les schémas d'utilisation abusive dans l'utilisation interne de l'IA |
Ces investissements réduisent les coûts de correction des violations en aval, les sanctions réglementaires et les violations des SLA, contribuant ainsi à stabiliser le coût total de possession de l'IA.
Implémentez la surveillance et la validation à l'exécution : commencez par optimiser la détection des anomalies afin de détecter les comportements au niveau de la couche d'inférence, tels que les modèles d'appels d'API anormaux, les variations d'entropie de sortie ou les pics de fréquence des requêtes. Des fournisseurs comme DataDome et Telesign proposent désormais des analyses comportementales en temps réel adaptées aux signatures d'utilisation abusive de l'IA de génération.
Les équipes doivent surveiller les variations d'entropie dans les sorties, repérer les irrégularités des jetons dans les réponses des modèles et surveiller la fréquence atypique des requêtes provenant de comptes privilégiés. Des configurations efficaces incluent la transmission des journaux vers des outils SIEM (tels que Splunk ou Datadog) avec des analyseurs d'IA de génération personnalisés et la définition de seuils d'alerte en temps réel pour les écarts par rapport aux valeurs de référence des modèles.
Adopter une architecture Zero Trust pour l'IA : La Zero Trust est incontournable pour les environnements d'IA. Elle repose sur le principe « ne jamais faire confiance, toujours vérifier ». En adoptant cette architecture, souligne Riemer, les organisations peuvent garantir que « seuls les utilisateurs et les appareils authentifiés ont accès aux données et applications sensibles, quel que soit leur emplacement physique ».
La confiance zéro au moment de l'inférence doit être appliquée à plusieurs niveaux :
- Identité : authentifier les acteurs humains et de service accédant aux points de terminaison d'inférence.
- Autorisations : Étendez l'accès LLM à l'aide du contrôle d'accès basé sur les rôles (RBAC) avec des privilèges limités dans le temps.
- Segmentation : isolez les microservices d'inférence avec des politiques de maillage de services et appliquez les valeurs par défaut de moindre privilège via des plateformes de protection de la charge de travail cloud (CWPP).

Une stratégie proactive de sécurité de l’IA nécessite une approche holistique, englobant la visibilité et la sécurité de la chaîne d’approvisionnement pendant le développement, la sécurisation de l’infrastructure et des données et la mise en œuvre de mesures de protection robustes pour protéger les systèmes d’IA en cours d’exécution pendant la production.
Pour préserver le retour sur investissement de l'IA d'entreprise, il est nécessaire de modéliser activement les avantages financiers de la sécurité. Commencez par une projection de référence du retour sur investissement, puis intégrez des scénarios d'évitement de coûts pour chaque contrôle de sécurité. En associant les investissements en cybersécurité aux coûts évités, notamment la résolution des incidents, les violations des accords de niveau de service et la perte de clientèle, la réduction des risques se traduit par un gain mesurable en retour sur investissement.
Les entreprises doivent modéliser trois scénarios de retour sur investissement (ROI) incluant la situation de référence, les investissements en sécurité et la reprise après faille afin de démontrer clairement les économies de coûts. Par exemple, une entreprise de télécommunications déployant la validation des sorties a évité plus de 12 000 requêtes mal acheminées par mois, économisant ainsi 6,3 millions de dollars par an en pénalités SLA et en volume d'appels. Reliez les investissements aux coûts évités liés à la correction des failles, au non-respect des SLA, à l'impact sur la marque et à la perte de clientèle afin de présenter un argument de ROI défendable aux directeurs financiers.
Les directeurs financiers doivent communiquer clairement sur la manière dont les dépenses de sécurité protègent les résultats financiers. Pour garantir le retour sur investissement de l'IA au niveau de l'inférence, les investissements en sécurité doivent être modélisés comme toute autre allocation stratégique de capital : en lien direct avec le coût total de possession, la réduction des risques et la préservation des revenus.
Utilisez cette liste de contrôle pour rendre les investissements en matière de sécurité de l’IA défendables au sein du conseil d’administration et réalisables dans le cycle budgétaire.
- Associez chaque dépense de sécurité de l'IA à une catégorie de réduction du coût total de possession projetée (conformité, correction des violations, stabilité du SLA).
- Exécutez des simulations d’évitement des coûts avec des scénarios d’horizon de 3 ans : de base, protégé et réactif en cas de violation.
- Quantifiez le risque financier lié aux violations des SLA, aux amendes réglementaires, à l’érosion de la confiance dans la marque et au désabonnement des clients.
- Co-modélisez les budgets de sécurité de la couche d'inférence avec les RSSI et les directeurs financiers pour briser les silos organisationnels.
- Présentez les investissements en matière de sécurité comme des catalyseurs de croissance, et non comme des frais généraux, en montrant comment ils stabilisent l’infrastructure de l’IA pour une capture de valeur durable.
Ce modèle ne défend pas seulement les investissements dans l’IA ; il défend également les budgets et les marques et peut protéger et accroître la crédibilité du conseil d’administration.
Les RSSI doivent présenter la gestion des risques liés à l'IA comme un levier d'activité, quantifié en termes de protection du retour sur investissement, de préservation de la confiance dans la marque et de stabilité réglementaire. À mesure que l'inférence de l'IA s'intègre de plus en plus aux processus de génération de revenus, sa protection n'est plus un centre de coûts ; c'est le plan de contrôle de la viabilité financière de l'IA. Les investissements stratégiques en matière de sécurité au niveau de l'infrastructure doivent être justifiés par des indicateurs financiers sur lesquels les directeurs financiers peuvent agir.
Pour aller de l'avant, les organisations doivent équilibrer leurs investissements dans l'innovation en IA et leur protection. Cela nécessite un alignement stratégique inédit. Comme l'a déclaré Robert Grazioli, DSI d'Ivanti, à VentureBeat : « L'alignement des RSSI et des DSI sera crucial pour protéger efficacement les entreprises modernes. » Cette collaboration est essentielle pour décloisonner les données et les budgets qui compromettent la sécurité, permettant ainsi aux organisations de gérer le coût réel de l'IA et de transformer un pari risqué en un moteur de croissance durable et à fort retour sur investissement.
Schreier de Telesign a ajouté : « Nous envisageons les risques liés à l'inférence de l'IA sous l'angle de l'identité numérique et de la confiance. Nous intégrons la sécurité tout au long du cycle de vie de nos outils d'IA : contrôles d'accès, surveillance de l'utilisation, limitation du débit et analyses comportementales pour détecter les abus et protéger nos clients et leurs utilisateurs finaux contre les menaces émergentes. »
Il a poursuivi : « Nous abordons la validation des résultats comme une couche critique de notre architecture de sécurité de l'IA, en particulier parce que de nombreux risques liés au temps d'inférence ne proviennent pas de la manière dont un modèle est formé, mais de la manière dont il se comporte dans la nature. »
venturebeat