Outils de Tests de Régression en 2026 : ce qui Fonctionne Vraiment pour Votre Produit

Actuellement, les tests de régression consomment entre 50 % et 80 % du budget total de vérification et de maintenance dans la plupart des équipes logicielles. C’est ce qui empêche les produits de se casser entre les versions. Mais si vous brûlez la moitié de votre budget QA sur les mauvais outils, ou pire, sur des exécutions manuelles que votre équipe redoute, vous payez deux fois : une fois pour les tests de régression, une fois pour les bugs qui passent quand même.

Dans ce guide, nous couvrons ce que font réellement les outils actuels de tests de régression, comment en choisir un pour votre situation spécifique, et par où commencer si vous n’avez jamais automatisé cette partie de votre flux de travail.

Principaux Types d'Outils de Tests de Régression

Tous les outils de test de régression logicielle ne sont pas construits de la même manière, et confondre les catégories est comment les équipes finissent avec des licences redondantes ou des lacunes de couverture critiques. Actuellement, le marché se divise essentiellement en cinq types d’outils, chacun gérant une partie spécifique de votre produit. Vous finirez probablement par avoir besoin d’au moins deux d’entre eux.

L’association habituelle est un framework fonctionnel plus une couche visuelle. Les tests fonctionnels vous disent si une fonctionnalité marche. Les tests visuels vous disent si elle a la bonne apparence, ce qu’une suite fonctionnelle au vert ne révélera jamais.

Outils de Tests de Régression Open Source

Ce sont les options par défaut lorsque les ingénieurs possèdent le code de test et qu’il vit dans le même dépôt que le produit. Elles ne coûtent rien en licence et tout en maintenance, ce qui est l’échange que vous acceptez pour un contrôle total. Les trois ci-dessous sont gratuites et activement développées.

Playwright

Playwright de Microsoft est passé de nouveau venu à choix par défaut pour les nouveaux projets web en moins de trois ans, et 2026 est l’année où il a clairement pris de l’avance. La version 1.56 a ajouté trois assistants IA qui divisent le travail qu’un ingénieur QA fait normalement à la main. Le premier explore votre application en direct et rédige un plan en langage simple de ce qui devrait être testé. Le deuxième transforme ce plan en tests fonctionnels. Le troisième intervient quand un test échoue, comprend pourquoi, et le corrige.

L’avantage pratique est que les deux parties les plus fastidieuses de l’automatisation, écrire des tests à partir de zéro et les réparer après chaque changement d’UI, ont désormais un assistant intégré. La configuration prend une seule commande et s’exécute dans l’éditeur de code que vos développeurs utilisent déjà. Vous vérifiez toujours ce que produisent les assistants avant la mise en production, mais le point de départ n’est plus un fichier vide.

Idéal pour : les applications web modernes, la couverture cross-browser à grande échelle, et toute équipe qui démarre à neuf en 2026. C’est aussi le framework que nos propres ingénieurs privilégient le plus souvent dans les projets de tests automatisés.

Selenium

Selenium reste le framework d’automatisation de navigateur le plus largement déployé au monde, et Selenium 4 est une version moderne plutôt qu’un reliquat. Il a apporté une conformité complète au W3C WebDriver, une Grid reconstruite fonctionnant sur Docker et Kubernetes, des API BiDi pour observer les événements du navigateur en temps réel, et un support natif OpenTelemetry pour tracer la performance des tests dans le CI/CD.

Si vous exploitez déjà Selenium à grande échelle, améliorez-le sur place plutôt que de migrer, car une suite fonctionnelle que votre équipe connaît vaut mieux qu’une réécriture qui cale à mi-chemin. Si vous démarrez à neuf en 2026 sur un produit web-first, Playwright est le meilleur choix par défaut. Selenium l’emporte toujours sur les combinaisons inhabituelles de navigateurs et d’OS et pour les équipes standardisées sur Ruby ou un autre langage que Playwright ne cible pas.

Idéal pour : les organisations avec une infrastructure Selenium existante, des stacks multilingues, et des applications héritées avec de larges exigences de compatibilité.

Cypress

Cypress s’exécute à l’intérieur du navigateur lui-même, ce qui est une conception fondamentalement différente de Selenium ou Playwright. Ce choix achète une excellente expérience développeur : vous regardez les tests s’exécuter en direct, revenez en arrière pas à pas à travers eux, et les écrivez avec l’une des API les plus propres disponibles.

