Bornes, abus et tests d'attaque

Dernier risque de la liste, le plus prosaïque : la consommation non bornée. Chaque requête à un modèle coûte de l'argent et du calcul. Sans limites, un utilisateur malveillant, un script abusif ou une simple boucle mal écrite peut épuiser votre budget ou rendre le service indisponible pour tous. On parle parfois de « déni de portefeuille ».

Les bornes à poser

• Par requête : taille maximale de l'entrée, nombre maximal de tokens produits, durée maximale.
• Par utilisateur et par période : un quota appliqué côté serveur, avec des seuils différents selon les comptes.
• Par agent : nombre d'étapes, nombre d'appels d'outils, dépense maximale par tâche.
• Globalement : des alertes de dépense qui préviennent un humain, et un plafond qui coupe avant la catastrophe.

Un abus moins visible : l'usage de votre application comme accès gratuit à un modèle coûteux, ou l'extraction en masse de ses réponses pour entraîner un concurrent. Les quotas et la détection d'usages anormaux couvrent aussi ces cas.

Le red teaming, en continu

Le cours « Construire avec l'IA » a posé le principe : attaquer son propre système avant les autres. En production, cela devient une suite de tests d'attaque versionnée, rejouée à chaque changement de prompt, de modèle ou d'outil, comme les évaluations de qualité :

• des documents et des courriels piégés, pour l'injection indirecte ;
• des tentatives d'exfiltration par la sortie (liens, images, appels d'outils) ;
• des tests de droits : l'utilisateur A peut-il obtenir les données de B ?
• des requêtes coûteuses : entrées géantes, demandes qui font boucler l'agent.

Des outils libres existent pour automatiser une partie de ces attaques ; ils complètent, sans les remplacer, les scénarios propres à votre application.

Le jour où ça arrive

Préparez avant l'incident : un interrupteur qui désactive l'agent ou un outil sans redéployer, des clés révocables rapidement, des journaux qui permettent de savoir qui a demandé quoi et ce que l'agent a fait. Le règlement européen sur la protection des données impose en outre de notifier certaines violations à l'autorité de contrôle dans les 72 heures : savoir reconstituer les faits vite n'est pas un luxe.