Applications d'IA
Tester les applications d'IA : ce qui casse et comment le tester.
Une application LLM échoue autrement qu'une application web classique. Le modèle renvoie à chaque fois quelque chose de différent : on ne peut donc pas faire d'assertion sur la réponse, mais sur tout ce qui l'entoure : qu'une réponse arrive, s'affiche en flux, s'arrête, échoue visiblement, respecte une limite et ne renvoie jamais de données que la personne n'a pas le droit de voir.
Dernière mise à jour : 24 août 2026
En quoi tester une application d'IA est-il différent ?
L'interface est la même. Le contrat ne l'est pas. L'automatisation de tests classique repose sur une assertion qui se vérifie deux fois de suite : cliquer ici, voir cela. Un modèle brise cette hypothèse dès la première exécution, ce qui explique pourquoi les équipes concluent souvent que leurs fonctionnalités d'IA ne peuvent pas être testées en régression, puis les livrent sans test.
Elles le peuvent. L'astuce consiste à déplacer l'assertion du texte vers les éléments déterministes : la réponse est arrivée dans le délai prévu, elle respecte le schéma demandé, elle cite un document que cet utilisateur peut lire, un refus s'affiche comme un refus, une nouvelle tentative n'a pas facturé deux fois. Tout cela relève de l'automatisation ordinaire. Juger si la réponse est bonne est un problème d'évaluation : il exige votre propre référence, et sa place est dans un banc d'essai à côté de vos prompts, pas dans une suite de régression.
Ce qui casse vraiment dans une application LLM
Ce sont des comportements, pas des avis sur la qualité de la sortie, ce qui les rend testables. Chacun parvient aux utilisateurs sous forme de bug du produit plutôt que de mauvaise réponse.
| Défaillance | Comment elle atteint l'utilisateur | Le test |
|---|---|---|
| La réponse s’affiche en flux, puis s’arrête à mi-chemin | Une connexion coupée en plein flux laisse à l’écran une réponse à moitié écrite, sans erreur ni nouvel essai. Les utilisateurs la lisent comme la réponse. | Coupez la réponse en plein flux et vérifiez que l’interface affiche un état d’échec, pas une réponse tronquée. |
| Le modèle est lent, et l’interface n’a rien à répondre à cela | Un p95 à quarante secondes alors que l’interface n’offre ni progression, ni annulation, ni délai d’expiration. Les gens cliquent à nouveau, et maintenant deux requêtes sont facturées. | Gardez la réponse ouverte au-delà du délai d’expiration et vérifiez qu’il y a un état visible, un moyen d’annuler, et aucune requête en double au second clic. |
| Le fournisseur renvoie 429 ou 503 | Les limites de débit et les pannes de fournisseur sont courantes, pas exceptionnelles. Les applications qui les jugent impossibles affichent une erreur brute ou un indicateur de chargement sans fin. | Renvoyez 429 et 503 depuis le fournisseur et vérifiez que l’application se dégrade en un message sur lequel l’utilisateur peut agir. |
| Réponses vides, refusées et filtrées pour sécurité | Le modèle refuse, ou le filtre de sécurité se déclenche, et l’interface affiche une bulle vide parce qu’elle ne gère que le chemin nominal. | Forcez un refus et une complétion vide ; vérifiez qu’aucun ne produit un message vide ou une mise en page cassée. |
| La conversation perd son contexte | L’historique est tronqué pour tenir dans la fenêtre et l’assistant oublie en silence ce qu’on lui a dit trois messages plus tôt. Cela se lit comme un produit stupide. | Menez une conversation au-delà de la limite de contexte et vérifiez que l’application dit ce qu’elle a écarté au lieu de l’écarter discrètement. |
| Les appels d’outils se déclenchent plus d’une fois | Un agent réessaie une étape dont l’outil s’est déjà exécuté. Ce que cet outil a fait — un e-mail, un débit, une écriture — arrive deux fois. | Faites expirer un appel d’outil après son succès et vérifiez que le nouvel essai ne répète pas l’effet de bord. |
| La récupération renvoie le document d’un autre locataire | Le magasin de vecteurs est filtré dans le prompt plutôt que dans la requête ; une récupération qui ignore l’instruction renvoie donc des données que l’utilisateur n’a pas le droit de lire. | Interrogez en tant qu’un locataire un document appartenant à un autre et vérifiez qu’il est absent de l’ensemble récupéré, et pas seulement non mentionné dans la réponse. |
| Le coût s’emballe sans plafond | Pas de plafond par utilisateur : une boucle ou un compte scripté devient une facture que personne ne remarque avant l’échéance. | Sollicitez le même endpoint à répétition et vérifiez qu’une limite existe — par utilisateur, par clé, par minute. |
Sécurité
Tests de sécurité des LLM : la surface à vérifier
Une fonctionnalité d'IA est généralement reliée à deux éléments qu'une fonctionnalité normale n'a pas : un point d'accès payant et un composant qui suit les instructions trouvées dans tout ce qu'il lit. Les deux élargissent la surface d'attaque d'une façon que les revues de sécurité applicative standard n'ont pas été conçues pour traiter.
Classés ci-dessous selon la fréquence à laquelle on les trouve réellement, ce qui n'est pas l'ordre dans lequel on en parle.
- 01
Clés de fournisseur dans le bundle client
Une clé de fournisseur de modèle livrée dans le JavaScript du front-end, ou accessible via une route proxy sans authentification devant.
Quiconque a les outils de développement peut dépenser votre quota. C’est la vérification la moins chère de cette liste et la plus coûteuse à manquer.
- 02
Injection de prompt via le contenu
Des instructions cachées dans quelque chose que le modèle lit — un document téléversé, une page récupérée, un ticket de support, le corps d’un e-mail — que le modèle suit ensuite.
L’attaquant ne touche jamais votre zone de saisie. Tout ce que votre système ingère est une entrée, que vous l’ayez conçu ainsi ou non.
- 03
Injection qui atteint un outil
Des instructions injectées qui poussent un agent à appeler un outil : envoyer un message, écrire un enregistrement, faire une requête vers une adresse interne.
C’est là que l’injection cesse d’être une gêne pour devenir un incident. Le rayon d’action est tout ce que l’agent a le droit de faire.
- 04
Divulgation du prompt système et de secrets
Amener le modèle à répéter ses propres instructions, ses définitions d’outils ou des fragments de configuration qu’on lui a donnés.
Le prompt système contient souvent des règles métier, des endpoints internes et parfois des identifiants que personne n’avait prévu d’y mettre.
- 05
Récupération inter-locataires
Une récupération délimitée en demandant poliment au modèle plutôt qu’en filtrant la requête.
Un prompt n’est pas un contrôle d’accès. Si le filtre vit dans les instructions, une instruction ignorée est une fuite de données.
- 06
Sortie rendue comme balisage ou code
Une sortie de modèle placée dans la page comme HTML, ou dans un shell, une requête ou un eval.
De l’injection classique avec une nouvelle source. Le modèle est désormais une entrée non fiable, et un attaquant peut l’influencer.
- 07
Dépense illimitée comme déni de service
Un endpoint qui appelle un modèle payant sans limite de débit, sans plafond par compte et sans limite de taille sur ce qu’il accepte.
L’attaque ne vise pas à vous faire tomber. Elle vise à faire grimper une facture jusqu’à ce que vous vous fassiez tomber vous-même.
- 08
Ce que conservent les journaux
Des prompts et complétions écrits dans les journaux et l’analytique — y compris ce qu’un utilisateur y a collé.
Les gens collent des identifiants de production et des fiches clients dans les zones de chat. La durée de conservation de vos journaux devient une question de protection des données.
Ce que QA Spider automatise, et ce qu'il n'automatise pas
Formulé assez précisément pour que vous puissiez nous le demander.
Nous automatisons ceci
- Pilote votre produit dans un vrai navigateur ; les cas de flux, de délai d’expiration, de nouvel essai, d’état vide et d’état d’erreur ci-dessus sont donc de simples tests UI — ils tournent selon un planning et à chaque déploiement.
- Vérifie l’API sous l’interface, y compris les routes que votre front-end appelle pour atteindre un modèle.
- Déclare ce qui échoue comme ticket dans Jira, Azure DevOps, ClickUp, GitHub ou Linear, avec les étapes pour le reproduire et une capture d’écran.
- Lance une passe de sécurité de surface sur le site public : transport et en-têtes de sécurité, flags de cookies, contenu mixte, exposition des formulaires, DNS et protection contre l’usurpation d’e-mail.
Nous ne faisons pas ceci
- Nous ne livrons pas actuellement de suite automatisée d’injection de prompt ou de jailbreak. Si quelqu’un vous dit que son robot le fait d’emblée, demandez-lui de vous montrer les assertions.
- Nous n’évaluons pas si une réponse est correcte. C’est un problème d’évaluation, il demande votre vérité terrain, et c’est une discipline différente du test de régression.
Questions fréquentes sur le test des applications d'IA
- En quoi tester une application d’IA diffère-t-il de tester une application web normale ?
- L’interface est la même ; la sortie ne l’est pas. Une application normale renvoie deux fois la même réponse, on peut donc la vérifier. Un modèle renvoie quelque chose de différent à chaque fois, donc les assertions se déplacent vers la forme et le comportement autour de la réponse — qu’elle arrive, s’affiche en flux, s’arrête, échoue visiblement et coûte ce qu’elle doit.
- Comment écrire une assertion quand la sortie change à chaque fois ?
- Vérifiez le contrat, pas la prose. Qu’une réponse soit arrivée dans le budget, qu’elle ait été analysée selon le schéma demandé, qu’elle ait cité un document que l’utilisateur peut voir, qu’un refus s’affiche comme un refus. Juger la formulation est une évaluation, lancée séparément de la suite de régression.
- Qu’est-ce que l’injection de prompt, et comment la tester ?
- Des instructions cachées dans un contenu que votre système lit — un document, une page web, un ticket — auxquelles le modèle obéit ensuite. On la teste en plaçant des instructions dans chaque canal qui atteint le modèle et en vérifiant que l’effet n’arrive jamais : aucun outil appelé, aucune donnée renvoyée, aucun prompt système répété.
- Quel est le problème de sécurité le plus courant dans les produits d’IA ?
- Les moins glorieux. Une clé de fournisseur accessible depuis le navigateur, un endpoint de modèle sans limite de débit, et une récupération délimitée par une instruction dans le prompt plutôt que par un filtre sur la requête. Tous trois sont moins chers à trouver qu’un jailbreak astucieux et plus susceptibles d’être là.
- QA Spider peut-il tester mon produit d’IA ?
- Le comportement autour du modèle, oui : flux, délais d’expiration, nouveaux essais, refus, états d’erreur, limites de débit et l’API sous l’interface, testés dans un vrai navigateur à chaque déploiement. Nous ne livrons pas aujourd’hui de suites automatisées d’injection de prompt, et nous préférons le dire plutôt que de vous laisser le découvrir plus tard.
- Vérifiez-vous si le modèle donne des réponses correctes ?
- Non. La justesse demande votre vérité terrain et relève d’un banc d’évaluation que vous possédez et versionnez avec vos prompts. Le test de régression répond à une autre question : ce qui marchait hier marche-t-il encore après le déploiement d’aujourd’hui.
Essayez-le sur votre produit d'IA.
Le comportement autour du modèle — flux, délais d'attente, nouvelles tentatives, refus, limites de débit et API sous l'interface — testé dans un vrai navigateur, à chaque déploiement.