Les développeurs frontend l’adoptent plus vite que toute alternative, ce qui compte quand l’objectif est que les ingénieurs possèdent leur propre couverture plutôt que de la balancer par-dessus le mur.

Les limites sont tout aussi claires. Cypress ne fonctionne qu’avec JavaScript et TypeScript, donc il est exclu pour les équipes Python ou Java. La couverture mobile signifie des fenêtres d’affichage adaptatives, pas de vrais appareils. Exécuter des tests en parallèle nécessite un plan Cypress Cloud payant, où l’option gratuite cesse d’être gratuite dès que votre suite grandit.

Idéal pour : les équipes JavaScript-first construisant des applications web modernes qui veulent un retour rapide sans travail d’infrastructure.

Plateformes Commerciales et d'Entreprise

Celles-ci regroupent plusieurs surfaces de test en une seule licence, ce qui séduit les équipes qui devraient sinon jongler avec trois fournisseurs et trois contrats. Le compromis est presque toujours un format de test propriétaire. Pesez la facilité d’exportation avant de vous engager, car une suite que vous ne pouvez pas déplacer est une suite que vous réécrirez éventuellement de zéro.

Katalon Studio

Katalon Studio se situe entre simplicité sans code et puissance scriptée. Il tourne sur Selenium pour le web et Appium pour le mobile, donc migrer une suite Selenium existante est relativement indolore, et il ajoute des tests API REST et SOAP plus une couverture bureau dans le même produit. Les versions récentes superposent la création de tests assistée par IA, des attentes intelligentes, et des localisateurs auto-réparables, avec TestOps vous donnant des tableaux de bord sur la couverture, l’instabilité, et le débit d’équipe.

Le piège est le verrouillage fournisseur. Katalon stocke les scripts de test dans son propre format propriétaire, donc quitter la plateforme signifie reconstruire plutôt qu’exporter.

Idéal pour : les équipes QA aux compétences mixtes où testeurs techniques et non techniques doivent tous deux contribuer, et les organisations consolidant plusieurs outils en un seul contrat.

Tricentis Tosca

Pour les grandes organisations utilisant SAP, Salesforce, Oracle, ou similaire, Tricentis Tosca est dans une catégorie à part. Il utilise le test basé sur les modèles, ce qui signifie que les détails techniques, la logique de test, et les données de test sont stockés séparément et joints seulement lors de l’exécution d’un test. Quand quelque chose change dans l’application, vous mettez à jour le modèle une fois au lieu de modifier cinquante cas de test. Tosca prend en charge plus de 160 technologies, y compris SAP GUI et Fiori, les terminaux mainframe, les applications de bureau Windows, et les logiciels packagés tels que Salesforce et ServiceNow.

Tricentis a lancé Agentic Test Automation avec Vision AI mi-2025, initialement pour SAP Fiori et les applications web. Durant 2026, la capacité s’est déplacée vers Tosca Cloud et a gagné TBox comme second moteur de pilotage, où TBox lit les contrôles par leurs propriétés techniques et Vision AI les reconnaît visuellement. TBox lui-même n’est pas nouveau, il est le moteur d’automatisation central de Tosca depuis des années ; ce qui a changé, c’est que des agents IA peuvent désormais le piloter.

Idéal pour : les organisations d’entreprise, les environnements SAP, et les secteurs réglementés qui ont besoin d’une traçabilité liée au risque métier.

Plateformes Natives IA et Augmentées par IA

Ce groupe mérite sa propre section car l’architecture est vraiment différente. Au lieu de rafistoler des sélecteurs cassés, ces plateformes suppriment entièrement la couche de sélecteurs : vous écrivez des tests en langage naturel ou un agent les écrit pour vous, et les éléments sont identifiés à l’exécution par intention, ancres visuelles, ou correspondance floue.

Les plateformes natives IA intègrent l’intelligence dans la façon dont les tests sont écrits dès le départ. Les plateformes augmentées par IA conservent un enregistreur ou une couche de code conventionnels et ajoutent de la réparation par-dessus, ce qui réduit les dégâts sans supprimer la fragilité sous-jacente. Pour voir comment ces différentes approches se comparent en pratique, il est utile d’évaluer certains des principaux outils de test IA du marché. Si votre produit inclut une fonctionnalité LLM, notez que les sorties du modèle nécessitent une approche entièrement distincte, que nous couvrons dans notre guide sur les tests de régression LLM.

