Liste de contrôle pour les tests LLM : guide de pré-lancement

Air Canada a perdu un procès parce que son chatbot avait inventé une politique de remboursement. Le tribunal a jugé que la compagnie aérienne devait honorer ce que le bot avait promis. Klarna a renoncé à sa stratégie de service client axée sur l’IA après que son chatbot ait fourni un service moins performant que celui des humains, et a recommencé à embaucher des agents. Ces deux affaires ont fait la une des journaux car le problème sous-jacent était le même. Un grand modèle linguistique a été mis en production sans le processus d’assurance qualité dont la technologie a réellement besoin.

Ce schéma est très répandu. Le rapport « 2025 State of AI » de McKinsey a révélé que 78 % des organisations utilisent désormais l’IA dans au moins une fonction métier, mais que seulement un tiers environ l’ont déployée à l’échelle de l’entreprise. La plupart des autres mènent des projets pilotes qui soit stagnent en phase de développement, soit sont mis en production avant d’être prêts, sans moyen structuré de savoir ce qui se passe réellement.

Cette liste de contrôle pour les tests de LLM est conçue pour le deuxième groupe. Elle couvre sept étapes préalables au lancement, les seuils qui distinguent le « prêt » du « pas encore prêt », les outils nécessaires à chaque étape, ainsi que les schémas d’échec qui apparaissent le plus souvent lors des tests de LLM pour les produits destinés à la production. Considérez-la comme une étape structurée à franchir avant le lancement.

Pourquoi les tests LLM remettent en cause les principes traditionnels de l’assurance qualité

Les logiciels traditionnels sont déterministes. Une même entrée donne la même sortie, de sorte que les assertions de test sont clairement réussies ou échouées. Les grands modèles linguistiques ne se comportent pas ainsi. Posez deux fois la même question et vous obtiendrez deux réponses valides mais différentes. Modifiez un mot dans l’invite du système, et le comportement en aval évolue d’une manière que vous ne pouvez pas entièrement prédire.

Ce non-déterminisme redéfinit la manière de tester le comportement des LLM. Vous remplacez les assertions binaires par des seuils notés. Vous mesurez la fréquence à laquelle le modèle se comporte correctement plutôt que de déterminer s’il le fait ou non lors d’un seul exécution. Et vous prenez en compte une nouvelle catégorie d’échecs dont l’assurance qualité traditionnelle n’avait jamais à se soucier : hallucinations, injection de prompt, jailbreaks, fuite de données d’entraînement, dérive des biais et régressions silencieuses après chaque mise à jour du modèle.

Il en résulte une discipline de test différente, ancrée dans les métriques d’évaluation des LLM qui comptent et dont la portée dépasse la simple correction fonctionnelle. La liste de contrôle ci-dessous structure cette discipline en sept étapes qui s’appuient les unes sur les autres.

Liste de contrôle en 7 étapes pour les tests des LLM

Exécutez ces étapes dans l’ordre. Chacune produit un résultat dont l’étape suivante a besoin. Si vous sautez les premières étapes, vous le paierez plus tard, lorsque la correction d’un ensemble de données défectueux ou la réécriture d’une invite système coûtera dix fois plus cher que ce qu’elle aurait coûté au premier jour. Les sept étapes ci-dessous reflètent la séquence suivie par la plupart des programmes d’évaluation de LLM destinés à la production, et elles s’adaptent à la hausse ou à la baisse en fonction du niveau de risque.

Étape 1 : Définissez votre contrat d’évaluation

Avant d’écrire le moindre test, documentez trois éléments : le cas d’utilisation, le niveau de risque et les seuils acceptables pour chaque indicateur que vous prévoyez de suivre. Obtenez l’accord des équipes produit, ingénierie et assurance qualité sur ces trois points. Sans ce contrat, toute discussion ultérieure sur la question « est-ce suffisamment bon pour être mis en production ? » deviendra une simple opinion.

Le niveau de risque est primordial. Un chatbot destiné aux clients peut tolérer un taux d’hallucination d’environ 5 %. Un assistant médical ou juridique doit rester en dessous de 1 %. Choisissez d’abord le niveau, puis les seuils. Points de départ courants pour les déploiements en production :

