Installer ChromeDriver sur Linux sans erreur de version

Installer ChromeDriver sur Linux paraît simple jusqu’au premier message Selenium du type “driver introuvable” ou “session not created”. Dans la plupart des cas, le problème ne vient pas du script de test, mais d’un trio mal aligné : navigateur, driver et chemin d’exécution.

Le bon réflexe consiste donc à vérifier la version de Chrome, choisir le bon ChromeDriver, le placer dans un dossier maîtrisé, puis tester son accès avant de lancer la suite automatisée.

Comment installer ChromeDriver sous Linux correctement ?

Pour installer linux chromedriver proprement, commencez par identifier la version du navigateur, récupérez le ChromeDriver correspondant depuis une source officielle, rendez le binaire exécutable, placez-le dans un répertoire connu du système, puis lancez un test minimal Selenium avant d’intégrer le driver dans votre pipeline.

google-chrome --version
chromedriver --version
which chromedriver

Choisir la bonne version avant de télécharger

La règle de base est directe : ChromeDriver pilote une version précise du navigateur. Si le navigateur a été mis à jour par le gestionnaire de paquets, mais que le driver est resté figé dans un dossier projet, Selenium peut refuser de créer une session. Cette erreur est classique sur les postes Linux, les images Docker et les runners CI.

Depuis les versions récentes de Chrome, Google recommande de passer par les artefacts Chrome for Testing pour récupérer des versions cohérentes de Chrome et ChromeDriver. C’est plus fiable que de chercher un vieux ZIP au hasard ou de copier un binaire depuis une machine qui “marche”.

Dans un parc professionnel, documentez aussi le canal utilisé : stable, beta, dev ou Chromium distribué par la distribution. Le canal du navigateur décide du driver à retenir, pas l’inverse.

Ce point évite une confusion fréquente : Chrome n’est pas toujours Chromium. Selon la distribution, le paquet disponible peut changer de nom, d’emplacement ou de politique de sandbox. Le script Selenium doit donc viser le navigateur réellement présent, pas celui supposé dans la documentation interne.

Vérifier le PATH et les droits d’exécution

Si Selenium ne trouve pas ChromeDriver, commencez par vérifier le chemin. Un binaire téléchargé dans ~/Downloads ou dans un dossier projet n’est pas forcément visible par l’utilisateur qui lance les tests. Sur un serveur, ce détail change selon que le test tourne en shell interactif, service systemd, conteneur ou runner CI.

chmod +x chromedriver
sudo mv chromedriver /usr/local/bin/chromedriver
chromedriver --version

Une autre approche consiste à ne pas dépendre du PATH global et à déclarer explicitement le chemin dans le code de test. C’est souvent plus propre pour une équipe qui versionne ses images Docker ou ses runners, car le chemin du driver devient une configuration visible au lieu d’un état implicite de la machine.

Gardez aussi la séparation entre installation système et configuration projet. Installer ChromeDriver dans /usr/local/bin dépanne vite, mais un dépôt qui déclare son driver, son navigateur et ses options d’exécution reste plus facile à rejouer sur un nouveau serveur.

Attention aux environnements headless et CI

Un script qui fonctionne sur un poste Linux peut échouer sur un serveur sans interface graphique. Le mode headless règle une partie du problème, mais il ne supprime pas les dépendances système, les permissions de dossier temporaire, le sandboxing ou les limites mémoire. C’est pour cela qu’un test minimal doit être exécuté dans l’environnement cible, pas seulement sur la machine du développeur.

Dans Docker, évitez de mélanger installation dynamique et cache ancien. Une image qui installe Chrome aujourd’hui mais conserve un ChromeDriver d’hier finira par casser. Le plus robuste est de reconstruire ensemble le navigateur, le driver et les dépendances, puis de figer l’image validée.

google-chrome --headless=new --version
chromedriver --version

Quand utiliser Selenium Manager plutôt qu’un binaire manuel

Les versions récentes de Selenium peuvent gérer automatiquement le driver dans de nombreux cas. C’est pratique pour un poste de développement ou un projet simple. En revanche, une équipe infrastructure préfère parfois garder un contrôle explicite des binaires : audit, version figée, image Docker validée, absence d’accès réseau pendant les tests ou reproductibilité complète.

Le choix n’est pas idéologique. Si Selenium Manager résout le driver sans surprise, gardez-le. Si votre contexte impose des versions maîtrisées, un proxy, un dépôt interne ou un runner isolé, documentez le binaire ChromeDriver et son cycle de mise à jour.

Les erreurs à éviter en production

La première erreur consiste à corriger une incompatibilité en téléchargeant “la dernière version” sans regarder le navigateur installé. Une version plus récente n’est pas toujours la bonne. La deuxième est de lancer les tests sous un utilisateur différent de celui qui a installé le driver. La troisième est de mélanger Chrome, Chromium et paquets Snap/Flatpak sans vérifier le binaire réellement ouvert.

• Gardez une commande de diagnostic dans la documentation du projet.
• Versionnez le Dockerfile ou le script d’installation du runner.
• Évitez les chemins locaux cachés dans un poste développeur.
• Réexécutez un test minimal après chaque mise à jour navigateur.

Pour NixSoftware, le bon angle est opérationnel : rendre le test reproductible. ChromeDriver n’est qu’un composant ; la vraie fiabilité vient de l’environnement Linux qui l’exécute.

La méthode la plus stable pour une équipe Linux

Pour un usage ponctuel, installer ChromeDriver manuellement peut suffire. Pour une équipe, un runner CI ou des tests critiques, la méthode stable consiste à figer navigateur, driver, dépendances et options Selenium dans une image ou un script rejouable. C’est le seul moyen d’éviter les corrections de dernière minute après une mise à jour silencieuse.

Si un test casse, revenez au diagnostic court : version du navigateur, version du driver, chemin appelé, utilisateur d’exécution et environnement headless. Dans la majorité des incidents, l’un de ces cinq points explique l’échec.