testRigor

testRigor est l’exemple le plus clair d’écrire des tests de la façon dont vous les décririez à un collègue. Vous tapez des instructions comme « cliquez sur le bouton de paiement et confirmez que le total affiche &pound ;49.99 » et la plateforme détermine comment exécuter cela sur l’application en direct. Comme il n’y a aucun sélecteur dans le test, un développeur qui renomme une classe CSS ou restructure un composant ne casse rien.

Le compromis est que vous êtes entièrement à l’intérieur d’un système propriétaire sans code à exporter, et la tarification nécessite une conversation commerciale. Les équipes choisissent testRigor quand les personnes qui comprennent le mieux le produit sont des testeurs manuels plutôt que des ingénieurs, et quand le coût de laisser cette connaissance en dehors de la suite d’automatisation est devenu évident.

Idéal pour : les équipes convertissant des testeurs manuels en contributeurs à l’automatisation.

mabl

mabl a été l’une des premières plateformes à appliquer l’apprentissage automatique à la maintenance des tests, et cette longueur d’avance se voit. Son auto-réparation est vraiment mature, et l’enregistreur visuel plus l’éditeur low-code rendent la création de tests accessible aux ingénieurs QA qui ne scriptent pas. Web, API, et tests cross-browser vivent tous dans une plateforme.

La limitation honnête est que mabl reste conscient des sélecteurs en dessous. Il gère bien les changements d’ID d’élément, les renommages de classe, et les décalages de mise en page, et peine avec des réécritures structurelles plus profondes. Des estimations tierces situent les équipes entre plusieurs centaines et quelques milliers de dollars par mois, bien que mabl ne publie pas de grille tarifaire.

Idéal pour : les équipes dont le problème principal est le coût de maintenance plutôt que la vitesse de rédaction.

ACCELQ

ACCELQ prend un angle différent. Au lieu de modéliser votre interface utilisateur, il modélise vos processus métier, puis génère des scénarios de test qui correspondent à des résultats métier. Pour une plateforme de sinistres ou un produit de prêt, cela signifie que la couverture est mesurée en risque métier plutôt qu’en chemins de code, ce qui est le langage que votre équipe conformité parle déjà.

Idéal pour : les produits réglementés où la validation de la logique métier compte autant que le comportement de l’UI.

Outils de Tests de Régression Visuelle

Les tests fonctionnels s’assurent qu’une fonctionnalité marche, tandis que les outils visuels gèrent son apparence. Il est super courant que les équipes négligent la différence et soient prises au dépourvu. Un changement CSS qui rend un bouton invisible sur Firefox, ou une mise à jour de police qui casse la mise en page de la caisse sur mobile, ne déclenchera pas une seule erreur d’assertion. Votre suite reste au vert pendant que les utilisateurs se heurtent à un mur.

La tarification dans cette catégorie est basée sur le volume et change souvent, vérifiez donc auprès de la page en direct du fournisseur avant de budgétiser. Notre checklist de tests de régression visuelle couvre ce qu’il faut inclure dans la couverture de référence.

Applitools Eyes

Applitools Eyes compare la mise en page, l’alignement, l’espacement, les polices, et les couleurs plutôt que de faire un diff pixel par pixel brut. Cette distinction compte en pratique, car la comparaison de pixels génère un flot de faux positifs dus à l’anti-aliasing et aux différences de rendu de police que personne n’a le temps de revoir. Eyes se superpose à n’importe quel framework fonctionnel que vous utilisez déjà, avec des SDK pour Selenium, Cypress, Playwright, WebdriverIO, et Appium.

Idéal pour : les produits axés design et d’entreprise où les défauts visuels ont un coût commercial.

Percy

Percy est le choix naturel si vous utilisez déjà BrowserStack pour les tests fonctionnels, et le niveau gratuit à 5 000 captures d’écran par mois est assez généreux pour lancer un vrai pilote plutôt qu’un pilote factice. Les revues se déroulent dans une interface partagée où n’importe qui dans l’équipe peut approuver ou rejeter un changement visuel, ce qui garde les designers dans la boucle plutôt que de tout router via la QA.

