Alternative à Selenium : où partir et comment migrer sans tout casser

Pourquoi partir sur Playwright. C'est l'outil qui répond au plus grand nombre de raisons de partir. Il attend tout seul qu'un élément soit visible et cliquable avant d'agir (l'auto-waiting), ce qui supprime la principale source de tests instables. Il apporte son propre lanceur de tests avec assertions, isolation, parallélisme et mode sans interface activés par défaut. Il ajoute un visualiseur de traces, un générateur de code qui enregistre tes clics, un mode interactif où tu remontes le temps, et un rapport HTML qui signale les tests instables. Projet Microsoft open source sous licence Apache 2.0, il dépasse les 99 000 étoiles sur GitHub.

Pour qui. Les équipes en Java, Python ou .NET qui veulent changer d'outil sans changer de langage, et les équipes TypeScript qui partent de zéro. Il pilote Chromium, Firefox et WebKit (le moteur de Safari) sur Windows, Linux et macOS.

Pour qui ce n'est pas fait. Une équipe Ruby, Kotlin ou PHP : ces langages ne sont pas pris en charge. Et une équipe qui doit tester sur de vrais téléphones : Playwright émule Chrome Android et Safari mobile, mais ne pilote pas d'appareil réel.

Sa limite. Le mode strict surprend au début. Un sélecteur qui trouve plusieurs éléments lève une erreur au lieu de prendre le premier, comme le faisait Selenium. Les sélecteurs ambigus de ta vieille suite cassent dès le premier jour. C'est sain, mais ça se prévoit. Côté infrastructure, chaque contexte Chromium consomme 150 à 200 Mo : sur un runner GitHub Actions de 7 Go, reste à 4 à 6 workers.

Comment migrer. Passe page à tes Page Objects à la place du driver, remplace les attentes explicites par les assertions de Playwright qui réessaient seules, et lance npx playwright codegen sur un parcours pour voir les sélecteurs qu'il propose. Une équipe .NET dit avoir migré une petite suite en une semaine.

Son prix. Gratuit. Si tu veux exécuter dans le cloud sans gérer de machines, Microsoft propose Azure Playwright Workspaces, facturé à la minute de test, avec un essai de 30 jours ou 100 minutes avant le passage au paiement à l'usage.

Pourquoi partir sur Cypress. Cypress tourne dans le navigateur, à côté de ton application. Tu vois chaque commande s'exécuter, tu cliques sur une étape et tu retrouves l'état exact de la page à ce moment. Pour une équipe front qui écrit ses propres tests, c'est le confort le plus apprécié. L'éditeur publie un guide officiel de migration depuis Selenium avec les correspondances commande par commande.

Pour qui. Les équipes JavaScript ou TypeScript, souvent sur React, Vue ou Angular, qui veulent que les développeurs écrivent et lancent les tests eux-mêmes.

Pour qui ce n'est pas fait. Une équipe Java, Python, C# ou Ruby : Cypress ne parle que JavaScript et TypeScript, donc toute ta suite se réécrit. Et les parcours qui ouvrent plusieurs onglets ou deux navigateurs en même temps (un chat entre deux utilisateurs, par exemple) : Cypress travaille sur un seul onglet par conception.

Sa limite. Safari n'est pris en charge qu'en mode expérimental, via WebKit, et sans cy.origin() ni Test Replay. L'exécution en parallèle, l'équivalent de la Grid, passe par Cypress Cloud avec cypress run --record --parallel. Le plan Starter gratuit s'arrête à 500 résultats de test par mois : une suite de 100 tests lancée cinq fois l'épuise.

Comment migrer. Les correspondances sont simples. findElement(By.id('x')) devient cy.get('#x'), un lien par texte devient cy.contains('a', 'Suivant'), et driver.sleep() disparaît. Les appels réseau s'attendent avec cy.intercept() puis cy.wait('@alias'). Tes Page Objects se gardent, sans le driver.

Son prix. L'application est gratuite et open source. Cypress Cloud : Starter gratuit (10 utilisateurs, 500 résultats par mois), Team à 799 $ par an, Business à 3 199 $ par an, Enterprise sur devis. Au-delà du quota, compte 6 $ les 1 000 résultats.

Pourquoi partir sur WebdriverIO. WebdriverIO repose sur le même protocole W3C WebDriver que Selenium, et sur son successeur WebDriver BiDi. Il ajoute ce qui manque le plus à Selenium : l'attente automatique des éléments. Comme il parle le même protocole, tes grilles Selenium existantes et tes clouds (BrowserStack, Sauce Labs) continuent de fonctionner.

Pour qui. Les équipes JavaScript qui ont investi dans une grille ou un cloud et veulent un cadre plus moderne sans tout jeter. Et celles qui testent aussi des applis mobiles : WebdriverIO pilote Appium avec la même syntaxe.

Pour qui ce n'est pas fait. Une équipe Java ou Python : comme Cypress, WebdriverIO impose JavaScript ou TypeScript. Dans ce cas, Playwright garde ton langage.

Sa limite. Tu restes sur WebDriver, donc avec une partie de sa lenteur et de ses dépendances aux pilotes. Le gain sur l'instabilité est réel grâce à l'auto-waiting, mais moins net qu'avec Playwright.

Comment migrer. Garde tes capacités de navigateur et l'adresse de ta grille, réécris les tests en JavaScript un parcours à la fois, et laisse les deux suites pointer vers la même grille pendant la transition.

Son prix. Gratuit, open source sous licence MIT.

Pourquoi partir sur Katalon. Katalon est une surcouche à Selenium et Appium. Tu enregistres un parcours, tu le rejoues, tu passes en mode script quand il faut. Il couvre le web, le mobile, les API et le bureau dans un même outil, avec des agents IA qui réparent un sélecteur cassé (l'auto-réparation) et analysent les échecs. C'est la voie des équipes QA qui n'ont pas de développeur à temps plein sur les tests.

Pour qui. Les équipes de testeurs fonctionnels, et les entreprises qui veulent un seul outil pour le web, le mobile et les API, avec intégrations Jira, GitHub, GitLab, Slack et Azure DevOps.

Pour qui ce n'est pas fait. Une équipe de développeurs qui veut ses tests dans le dépôt, en code, revus en PR : un framework comme Playwright lui ira mieux.

Sa limite. Le plan gratuit est surtout une découverte : pas d'exécution en parallèle, pas de CI/CD, pas de mode sans interface, pas d'auto-réparation. Pour la CI, il faut Professional, facturé à l'année et par siège. Les prix qui circulent sur d'autres sites se contredisent : seule la page officielle de Katalon fait foi.

Comment migrer. Katalon importe peu de choses d'une suite Selenium écrite à la main. Commence par réenregistrer tes cinq parcours les plus critiques, branche-les dans la CI, puis reprends le reste par ordre de valeur.

Son prix. Free à 0 $. Professional à 1 800 $ par siège et par an (environ 150 $ par mois), facturé à l'année. Enterprise sur devis (SSO, SCIM, installation sur site).

Pourquoi partir sur Ghost Inspector. Tu installes une extension, tu cliques dans ton site, et le parcours devient un test qui tourne dans le cloud à intervalle régulier ou à chaque déploiement. Pas de Grid, pas de pilote, pas de serveur. Pour une équipe marketing ou produit qui veut savoir que l'inscription et le paiement marchent encore, c'est la solution la plus courte.

Pour qui. Les PME et les équipes produit qui ont une dizaine de parcours critiques à surveiller, sans ingénieur QA.

Pour qui ce n'est pas fait. Une équipe avec des centaines de tests de régression complexes, des données de test à préparer et des cas limites : l'enregistrement montre vite ses limites.

Sa limite. Il n'y a pas de plan gratuit, seulement un essai de 14 jours sans carte. Le test des e-mails n'est pas dans Starter, le SSO est une option payante et l'historique se garde 6 mois.

Comment migrer. Ne convertis pas ta suite. Réenregistre les parcours qui comptent pour le chiffre d'affaires, programme-les après chaque déploiement, et laisse le reste à des tests unitaires.

Son prix. Starter à 109 $ par mois en annuel (125 $ au mois) pour 10 000 exécutions et 5 membres. Growth à 225 $ par mois en annuel (249 $ au mois) pour 30 000 exécutions. Scale à 449 $ par mois en annuel (499 $ au mois) pour 100 000 exécutions.

Pourquoi partir sur BugBug. BugBug enregistre tes parcours depuis Chrome et les rejoue, avec un plan gratuit qui tourne en local. Pour une start-up qui veut quelques tests de bout en bout sans payer ni coder, c'est la porte d'entrée la plus basse de cette liste.

Pour qui. Les petites équipes sur une application web, avec un public qui utilise surtout Chrome ou Edge.

Pour qui ce n'est pas fait. Tous ceux qui doivent couvrir Safari ou Firefox. BugBug ne pilote que les navigateurs Chromium (Chrome, Edge, Opera, Brave), sans mobile natif ni bureau. C'est un vrai recul par rapport à Selenium sur la couverture des navigateurs.

Sa limite. Le gratuit est serré : 1 utilisateur, 1 projet, 4 suites, 15 tests, 7 jours d'historique et des exécutions locales seulement. Chaque exécution en parallèle supplémentaire coûte 80 $ par mois.

Comment migrer. Réenregistre les parcours critiques, et garde quelques tests Selenium ou Playwright pour Safari si ton audience le demande.

Son prix. Free à 0 $. Core à 99 $ par mois et Pro à 189 $ par mois, facturés à l'année, hors taxes. Business sur devis.

Pourquoi partir sur testRigor. Si ce sont les sélecteurs qui te font partir, testRigor les supprime. Tu écris le test en anglais courant (« click Sign in », « check that page contains Welcome »), et l'outil trouve les éléments par leur texte visible et leur position, pas par CSS ou XPath. Une refonte de la structure HTML ne casse donc pas le test tant que l'écran affiche la même chose.

Pour qui. Les équipes où des profils métier ou QA manuels doivent écrire des tests, et celles dont la maintenance des sélecteurs est le premier poste de coût.

Pour qui ce n'est pas fait. Une équipe qui veut tout garder en code dans son dépôt, ou qui a besoin d'un prix public pour budgéter.

Sa limite. Le plan gratuit rend tes tests et leurs résultats publics : inutilisable pour une appli interne. Le plan privé se négocie, avec un essai de 14 jours, et se facture à l'infrastructure (le nombre de serveurs en parallèle), pas à l'utilisateur.

Comment migrer. Réécris un parcours critique en phrases pendant l'essai, compare le temps passé avec ton test Selenium, et mesure combien de tests survivent à ta prochaine mise en production.

Son prix. Gratuit si tes tests sont publics, payant sur devis pour des tests privés.

Pourquoi partir sur Puppeteer. Beaucoup de scripts Selenium ne testent rien : ils remplissent des formulaires, génèrent des PDF ou collectent des données. Pour ces usages, Puppeteer, la bibliothèque Node.js de Google, est plus légère. Depuis sa version 23, elle pilote Chrome et Firefox, ce dernier via WebDriver BiDi, le même standard que Selenium adopte.

Pour qui. Les développeurs JavaScript qui automatisent un navigateur dans un script ou un service, et qui n'ont besoin ni d'un lanceur de tests ni de Safari.

Pour qui ce n'est pas fait. Une équipe QA : Puppeteer n'est pas un framework de test complet. Sa propre documentation reconnaît que Selenium offre plus de langages et un outillage du type Grid. Pour des tests, prends Playwright.

Sa limite. JavaScript seulement, pas de WebKit, et rien pour le parallélisme à grande échelle.

Comment migrer. Réécris le script en Node.js, en remplaçant driver.get() par page.goto(). Si ton script collecte des données à grande échelle, un outil dédié t'évitera de gérer les blocages : notre guide pour quitter Octoparse et notre avis sur Apify comparent ces options. Pour de la RPA sur des applis de bureau, regarde plutôt notre guide pour quitter UiPath.

Son prix. Gratuit et open source.