Les offres d'automaticien de test Playwright ou Cypress demandent TypeScript, le Page Object Model, une CI GitLab ou GitHub Actions et souvent Jira avec Xray pour suivre les campagnes. Beaucoup ajoutent des tests d'API avec Postman ou Bruno, et parfois Appium pour le mobile. Playwright gagne du terrain dans les annonces récentes, Cypress reste très présent dans les équipes front. Les deux outils partagent des principes, mais pas leur fonctionnement : Cypress s'exécute dans le navigateur, Playwright le pilote de l'extérieur.
Selenium ou le test manuel : la plupart des candidats arrivent de là. Ils savent écrire un scénario et le faire passer une fois. L'écart se voit sur la durée : attentes fixes, tests qui dépendent les uns des autres, connexion refaite à chaque test, suite de 40 minutes qui échoue au hasard. Un automaticien confirmé sait lire une trace, simuler un service externe et dire quels tests n'ont rien à faire au niveau de l'interface.
Demandez le nombre de tests de la dernière suite, sa durée en CI et son taux d'échecs aléatoires. La réponse dit si la personne a tenu une suite en production. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Playwright, Cypress et l'outillage autour
Playwright
Le framework de test web de Microsoft. Il pilote Chromium, Firefox et WebKit (le moteur de Safari) depuis l'extérieur du navigateur, en TypeScript le plus souvent, aussi en Python, Java ou .NET. Il attend tout seul que les éléments soient prêts, isole chaque test dans un contexte neuf et enregistre des traces qu'on rejoue pas à pas. Le lanceur de tests @playwright/test gère les fixtures, le parallélisme et le découpage sur plusieurs machines.
Cypress
Un framework qui s'exécute dans le navigateur, à côté de l'application. Les commandes s'enchaînent dans une file d'attente et réessaient automatiquement leurs assertions. Son interface de débogage plaît aux développeurs front. Il gère un seul onglet, et le support de WebKit reste expérimental. La version 16, sortie en 2026, fait passer le trafic de Chrome et Edge par le réseau natif du navigateur, ce qui touche certaines interceptions.
TypeScript
Le langage de la plupart des suites Playwright et Cypress récentes. Le typage évite des erreurs dans les objets page et les commandes personnalisées. Un automaticien doit comprendre l'asynchrone de JavaScript : un await oublié devant une assertion Playwright fait passer un test qui aurait dû échouer.
Interception réseau
page.route() dans Playwright, cy.intercept() dans Cypress. On observe ou on remplace les appels HTTP de l'application pour attendre une réponse précise, simuler un service externe indisponible ou forcer un cas d'erreur. C'est ce qui rend testable un parcours qui dépend d'un prestataire de paiement ou d'une API lente.
Tests de composants
Un composant React, Vue ou Angular monté seul dans un vrai navigateur. Cypress les propose de façon stable. Chez Playwright, la fonction reste expérimentale et a changé de modèle en 2026. Ils couvrent les états d'un composant plus vite qu'un parcours complet.
Régression visuelle
Comparer une capture d'écran à une image de référence pour repérer un changement d'affichage. Playwright le fait avec toHaveScreenshot(), d'autres équipes utilisent Percy, Applitools ou Chromatic. Les références dépendent du système et du navigateur, d'où des échecs en série quand on les génère sur un poste et qu'on compare en CI.
CI et parallélisation
GitLab CI, GitHub Actions ou Jenkins, avec les images Docker officielles des deux outils. Playwright découpe une suite sur plusieurs machines (--shard) et fusionne les rapports. Cypress répartit les tests avec sa parallélisation dans Cypress Cloud, un service payant. Le temps d'une suite sur une merge request se règle à cet endroit.
Accessibilité avec axe-core
Les bibliothèques @axe-core/playwright et cypress-axe lancent des contrôles d'accessibilité automatiques pendant les tests. Elles repèrent une partie des défauts (contrastes, libellés manquants, rôles) sans remplacer un audit RGAA.
Outils IA et MCP
Playwright fournit des agents qui planifient, génèrent et réparent des tests, et un serveur MCP qui permet à un assistant IA de piloter un navigateur. Cypress propose cy.prompt, en bêta, pour écrire des étapes en langage courant. Ces outils produisent un premier jet que l'automaticien relit, surtout quand un test réparé passe de nouveau au vert.
Le poste change selon la place de l'automaticien dans l'équipe. Intégré à une équipe produit, il écrit les tests avec les développeurs, les fait tourner sur chaque merge request et relit leur code de test. Rattaché à une équipe qualité transverse, il maintient une suite de non-régression pour plusieurs applications et en suit la stabilité. Dans les deux cas, il prépare ses données par API, simule les services externes et décide de ce qui mérite un test de bout en bout. Certaines offres qui citent Playwright décrivent en fait une migration depuis Selenium ou Cypress : vérifiez si le poste consiste à construire une suite, à la reprendre ou à la migrer.
Les points à vérifier chez un automaticien Cypress / Playwright
- Sélecteurs robustes et attentes automatiques
- Isolation des tests et données préparées par API
- Interception réseau et services simulés
- Code de test TypeScript structuré et relu
- Parallélisation et exécution en CI
- Diagnostic des tests instables
À poser à un automaticien Playwright ou Cypress
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un test Playwright passe en local et échoue une fois sur dix en CI. Comment trouvez-vous la cause ?
Une bonne réponseIl reproduit d'abord l'échec, par exemple avec --repeat-each et le même nombre de workers que la CI, et active la trace au premier essai raté (trace: 'on-first-retry'). Le trace viewer montre chaque action, l'état du DOM avant et après, les appels réseau et la console. Les causes habituelles : une assertion faite sur une valeur lue une seule fois, un compte ou des données partagés entre deux tests parallèles, un test qui dépend de l'ordre, une animation, une machine de CI plus lente. Il corrige la cause et garde les relances pour signaler le test comme instable dans le rapport.
Signal d'alerteUn waitForTimeout(3000) ajouté au hasard, un timeout global multiplié par trois, ou retries à 5 sans regarder pourquoi le test échoue.
Question 2 · junior à confirmé
Quel sélecteur choisissez-vous pour cliquer sur le bouton Valider d'un formulaire, et pourquoi ?
Une bonne réponseUn sélecteur qui décrit ce que voit l'utilisateur : getByRole('button', { name: 'Valider' }) dans Playwright, cy.contains('button', 'Valider') ou un attribut data-cy dans Cypress. À défaut, un data-testid convenu avec les développeurs. Il explique qu'un sélecteur par rôle vérifie au passage que le bouton est accessible, et qu'il résiste aux changements de style. Il sait que Playwright refuse d'agir quand le localisateur trouve plusieurs éléments (mode strict).
Signal d'alerteUne XPath absolue copiée depuis les outils du navigateur, un nth-child, ou une classe CSS générée par le framework qui change à chaque build.
Question 3 · confirmé
Dans Cypress, pourquoi ne peut-on pas écrire const titre = cy.get('h1').invoke('text') puis comparer titre à une chaîne ?
Une bonne réponseLes commandes Cypress ne s'exécutent pas tout de suite : elles sont mises en file d'attente et renvoient un objet chaînable, pas la valeur. Pour comparer, on enchaîne une assertion (.should('have.text', ...)) qui réessaie jusqu'au délai, ou on récupère la valeur dans un .then(). Il ajoute que ces objets ne sont pas des promesses et qu'un await ne règle rien, et qu'un alias (.as()) sert à réutiliser une valeur plus loin.
Signal d'alerte« J'ajoute un await », ou une réponse qui traite cy.get comme un document.querySelector qui renverrait l'élément.
Question 4 · confirmé
Le parcours de paiement appelle un prestataire externe, lent et souvent indisponible en recette. Comment le testez-vous ?
Une bonne réponseIl simule la réponse du prestataire dans la plupart des tests, avec page.route() dans Playwright ou cy.intercept() dans Cypress : paiement accepté, refusé, délai dépassé, erreur 500. Il vérifie aussi ce que l'application envoie, pas seulement ce qu'elle reçoit. Il garde quelques tests contre le vrai bac à sable du prestataire, lancés à part (chaque nuit par exemple), pour savoir si son contrat a changé. L'API de l'application elle-même n'est pas simulée dans les parcours de bout en bout.
Signal d'alerteTout simuler, y compris l'API maison, sans aucun test contre un vrai service. Ou l'inverse : tous les tests dépendent du bac à sable, et la suite tombe dès qu'il ralentit.
Question 5 · confirmé
Chaque test commence par remplir le formulaire de connexion, et la suite dure 40 minutes. Que changez-vous ?
Une bonne réponseIl se connecte une fois et réutilise la session. Dans Playwright, un projet de setup enregistre l'état du navigateur (storageState) pour chaque rôle, et les tests le chargent. Dans Cypress, cy.session() met la session en cache, idéalement avec une connexion par cy.request() plutôt que par l'interface. Un seul test garde le formulaire de connexion. Il prévoit un compte par worker quand les tests modifient les données du compte.
Signal d'alerteDésactiver l'isolation pour enchaîner les tests dans la même session, ce qui rend chaque test dépendant du précédent. Ou supprimer des tests pour gagner du temps.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter un automaticien Playwright ou Cypress
Playwright ou Cypress, faut-il les distinguer dans l'offre ?
Oui si votre suite existe déjà dans l'un des deux. Les principes sont proches (sélecteurs, attentes automatiques, interception réseau), mais le modèle d'exécution diffère : Cypress enchaîne des commandes dans le navigateur, Playwright utilise async/await et pilote plusieurs onglets ou navigateurs. Un automaticien confirmé passe de l'un à l'autre en quelques semaines. Pour un premier projet sans existant, écrivez « Playwright ou Cypress » et demandez en entretien pourquoi la personne choisirait l'un ou l'autre.
Quel niveau de TypeScript attendre d'un automaticien web ?
Assez pour écrire du code que les développeurs acceptent de relire : fonctions et classes typées, modules, gestion de l'asynchrone avec async/await et des promesses. Il n'a pas besoin de connaître React ou Angular en profondeur, mais il doit lire le code du composant qu'il teste pour y ajouter un data-testid. Un profil qui ne sait pas expliquer pourquoi un await manquant fait passer un test aura du mal sur Playwright.
Que donner à faire en test technique à un automaticien Playwright ?
Une petite application de démonstration et une heure : un parcours à automatiser avec une connexion, un appel API à simuler et une donnée à préparer. Ajoutez un test existant qui échoue de temps en temps, à diagnostiquer. Faites commenter le travail à voix haute ou débriefez-le ensuite. Vous regardez les sélecteurs, l'absence d'attentes fixes, l'indépendance des tests et la façon de lire une trace.
Les agents IA de Playwright et cy.prompt changent-ils le poste ?
Ils accélèrent l'écriture d'un premier jet et la correction d'un sélecteur cassé. Ils ne choisissent pas ce qui mérite un test ni ce qu'une assertion doit vérifier. Le risque connu est un test réparé qui passe de nouveau au vert parce que son assertion a été affaiblie. Demandez au candidat comment il relit un test généré : la réponse vous dit s'il utilise ces outils avec méthode.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