• Fidélité : 0,75 ou plus sur une échelle normalisée de 0 à 1.
• Pertinence de la réponse : 0,70 ou plus.
• Toxicité : 0,10 ou moins.
• Taux d’hallucinations : 5 % ou moins pour une utilisation générale, 1 % pour les contextes à enjeux élevés.

Le contrat devient le critère de sélection. Si un modèle ne respecte pas l’un des seuils, il n’est pas déployé.

Étape 2 : constituez votre ensemble de données de référence

L’ensemble de données est le fondement de tous les tests qui suivront. Un ensemble de données médiocre vous donnera des chiffres qui semblent fiables mais qui ne signifient rien en production.

Pour un lancement de base, constituez au moins 50 exemples. Pour une évaluation de niveau production, visez 500 exemples ou plus. La meilleure source est constituée de données d’utilisation réelles, anonymisées et étiquetées. Si vous ne disposez pas encore de telles données, simulez des entrées représentatives dans trois catégories : les cas normaux que les utilisateurs rencontreront la plupart du temps, les cas limites tels que les scénarios rares et les entrées mal formées, et les entrées adversaires, y compris les tentatives de jailbreak et les invites de violation de périmètre.

Lorsque les équipes demandent comment tester des applications LLM sans avoir d’abord constitué un ensemble de données de référence, la réponse honnête est qu’elles ne le peuvent pas. L’ensemble de données doit venir en premier, même s’il est modeste au départ, et s’enrichir à mesure que les journaux de production révèlent de nouveaux schémas de défaillance au cours des premières semaines d’utilisation.

Étape 3 : Tester la qualité des résultats

C’est par là que la plupart des équipes commencent, souvent avant qu’elles ne le devraient. Les tests de qualité des résultats couvrent trois indicateurs qui fonctionnent ensemble :

• La fidélité mesure si la réponse du modèle reste dans les limites du matériel source. C’est un critère non négociable pour tout système RAG.
• La pertinence de la réponse mesure si la réponse répond effectivement à la question de l’utilisateur. Une réponse fidèle peut tout de même répondre à la mauvaise question.
• Le taux d’hallucination mesure la fréquence à laquelle les résultats contiennent des affirmations factuellement erronées, avec des seuils adaptés à votre niveau de risque.

Pour les pipelines RAG, les tests de récupération précèdent les tests de génération. Les analyses du secteur montrent systématiquement que la majorité des échecs RAG proviennent de la récupération, et non du modèle lui-même. Une suite pratique d’outils d’évaluation RAG permet de détecter les lacunes de récupération avant qu’elles n’atteignent les réponses destinées aux utilisateurs.

Parmi les outils qui fonctionnent bien à ce stade, on peut citer DeepEval, Ragas et G-Eval pour la notation LLM-as-a-judge. Prévoyez une à deux semaines pour cette étape sur un produit destiné aux clients.

Étape 4 : Tests de biais et de sécurité

Les tests de sécurité couvrent deux aspects distincts. L’évaluation de la toxicité détecte les résultats nuisibles, offensants ou discriminatoires au moment de la génération. Les tests de biais mettent en évidence des différences systématiques dans la manière dont le modèle traite différents groupes démographiques, même lorsque les réponses individuelles semblent correctes prises isolément.

Les scanners automatisés détectent les cas évidents. L’API Perspective de Google constitue une référence courante en matière de toxicité, et des bibliothèques telles qu’AIF360 facilitent les analyses d’équité démographique. Cependant, les outils automatisés ne détectent pas les préjudices subtils et spécifiques au contexte. C’est pourquoi le cadre de gestion des risques liés à l’IA du NIST et son profil d’IA générative préconisent de combiner l’évaluation automatisée avec une révision humaine tout au long du cycle de vie de l’IA. Les programmes les plus performants associent chaque analyse automatisée à une révision manuelle d’au moins 50 cas limites signalés pour un jugement humain.

La pression en matière de conformité renforce désormais cette étape. La loi européenne sur l’IA exige que les systèmes d’IA à haut risque documentent les tests de précision, d’atténuation des biais et de supervision humaine. Pour les produits commercialisés dans l’UE, cette étape n’est plus facultative, même si vous l’aviez ignorée auparavant.

Étape 5 : Effectuer des tests de sécurité et des tests de type « red team »