BrowserStack rapporte que son agent de revue visuelle IA réduit le temps de revue et filtre une grande part des faux positifs dus au rendu sous-pixel et à la variation de police. Ce sont les propres chiffres du fournisseur, vérifiez-les donc par rapport à vos propres niveaux de bruit pendant un essai.

Idéal pour : les équipes déjà sur BrowserStack qui veulent une couverture visuelle sans nouveau cycle d’approvisionnement.

Outils de Tests de Régression SAP

SAP est son propre monde. Plusieurs modules, logique métier personnalisée, applications Fiori fonctionnant aux côtés de transactions GUI classiques, et mises à jour cloud trimestrielles signifient que les frameworks web standards ne peuvent tout simplement pas naviguer l’architecture de façon fiable. Les outils qui fonctionnent ici sont conçus à cet effet.

Tricentis Tosca est le choix le plus large et le plus actuel, couvert en détail ci-dessus. Il lit nativement les définitions d’écran SAP, construit des modules à partir de codes de transaction, et couvre des processus de bout en bout comme order-to-cash et procure-to-pay à travers S/4HANA, Fiori, et SuccessFactors.

Worksoft Certify est la principale alternative. Il adopte une approche sans code pour les tests de processus métier de bout en bout à travers SAP, Salesforce, et Oracle, ce qui convient aux organisations exploitant plusieurs systèmes d’entreprise interconnectés plutôt que SAP seul.

Avantages :

• Les analystes métier peuvent créer de l’automatisation sans écrire de code
• Solide dans les environnements mixtes SAP, Salesforce, et Oracle
• Focalisé sur les processus métier de bout en bout plutôt que sur des écrans individuels

Inconvénients :

• Tarification entreprise sans chiffres publics
• Communauté et écosystème plus restreints que Tricentis
• Valeur limitée si votre stack est du web moderne plutôt qu’un logiciel packagé

Six Questions à Poser Avant de Choisir un Outil

Bien choisir commence par savoir ce que vous résolvez. Ces six questions vous éviteront un déploiement de six mois qui se termine par une licence abandonnée.

1. Quelle est votre pile technologique principale ? Une équipe JavaScript sur React a besoin de quelque chose de différent d’une entreprise Java sur SAP. L’outil doit parler votre langage, littéralement.

2. Qui écrira et maintiendra les tests ? Les équipes QA non techniques ont besoin d’outils sans code ou en langage simple. Les ingénieurs solides tirent plus d’un framework code-first, et cela ne coûte rien en frais de licence.

3. À quelle fréquence livrez-vous ? Les déploiements quotidiens nécessitent un outil qui s’exécute rapidement et se branche sur GitHub Actions, Jenkins, ou GitLab sans travail sur mesure.

4. Que testez-vous réellement ? Web, API, bureau, mobile, ou les quatre. Certains outils font une chose brillamment. D’autres couvrent tout et en font l’essentiel de façon adéquate.

5. À quoi ressemble l’échec pour vous ? Un produit axé design a des enjeux différents d’un backend API. Cela décide si vous avez besoin d’outils de test de régression UI en plus des fonctionnels.

6. Comment l’outil gère-t-il une refonte majeure de l’UI ? Demandez cela à chaque fournisseur et écoutez attentivement la réponse. Cela prédit votre facture de maintenance mieux que n’importe quel benchmark, car une refonte est exactement là où l’automatisation basée sur les sélecteurs s’effondre silencieusement.

Si vous voulez une façon structurée de transformer ces réponses en plan, notre guide de stratégie de tests de régression explique comment arrêter le retour des mêmes bugs.

Plan de Déploiement Pratique en Six Étapes

Savoir quels outils existent est la moitié du problème. Les intégrer dans votre flux de travail sans dérailler votre cycle de version est l’autre moitié. Voici la séquence qui fonctionne.

Étape 1 : Cartographiez d’abord vos chemins critiques. Avant de toucher à un outil, listez les 30 à 50 flux utilisateur que votre produit ne peut pas se permettre de casser : connexion, paiement, saisie de données principale, intégrations clés. Cette liste est votre première suite de régression. Tout le reste attend.

