LLM10 : votre IA peut être saturée, détournée ou clonée.

LLM10:2025 Unbounded Consumption : quand l'abus de votre IA devient votre problème

Imaginez ouvrir votre tableau de bord cloud un matin et découvrir une facture dix fois supérieure à l'ordinaire. Votre assistant IA a traité des millions de requêtes pendant la nuit. Vous n'avez rien demandé. Vos clients non plus. Quelqu'un d'autre en a profité — à vos frais.

Ce n'est pas un scénario hypothétique. C'est l'une des attaques documentées contre les applications IA en production, et l'OWASP l'a classée comme la 10e et dernière vulnérabilité de son Top 10 LLM 2025 : LLM10:2025 – Unbounded Consumption, ou « consommation non maîtrisée ». Votre IA peut être épuisée, détournée, rendue indisponible — ou utilisée pour cloner votre propre modèle au profit d'un concurrent.

C'est le dernier article de notre série sur le Top 10 OWASP LLM 2025. Retrouvez les épisodes précédents : LLM01 – Prompt Injection, LLM06 – Excessive Agency, LLM07 – System Prompt Leakage et LLM09 – Misinformation.

Consommation IA non maîtrisée : ce que ça veut dire concrètement

Qu'est-ce que le risque LLM10 Unbounded Consumption ?
C'est la situation où une application IA ne limite pas le nombre, la taille ou la fréquence des requêtes qu'elle accepte. Sans ces limites, un attaquant peut envoyer un volume massif de demandes — saturant les ressources, paralysant le service, ou exploitant le modèle à des fins non autorisées. L'impact peut être financier, opérationnel ou concurrentiel.

Pourquoi ce risque concerne-t-il les PME ?
Parce que la plupart des PME qui déploient une IA le font via des services cloud facturés à l'usage. Chaque requête a un coût. Et si personne ne contrôle le volume de ces requêtes, ce coût peut devenir incontrôlable — qu'il s'agisse d'un abus délibéré ou d'une simple erreur de configuration.

Trois catégories d'attaque qui peuvent toucher votre PME

Le « Denial of Wallet » : votre facture cloud peut-elle exploser du jour au lendemain ?

Oui. Et c'est la variante la plus redoutable de LLM10 pour les dirigeants. Le principe est simple : les services IA cloud sont facturés à la requête ou au token traité. Un attaquant qui bombarde votre API IA de millions de requêtes ne cherche pas nécessairement à faire tomber votre service — il cherche à vous ruiner financièrement.

Ce type d'attaque porte un nom dans la communauté de la cybersécurité : Denial of Wallet (DoW), par analogie avec le Denial of Service (DoS). Là où le DoS coupe l'accès, le DoW vide le portefeuille. Des incidents documentés ont montré que des erreurs de configuration, des clés API compromises ou des mécanismes de contrôle insuffisants pouvaient conduire à une consommation massive de ressources IA et à des coûts importants.

Pour une PME qui utilise GPT-4 ou Claude via API, sans quota ni alerte de consommation, une telle attaque peut représenter plusieurs milliers d'euros de facturation supplémentaire en quelques heures. La plupart des dirigeants découvrent le problème en consultant leur relevé — pas en temps réel.

Le déni de service IA : quand votre assistant tombe et ne répond plus ?

La variante classique : inonder votre application de requêtes jusqu'à saturation. Un LLM est gourmand en ressources de calcul. Une requête complexe — comportant un grand volume de contexte ou nécessitant une génération importante de texte — peut mobiliser bien plus de ressources qu'une requête simple. Un attaquant qui envoie en continu des requêtes volontairement complexes peut rendre votre assistant IA inutilisable pour vos vrais utilisateurs.

C'est particulièrement critique si votre chatbot IA est le point d'entrée de votre service client ou d'un outil interne dont vos équipes dépendent au quotidien. Une heure d'indisponibilité ne coûte pas que de l'argent — elle coûte de la confiance.

Ce risque est amplifié dans les architectures d'agents IA autonomes, où une seule requête peut déclencher une cascade d'actions — comme documenté dans notre article sur l'autonomie excessive des agents IA (LLM06).

Le vol de modèle : votre IA entraînée peut-elle être clonée par un concurrent ?

Ce risque est moins immédiat mais potentiellement plus grave sur le long terme. Si votre entreprise a investi dans un modèle IA personnalisé (fine-tuning) ou une base de connaissances avancée (RAG) — ce système représente un actif propriétaire. Un concurrent peut tenter de le cloner ou d'en extraire le savoir métier en interrogeant systématiquement votre API avec des requêtes conçues pour extraire ses comportements caractéristiques — souvent en combinaison avec des techniques d'injection de prompt (LLM01) pour contourner les filtres de sortie.

