Automatisation · 5 min de lecture ·
Dans la plupart des projets que nous auditons, le choix de l’outil n’explique ni les succès ni les échecs. Voici les cinq critères qui décident réellement — et les trois causes d’instabilité qu’aucune migration ne règle.
La question revient à chaque cadrage : « on part sur quoi, Playwright ou Selenium ? »
Elle est mal posée. Dans la grande majorité des projets que nous auditons, le choix de l’outil n’explique ni les succès, ni les échecs. Une suite instable le reste après migration, parce que les causes de l’instabilité sont ailleurs : données partagées, attentes mal gérées, tests au mauvais niveau.
Cela dit, le choix n’est pas neutre. Voici les critères qui le déterminent réellement.
Selenium a longtemps souffert d’une réputation méritée : attentes explicites à écrire soi-même, instabilité chronique, configuration des pilotes de navigateur pénible. Ces trois points ont été largement traités dans les versions récentes.
Playwright est arrivé avec trois apports réels : attente automatique par défaut, isolation des contextes de navigateur, et un outillage de diagnostic nettement supérieur.
Ce qui n’a pas changé : aucun des deux ne vous dispense de concevoir votre architecture de tests. L’outil ne décide ni du niveau auquel vous testez, ni de la gestion de vos données, ni de ce que vous faites d’un test instable.
C’est le critère numéro un, et il tranche la plupart des cas à lui seul.
Playwright est excellent en TypeScript, bon en Python, correct en Java et en .NET. Selenium est natif dans tous ces langages, avec une maturité équivalente partout — c’est sa force historique.
Si votre équipe de développement écrit du Java et que vos testeurs travaillent avec eux, écrire les tests en TypeScript crée une frontière. La revue de code croisée devient impossible, le partage d’utilitaires aussi. Le gain technique de l’outil ne compense presque jamais cette rupture.
Choisissez le langage de l’équipe qui maintiendra les tests, puis l’outil qui le sert le mieux.
| Contexte | Ce qui pèse |
|---|---|
| Application web moderne, rendu côté client | Playwright — l’attente automatique élimine une catégorie entière de problèmes |
| Application patrimoniale, pages serveur | Les deux conviennent ; l’écart se réduit fortement |
| Parc avec navigateurs anciens ou imposés | Selenium — la couverture de navigateurs est plus large |
| Web + mobile natif dans la même suite | Selenium, pour la continuité avec Appium |
| Application de bureau ou client lourd | Ni l’un ni l’autre : c’est un autre écosystème |
Un projet qui possède déjà deux cents tests Selenium fonctionnels, une intégration de rapports et des utilitaires maison n’a presque jamais intérêt à migrer.
Le calcul est simple et rarement fait : la migration coûte le temps de réécriture plus le temps de re-stabilisation plus la perte de confiance pendant la transition. Le gain, lui, est marginal si l’instabilité venait de vos données de test — ce qui est le cas le plus fréquent.
Notre recommandation, contre-intuitive : avant d’envisager une migration, corrigez vos attentes et isolez vos données. Si la suite redevient stable, vous n’avez plus de raison de migrer. Si elle ne l’est toujours pas, vous savez au moins que le problème n’était pas l’outil.
C’est le critère le plus sous-estimé, et il fait une vraie différence au quotidien.
Quand un test échoue en intégration, combien de temps faut-il pour comprendre pourquoi ?
Playwright fournit nativement une trace rejouable : capture d’écran à chaque étape, arbre du DOM, requêtes réseau, journal de la console. On rejoue l’échec sans reproduire l’environnement.
Selenium demande d’assembler cet outillage — captures, journaux, intégration avec un rapporteur. C’est faisable et bien documenté, mais c’est du travail à fournir.
Sur une équipe qui traite plusieurs échecs par jour, cet écart se compte en heures par semaine.
Playwright est généralement plus rapide, grâce au partage d’un même navigateur entre contextes isolés plutôt qu’au lancement d’une instance par test.
Mais l’écart entre les deux outils est d’un ordre de grandeur inférieur à l’écart entre un test d’interface et un test d’API. Si la durée de votre campagne est un problème, le levier n’est pas l’outil : c’est le niveau auquel vous testez.
La popularité. Les deux ont une communauté suffisante et un avenir assuré.
Les comparatifs d’éditeurs. Ils sont écrits par des gens qui vendent l’un des deux.
La syntaxe. On s’y habitue en deux semaines. Ce n’est pas un critère de choix sur cinq ans.
« C’est plus moderne. » Ce n’est pas un critère. La question est ce que ça change pour votre équipe.
Nouveau projet, équipe TypeScript ou Python, application web moderne → Playwright. L’attente automatique et l’outillage de diagnostic font gagner du temps dès la première semaine.
Nouveau projet, équipe Java, application d’entreprise → les deux se défendent. Selenium si l’équipe le connaît déjà ; Playwright si personne n’a d’historique et que le diagnostic vous importe.
Suite Selenium existante et stable → n’y touchez pas. Investissez ailleurs.
Suite Selenium existante et instable → corrigez d’abord attentes et données. Réévaluez ensuite. Dans les trois quarts des cas que nous voyons, la question de la migration disparaît d’elle-même.
Besoin de couvrir web et mobile natif → Selenium, pour la continuité de l’écosystème.
Nous auditons régulièrement des suites qui ont migré d’un outil à l’autre en espérant résoudre leur instabilité. Le résultat est presque toujours le même : une suite instable dans une nouvelle syntaxe, et six mois perdus.
L’instabilité vient de trois choses, dans cet ordre :
Aucune des trois ne se règle par un changement d’outil.
Omar OUJAA
Fondateur · Full Stack QA · DevOps
Ingénieur, certifié ISTQB Test Manager, auteur aux Éditions ENI. Fondateur de STRATEST en 2018.
En savoir plus