Tests de non-régression : de l’Excel à Playwright

Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 17 octobre 2026.

En bref

Dans la réalisation TW3, l’IA écrit une fois les tests depuis les scénarios métier ; les scripts sont ensuite rejoués sans modèle, avec des preuves en cas d’échec. La réalisation présentée par TW3 Partners au 9 octobre 2026 concerne une plateforme qui évolue chaque semaine, auparavant recettée manuellement sur plusieurs profils. Les scénarios Excel des équipes métier deviennent des scripts Playwright, générés par Claude Sonnet et exécutés sur le cloud Azure du client. Chaque échec est accompagné d’une justification et de captures d’écran.

Selon l’Insee, dans sa publication du 21 juillet 2026, 73 % des entreprises utilisant l’IA en 2025 déclarent l’employer pour optimiser les coûts, notamment par l’automatisation de tâches répétitives. Cette enquête couvre les entreprises en France de 10 salariés ou plus des secteurs principalement marchands, hors agriculture, finance et assurance. Ce chiffre décrit une finalité déclarée ; la réalisation TW3 ne publie aucun gain de temps ni taux de réduction des régressions.

1. Qu’est-ce qu’un test de non-régression automatisé ?

Un test de non-régression désigne ici un scénario rejoué après une modification de l’application pour vérifier qu’un comportement déjà validé reste conforme au résultat attendu. Son automatisation confie au script les actions et les vérifications auparavant réalisées à la main. Pour la direction métier, le point de départ reste donc le cahier de recette : ce que l’utilisateur doit pouvoir faire et le résultat qui permet d’accepter le parcours.

La fiche TW3 Partners décrit une recette manuelle longue et des régressions découvertes tard. L’agent intervient pour convertir les scénarios existants en tests navigateur. Pour reprendre ce fonctionnement, nous recommandons de rejouer les scénarios sur chaque version à valider.

Dans sa documentation « Installation » disponible au 9 octobre 2026, Playwright se définit comme un cadre de tests de bout en bout pour les applications web modernes. Il rassemble l’exécution des tests, les assertions, l’isolation et la parallélisation. Une assertion est la vérification du résultat attendu, selon les bonnes pratiques de Playwright, relevées au 9 octobre 2026. Nous recommandons de commencer la relecture d’un test par cette vérification : quel résultat métier permettra de prononcer sa réussite ?

2. Pourquoi l’agent écrit-il les scripts une seule fois ?

L’agent écrit les scripts une fois pour que les campagnes suivantes exécutent les mêmes instructions, sans solliciter un modèle pour décider des actions. La fiche TW3 Partners décrit explicitement cette séparation : exploration de l’application et production de scripts Playwright déterministes, puis exécution en lot parallèle sans IA dans la boucle.

Étape	Rôle de l’agent	Rôle du script
Préparation	Explorer l’application et produire le code à partir des scénarios	Formaliser les actions à rejouer
Campagne	Aucun appel de modèle pendant l’exécution	Exécuter les tests et alimenter le rapport réussite ou échec

Pour rendre ce fonctionnement contrôlable, nous recommandons de relire les scripts produits et de conserver leur historique de versions. Le responsable de recette doit pouvoir rapprocher le scénario métier de la vérification inscrite dans le code. Toute modification du comportement attendu devrait entraîner une nouvelle validation de ce rapprochement.

La stabilité des instructions doit aussi s’accompagner d’un environnement de test maîtrisé. Les bonnes pratiques de Playwright recommandent notamment de contrôler les données lorsqu’une base est utilisée. Nous conseillons donc d’identifier, pour chaque campagne, la version de l’application et celle des scripts, ainsi que le jeu de données employé. Cette organisation est une recommandation de méthode, à prévoir au cadrage du projet.

3. Comment passer d’un cahier de recette Excel à des tests navigateur ?

Le passage commence par l’import du catalogue de scénarios métier, suivi de l’exploration de l’application par l’agent pour générer les scripts. Ces étapes figurent dans la réalisation TW3 Partners, dont les scénarios sont écrits en Excel par les équipes métier.

Pour préparer cet import, nous recommandons une relecture commune au métier et à l’équipe de développement. Chaque scénario devrait permettre de retrouver le profil concerné, les conditions de départ, les actions à accomplir et le résultat attendu. Cette proposition constitue une grille de préparation ; elle ne décrit pas les colonnes du fichier utilisé dans la réalisation.

La documentation Playwright sur les bonnes pratiques recommande de tester le comportement visible par l’utilisateur. Elle préconise aussi de privilégier des attributs visibles par l’utilisateur pour repérer les éléments. Une dépendance à la structure interne de la page peut faire échouer un test après une modification de cette structure.

Nous conseillons d’appliquer ces critères lors de la relecture du code produit par l’agent : le parcours suit-il le scénario métier ? Les éléments ciblés correspondent-ils aux actions attendues ? Le test vérifie-t-il effectivement le résultat demandé ? Le métier peut relire le parcours et son critère d’acceptation, tandis que le développeur examine leur traduction dans le script.

4. Pourquoi rejouer chaque scénario sur chaque profil d’utilisateur ?

Le rejeu par profil reprend le périmètre de la recette manuelle, qui couvrait déjà plusieurs profils d’utilisateurs. La fiche TW3 Partners indique que les scénarios deviennent des tests rejoués automatiquement sur chaque profil, avec une exécution en lot parallèle.