Avec suffisamment de réponses collectées, il est possible d'entraîner un modèle reproduisant une partie du comportement observable de votre système, sans disposer des données d'entraînement originales. L'OWASP identifie deux variantes : l'extraction par API, qui collecte des paires question/réponse, et la réplication fonctionnelle, qui utilise les sorties de votre modèle pour entraîner un autre modèle concurrent.

Ce type de menace est directement lié aux risques de propriété intellectuelle évoqués dans notre article sur la fuite des instructions de votre IA (LLM07) : ensemble, ces deux vecteurs permettent de reconstituer non seulement le comportement, mais aussi la logique interne de votre outil.

Votre PME face aux risques LLM10 : niveau d'exposition selon les usages

Pourquoi les PME sont plus exposées qu'elles ne le pensent

Il y a une idée reçue tenace : « je suis trop petit pour être ciblé ». En matière de LLM10, c'est exactement l'inverse. Les grandes entreprises ont des équipes dédiées à la surveillance des coûts cloud et des architectures sophistiquées de limitation de débit (rate limiting). Les PME, elles, déploient souvent une IA rapidement, sur un abonnement cloud standard, sans avoir paramétré de quotas ni d'alertes de consommation.

Trois facteurs aggravent cette exposition :

• Les déploiements IA en PME sont souvent réalisés par des prestataires qui optimisent pour la fonctionnalité, pas pour la sécurité opérationnelle — les limites de consommation sont rarement dans le scope initial,
• Les APIs IA grand public (OpenAI, Anthropic, Google) appliquent leurs propres mécanismes de protection, mais elles ne peuvent pas distinguer un usage légitime d'un abus spécifique à votre application. La protection métier reste à votre charge,
• La surveillance des coûts cloud n'est pas encore intégrée dans les pratiques de cybersécurité de la plupart des PME, alors qu'elle devrait l'être.

Ce phénomène s'inscrit dans la tendance plus large que nous avons documentée dans notre article sur l'explosion des cyberattaques exploitant l'IA générative : les attaquants ciblent les maillons les moins protégés, et l'IA non sécurisée des PME en fait partie.

Ce qu'on met en place pour protéger votre IA de la surconsommation

1. Activer les quotas et les alertes de consommation dès le premier jour. C'est la mesure la plus simple et la plus efficace. Tous les grands fournisseurs IA cloud (OpenAI, Azure, AWS, Anthropic) permettent de configurer des budgets mensuels et des alertes par email ou SMS dès qu'un seuil est atteint. Si ces alertes ne sont pas configurées, vous découvrirez le problème sur votre facture — pas avant. Vérifiez aujourd'hui que votre prestataire les a activées.
2. Mettre en place du rate limiting sur votre API IA. Le rate limiting consiste à limiter le nombre de requêtes qu'un utilisateur ou une adresse IP peut envoyer dans un intervalle de temps donné. Par exemple : 10 requêtes par minute par utilisateur, 500 par heure au total. Ces limites doivent être configurées au niveau de votre application, avant que la requête n'atteigne l'API IA. C'est un contrôle technique qui ne nécessite pas de compétences avancées mais qui bloque efficacement les attaques par saturation.
3. Valider la taille et la complexité des entrées. Définir une taille maximale pour les requêtes que votre application accepte. Une requête de 10 000 mots (soit plusieurs dizaines de milliers de tokens) envoyée à un LLM coûte beaucoup plus qu'une requête de 100 mots — et un attaquant le sait. Limiter la longueur des entrées, rejeter les formats inhabituels, et valider le contenu avant transmission à l'API réduit significativement l'exposition aux attaques par inondation de données volumineuses.
4. Authentifier et identifier chaque utilisateur de votre IA. Si n'importe qui peut interroger votre IA sans s'authentifier, vous n'avez aucun moyen de détecter un abus ni de l'arrêter. Chaque utilisateur doit être identifié, et ses droits doivent être définis selon le principe du moindre privilège : accès restreint aux seules fonctions et volumes nécessaires à son rôle. Cela s'applique aussi aux usages internes : tous vos collaborateurs n'ont pas les mêmes besoins IA.
5. Surveiller les patterns de consommation en temps réel. Un volume anormalement élevé de requêtes à 3h du matin, des requêtes toutes identiques envoyées en rafale, ou un utilisateur qui consomme dix fois plus que ses collègues — ces signaux doivent déclencher une alerte automatique, pas une découverte post-factum. C'est précisément le type de surveillance couverte par un service MDR (Managed Detection and Response), étendu aux logs et métriques de vos APIs IA.
6. Protéger votre modèle contre l'extraction. Si vous avez investi dans un modèle personnalisé ou un système RAG, limitez le volume de requêtes par compte externe, limitez les requêtes répétitives, surveillez les comportements d'extraction et appliquez des quotas adaptés, et ne rendez pas publics les probabilités ou scores internes (logprobs) que certaines APIs exposent. Un audit de la configuration de votre API IA peut identifier ces expositions avant qu'elles ne soient exploitées.