Les LLM introduisent une surface d’attaque pour laquelle les tests de sécurité traditionnels n’ont pas été conçus. Les cinq vecteurs les plus courants à tester avant le lancement :

• L’injection directe de prompt, où la saisie de l’utilisateur remplace le prompt du système.
• L’injection indirecte de prompts via des instructions malveillantes intégrées dans des documents récupérés, des URL ou des fichiers téléchargés.
• Les jailbreaks utilisant des jeux de rôle, des scénarios hypothétiques ou des invites de type DAN qui contournent les filtres de sécurité.
• Tentatives d’extraction de l’invite système qui révèlent votre modèle et tout contexte sensible qu’il contient.
• Fuite de données d’entraînement sous forme de requêtes spécialement conçues qui extraient des fragments de l’ensemble d’entraînement du modèle.

Les scanners automatisés tels que Garak et PyRIT couvrent les schémas d’attaque connus au niveau des couches d’entrée et de sortie. Ils sont nécessaires mais ne suffisent pas. Les injections indirectes via du contenu de confiance et les exploits d’outils en chaîne nécessitent généralement l’intervention de red teamers humains pour être détectées, car elles dépendent d’un contexte que le scanner ne peut pas voir.

Pour les déploiements en production, associez la base de référence automatisée à des services de tests d’intrusion ciblés. C’est à ce stade que les équipes qui font l’impasse sur l’expertise externe perdent le plus, car les attaques LLM les plus impactantes sont rarement celles mentionnées dans la documentation.

Étape 6 : Valider les performances, la latence et le coût

Les tests de performance des produits basés sur les LLM vont au-delà de la simple question « la réponse semble-t-elle rapide ? ». Trois chiffres sont essentiels. Le temps jusqu’au premier token (TTFT) détermine la vitesse perçue pour les interfaces de streaming et doit être inférieur à une seconde pour le chat. La latence totale de réponse, en particulier la valeur p95, en dit plus long que la moyenne sur l’expérience utilisateur réelle. Le coût par requête doit être suivi à la base de référence et à dix fois le volume de production prévu, car l’architecture qui gère 10 utilisateurs de test pour deux cents dollars par mois se comporte très différemment avec cinquante mille sessions simultanées.

C’est là que les équipes qui se demandent comment tester les LLM sous une charge réaliste découvrent que leur architecture pilote ne peut pas évoluer. Les couches de mise en cache, les modèles de secours, la limitation de débit et les équilibreurs de charge redéfinissent tous le profil de latence et de coût en production. Effectuez des tests de charge sur l’architecture de production, pas sur le pilote.

Étape 7 : Finaliser la suite de tests de régression et l’observabilité

La dernière étape est celle que la plupart des équipes considèrent comme facultative, ce qui explique aussi pourquoi elles déploient puis se dégradent discrètement. Chaque mise à jour de prompt, chaque changement de modèle et chaque modification de la base de connaissances peut briser ce qui fonctionnait hier.

Intégrez les tests de toutes les étapes précédentes dans une suite de tests de régression qui s’exécute à chaque modification, et non à chaque version. Enregistrez les scores de référence afin que les régressions futures soient visibles immédiatement, et non après une réclamation client. Ajoutez l’observabilité en production avant le lancement, et non après le premier incident. Le traçage, la journalisation des réponses et les alertes de dérive doivent tous être en place dès le premier jour.

Les tests de régression pour les produits basés sur les LLM diffèrent des tests de régression traditionnels. La suite est probabiliste, les seuils sont notés et les comparaisons s’effectuent entre des distributions plutôt que sur des correspondances exactes. Le principe reste toutefois le même : détecter la régression en CI, et non sur la capture d’écran d’un client publiée sur les réseaux sociaux.

Où les tests LLM échouent, même avec la liste de contrôle

Même une liste de contrôle complète pour les tests d’IA laisse place à des échecs prévisibles. Trois schémas reviennent régulièrement lors des revues de pré-lancement des produits basés sur les LLM.

Considérer l’évaluation comme un rituel de lancement. Les équipes exécutent la liste de contrôle une seule fois, atteignent leurs seuils, livrent le produit et mettent la suite de tests de côté. La première mise à jour du modèle annule silencieusement la moitié des gains, et personne ne s’en rend compte jusqu’à ce qu’un utilisateur le signale. La solution consiste à intégrer la suite de tests de régression à chaque déploiement, et non à en faire une étape que l’on coche puis que l’on oublie.