Étape 2 : Adaptez l’outil à votre équipe, pas au battage médiatique. Les ingénieurs JavaScript construisant une application web devraient regarder Playwright ou Cypress. Des compétences mixtes ou une couverture SAP pointent vers Katalon ou Tosca. Des testeurs manuels sans ingénieurs d’automatisation pointent vers testRigor ou Testsigma.

Étape 3 : Commencez par la fumée, pas la régression complète. Une courte suite qui vérifie vos chemins critiques après chaque déploiement vaut plus qu’une suite de quatre heures que personne n’exécute. Commencez petit et exécutez-la à chaque fusion.

Étape 4 : Connectez-la au CI/CD dès le premier jour. Une suite qui s’exécute manuellement est une suite qui cesse de s’exécuter. Câblez l’outil à Jenkins, GitHub Actions, GitLab CI, ou Azure DevOps avant d’écrire votre deuxième test.

Étape 5 : Ajoutez une couverture visuelle là où ça fait le plus mal. Une fois que les tests fonctionnels tournent en CI, choisissez les cinq à dix pages où une mise en page cassée vous coûterait de l’argent et ajoutez-y une couche visuelle. Pas partout.

Étape 6 : Mesurez, puis étendez. Suivez trois chiffres dès le début : temps d’exécution, taux d’échappement de défauts, et taux de faux positifs. Utilisez-les pour décider quoi automatiser ensuite et pour défendre le budget quand quelqu’un le remet en question.

Matrice de Décision

Si vous pesez encore les options, ce tableau réduit le choix par situation. Chaque outil listé ici est expliqué quelque part ci-dessus, donc vous pouvez remonter pour le raisonnement plutôt que de faire confiance à une étiquette d’une ligne.

Il n’y a pas de vainqueur universel, c’est pourquoi les six questions comptent plus que la matrice. Le bon outil est celui que votre équipe exécute réellement. Une suite Selenium bien maintenue bat une configuration Playwright de classe mondiale que personne ne touche.

La Partie dont Personne ne Parle : la Maintenance

Chaque outil ici produit des tests qui finissent par casser, non pas parce que l’outil est mauvais mais parce que votre produit change. C’est le coût caché que la plupart des comparaisons sautent, et c’est là que va le vrai budget après la première année.

Playwright et Cypress ont une surcharge plus faible que Selenium car ils gèrent l’attente automatiquement et génèrent des localisateurs plus stables, et l’agent Healer de Playwright ferme désormais une partie de la boucle de réparation à l’intérieur même du framework. La conception basée sur les modèles de Tosca signifie qu’une mise à jour dans le modèle corrige de nombreux cas de test. Les plateformes natives IA contournent le problème différemment, en identifiant les éléments par intention, de sorte qu’une classe renommée n’est jamais enregistrée comme un changement.

La recherche sur la façon dont les équipes distribuées gèrent cela est mince, mais un point de données utile existe. Cet article d’atelier ACM de 2026, basé sur des entretiens avec vingt professionnels QA, a trouvé que les équipes distantes et hybrides remplacent la coordination informelle en personne par de la documentation, un reporting standardisé, des dépôts partagés, et de la traçabilité plutôt que la seule automatisation. Ce que cela suggère, c’est que votre décision d’outillage est aussi une décision de documentation, car la plateforme devient le registre partagé une fois la conversation de couloir disparue.

Pourquoi les Équipes s'Associent à QAwerk pour les Tests de Régression

Les outils ne se maintiennent pas seuls, c’est pourquoi QAwerk s’intègre pleinement dans votre cycle de version pour construire et exécuter vos suites de régression. Voici à quoi cela ressemble en pratique :

• Granola : Avant de s’associer avec nous, ce bloc-notes IA n’avait pas d’équipe QA interne, nous avons donc construit un framework d’automatisation sur mesure à partir de zéro et l’avons connecté directement à leur flux de travail. Nous avons automatisé 76 % de leur suite de régression principale et détecté plus de 200 bugs, débloquant leurs versions hebdomadaires alors qu’ils atteignaient une valorisation de 1,5 milliard de dollars.
• ClickHouse : Ils devaient augmenter la couverture automatisée sans ralentir leurs builds hebdomadaires. Nous avons conçu une suite de tests quotidienne qui a détecté plus de 250 bugs, gardant leur cadence de version parfaitement sur les rails alors qu’ils développaient rapidement leur base de clients entreprise.
• Thirdfort : Lors d’une migration à enjeux élevés vers une application multiplateforme, nous avons exécuté des cycles de régression côte à côte rigoureux sur de vrais appareils pour protéger leurs flux de conformité stricts. Nous avons détecté plus de 80 bugs critiques, assurant un déploiement sans faille qui n’a pas perturbé les 1 500 entreprises réglementées qui dépendent de la plateforme.

