Comment tester Safari avec Playwright ? Parcours pratique 2026 pour étudiants

Playwright prend en charge trois moteurs de navigateur : Chromium, WebKit et Firefox, comme le précise sa documentation officielle sur les navigateurs. Cela vous permet de commencer à tester Safari avec Playwright en exécutant des tests WebKit, y compris depuis Windows, mais cela ne transforme pas WebKit en Safari.

Symptôme : votre site fonctionne dans votre navigateur habituel, mais vous ne savez pas s’il se comportera de la même façon dans Safari. Solution rapide : lancez d’abord les tests Playwright avec WebKit, puis vérifiez le vrai navigateur Safari sur macOS si votre cours ou votre projet l’exige.

Ce guide s’adresse aux étudiants qui développent un projet web sur Windows ou sur un ordinateur scolaire et veulent ajouter un contrôle automatisé. Il convient aussi si un problème de mise en page ou d’interaction vous fait suspecter Safari, sans que vous sachiez encore quel navigateur l’a révélé. Si votre rendu doit prouver un résultat obtenu dans Safari, vous trouverez une méthode pour séparer le premier contrôle de la vérification finale.

Choisissez d’abord le résultat que vous devez prouver

Un test automatisé est comparable à un correcteur qui rejoue toujours les mêmes actions : il ouvre une page, clique sur un élément et vérifie une réponse attendue. Ce contrôle vous évite de tout refaire manuellement après chaque modification. Il ne prouve toutefois que ce que le test a effectivement vérifié.

Avant de lancer Playwright, formulez votre objectif en termes concrets. « Tester Safari » peut vouloir dire plusieurs choses :

• Vérifier que la page s’ouvre et que ses éléments principaux apparaissent.
• Contrôler qu’un menu, un formulaire ou un bouton fonctionne.
• Repérer une différence de présentation qui survient avec WebKit.
• Fournir une preuve que la page a été ouverte dans le navigateur Safari lui-même.

Ces résultats n’ont pas la même valeur pour un devoir. Une capture d’écran issue de WebKit ne démontre pas que le site a été vu dans Safari. À l’inverse, si vous voulez simplement détecter tôt un bouton inactif ou une page qui ne se charge pas, le contrôle Playwright peut être un bon premier filtre.

Notez également ce que votre cours demande comme preuve. S’il réclame uniquement des tests automatisés, un rapport Playwright peut convenir. S’il nomme Safari ou exige une capture de ce navigateur, prévoyez une vérification sur macOS et décrivez précisément comment vous l’avez réalisée.

Lancez une première vérification WebKit depuis votre projet Windows

Vous n’avez pas besoin de convertir votre ordinateur Windows en Mac pour démarrer un test WebKit avec Playwright. La documentation officielle décrit l’installation du paquet et des navigateurs pris en charge ; suivez ses commandes actuelles plutôt qu’un tutoriel ancien qui pourrait viser une autre version de l’outil (installation de Playwright).

Procédez dans cet ordre, en gardant votre projet existant :

• Ouvrez le dossier du projet. Dans le terminal, placez-vous à la racine du site, là où se trouvent ses fichiers et sa configuration. Vérifiez que le projet démarre normalement avant d’ajouter un test : si le serveur ne fonctionne déjà pas, Playwright ne pourra pas distinguer ce problème d’un souci de navigateur.
• Installez Playwright selon la documentation. Si les tests ne sont pas encore configurés, la documentation propose une installation guidée. Elle peut créer les fichiers de configuration et les premiers exemples. Lisez les choix présentés au lieu de remplacer sans contrôle les réglages de votre projet.
• Installez le navigateur nécessaire. Playwright utilise des versions de navigateur associées à son installation. Si WebKit manque, appliquez la commande d’installation indiquée par la documentation ; un test qui échoue parce que le navigateur n’est pas disponible ne révèle rien sur la compatibilité de votre page.
• Démarrez le serveur du projet. Pour un site local, il faut que l’adresse utilisée par le test corresponde au serveur réellement lancé. Vérifiez que la page s’ouvre dans votre navigateur habituel avant de démarrer la suite.
• Contrôlez le nom du projet WebKit. La commande de sélection dépend du nom défini dans la configuration. Les projets Playwright permettent de séparer les configurations de navigateur ; ne supposez pas que votre projet s’appelle WebKit si son fichier de configuration indique un autre nom.
• Lancez seulement ce projet. Si le nom configuré est webkit, utilisez npx playwright test --project=webkit. La documentation sur l’exécution des tests explique aussi comment lancer les tests et consulter leurs résultats.
• Conservez le résultat utile. Notez l’adresse testée, l’action effectuée, le résultat attendu et le message d’échec éventuel. Sans ces informations, un voyant rouge ne permet pas encore de savoir si le problème vient du site, du test ou du démarrage du serveur.

Si le test ne démarre pas, ne concluez pas immédiatement à une incompatibilité Safari. Vérifiez d’abord que WebKit a été installé, que le serveur répond à l’adresse configurée et que Playwright sélectionne bien le projet voulu.

Pour un premier cas, choisissez une action compréhensible : ouvrir la page d’accueil et vérifier qu’un titre visible contient le texte prévu, par exemple. Les [locateurs Playwright](https://playwright.dev/docs/locators) servent à désigner les éléments de la page. Préférez un rôle accessible ou un texte stable à une longue adresse technique copiée depuis l’inspecteur : le test sera plus facile à relire et à corriger si votre mise en page change.

Distinguez un problème de test d’une différence de navigateur

Un échec WebKit signifie d’abord qu’une vérification donnée n’a pas obtenu le résultat attendu dans cet environnement. Il ne suffit pas, à lui seul, à établir que « Safari est cassé » ou que le site est incompatible.

Commencez par relire la phrase d’échec. Une assertion — autrement dit, la vérification de la réponse attendue — peut échouer parce que le texte n’est pas encore affiché, parce que le test vise un mauvais élément ou parce que la page a emprunté un autre parcours. Les assertions Playwright et les conditions d’action documentent les attentes et les contrôles effectués avant certaines interactions. La documentation indique notamment que Playwright vérifie la visibilité, la stabilité, la réception des événements et l’état activé d’un élément avant certaines actions ; un échec de cette étape peut donc signaler que le clic n’a pas pu être réalisé comme prévu.

Rejouez ensuite le même scénario avec le même projet et les mêmes données dans Chromium et WebKit. Si les deux échouent au même endroit, cherchez d’abord un problème commun dans le code, le serveur ou le test. Si seul WebKit échoue, le contraste devient intéressant, mais reste un indice à examiner : vérifiez les journaux, la capture de la trace et l’état de la page au moment de l’échec. Le Trace Viewer permet d’inspecter les étapes enregistrées d’un test ; utilisez-le pour comprendre ce que le navigateur a réellement affiché et quelle action a précédé l’erreur.

Une différence visible mérite un contrôle ciblé. Par exemple, une police peut être chargée différemment, un bloc peut changer de largeur ou un menu peut réagir autrement. Ce sont des pistes de diagnostic, pas des preuves automatiques que Safari reproduira exactement l’écart. Reprenez l’action concernée dans un vrai Safari si la différence compte pour le rendu final ou si le cours demande explicitement ce navigateur.

Pour le média, le son et la vidéo, vérifiez aussi ce que votre page attend de l’appareil : lecture déclenchée par un clic, autorisation du navigateur, codec ou accès à une fonction du système. Un test automatisé qui passe ne signifie pas nécessairement qu’une lecture réelle, avec le matériel et les autorisations de l’utilisateur, a été validée.

Comparez la force des preuves avant de rendre votre projet

WebKit et Safari sont liés, mais ils ne sont pas interchangeables. Playwright précise que son WebKit est issu du projet WebKit et recommande de lancer WebKit sur macOS lorsqu’il faut se rapprocher de l’expérience Safari. La version automatisée ne pilote pas le navigateur Safari de marque Apple : la présentation officielle des navigateurs Playwright fixe cette limite.

<

Méthode de contrôle	Ce qu’elle permet de vérifier	Niveau de preuve pour Safari	À choisir si…
Playwright avec WebKit sur Windows	Chargement, éléments ciblés et interactions décrites dans les tests	Moyen pour un premier contrôle, insuffisant pour déclarer un test dans Safari	Vous voulez automatiser une première vérification depuis votre projet actuel
Playwright avec WebKit sur macOS	Scénarios automatisés exécutés dans WebKit sur macOS	Plus proche de l’environnement Safari, mais le navigateur testé reste WebKit	Vous voulez compléter vos tests sans les présenter comme une vérification Safari native
Vérification manuelle dans Safari sur macOS	Affichage et opérations réellement observés dans le navigateur Safari	Élevé pour les pages et actions effectivement vérifiées	Votre cours demande une validation Safari ou une preuve correspondante

Le niveau de preuve décrit ici est un repère de décision, pas une note officielle ni une garantie de compatibilité. Une vérification manuelle ne couvre que les pages, les actions et les conditions que vous avez réellement testées. Un rapport automatisé peut, lui aussi, être précis et utile, à condition de nommer correctement le navigateur utilisé.

Pour remettre un résultat vérifiable, écrivez « test Playwright avec WebKit » si c’est ce que vous avez exécuté. Réservez « vérifié dans Safari » au cas où vous avez réellement ouvert le navigateur Safari et reproduit les actions indiquées.

Choisissez la suite selon les conditions de votre devoir

Servez-vous de ces conditions pour décider sans payer ni installer un environnement dont vous n’avez pas besoin :

• Si votre objectif est de contrôler rapidement le chargement et les interactions courantes depuis Windows, commencez par Playwright avec WebKit. Gardez le rapport et le scénario exécuté.
• Si l’échec vient d’un locateur, d’une assertion ou d’un serveur indisponible, corrigez ou stabilisez d’abord le test. Ne présentez pas un problème du script comme un défaut de Safari.
• Si WebKit seul révèle un écart visuel ou fonctionnel important, rejouez exactement la même page et la même action dans Safari sur macOS avant d’attribuer la cause au navigateur.
• Si la consigne demande des captures ou un résultat obtenu dans Safari, utilisez une vraie session Safari sur macOS et consignez les preuves demandées. Un test WebKit seul ne répond pas à cette exigence.
• Si vous n’avez pas accès à macOS et que le rendu l’exige, terminez l’automatisation WebKit, puis cherchez un environnement Mac autorisé par votre établissement ou par votre équipe. Vérifiez les règles de confidentialité avant d’y copier le projet ou des données personnelles.

Quand un Mac est nécessaire seulement pour une validation ponctuelle, comparez cette option avec votre solution actuelle plutôt que de changer tout votre poste de travail. Un Mac distant peut éviter l’achat d’une machine dédiée et donner accès à macOS pour une session de vérification ; les conditions d’accès et les modalités sont à examiner selon le service choisi. Vous pouvez consulter les [solutions Mac à distance de MACGPU](https://macgpu.com/fr/index.html) pour déterminer si cette approche correspond à votre projet.

Pour préparer une vérification propre, mettez le dépôt ou les fichiers nécessaires à disposition, ouvrez Safari, chargez les pages demandées par le cours, puis rejouez les opérations importantes. Dans votre compte rendu, indiquez le navigateur réellement utilisé, les pages, les actions, le résultat observé et les captures correspondantes. Distinguez les observations directes des hypothèses : « le menu ne s’ouvre pas après ce clic » est vérifiable ; « Safari est incompatible » demande davantage de contrôles.

Si votre projet contient une démonstration vidéo ou audio, ajoutez une vérification adaptée au résultat attendu : lancement de la lecture, présence de l’image, réponse des commandes et comportement lorsque l’autorisation est demandée. Pour un site de design, comparez plutôt les éléments qui comptent pour votre rendu, comme la disposition des blocs, les polices et les menus. Ne transformez pas ces observations en verdict global sur le navigateur : elles décrivent le projet testé dans les conditions consignées.

Pour rendre votre rapport plus facile à corriger, joignez le résultat Playwright séparément de la preuve Safari. Le premier montre le scénario automatisé ; la seconde documente l’ouverture et les actions dans le navigateur réel. Si vous n’avez obtenu que le premier, indiquez clairement que la vérification Safari reste à effectuer. Cette distinction évite qu’un enseignant ou un coéquipier interprète une capture WebKit comme une capture Safari.

Si votre ordinateur scolaire interdit l’installation de logiciels, vous pouvez tout de même avancer en préparant les scénarios et en vérifiant le code du test dans un environnement autorisé. Demandez ensuite à l’établissement comment accéder à un Mac pour la validation exigée. Pour une machine distante, assurez-vous que la politique de votre cours permet d’y transférer le projet et que vous ne copiez pas de données sensibles. La disponibilité d’un accès distant ne remplace pas les règles de remise ou de confidentialité.

Au moment de sélectionner un environnement distant, tenez compte de ce que vous devez remettre : une session Safari, un rapport, des captures ou une interaction en direct. Vous pouvez examiner l’offre Mac à distance de MACGPU si l’accès temporaire à macOS répond à cette contrainte. En revanche, si vous avez besoin d’une machine locale pour un usage continu, d’un accès physique à des périphériques ou d’une configuration dédiée à long terme, la location distante n’est pas automatiquement le meilleur choix : comparez-la à un Mac local et aux moyens autorisés par votre établissement.

Le point de départ reste simple : Playwright avec WebKit vous aide à repérer des problèmes courants et à automatiser un parcours depuis Windows, mais son résultat ne doit pas être présenté comme un test du navigateur Safari. Si votre cours exige la validation réelle, ou si un écart WebKit mérite d’être confirmé, planifiez une session macOS et consignez ce que vous avez effectivement observé.