Nous recommandons de conserver une correspondance explicite entre les scénarios et les profils à couvrir. Avant une campagne, le responsable de recette devrait valider cette liste ; après la campagne, il devrait pouvoir retrouver le verdict associé à chaque parcours exécuté. Le périmètre prévu devient ainsi un document de contrôle pour la livraison.

L’indépendance des tests mérite une attention particulière. Les bonnes pratiques de Playwright demandent que chaque test dispose de son propre état, notamment pour les données et la session. La documentation explique que cette isolation améliore la reproductibilité et évite les échecs en cascade. Nous préconisons donc de vérifier avec la DSI les conditions de remise en état avant le rejeu, particulièrement lorsque plusieurs tests s’exécutent simultanément.

5. Que contient le rapport d’une campagne ?

Le rapport présente la réussite ou l’échec des tests, avec une justification et des captures d’écran pour chaque échec. C’est le livrable décrit dans la fiche TW3 Partners. La personne chargée de la recette dispose ainsi d’éléments à examiner au moment de statuer sur la version.

Nous recommandons d’organiser cette lecture autour du scénario concerné : quelle vérification a échoué, à quel moment du parcours et avec quelle observation à l’écran ? Le compte rendu de recette devrait ensuite conserver la décision prise et la personne chargée de son suivi. Une anomalie acceptée pour la livraison devrait être accompagnée de sa justification dans ce compte rendu.

Pour approfondir un diagnostic, les bonnes pratiques de Playwright décrivent un visualiseur de traces donnant accès à la chronologie des actions et aux requêtes réseau. Cette possibilité de l’outil peut être examinée au cadrage si les captures ne suffisent pas aux besoins de diagnostic. Elle constitue une option de méthode ; le rapport de la réalisation reste décrit par ses verdicts, ses justifications et ses captures.

6. Que faire des tests instables ?

Nous recommandons de trier les tests instables dans une campagne dédiée, étape prévue dans la réalisation TW3 Partners. Dans la documentation « Retries » de Playwright disponible au 9 octobre 2026, le statut « flaky » désigne un test qui échoue au premier passage puis réussit lorsqu’il est relancé. Cette définition décrit un résultat d’exécution ; elle laisse la cause de l’échec à diagnostiquer.

La même documentation distingue les tests réussis dès le premier passage de ceux qui échouent encore après toutes les relances. Nous recommandons de conserver ces distinctions dans la revue de campagne, en associant à chaque instabilité une investigation et une décision de suivi.

La documentation Playwright sur les bonnes pratiques fournit des points de contrôle : indépendance des tests, maîtrise des données et assertions qui attendent la condition recherchée. Ces assertions laissent à l’application le temps de présenter le résultat attendu. Nous conseillons de les examiner pendant le tri, puis de rejouer le scénario après correction. Les causes et corrections retenues doivent rester traçables pour la prochaine campagne.

7. Qui fait quoi entre métier, DSI et prestataire ?

Le métier rédige les scénarios, l’agent produit les scripts et la plateforme de tests les exécute. La fiche TW3 Partners mentionne des ingénieurs déployés chez le client, ainsi que des services de formation et de maintenance. Elle situe l’hébergement dans le cloud Azure du client, avec Container Apps et Azure SQL ; Claude Sonnet intervient dans la génération des scripts.

Pour le fonctionnement courant, nous recommandons de confier au métier la validation des résultats attendus et à l’équipe technique la relecture et l’entretien du code de test. La DSI devrait cadrer l’environnement d’exécution et les conditions d’accès. Le responsable de la livraison devrait disposer du rapport et des décisions prises sur les échecs avant d’autoriser le déploiement.

Il reste à désigner au cadrage qui adaptera ou régénérera un script lorsque l’interface ou le besoin métier change. Nous conseillons de fixer également qui validera cette modification et comment elle sera rattachée au scénario d’origine. La formation et la maintenance peuvent alors être organisées autour de responsabilités explicites.

FAQ

L’IA exécute-t-elle les tests à chaque version ?
Dans la réalisation décrite par TW3 Partners, elle écrit les scripts une fois lors de la préparation. Les campagnes exécutent ensuite les scripts Playwright sans modèle dans la boucle, en lot parallèle.

Faut-il réécrire le cahier de recette existant ?
La fiche TW3 Partners part du catalogue de scénarios Excel des équipes métier, qui est importé. Nous recommandons d’en vérifier les conditions de départ et les résultats attendus avant de générer les scripts.

Qu’est-ce que Playwright ?
Selon sa documentation « Installation », Playwright Test est un cadre de tests de bout en bout pour les applications web modernes. Elle présente notamment les assertions, l’isolation et l’exécution parallèle, utiles pour organiser une campagne de recette.

Comment sait-on pourquoi un test a échoué ?
Chaque échec arrive avec sa justification et ses captures d’écran, selon la fiche TW3 Partners. Nous recommandons que le responsable de recette examine ces éléments avec le scénario et son résultat attendu avant de décider de la suite.

Quel modèle écrit les scripts ?
La fiche TW3 Partners nomme Claude Sonnet pour la génération. L’exécution des tests se déroule ensuite sans modèle sur le cloud Azure du client.

Que faire lorsqu’un échec paraît sans rapport avec une régression ?
Nous recommandons de conserver les preuves et d’examiner le scénario lors du tri des tests instables. Au sens de la documentation « Retries » de Playwright, un test est classé « flaky » lorsqu’il échoue au premier passage puis réussit à la relance ; ce classement appelle une recherche de cause.

Tests de non-régression : transformer des scénarios de recette Excel en tests navigateur