Le schéma est toujours le même : nous choisissons le bon outil pour votre produit, nous prenons en charge la maintenance, et nous donnons à vos développeurs des rapports exploitables. Si les tests de régression ralentissent vos versions, dites-nous ce que vous livrez et nous vous dirons ce qu’il faut pour y remédier.

Questions Fréquentes

Quels outils sont disponibles pour les tests de régression ?

Cinq catégories couvrent le marché en 2026 : frameworks open source (Playwright, Selenium, Cypress), plateformes commerciales tout-en-un (Katalon Studio, Tricentis Tosca), plateformes natives IA (testRigor, mabl, ACCELQ, Testsigma), outils de tests de régression visuelle (Applitools Eyes, Percy, Chromatic, BackstopJS), et services gérés comme QAwerk. Celui qui convient dépend de votre stack, des compétences de votre équipe, et de la fréquence de vos versions.

Qu'est-ce qu'un outil de test de régression ?

Un outil de test de régression réexécute un ensemble défini de tests sur votre application après chaque changement de code, confirmant que les fonctionnalités qui fonctionnaient hier fonctionnent toujours aujourd’hui. Il automatise ce qui signifierait sinon qu’un testeur clique manuellement sur des dizaines ou des centaines de flux utilisateur après chaque déploiement.

Quels sont les meilleurs outils de tests de régression en 2026 ?

Playwright est en tête pour les produits web modernes grâce à sa vitesse, son exécution parallèle intégrée, et ses agents Planner, Generator, et Healer. Selenium reste la référence pour les environnements multilingues et hérités. Applitools Eyes est l’option de régression visuelle la plus solide. Tricentis Tosca est le choix le plus mature pour SAP. Katalon Studio offre le meilleur équilibre pour les équipes aux compétences mixtes.

Quelle est la différence entre les outils de test natifs IA et augmentés par IA ?

Les plateformes natives IA intègrent l’intelligence dans la façon dont les tests sont écrits, donc vous décrivez un scénario en langage simple ou un agent le génère, et les éléments sont trouvés par intention lors de l’exécution du test. Les outils augmentés par IA conservent un enregistreur ou une couche de code conventionnels et ajoutent de l’auto-réparation par-dessus, ce qui réduit la casse sans supprimer la dépendance sous-jacente aux sélecteurs. La différence apparaît lors d’une refonte majeure de l’interface, où les suites natives IA survivent généralement et les suites augmentées par IA souvent pas.

L'automatisation open source a-t-elle encore du sens en 2026 ?

Plus qu’il y a un an. Les agents de Playwright ont amené la boucle de planification, génération, et réparation que facturent les plateformes commerciales dans le niveau gratuit, s’exécutant via le serveur Playwright MCP contre l’arbre d’accessibilité. Vous fournissez toujours le temps d’ingénierie, ce qui est tout l’échange.

Combien coûtent les outils de tests de régression ?

Les frameworks open source sont gratuits. Les outils visuels démarrent avec de vrais niveaux gratuits et évoluent selon le volume de captures d’écran ou de points de contrôle. Les plateformes natives IA coûtent généralement de plusieurs centaines à plusieurs milliers de dollars par mois et publient rarement leurs tarifs. Les suites d’entreprise comme Tricentis Tosca sont estimées par des tiers entre 20 000 et 100 000 &euro ; ou plus par an. Ajoutez la formation, l’infrastructure, et le temps de maintenance à tout chiffre qui vous est communiqué.

Quelles sont les meilleures pratiques pour les outils de tests de régression ?

Quatre choses font la différence : exécutez votre suite à chaque déclenchement de pipeline plutôt que seulement avant les versions, commencez par les chemins critiques plutôt que d’essayer de tout couvrir d’un coup, suivez le taux d’échappement des défauts mois après mois pour prouver le retour sur investissement, et documentez la suite aussi soigneusement que vous la construisez pour que l’outillage devienne le registre partagé de ce qui est testé et pourquoi.