Tester le modèle de manière isolée. Un modèle qui obtient de bons résultats dans un environnement de test peut tout de même échouer en production parce que la récupération est défaillante, que l’invite du système est obsolète ou qu’un outil d’intégration limite le débit au mauvais moment. La liste de contrôle ne fonctionne que lorsqu’elle est appliquée à l’ensemble de la pile intégrée, y compris la couche d’orchestration, le pipeline RAG et toutes les API en aval auxquelles le modèle peut accéder.

Sauter les tests adversariaux parce que le produit semble présenter peu de risques. Les outils internes peuvent eux aussi être piratés. Tout LLM connecté à des données réelles, à des outils ou à des entrées utilisateur doit passer par l’étape 5, que votre public soit une seule équipe ou un million d’utilisateurs. Le cas de Klarna est instructif à cet égard. Un bot d’assistance que les utilisateurs ont piégé pour qu’il écrive du code Python n’était pas un déploiement à haut risque, mais les répercussions sur la réputation ont tout de même fait l’objet d’une couverture médiatique mondiale.

De la liste de contrôle au lancement

Une phase de tests pré-lancement dure généralement de trois à six semaines pour un produit destiné aux clients. Les outils internes peuvent être livrés en une à deux semaines si l’ensemble de données est prêt. Les déploiements à haut risque dans les secteurs réglementés nécessitent généralement six à douze semaines pour satisfaire à l’examen de conformité.

Le processus en sept étapes vous fournit la structure. Les seuils vous indiquent les étapes à franchir. La suite de tests de régression et la couche d’observabilité vous permettent de conserver ce que vous avez acquis grâce aux tests. Ce que cette liste de contrôle ne peut pas vous apporter, c’est le temps que vous n’avez pas prévu pour les tests au départ.

Si vous êtes plus proche du lancement que vous ne le souhaiteriez, contactez-nous et nous vous indiquerons quelles étapes exécuter en priorité en fonction de votre calendrier. Les services de test de LLM de QAwerk couvrent l’ensemble du processus grâce à des ingénieurs seniors expérimentés dans l’évaluation pré-lancement de LLM de production.

FAQ

Quelle est la différence entre les tests et l’évaluation des grands modèles de langage (LLM) ?

L’évaluation mesure la qualité des résultats par rapport à des indicateurs définis tels que la fidélité, la pertinence des réponses et la toxicité. Le test est un processus plus large qui inclut l’évaluation ainsi que des contrôles de sécurité, de performance, d’intégration et de régression. La plupart des équipes de production ont besoin des deux, exécutés de manière séquentielle, avant de déployer un grand modèle linguistique dans un contexte en contact avec la clientèle.

Combien de temps dure le test d’un LLM ?

Un cycle standard de pré-lancement prend trois à six semaines pour un produit destiné aux clients. Les outils internes peuvent être livrés en une à deux semaines si l’ensemble de données est prêt. Les déploiements à haut risque dans les domaines médical, juridique ou financier durent généralement de six à douze semaines afin de répondre aux exigences réglementaires et de conformité.

En quoi les tests des LLM diffèrent-ils des tests logiciels traditionnels ?

Les logiciels traditionnels sont déterministes : les tests réussissent ou échouent en fonction d’une correspondance exacte des résultats. Les grands modèles linguistiques produisent des résultats probabilistes, ce qui signifie qu’une même entrée peut renvoyer différentes réponses valides. Les tests remplacent les assertions binaires par des seuils notés en termes de précision, de sécurité, de latence et de cohérence, et ajoutent une toute nouvelle catégorie de contrôles adversariaux.

Quels outils sont utilisés pour les tests des LLM ?

Parmi les outils courants, on trouve DeepEval et Ragas pour la qualité des résultats, Promptfoo pour la régression des invites, Garak et PyRIT pour la sécurité adversaire, LangSmith et OpenAI Evals pour les pipelines d’évaluation, et Guardrails AI pour l’application de la sécurité en exécution. La plupart des équipes de production en combinent trois ou quatre en fonction de leur cas d’utilisation et de leur budget.