Ce que dit la réglementation sur la maîtrise de vos ressources IA

RGPD : une attaque par saturation peut-elle entraîner une violation de données personnelles ?

Si votre IA traite des données personnelles — ce qui est souvent le cas dans un contexte client ou RH — une attaque par saturation peut entraîner des traitements non conformes : des données extraites dans des volumes non prévus, des journaux de logs gonflés contenant des informations personnelles, ou des comportements imprévisibles du modèle sous charge. Les mesures de sécurité attendues incluent notamment le contrôle des accès, la maîtrise des traitements et des mécanismes permettant de préserver la disponibilité des services.

NIS2 : la disponibilité de votre IA est-elle une obligation légale ?

La directive NIS2 impose aux entités concernées des obligations de disponibilité et de résilience de leurs systèmes d'information. Une attaque par déni de service IA qui rend indisponible un service numérique peut, selon sa gravité et son impact, relever des obligations de notification prévues par NIS2. Cybermalveillance.gouv.fr recommande aux organisations de mettre en place des mécanismes de détection et de limitation des abus pour garantir cette résilience, y compris sur les composants IA.

EU AI Act : l'absence de quotas sur votre IA constitue-t-elle un manquement à la robustesse ?

Le règlement européen sur l'IA impose que les systèmes d'IA à risque soient robustes face aux tentatives de manipulation, notamment les attaques par abus de ressources. L'absence de mécanismes de contrôle de la consommation peut contribuer à démontrer un défaut de robustesse ou de cybersécurité, selon le contexte et la catégorie du système. L'ANSSI intègre ces exigences dans ses recommandations pour la sécurisation des architectures incluant des composants IA.

Ce qu'il faut retenir

• LLM10 couvre les risques liés à la consommation IA non maîtrisée : saturation de ressources, explosion de factures cloud, déni de service et vol de modèle ou de données,
• L'attaque la plus concrète pour les PME est le « Denial of Wallet » : bombarder votre API de requêtes pour faire exploser votre facture cloud à vos frais,
• Les PME sont particulièrement exposées parce qu'elles déploient de l'IA rapidement, sans quotas ni alertes de consommation configurés,
• Les protections essentielles sont simples : alertes de consommation, rate limiting, validation des entrées, authentification des utilisateurs,
• Un modèle IA personnalisé ou une base de connaissances RAG est un actif propriétaire qui peut être extrait si l'API n'est pas correctement protégée,
• RGPD, NIS2 et EU AI Act imposent tous une maîtrise technique des ressources et de la disponibilité. Une supervision adaptée de l'IA devient un élément essentiel de la conformité.

Conclusion : une facture surprise n'est jamais vraiment une surprise

LLM10 est le seul risque du Top 10 OWASP qui peut se matérialiser sans qu'aucune donnée ne fuite, sans qu'aucun système ne soit compromis, sans qu'aucun utilisateur ne soit lésé — et pourtant coûter très cher. Une facture cloud multipliée par dix. Un service IA hors ligne pendant des heures. Un modèle que vous avez payé des mois à développer, disponible chez un concurrent pour zéro euro.

Avec cet article, nous terminons notre série complète sur le Top 10 OWASP des risques IA 2025 — dix vulnérabilités, dix angles concrets pour les dirigeants de PME. De LLM01 – Prompt Injection à LLM10 – Unbounded Consumption, chaque risque a un visage différent : manipulation, fuite, autonomie excessive, désinformation, saturation. Tous partagent la même réponse de fond : gouverner l'IA, pas seulement l'utiliser.

Ces conséquences sont évitables. Pas par des mesures complexes ou coûteuses — par des configurations que tout déploiement IA sérieux devrait avoir dès le premier jour. Des quotas. Des alertes. Du rate limiting. Une surveillance.

Si votre IA est déjà en production et que vous n'êtes pas certain que ces éléments sont en place, c'est le bon moment pour vérifier. Nos équipes peuvent réaliser cet état des lieux rapidement. Contactez-nous pour un premier échange.