Tester une application d'IA générative
Une application d'IA générative ne se teste pas comme une application classique : sa surface d'attaque n'est pas dans le code, elle est dans ce que le modèle accepte de faire quand on le lui demande bien.
La faille n'est pas dans le code, elle est dans la consigne
Un modèle de langage ne distingue pas nativement l'instruction du développeur de celle qui arrive dans les données qu'on lui donne à lire. C'est la nature même de l'injection de prompt : un texte placé dans un document, une page web, un ticket ou un courriel devient une consigne dès que l'agent le traite. L'attaquant n'a pas besoin d'accéder à votre système — il lui suffit d'écrire là où votre agent ira lire.
Le risque grandit avec les capacités qu'on accorde. Un agent qui se contente de répondre expose surtout son contexte : instructions internes, extraits de documents, données d'autres utilisateurs restées en mémoire. Un agent qui peut appeler des outils — envoyer un courriel, écrire dans une base, déclencher une action — expose ces outils eux-mêmes, avec les droits qu'on lui a donnés.
S'ajoute la question des garde-fous. Ils sont presque toujours présents, et presque toujours contournables : reformulation, changement de langue, mise en scène, découpage de la demande. Les éprouver revient à mesurer non pas s'ils existent, mais ce qu'il en coûte de les franchir.
- Instruction cachée dans un document que l'agent traite
- Données d'un autre utilisateur restituées via le contexte
- Outils de l'agent détournés au-delà de son usage prévu
- Garde-fous franchis par simple reformulation
- Droits de l'agent plus larges que ceux de son utilisateur
Tout ce que l'agent lit peut lui donner un ordre
Comment nous procédons
Nous testons l'application telle qu'elle est exposée, avec les droits d'un utilisateur ordinaire, puis nous remontons vers ce que ces droits permettent d'atteindre.
Cadrage et capacités
Recensement de ce que l'agent peut faire : sources qu'il consulte, outils qu'il peut appeler, données auxquelles il accède, et sous quelle identité. Cette carte des capacités définit ce qui est réellement en jeu.
Injection directe et indirecte
Tentatives de détournement par l'entrée utilisateur, puis par les contenus que l'agent ingère — un document, une page, un enregistrement. La seconde est la plus grave, car elle n'exige aucun accès à votre application.
Contexte et cloisonnement
Recherche de ce que le modèle restitue de son contexte : instructions internes, fragments de documents, traces d'autres sessions. On vérifie qu'un utilisateur ne peut pas atteindre, par l'agent, ce que ses propres droits lui interdisent.
Outils et effets de bord
Épreuve des actions que l'agent peut déclencher : usage détourné, enchaînement non prévu, exécution sans confirmation. Un agent qui écrit ou envoie est un agent qui peut être utilisé pour écrire ou envoyer autre chose.
Restitution et durcissement
Rapport priorisé avec preuve reproductible, puis recommandations concrètes : réduction des droits, séparation des sources de confiance, validation des sorties, journalisation exploitable. Contre-test après correction.
Plusieurs expertises, un seul interlocuteur
Le test éprouve l'application, l'intégration encadre les droits, la formation prépare ceux qui la conçoivent.
- Carte des capacités et des droits de l'agent
- Scénarios d'injection reproductibles
- Constats priorisés selon l'impact réel
- Recommandations de durcissement applicables
- Contre-test après correction
Questions fréquentes
Que peut faire votre agent si on le lui demande bien ?
Dites-nous ce qu'il consulte et ce qu'il peut déclencher : nous cadrons le test à partir de là.