Agents IA en PME/ETI : quels garde-fous mettre en place avant déploiement

Un écart à anticiper entre vitesse d'adoption et maturité de gouvernance

Les agents IA autonomes — c'est-à-dire des systèmes capables d'enchaîner des appels d'outils et de raisonner sur plusieurs étapes pour atteindre un objectif — se déploient désormais dans des organisations de toute taille, sans qu'un développement spécifique soit toujours nécessaire. Pour une direction informatique ou un dirigeant de PME/ETI évaluant un déploiement, l'enjeu n'est plus seulement technique : il est aussi organisationnel, financier et juridique.

L'intérêt éditorial de ce sujet tient à un écart observable : la démocratisation de ces agents précède, dans la majorité des organisations adoptantes, la maturation des garde-fous — gouvernance, plafonds financiers, supervision humaine, journalisation. Un cas documenté en 2026 rend cet écart particulièrement lisible.

Ce que le cas documenté par Mandiant permet d'observer

Le rapport Mandiant AI Risk and Resilience publié par Google Cloud en 2026 décrit, sous l'intitulé « Denial-of-Wallet using rogue reasoning loop », un cas opérationnel qu'il convient de présenter avec le périmètre exact que lui donne la source.

Périmètre tel que décrit : un grand groupe international de services financiers — donc une grande entreprise, et non une PME/ETI — avait déployé un agent dédié au rapprochement d'anomalies dans ses écritures comptables. L'agent disposait d'un accès direct en lecture/écriture à des bases internes de facturation.

Fait déclencheur : une valeur nulle corrompue a mis en panne l'outil de formatage de l'agent.

Effet en cascade : face à cet échec, l'agent est entré dans une boucle de raisonnement récursive non contrainte, cherchant à forcer la résolution. En moins d'une heure, il a généré plus de 15 000 appels API de raisonnement à coût élevé, entraînant un pic de facturation cloud d'environ 50 000 dollars. La même boucle a provoqué un verrouillage sévère des bases de données locales, interrompant des transactions métier actives.

Contrôles que la source primaire recommande explicitement : Mandiant cite, comme mesures défensives pour ce type de défaillance :

• la définition de seuils plafonds de coût (cost-cap thresholds) ;
• des disjoncteurs financiers automatiques (circuit breakers) déclenchés après un seuil d'échecs consécutifs ;
• des limites strictes en temps réel sur la récursion et les débits d'appels, posées au niveau de l'identité de service et du projet ;
• des exigences d'observabilité et de monitoring ;
• une gestion des identités et des accès (IAM) et un contrôle basé sur les rôles (RBAC) spécifiques aux agents.

Ce que ce cas ne permet pas de dire

Plusieurs limites doivent accompagner toute réutilisation de cet exemple.

• Un cas documenté, pas une étude statistique. Le rapport Mandiant relate un incident précis. Il ne quantifie pas la fréquence de ce type de boucle dans une population d'agents déployés et n'établit pas de probabilité de survenue. Il ne permet pas, à lui seul, de généraliser le risque à l'ensemble des déploiements.
• Une couverture secondaire à interroger avec prudence. Une reprise de ce même rapport par SecurityWeek ne retient que la boucle, le volume d'appels API, le montant et la durée ; elle ne mentionne ni la valeur nulle corrompue, ni l'accès à la base de facturation, ni le verrouillage de base. Cette différence invite à distinguer ce qui relève du cas documenté et ce qui relève de sa reformulation médiatique.
• Une grande entreprise, pas une PME. Le cas Mandiant concerne explicitement un grand groupe international. Une transposition directe à une PME/ETI doit rester prudente : les volumétries, les interconnexions, les budgets et la maturité des équipes diffèrent. Le cas sert d'illustration de mécanismes de défaillance, pas de transposition factuelle.
• Aucune identification publique. Le nom de l'organisation, le modèle d'IA utilisé, le fournisseur de l'agent et le contexte temporel précis ne sont pas communiqués dans la source primaire.

Recommandations LPCD pour un déploiement raisonné en PME/ETI

Les recommandations qui suivent sont séparées des faits précédents. Elles constituent une proposition de méthode à adapter selon la maturité, le secteur et le contexte propres à chaque organisation. Elles ne sont ni exhaustives, ni garanties de résultat.

Cadrer le périmètre d'action avant toute mise en production

Un agent en phase initiale ne devrait pas disposer d'un accès en lecture/écriture à des systèmes transactionnels critiques. Définir :

• le périmètre fonctionnel précis — un cas d'usage limité, mesurable, réversible ;
• les données et systèmes accessibles, idéalement en lecture seule ;
• la nature des décisions engageantes qui resteront soumises à validation humaine.

Poser des plafonds financiers et opérationnels

Reprendre les contrôles explicitement recommandés par la source primaire, calibrés à l'échelle PME/ETI :

• un plafond budgétaire quotidien ou mensuel, en valeur absolue, sur les appels d'inférence ou la consommation de jetons ;
• des disjoncteurs automatiques au-delà d'un seuil d'échecs consécutifs ou d'une volumétrie inhabituelle ;
• des limites de récursion et de débit côté service technique, vérifiables dans la configuration.

Prévoir la supervision humaine des décisions engageantes

Toute action modifiant un système externe, déclenchant une transaction ou publiant un contenu vers l'extérieur devrait, dans une configuration maîtrisée, requérir une validation humaine. La supervision peut être allégée progressivement, mais ne devrait pas être absente lors des phases initiales.

Tester en environnement contrôlé avant production

Un bac à sable reproduisant le contexte métier — données anonymisées, comptes techniques dédiés, jeux de données corrompues ou inattendues — permet d'observer comment l'agent gère l'échec avant qu'il ne le gère en production. L'objectif n'est pas d'éliminer tout risque, mais de rendre visibles les comportements face à des données non nominales.

Instrumenter l'observabilité et la journalisation

Tracer les appels, leurs coûts estimés, leurs résultats, leurs échecs. Une revue périodique des journaux est, dans une PME/ETI, le seul dispositif opérationnel permettant de détecter une dérive avant qu'elle n'atteigne une ampleur critique.

Première action concrète

Avant tout déploiement, identifier le poste de coût maximal admissible pour un agent en phase pilote — par exemple un plafond inférieur à 10 % du budget cloud mensuel habituel — et formaliser ce seuil dans la configuration technique du service, avec alerte automatique au premier franchissement. Cette action ne mobilise pas de développement spécifique : elle s'appuie sur les mécanismes natifs de quota et de budget des principaux fournisseurs cloud, ou sur un proxy interne léger. À elle seule, elle n'élimine aucun risque, mais elle transforme un incident potentiel en dépassement budgété et audible.