Réflexion stratégique sur le choix du cadre de tests automatisés E2E

Billet #195 : Réflexion stratégique sur le choix du cadre d'automatisation E2E
Type : Stratégie / Automatisation / Positionnement technique
Composants concernés : e2e/, e2e/playwright.config.ts, e2e/package.json, e2e/src/pages/, e2e/src/tests/, documentation technique du projet

1. Contexte

Le projet Analyste Financier Augmenté a deux objectifs principaux. Il sert à la fois à construire une application privée d’analyse de portefeuille boursier et à expérimenter l’automatisation du développement logiciel avec l’aide de l’IA.

Dans ce cadre, le choix du cadre de test E2E et du langage associé ne devait pas seulement répondre à un besoin technique immédiat. Il devait aussi soutenir trois ambitions complémentaires : la fiabilité du produit, la montée en compétences sur des outils recherchés sur le marché canadien, et la capacité à faire évoluer le projet sur le long terme.

2. Question de départ

La réflexion portait sur deux décisions liées :

quel cadre de test privilégier pour automatiser les parcours UI du projet (Playwright, Selenium ou Cypress) ;
quel langage retenir pour structurer ce cadre de test sur la durée (TypeScript ou une alternative plus proche du backend Python).

L'objectif n'était pas de choisir l'outil « à la mode », mais la combinaison la plus cohérente avec la réalité du projet : application Flask privée, logique QA forte, documentation pilotée par les tests, automatisation continue et expérimentation active autour de l'IA.

3. Analyse des options

3.1 — Pourquoi Playwright s'impose face à Selenium et Cypress

Selenium reste une référence historique, mais il impose souvent une couche d'orchestration plus lourde et plus verbeuse pour obtenir un niveau de stabilité comparable. Pour un projet solo, évolutif et orienté rapidité d'itération, cette lourdeur aurait ajouté de la friction sans bénéfice décisif.

Cypress, de son côté, est très agréable pour un usage front-end local, mais il correspond moins bien à une stratégie E2E plus large intégrant multi-navigateurs, rapports structurés, traçabilité et montée en maturité du cadre de test sur le long terme.

Playwright offrait donc le meilleur équilibre pour ce projet :

support natif de chromium, firefox et webkit ;
exécution moderne et plus stable des scénarios navigateur ;
rapports HTML et traces utiles à la QA ;
bonne compatibilité avec une architecture Page Object Model ;
intégration naturelle dans une logique CI/CD et documentation de qualité.

3.2 — Pourquoi le débat TypeScript vs Python restait légitime

Le backend, le pipeline de données, les tests Pytest et une grande partie de l'automatisation du dépôt reposent déjà sur Python. Dans une logique de simplification maximale, il aurait donc été parfaitement défendable d'utiliser aussi Playwright en Python afin de réduire la fragmentation technologique.

Cette option reste pertinente pour un projet purement personnel, centré uniquement sur la rapidité d'apprentissage et la cohérence mono-langage.

4. Décision retenue : `Playwright + TypeScript`

Malgré l'avantage de cohérence apporté par Python, la décision la plus stratégique pour ce projet a été de conserver Playwright + TypeScript pour la couche E2E.

Ce choix s'explique par plusieurs raisons :

il renforce des compétences modernes directement valorisables sur le marché de l'emploi ;
il aligne le projet avec des pratiques actuelles d'automatisation UI et de QA engineering ;
il apporte une meilleure structuration à long terme pour les pages, fixtures, configurations et scénarios ;
il complète le socle Python du projet au lieu de le concurrencer.

La répartition devient alors claire :

Python pour le backend, la data, l'ETL, l'IA et les validations métier ;
Playwright + TypeScript pour l'automatisation UI, les parcours utilisateur et la fiabilisation navigateur.

Cette séparation n'est pas une dispersion ; elle constitue un compromis réfléchi entre cohérence technique, apprentissage utile et employabilité.

5. Pourquoi ce choix est important pour le projet et pour l'industrie

Pour le projet, cette décision donne une direction stable : construire une application réelle tout en transformant le dépôt en terrain d'expérimentation crédible pour l'automatisation du cycle de développement, l'usage de l'IA, la documentation durable et la qualité logicielle.

Pour l'industrie, elle reflète une évolution de fond : les systèmes logiciels de demain devront combiner plusieurs couches de compétences — backend, data, qualité, CI/CD, documentation structurée et IA assistive — au lieu de les traiter comme des silos séparés. Ce projet sert précisément à explorer cette convergence dans un cadre concret, versionné et mesurable.

6. Plan d'implémentation prévu du cadre de test

À la suite de cette décision stratégique, le plan d'implémentation du cadre de test E2E automatisé a été structuré en 7 tâches :

Tâche 1 : fondations techniques du cadre de test (Billet #167) ;
Tâche 2 : navigation intelligente et audit d'architecture (Billet #168) ;
Tâche 3 : sécurisation des environnements et protection des identifiants (Billet #169) ;
Tâche 4 : intelligence des données de test avec Faker et DDT (Billet #170) ;
Tâche 5 : optimisation des performances et de la robustesse via Storage State (Billet #171) ;
Tâche 6 : ajout des tests avancés API et visuels ;
Tâche 7 : mise en place de la traçabilité, du retry et du CI/CD.

Ce plan transforme la réflexion stratégique en feuille de route opérationnelle, progressive et mesurable.

7. Conclusion

À la lumière des objectifs du projet, Playwright apparaît comme le meilleur choix pour le cadre de test E2E, et TypeScript comme le meilleur complément stratégique à long terme, malgré la forte présence de Python dans le reste de l'application.

Si l'objectif avait été uniquement la simplicité immédiate, Playwright en Python aurait pu être privilégié. Mais dans une perspective d'évolution, d'automatisation avancée et de développement de compétences recherchées sur le marché, la combinaison Playwright + TypeScript reste la recommandation la plus cohérente.