Navigateur headless

Un navigateur headless (sans interface graphique) charge les pages, exécute le JavaScript, construit le DOM et gère les requêtes réseau exactement comme un navigateur normal, mais il n’affiche rien à l’écran. Les tests le pilotent via le même protocole d’automatisation qu’un navigateur avec fenêtre (headed). Comme il n’a besoin d’aucun serveur d’affichage, c’est la façon standard d’exécuter des tests d’UI dans les conteneurs de CI et sur les agents de build.

Exemple

Playwright s’exécute en mode headless par défaut. Vous activez une fenêtre visible pour déboguer :

npx playwright test            # headless
npx playwright test --headed   # show the browser
npx playwright test --ui       # interactive UI mode

Avec Selenium 4, on demande le mode headless via les options du navigateur :

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new");
WebDriver driver = new ChromeDriver(options);

FirefoxOptions options = new FirefoxOptions();
options.addArguments("-headless");
WebDriver driver = new FirefoxDriver(options);

Pourquoi c’est important

• Il tourne partout. Les agents de build et les conteneurs Docker n’ont généralement pas d’écran ; une exécution headed nécessiterait un framebuffer virtuel.
• Il consomme moins de ressources qu’un navigateur avec fenêtre : vous pouvez donc exécuter plus de workers en parallèle sur la même machine.
• C’est un vrai navigateur. Les versions headless modernes de Chrome et Firefox utilisent le même moteur de rendu que leurs versions avec fenêtre, c’est pourquoi les tests écrits en headless se comportent généralement de la même manière en mode headed.

Pièges courants

• Différences de viewport. Un navigateur headless peut démarrer avec une taille de fenêtre par défaut différente de celle de votre navigateur de bureau. Définissez le viewport explicitement pour que les mises en page responsive se comportent de façon cohérente.
• « Ça marche en headed, ça échoue en headless. » C’est généralement un problème de timing, pas du mode headless lui-même : l’exécution headless est plus rapide ou plus lente et révèle une attente manquante. Capturez une trace ou une capture d’écran en cas d’échec plutôt que de passer la CI en mode headed.
• Déboguer à l’aveugle. Activez les captures d’écran, la vidéo ou les traces pour les tests en échec, afin de voir ce que le navigateur headless a vu.
• Confondre headless et « pas un navigateur ». Les outils qui se contentent de récupérer le HTML, sans exécuter le JavaScript, ne sont pas des navigateurs headless et ne peuvent pas tester une single-page app moderne.