01 — Sous le capot
Ce qu'il y a derrière l'outil
Avant de comparer des produits, il est utile de savoir de quoi ils sont faits.
Le modèle de langage lui-même
La couche d'orchestration
La source de connaissance du projet
La gestion du contexte
Les garde-fous
Savoir laquelle de ces briques pose problème change tout. Une réponse hors sujet vient très souvent d'un contexte projet absent. Le modèle, lui, est rarement en cause. Changer d'outil ne corrige alors rien du tout.
02 — Panorama
Familles d'outils
Il existe aujourd'hui plusieurs familles d'outils basés sur un modèle de langage, du plus intégré au plus autonome.
Assistants intégrés à l'environnement de développement
Exemple : un assistant comme GitHub Copilot suggérant le squelette d'un script Playwright ou une liste de valeurs de test au format JSON directement dans VS Code.
Plateformes de test de bout en bout dotées de fonctions d'IA
Exemple : un outil d'automatisation comme Testim ou ACCELQ utilisant l'IA pour ajuster dynamiquement ses sélecteurs de boutons et éviter que les tests ne tombent en échec lors d'une refonte graphique.
Outils de comparaison visuelle basés IA
Exemple : une plateforme comme Applitools comparant le rendu de la page d'accueil sur Chrome et Safari.
Plateformes d'orchestration et agents de test
Exemple : un agent autonome à qui l'on fournit une User Story et qui navigue de lui-même dans l'application web pour valider le parcours d'achat. Il soumet un rapport détaillé des anomalies rencontrées sans scénario pré-écrit.
Quelle que soit la famille retenue, ces outils ne créent pas un processus parallèle. Ils se branchent sur les étapes de test déjà connues.
Les produits nommés ci-dessus illustrent chaque famille à un instant donné du marché. Ce ne sont ni des recommandations ni une liste exhaustive. Le syllabus CT-GenAI ne cite lui-même aucun outil.
03 — La brique décisive
Donner à l'IA la connaissance du projet
Quatre façons de faire, de la plus légère à la plus lourde. Elles répondent au même besoin. Elles n'ont ni le même coût ni la même portée. Sur mobile, swipez la carte pour passer à la suivante.
Tout coller dans le prompt
La façon la plus simple consiste à copier les règles de gestion ou la user story dans la demande. Aucune installation, aucun outil supplémentaire. C'est ce que fait n'importe quel testeur avec un chatbot. Pour une tâche ponctuelle, c'est déjà très efficace.
La limite : La fenêtre contextuelle est vite saturée. Il ne faut pas y insérer un référentiel de mille cas de test. De plus, tout doit être réinséré à chaque nouvelle conversation.
Brancher une recherche documentaire
L'outil va chercher lui-même l'information au moment de la demande. Sur le web, ou dans un espace documentaire d'entreprise. Il l'ajoute ensuite au prompt avant d'appeler le modèle. La réponse s'appuie donc sur une information à jour, et non sur ce que le modèle a mémorisé pendant son entraînement. C'est déjà du RAGRetrieval-Augmented Generation, ou génération augmentée par la recherche, dans sa forme la plus simple. Rien n'est préparé à l'avance. La recherche se refait à chaque question.
La limite : La qualité de la réponse dépend entièrement de celle de la recherche. Une recherche par mots-clés qui rate le bon document produit une réponse confiante et hors sujet.
Indexer la documentation du projet
C'est la forme de RAGRetrieval-Augmented Generation, ou génération augmentée par la recherche la plus répandue en entreprise. La documentation du projet est découpée en fragments puis indexée une fois pour toutes. À chaque demande, les fragments les plus proches de la question sont retrouvés et injectés dans le prompt. La recherche ne porte plus sur les mots employés mais sur le sens. Le modèle ne change pas. C'est ce qu'on lui donne à lire qui change.
La limite : Il faut construire cet index, et surtout le maintenir. Une documentation indexée il y a six mois répond avec les informations d'il y a six mois.
Spécialiser le modèle par fine-tuning
Le fine-tuning réentraîne partiellement un modèle existant. On lui fournit un jeu d'exemples propres à l'organisation, par exemple plusieurs milliers de cas de test déjà rédigés au format maison. Le modèle intègre alors le style et le vocabulaire attendus. On n'a plus besoin de les redemander à chaque prompt.
La limite : Le coût, le volume d'exemples nécessaire et la préparation des données dépassent presque toujours ce qu'une équipe de test peut porter seule. Et le modèle spécialisé n'apprend pas les faits du projet. Il en apprend la forme. Il ne remplace donc jamais le RAG.
Tout coller dans le prompt
La façon la plus simple consiste à copier les règles de gestion ou la user story dans la demande. Aucune installation, aucun outil supplémentaire. C'est ce que fait n'importe quel testeur avec un chatbot. Pour une tâche ponctuelle, c'est déjà très efficace.
La limite : La fenêtre contextuelle est vite saturée. Il ne faut pas y insérer un référentiel de mille cas de test. De plus, tout doit être réinséré à chaque nouvelle conversation.
Brancher une recherche documentaire
L'outil va chercher lui-même l'information au moment de la demande. Sur le web, ou dans un espace documentaire d'entreprise. Il l'ajoute ensuite au prompt avant d'appeler le modèle. La réponse s'appuie donc sur une information à jour, et non sur ce que le modèle a mémorisé pendant son entraînement. C'est déjà du RAGRetrieval-Augmented Generation, ou génération augmentée par la recherche, dans sa forme la plus simple. Rien n'est préparé à l'avance. La recherche se refait à chaque question.
La limite : La qualité de la réponse dépend entièrement de celle de la recherche. Une recherche par mots-clés qui rate le bon document produit une réponse confiante et hors sujet.
Indexer la documentation du projet
C'est la forme de RAGRetrieval-Augmented Generation, ou génération augmentée par la recherche la plus répandue en entreprise. La documentation du projet est découpée en fragments puis indexée une fois pour toutes. À chaque demande, les fragments les plus proches de la question sont retrouvés et injectés dans le prompt. La recherche ne porte plus sur les mots employés mais sur le sens. Le modèle ne change pas. C'est ce qu'on lui donne à lire qui change.
La limite : Il faut construire cet index, et surtout le maintenir. Une documentation indexée il y a six mois répond avec les informations d'il y a six mois.
Spécialiser le modèle par fine-tuning
Le fine-tuning réentraîne partiellement un modèle existant. On lui fournit un jeu d'exemples propres à l'organisation, par exemple plusieurs milliers de cas de test déjà rédigés au format maison. Le modèle intègre alors le style et le vocabulaire attendus. On n'a plus besoin de les redemander à chaque prompt.
La limite : Le coût, le volume d'exemples nécessaire et la préparation des données dépassent presque toujours ce qu'une équipe de test peut porter seule. Et le modèle spécialisé n'apprend pas les faits du projet. Il en apprend la forme. Il ne remplace donc jamais le RAG.
Dans la très grande majorité des cas, les deux premières approches suffisent. La troisième couvre presque tout le reste.
Pour aller plus loin, la mécanique d'un RAG
Comprendre le principe suffit pour choisir un outil. Cette partie s'adresse à qui veut aller plus loin. Elle détaille ce qui se passe entre la question posée et la réponse obtenue.
Le découpage en fragments
La transformation en vecteurs
Le stockage en base vectorielle
L'injection dans le prompt
04 — S'organiser
Choisir un outil
Quelques critères concrets pour évaluer un outil avant de l'adopter. Sur mobile, swipez la carte pour passer à la suivante.
La pertinence des suggestions
Un outil qui génère beaucoup de contenu mais peu exploitable coûte plus de temps en relecture qu'il n'en fait gagner. Tester l'outil sur un cas réel du projet avant de l'adopter reste le meilleur moyen de juger sa pertinence effective.
L'explicabilité des résultats
Quand l'outil priorise ou signale un test, peut-on comprendre pourquoi ? Un outil doit pouvoir expliquer ses choix auprès des parties prenantes.
Le coût à l'échelle de l'équipe
Le coût d'un outil basé sur un modèle de langage dépend souvent du volume de contenu traité, pas seulement du nombre de licences. Un usage qui semble abordable en test devient parfois coûteux une fois généralisé à toute l'équipe.
Le traitement de la confidentialité des données
Où sont hébergées les données envoyées à l'outil, et sont-elles réutilisées pour entraîner d'autres modèles ? Cette question se pose avec d'autant plus de force pour un outil qui traite en continu du code et des données de test.
La facilité d'intégration avec l'existant
Un outil qui s'ajoute proprement à la chaîne d'intégration continue déjà en place vaut mieux qu'un outil puissant mais qui impose de reconstruire une partie de l'infrastructure de test pour l'accueillir.
La pertinence des suggestions
Un outil qui génère beaucoup de contenu mais peu exploitable coûte plus de temps en relecture qu'il n'en fait gagner. Tester l'outil sur un cas réel du projet avant de l'adopter reste le meilleur moyen de juger sa pertinence effective.
L'explicabilité des résultats
Quand l'outil priorise ou signale un test, peut-on comprendre pourquoi ? Un outil doit pouvoir expliquer ses choix auprès des parties prenantes.
Le coût à l'échelle de l'équipe
Le coût d'un outil basé sur un modèle de langage dépend souvent du volume de contenu traité, pas seulement du nombre de licences. Un usage qui semble abordable en test devient parfois coûteux une fois généralisé à toute l'équipe.
Le traitement de la confidentialité des données
Où sont hébergées les données envoyées à l'outil, et sont-elles réutilisées pour entraîner d'autres modèles ? Cette question se pose avec d'autant plus de force pour un outil qui traite en continu du code et des données de test.
La facilité d'intégration avec l'existant
Un outil qui s'ajoute proprement à la chaîne d'intégration continue déjà en place vaut mieux qu'un outil puissant mais qui impose de reconstruire une partie de l'infrastructure de test pour l'accueillir.
05 — Points de vigilance
Quelques questions à se poser
Ces limites concernent l'infrastructure elle-même.
La latence ajoutée par un appel externe
La dépendance à un fournisseur unique
La gestion des clés d'accès
Qui surveille le modèle une fois en place
A retenir
Ce qu'il faut retenir
Un outil basé LLM est fait de plusieurs briques
Le modèle, la couche d'orchestration, la source de connaissance du projet, la gestion du contexte et les garde-fous. Savoir laquelle pose problème évite de changer d'outil quand c'est le contexte fourni qui était en cause.
Quatre familles d'outils, un niveau d'autonomie croissant
De l'assistant intégré à l'éditeur jusqu'à l'agent de test autonome. Chaque famille déplace un peu plus loin la part que l'outil prend en charge seul.
Le RAG donne au modèle la connaissance du projet
On ne réentraîne pas le modèle. On lui fait lire la documentation du projet au moment de la demande. C'est l'approche qui répond au plus grand nombre de besoins d'une équipe de test.
Le fine-tuning arrive en dernier
Il enseigne une forme et un vocabulaire, pas les faits d'un produit. Son coût et le volume d'exemples nécessaire le placent hors de portée de la plupart des équipes de test, et il ne remplace pas le RAG.
Ces outils se branchent sur la chaîne existante
Un outil basé LLM s'ajoute au processus de test déjà en place.
Le choix d'un outil se fait sur des critères concrets
Pertinence des suggestions, explicabilité, coût réel à l'échelle de l'équipe, confidentialité des données et facilité d'intégration.
L'infrastructure elle-même a ses propres limites
Latence, dépendance à un fournisseur, gestion des clés d'accès et surveillance du modèle dans la durée. Ces risques techniques sont distincts de ceux déjà vus sur le contenu généré par l'IA.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Un outil de test basé LLM propose des cas de test qui ignorent une règle métier pourtant écrite dans la spécification du projet. Quelle brique est la plus probablement en cause ?
Une conversation longue avec un assistant de test finit par ignorer une contrainte de format donnée au tout début. Quelle brique est en cause ?
Un outil interne retire les identifiants clients d'un prompt avant l'envoi, puis vérifie que la réponse respecte le format attendu. De quelle brique s'agit-il ?
Quelle est la différence de fond entre le RAG et le fine-tuning ?
Pourquoi une base de données vectorielle est-elle utilisée dans une infrastructure RAG plutôt qu'une recherche par mots-clés ?
Une équipe indexe sa documentation en fragments d'une page entière. Les réponses obtenues citent beaucoup de texte hors sujet. Quel réglage revoir en premier ?
Une documentation indexée dans un RAG il y a six mois n'a pas été mise à jour depuis. Quel est le risque principal ?
À quoi servent les LLMOps dans une chaîne de test basée sur un modèle de langage ?
Une équipe veut qu'un assistant génère des cas de test au format maison, à partir d'exigences produit qui changent chaque sprint. Par quoi commencer ?
Qu'est-ce qui distingue une plateforme d'orchestration et d'agents de test des trois autres familles d'outils ?
Pourquoi tester un outil sur un cas réel du projet avant de l'adopter ?
Pourquoi l'explicabilité des résultats est-elle un critère de choix important ?
Pourquoi la latence ajoutée par un appel à un modèle externe peut-elle poser problème en intégration continue ?
Que risque une chaîne de test construite entièrement autour d'un seul fournisseur de modèle ?
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin