Dépannage : les 10 erreurs d’installation les plus fréquentes

Ce chapitre n’est pas fait pour être lu d’un bout à l’autre. Il est fait pour être retrouvé le jour où votre terminal affiche une ligne rouge et où personne ne peut regarder par-dessus votre épaule.

Le principe est toujours le même : un message d’erreur n’est pas une punition, c’est une information. Devant une panne d’installation Java/Maven, posez-vous trois questions, dans cet ordre.

1. Le programme est-il installé ?
2. Le système sait-il où il est installé (PATH, JAVA_HOME) ?
3. Quelque chose s’interpose-t-il entre vous et le réseau ou le disque (proxy, antivirus, droits, espace) ?

Gardez cet ordre. Il évite de reconfigurer JAVA_HOME pendant deux heures alors que le JDK n’a jamais été installé.

Le bilan en quatre commandes

Avant d’ouvrir une fiche, produisez toujours ce bilan. C’est lui qui vous dira quelle fiche lire.

Sur macOS et Linux (Terminal) :

java -version
javac -version
mvn -version
echo "$JAVA_HOME"

Sur Windows, dans l’Invite de commandes (cmd.exe) :

java -version
javac -version
mvn -version
echo %JAVA_HOME%

Sur Windows, dans PowerShell, la dernière ligne change :

java -version
javac -version
mvn -version
$env:JAVA_HOME

À quoi ressemble un bilan sain

java -version doit afficher trois lignes de cette forme. Le numéro de correctif (.22) et le nom du fournisseur (Temurin, Zulu, Corretto…) varient selon ce que vous avez installé ; ce qui compte, c’est que la première ligne commence par openjdk version "11. ou java version "11. :

openjdk version "11.0.22" 2024-01-16
OpenJDK Runtime Environment Temurin-11.0.22+7 (build 11.0.22+7)
OpenJDK 64-Bit Server VM Temurin-11.0.22+7 (build 11.0.22+7, mixed mode)

javac -version doit afficher une seule ligne :

javac 11.0.22

mvn -version doit afficher un bloc dont la ligne Java version reprend la même version 11 :

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /opt/maven
Java version: 11.0.22, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm/temurin-11-jdk-amd64
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "6.5.0-21-generic", arch: "amd64", family: "unix"

Si ces trois commandes répondent et que les versions concordent, votre installation est bonne. Fermez ce chapitre.

Piège classique : java -version écrit sur la sortie d’erreur, pas sur la sortie standard. Si vous essayez de copier le résultat dans un fichier avec java -version > bilan.txt, le fichier sera vide. Écrivez java -version 2> bilan.txt (ou java --version, qui écrit bien sur la sortie standard à partir de Java 9).

Le tableau de diagnostic

Cherchez votre ligne, allez à la fiche.

---

Panne 1 — java : commande introuvable

Le message, tel qu’il apparaît.

Windows, Invite de commandes :

'java' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

Windows, PowerShell :

java : Le terme «java» n'est pas reconnu comme nom d'applet de commande,
fonction, fichier de script ou programme exécutable.

Linux (bash) :

bash: java: command not found

macOS (zsh) :

zsh: command not found: java

macOS peut aussi afficher ceci, ce qui est trompeur : la commande java existe bien (c’est un lanceur fourni par Apple), mais elle ne trouve aucun JDK derrière elle :

java -version
javac -version
mvn -version
echo %JAVA_HOME%

0

Ubuntu affiche parfois une variante qui vous propose une solution — ne la suivez pas telle quelle, default-jre installe un environnement d’exécution, et default-jdk installe la version par défaut de la distribution, qui n’est pas forcément la 11 :

Command 'java' not found, but can be installed with:
sudo apt install default-jre

Ce que ça veut dire réellement. Votre interpréteur de commandes parcourt la liste de dossiers contenue dans la variable PATH et n’y trouve aucun fichier nommé java. Deux causes, et une seule façon de les départager : soit le JDK n’est pas installé, soit il l’est mais son dossier bin n’est pas dans le PATH.

Départagez d’abord. Cherchez le JDK sur le disque :

# macOS
/usr/libexec/java_home -V

# Linux
ls /usr/lib/jvm

rem Windows, Invite de commandes : une commande par dossier,
rem car dir s'arrete si le premier chemin n'existe pas
dir "C:\Program Files\Java"
dir "C:\Program Files\Eclipse Adoptium"

La manœuvre de sortie, cas A — rien n’est installé.

rem Windows
winget install -e --id EclipseAdoptium.Temurin.11.JDK

# macOS (Homebrew)
brew install --cask temurin@11

# Debian / Ubuntu
sudo apt update
sudo apt install openjdk-11-jdk

La manœuvre de sortie, cas B — le JDK est là mais introuvable. Il faut ajouter son dossier bin au PATH.

Sur macOS (zsh) :

echo 'export JAVA_HOME="$(/usr/libexec/java_home -v 11)"' >> ~/.zshrc
echo 'export PATH="$JAVA_HOME/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Sur Linux (bash), en remplaçant le chemin par celui que ls /usr/lib/jvm vous a montré :

echo 'export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64' >> ~/.bashrc
echo 'export PATH="$JAVA_HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Sur Windows, ouvrez l’éditeur de variables d’environnement avec cette commande :

rundll32 sysdm.cpl,EditEnvironmentVariables

Créez JAVA_HOME avec le chemin du JDK (par exemple C:\Program Files\Eclipse Adoptium\jdk-11.0.22.7-hotspot, sans le \bin à la fin), puis ajoutez une entrée %JAVA_HOME%\bin à la variable Path.

N’utilisez pas setx PATH … pour modifier le PATH. setx tronque la valeur écrite au-delà de 1024 caractères et développe au passage les variables qu’elle contient : vous pouvez perdre une partie de votre PATH sans message d’erreur. Passez par la fenêtre graphique.

Vérification. Fermez complètement le terminal et rouvrez-en un neuf : une variable d’environnement n’est lue qu’au démarrage du terminal, et c’est de loin l’explication la plus courante du « j’ai tout fait et ça ne marche toujours pas ». Puis :

java -version

Vous devez voir une première ligne commençant par openjdk version "11..

Si ça échoue encore. Affichez le PATH réellement vu par ce terminal et cherchez-y votre dossier bin :

java -version
javac -version
mvn -version
$env:JAVA_HOME

0

rem Windows, Invite de commandes
echo %PATH%

Si le dossier attendu n’apparaît pas dans cette liste, la modification n’a pas été enregistrée : reprenez l’étape précédente.

---

Panne 2 — java répond, javac non

Le message, tel qu’il apparaît.

bash: javac: command not found

Command 'javac' not found, but can be installed with:
sudo apt install default-jdk

Et sous Windows :

'javac' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

Ce que ça veut dire réellement. Vous avez installé un JRE (Java Runtime Environment) et non un JDK (Java Development Kit). Le JRE sait exécuter du Java ; il ne sait pas le compiler. javac est le compilateur, et il n’existe que dans le JDK.

La confusion est facile : le téléchargement grand public proposé sur java.com est un environnement d’exécution, pas un kit de développement. Vous n’en avez pas besoin : vous écrivez du code, il vous faut un JDK.

Variante moins évidente : vous avez bien un JDK, mais votre PATH pointe vers le dossier bin d’un JRE installé ailleurs. Vérifiez quel java gagne :

# macOS / Linux
which -a java
which -a javac

rem Windows, Invite de commandes
where java
where javac

Si where java répond C:\Windows\System32\java.exe ou C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe, vous êtes sur un lanceur déposé par une installation Java grand public, pas sur votre JDK.

La manœuvre de sortie. Installez un JDK 11 (voir Panne 1, cas A), puis refaites pointer JAVA_HOME et PATH vers son dossier, et non vers le JRE. Sous Windows, si C:\Program Files (x86)\Common Files\Oracle\Java\javapath apparaît dans votre Path, déplacez l’entrée %JAVA_HOME%\bin au-dessus d’elle : Windows prend le premier chemin qui répond.

Vérification.

javac -version

Doit afficher exactement une ligne de la forme javac 11.0.x.

---

Panne 3 — Ce n’est pas la bonne version qui répond

Le message, tel qu’il apparaît. Il y en a trois, selon le moment où la panne se révèle.

Au bilan, java -version affiche autre chose que 11 :

java version "1.8.0_401"

1.8.0 est Java 8. L’ancienne numérotation préfixait tout par 1.. Si vous lisez 1.8, vous avez Java 8.

À la compilation Maven, si le JDK actif est plus ancien que 11 :

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile
(default-compile) on project demo: Fatal error compiling: invalid target release: 11 -> [Help 1]

À l’exécution, si vous avez compilé avec 11 et que vous exécutez avec plus ancien :

openjdk version "11.0.22" 2024-01-16
OpenJDK Runtime Environment Temurin-11.0.22+7 (build 11.0.22+7)
OpenJDK 64-Bit Server VM Temurin-11.0.22+7 (build 11.0.22+7, mixed mode)

0

Le décodage de ces nombres :

Ce que ça veut dire réellement. Plusieurs Java cohabitent sur la machine et ce n’est pas celui que vous croyez qui répond. C’est ordinaire : un JDK installé par un autre logiciel, un JRE laissé par une mise à jour, un Java fourni par votre entreprise.

La manœuvre de sortie.

Sur Debian et Ubuntu, il existe un sélecteur système. Lancez-le pour java et pour javac, sinon vous obtenez un attelage incohérent :

sudo update-alternatives --config java
sudo update-alternatives --config javac

Sur macOS, listez ce qui est installé puis épinglez la 11 :

/usr/libexec/java_home -V
export JAVA_HOME="$(/usr/libexec/java_home -v 11)"
export PATH="$JAVA_HOME/bin:$PATH"

Si /usr/libexec/java_home -v 11 répond Unable to find any JVMs matching version "11", c’est qu’aucun JDK 11 n’est installé : revenez à la Panne 1, cas A.

Sur Windows, corrigez l’ordre dans la variable Path (rundll32 sysdm.cpl,EditEnvironmentVariables) : l’entrée %JAVA_HOME%\bin doit être au-dessus de toute autre entrée contenant Java.

Enfin, verrouillez la version côté projet. Dans votre pom.xml, ces propriétés évitent que le résultat dépende de la machine qui compile :

<properties>
  <maven.compiler.source>11</maven.compiler.source>
  <maven.compiler.target>11</maven.compiler.target>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

Attention : ces propriétés ne changent pas le JDK utilisé, elles disent seulement au compilateur quelle version cibler. Si le JDK actif est plus ancien que 11, vous obtiendrez invalid target release: 11, ce qui est justement le but : l’erreur arrive tôt et elle est claire.

Vérification. Les trois doivent être d’accord :

java -version
javac -version
mvn -version

java, javac et la ligne Java version: de Maven doivent annoncer le même 11.0.x.

---

Panne 4 — JAVA_HOME pointe ailleurs

Le message, tel qu’il apparaît.

Windows (mvn.cmd) :

ERROR: JAVA_HOME is set to an invalid directory.
JAVA_HOME = "C:\Program Files\Java\jdk1.8.0_311"
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

macOS et Linux (script mvn) :

The JAVA_HOME environment variable is not defined correctly,
this environment variable is needed to run this program.
NB: JAVA_HOME should point to a JDK, not a JRE

Ce que ça veut dire réellement. Quand JAVA_HOME est définie, Maven s’en sert en priorité : il exécute $JAVA_HOME/bin/java sans consulter le PATH. Une valeur fausse fait donc échouer Maven même si java -version répond parfaitement. Trois erreurs produisent ce message.

• JAVA_HOME contient un chemin qui n’existe plus (JDK désinstallé ou mis à jour, le numéro de version dans le chemin a changé).
• JAVA_HOME inclut \bin à la fin. Il ne doit pas : Maven ajoute \bin lui-même et cherche donc …\bin\bin\java.
• JAVA_HOME pointe sur un JRE. La dernière ligne du message le dit explicitement.

La manœuvre de sortie. Affichez d’abord la valeur réelle, sans la deviner :

# macOS / Linux
echo "$JAVA_HOME"
ls "$JAVA_HOME/bin/javac"

rem Windows, Invite de commandes
echo %JAVA_HOME%
dir "%JAVA_HOME%\bin\javac.exe"

Si le ls ou le dir ne trouve pas javac, le diagnostic est fait.

Pour reconstruire la valeur sans la saisir à la main sur Linux, en partant du javac actif :

export JAVA_HOME="$(dirname "$(dirname "$(readlink -f "$(which javac)")")")"
echo "$JAVA_HOME"

Sur macOS :

javac 11.0.22

0

Ces deux export ne valent que pour le terminal courant. Pour les rendre permanents, ajoutez-les à ~/.bashrc (Linux) ou ~/.zshrc (macOS) comme en Panne 1.

Vérification.

mvn -version

La ligne Java version: doit annoncer 11.0.x et la ligne runtime: doit pointer sur le dossier que vous venez de définir.

---

Panne 5 — mvn introuvable

Le message, tel qu’il apparaît. Identique à celui de la Panne 1, avec mvn à la place de java :

bash: mvn: command not found

'mvn' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

Ce que ça veut dire réellement. Même cause, même remède : le dossier bin de Maven n’est pas dans le PATH. La nuance propre à Maven : sur Windows et macOS, il se distribue aussi sous forme d’archive à décompresser, sans installeur. Décompresser ne modifie pas le PATH ; tant que vous ne l’avez pas fait vous-même, mvn reste introuvable.

La manœuvre de sortie. Le plus simple est de laisser un gestionnaire de paquets s’en occuper :

rem Windows
winget install -e --id Apache.Maven

# macOS (Homebrew)
brew install maven

# Debian / Ubuntu
sudo apt update
sudo apt install maven

Si vous devez installer à la main (machine sans accès direct, politique d’entreprise), décompressez l’archive puis ajoutez le dossier bin au PATH :

# Linux
sudo tar xzvf apache-maven-3.9.6-bin.tar.gz -C /opt
sudo mv /opt/apache-maven-3.9.6 /opt/maven
echo 'export PATH="/opt/maven/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Sur Windows, décompressez par exemple dans C:\dev\maven, puis ajoutez C:\dev\maven\bin à la variable Path via rundll32 sysdm.cpl,EditEnvironmentVariables.

Vérification. Dans un terminal neuf :

mvn -version

La première ligne doit commencer par Apache Maven 3..

Si ça échoue encore. Vérifiez que le dossier que vous avez ajouté contient bien l’exécutable, et pas un sous-dossier de plus : une archive décompressée deux fois donne C:\dev\maven\apache-maven-3.9.6\bin.

# Linux / macOS
ls /opt/maven/bin/mvn

rem Windows, Invite de commandes
dir C:\dev\maven\bin\mvn.cmd

---

Panne 6 — Le build Maven n’arrive pas à télécharger les dépendances

Le message est long et la cause est ailleurs que dans votre code : c’est ce qui rend cette panne difficile à lire.

Le message, tel qu’il apparaît. Variante « le réseau ne répond pas » :

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /opt/maven
Java version: 11.0.22, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm/temurin-11-jdk-amd64
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "6.5.0-21-generic", arch: "amd64", family: "unix"

0

Variante « le réseau répond, mais le certificat est inconnu » :

[ERROR] Could not transfer artifact org.seleniumhq.selenium:selenium-java:jar:4.19.1
from/to central (https://repo.maven.apache.org/maven2): PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target

Variante « Maven a déjà échoué et refuse de réessayer » :

[ERROR] Failure to find org.seleniumhq.selenium:selenium-java:jar:4.19.1 in
https://repo.maven.apache.org/maven2 was cached in the local repository, resolution
will not be reattempted until the update interval of central has elapsed or updates
are forced

Ce que ça veut dire réellement.

• Connection timed out : rien ne sort de votre machine vers Internet en direct. Sur un réseau d’entreprise ou d’école, tout passe par un proxy que Maven ne connaît pas.
• PKIX path building failed : le proxy déchiffre et re-signe le trafic HTTPS avec un certificat interne. Votre navigateur lui fait confiance parce que le certificat a été installé dans Windows ou macOS ; le JDK, lui, a son propre magasin de certificats et ne le connaît pas.
• was cached in the local repository : Maven a noté l’échec précédent et attend avant de réessayer. Ce message masque souvent la vraie erreur, plus ancienne.

La manœuvre de sortie, cas « cache ». Commencez toujours par celui-ci, il ne coûte rien :

mvn -U clean test

Le drapeau -U force Maven à réessayer les téléchargements qu’il avait abandonnés. Si l’échec persiste, le message affiché est maintenant le vrai.

Si -U ne suffit pas, supprimez les marqueurs d’échec laissés dans le dépôt local :

# macOS / Linux
find ~/.m2/repository -name "*.lastUpdated" -delete

rem Windows, Invite de commandes
del /s /q "%USERPROFILE%\.m2\repository\*.lastUpdated"

La manœuvre de sortie, cas « proxy ». Déclarez le proxy à Maven dans son fichier de configuration personnel. Il se trouve ici, et il faut souvent le créer :

• Windows : %USERPROFILE%\.m2\settings.xml
• macOS et Linux : ~/.m2/settings.xml

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0">
  <proxies>
    <proxy>
      <id>proxy-entreprise</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.monentreprise.fr</host>
      <port>8080</port>
      <username>votre_identifiant</username>
      <password>votre_mot_de_passe</password>
      <nonProxyHosts>localhost|127.0.0.1|*.monentreprise.fr</nonProxyHosts>
    </proxy>
  </proxies>
</settings>

Ce fichier contient votre mot de passe en clair : ne le versionnez pas et ne le copiez pas dans un dépôt Git. Si le proxy n’exige pas d’authentification, supprimez simplement les balises username et password.

L’adresse et le port du proxy ne s’inventent pas : demandez-les à votre service informatique, ou lisez-les dans les réglages réseau de votre système. Si le proxy demande une authentification que vous ne connaissez pas (jeton d’entreprise, Kerberos), ce chapitre ne suffira pas et il faut passer par eux.

La manœuvre de sortie, cas « PKIX ». Il faut ajouter le certificat du proxy au magasin du JDK. Exportez-le d’abord depuis votre navigateur (dans les détails du cadenas d’une page HTTPS, exportez le certificat racine au format .cer), puis lancez keytool par son chemin complet : sudo et les fenêtres administrateur n’héritent pas forcément de votre PATH.

# macOS / Linux, dans le dossier contenant proxy.cer
sudo "$JAVA_HOME/bin/keytool" -import -trustcacerts -alias proxy-entreprise \
  -file proxy.cer \
  -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit

rem Windows, Invite de commandes ouverte en administrateur,
rem dans le dossier contenant proxy.cer
echo %JAVA_HOME%
"%JAVA_HOME%\bin\keytool" -import -trustcacerts -alias proxy-entreprise -file proxy.cer -keystore "%JAVA_HOME%\lib\security\cacerts" -storepass changeit

Trois points qui font échouer cette commande.

• Sous Windows, une fenêtre ouverte en administrateur ne voit pas toujours vos variables utilisateur. Si echo %JAVA_HOME% affiche %JAVA_HOME%, définissez JAVA_HOME comme variable système, ou remplacez %JAVA_HOME% par le chemin complet du JDK dans la commande.
• keytool error: java.lang.Exception: Certificate not imported, alias <proxy-entreprise> already exists : l’alias est déjà pris. Supprimez-le d’abord avec keytool -delete -alias proxy-entreprise -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit, puis recommencez.
• java.io.FileNotFoundException … (Permission denied) : vous n’écrivez pas dans le magasin. Reprenez la commande avec sudo, ou dans une Invite de commandes administrateur.

changeit est le mot de passe par défaut du magasin de certificats du JDK ; il n’est pas secret. Si vous mettez à jour votre JDK plus tard, il faudra refaire cet import : le magasin appartient à l’installation.

Vérification. Dans un projet Maven :

mvn -U clean test

Si des dépendances manquent encore localement, vous verrez défiler des lignes Downloading from central:. Dans tous les cas, la sortie doit se terminer par :

'java' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

0

---

Panne 7 — Droits administrateur refusés

Le message, tel qu’il apparaît.

Windows, à l’exécution d’un installeur ou d’une commande :

Accès refusé.

Error: Access is denied.

Debian et Ubuntu :

dpkg: error: requested operation requires superuser privilege

macOS et Linux, à l’écriture dans un dossier système :

mkdir: /opt/maven: Permission denied

Ce que ça veut dire réellement. Vous tentez d’écrire dans un dossier qui appartient au système (C:\Program Files, /opt, /usr/lib) alors que votre session n’a pas les droits. Sur un poste géré par une entreprise, ces droits ne vous seront pas forcément accordés, et insister ne changera rien.

La manœuvre de sortie, si vous avez les droits.

Sur Windows, ouvrez le terminal en administrateur : menu Démarrer, tapez cmd, clic droit sur « Invite de commandes », « Exécuter en tant qu’administrateur ». La fenêtre qui s’ouvre doit afficher Administrateur dans sa barre de titre.

Sur macOS et Linux, préfixez la commande par sudo, et seulement celle qui en a besoin :

sudo apt install openjdk-11-jdk

La manœuvre de sortie, si vous ne les avez pas. Vous pouvez travailler entièrement dans votre dossier personnel, où vous avez le droit d’écrire. Décompressez le JDK et Maven sous C:\Users\<vous>\dev\ (Windows) ou ~/dev/ (macOS, Linux), puis définissez JAVA_HOME et PATH comme variables utilisateur et non système. La fenêtre rundll32 sysdm.cpl,EditEnvironmentVariables a deux cadres : celui du haut, « Variables utilisateur », ne demande aucun droit particulier.

Attention à un cas particulier fréquent : le dossier ~/.m2 peut avoir été créé par une commande lancée avec sudo, et appartenir alors à l’administrateur. Maven, lancé normalement, ne peut plus y écrire. Rendez-vous le dossier :

sudo chown -R "$(whoami)" ~/.m2

Vérification. Sans sudo et sans terminal administrateur, ces deux commandes doivent passer — la seconde prouve que vous pouvez écrire dans le dépôt local :

mvn -version
touch ~/.m2/test-ecriture && rm ~/.m2/test-ecriture && echo "ecriture OK"

Vous devez lire ecriture OK.

---

Panne 8 — Disque plein

Le message, tel qu’il apparaît.

java.io.IOException: No space left on device

[ERROR] Failed to execute goal ... Error writing to file ... No space left on device

Et, plus perfide, aucun message : l’installeur du JDK s’interrompt, la barre de progression revient en arrière, ou Maven télécharge un fichier qui se révèle ensuite corrompu :

java : Le terme «java» n'est pas reconnu comme nom d'applet de commande,
fonction, fichier de script ou programme exécutable.

0

Cette empreinte d41d8cd98f00b204e9800998ecf8427e est le MD5 d’un fichier vide : c’est la signature d’un téléchargement interrompu.

Ce que ça veut dire réellement. Le disque, ou le dossier personnel si votre poste a un quota, est saturé. Une chaîne Java/Maven/Selenium consomme de la place à plusieurs endroits : le JDK, Maven, VS Code, le dépôt local ~/.m2/repository qui grossit à chaque dépendance téléchargée, et le cache des drivers de navigateur.

La manœuvre de sortie. Mesurez d’abord :

# macOS / Linux
df -h ~
du -sh ~/.m2/repository 2>/dev/null

rem Windows, PowerShell
Get-PSDrive C

Puis, si besoin, faites de la place. Le dépôt local Maven est entièrement reconstructible : le supprimer ne détruit aucun travail, cela vous coûtera seulement un re-téléchargement au prochain build.

# macOS / Linux
rm -rf ~/.m2/repository

rem Windows, Invite de commandes
rmdir /s /q "%USERPROFILE%\.m2\repository"

Ne supprimez pas ~/.m2/settings.xml s’il existe : c’est votre configuration de proxy (Panne 6), et elle ne se reconstruit pas toute seule.

Repère de bon sens, et non une mesure : si df -h ou Get-PSDrive vous montre moins de quelques giga-octets libres, faites le ménage avant de continuer plutôt que de déboguer des erreurs qui n’ont pas de rapport apparent avec le disque.

Vérification. Relancez un build complet ; il doit re-télécharger et aboutir :

mvn -U clean test

---

Panne 9 — L’antivirus ou Gatekeeper bloque le driver

Le message, tel qu’il apparaît.

macOS, dans une fenêtre du système : un avertissement indiquant que « chromedriver » ne peut pas être ouvert car son développeur n’a pas pu être vérifié.

Windows, où l’antivirus agit silencieusement : le fichier téléchargé disparaît du dossier, et Selenium échoue au démarrage avec un message de cette famille :

org.openqa.selenium.WebDriverException: Unable to obtain: ChromeDriver

Ou, quand c’est l’écriture du cache qui est bloquée :

java.io.FileNotFoundException: C:\Users\vous\.cache\selenium\chromedriver\...
(Accès refusé)

Ce que ça veut dire réellement. Depuis Selenium 4.6, Selenium Manager télécharge automatiquement le driver correspondant à votre navigateur : vous n’avez plus rien à télécharger ni à déclarer à la main. Ce téléchargement se fait au premier lancement et écrit dans un dossier de cache. Deux mécanismes de sécurité peuvent s’y opposer.

• Sur macOS, Gatekeeper met en quarantaine tout binaire téléchargé et non signé par un développeur identifié.
• Sur Windows, l’antivirus, ou la fonction « Accès contrôlé aux dossiers » de Windows Defender, empêche l’écriture ou supprime le binaire.

La manœuvre de sortie.

Sur macOS, retirez l’attribut de quarantaine. Localisez d’abord le fichier : le chemin contient l’architecture (mac-x64 sur processeur Intel, mac-arm64 sur puce Apple) et le numéro de version, donc ne le recopiez pas d’un tutoriel.

find ~/.cache/selenium -name chromedriver
xattr -r -d com.apple.quarantine ~/.cache/selenium

Si la seconde commande répond No such xattr, c’est que l’attribut n’était pas présent : le blocage vient d’ailleurs, passez à la vérification.

Sur Windows, ne désactivez pas votre antivirus. Ajoutez une exclusion ciblée sur deux dossiers :

• %USERPROFILE%\.cache\selenium
• %USERPROFILE%\.m2\repository

Dans Sécurité Windows : Protection contre les virus et menaces, Gérer les paramètres, Exclusions, Ajouter une exclusion, Dossier. Si votre antivirus est géré par votre entreprise, vous ne pourrez pas ajouter l’exclusion vous-même : c’est une demande à leur adresser, et c’est une demande courante.

Vérification. Ce test doit ouvrir une fenêtre Chrome, charger une page, puis la refermer. Il suppose un projet Maven dont le pom.xml déclare au minimum ceci (en plus des propriétés de la Panne 3) :

<dependencies>
  <dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.19.1</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.10.2</version>
    <scope>test</scope>
  </dependency>
</dependencies>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>3.2.5</version>
    </plugin>
  </plugins>
</build>

Placez le test dans src/test/java/DiagnosticTest.java :

bash: java: command not found

0

mvn -U clean test

Attendu : une fenêtre Chrome s’ouvre et se referme, puis [INFO] BUILD SUCCESS. Ce test a besoin d’un accès réseau vers selenium.dev ; si vous êtes derrière un proxy, traitez d’abord la Panne 6.

---

Panne 10 — Un chemin avec des espaces ou des accents, sous Windows

Le message, tel qu’il apparaît. Il n’y en a pas un seul, et c’est précisément ce qui rend cette panne pénible. Les formes les plus reconnaissables :

Error: Could not find or load main class C:\Program

Le chemin d'accès spécifié est introuvable.

error: unmappable character (0xE9) for encoding windows-1252

Et parfois simplement : le même projet compile chez quelqu’un d’autre et pas chez vous, sans explication.

Ce que ça veut dire réellement.

• Could not find or load main class C:\Program : un chemin contenant un espace (C:\Program Files\…) a été coupé au premier espace parce qu’il n’était pas entre guillemets. La preuve est dans le message : le chemin s’arrête net sur C:\Program.
• unmappable character : un caractère accentué que l’encodage de lecture ne sait pas représenter. Sous Windows, l’encodage par défaut n’est historiquement pas UTF-8, d’où les collisions dès qu’un fichier source contient é, è, à ou ç.
• Le cas silencieux : les dossiers synchronisés dans le cloud (OneDrive, Google Drive, Dropbox) peuvent verrouiller ou décharger des fichiers pendant que Maven écrit dedans. Les échecs sont alors intermittents, donc difficiles à diagnostiquer.

La manœuvre de sortie. Elle est brutale et elle est la bonne : travaillez dans un chemin court, sans espace, sans accent, hors du cloud.

rem Windows, Invite de commandes
mkdir C:\dev
cd /d C:\dev

Placez-y vos projets. Vérifiez aussi que JAVA_HOME ne traverse aucun dossier accentué : si votre nom d’utilisateur Windows contient un accent, votre dossier personnel en contient un aussi, et le cache Maven (%USERPROFILE%\.m2) s’y trouve. Vous pouvez le déplacer en créant cette variable utilisateur dans rundll32 sysdm.cpl,EditEnvironmentVariables :

Enfin, forcez l’encodage de lecture des sources dans le pom.xml — c’est la propriété déjà vue en Panne 3 :

<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

Une précision qui évite une fausse piste : project.build.sourceEncoding indique au compilateur comment lire vos fichiers source. Elle ne change pas la ligne platform encoding: affichée par mvn -version, qui reflète l’encodage de la machine virtuelle ; c’est -Dfile.encoding=UTF-8 dans MAVEN_OPTS qui agit sur celle-là.

Vérification. Depuis C:\dev\votre-projet :

rem Windows, Invite de commandes
mvn -U clean test > sortie.txt 2>&1
findstr /i "unmappable BUILD" sortie.txt

Vous devez voir [INFO] BUILD SUCCESS et aucune ligne contenant unmappable.

---

Panne 11 — Le driver et le navigateur ne sont pas d’accord

Ce n’est pas une panne d’installation, mais elle apparaît au même moment que les autres et elle est facile à confondre avec elles. D’où sa place ici.

Le message, tel qu’il apparaît.

org.openqa.selenium.SessionNotCreatedException: session not created:
This version of ChromeDriver only supports Chrome version 114
Current browser version is 126.0.6478.114 with binary path /usr/bin/google-chrome

Ce que ça veut dire réellement. Un chromedriver figé quelque part est utilisé à la place de celui que Selenium Manager aurait choisi. Chrome se met à jour tout seul, en silence, et le driver qui marchait hier ne correspond plus. Trois sources possibles pour ce driver figé :

• un chromedriver posé à la main dans un dossier du PATH ;
• un appel à System.setProperty("webdriver.chrome.driver", "...") resté dans votre code ;
• une dépendance de gestion de driver dans le pom.xml, héritée d’un tutoriel écrit avant Selenium 4.6.

La manœuvre de sortie. Laissez Selenium Manager faire son travail. Il n’y a rien d’autre à écrire que la construction du driver :

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

public class Demarrage {

    public static void main(String[] args) {
        // Avec Selenium 4.6 et plus, Selenium Manager choisit et telecharge
        // le driver correspondant au navigateur installe. Rien d'autre a declarer.
        WebDriver driver = new ChromeDriver(new ChromeOptions());
        driver.get("https://www.selenium.dev/");
        System.out.println(driver.getTitle());
        driver.quit();
    }
}

Et supprimez, s’ils existent : toute ligne System.setProperty("webdriver.chrome.driver", ...), tout appel à un gestionnaire de driver tiers, et tout chromedriver que vous auriez déposé dans un dossier du PATH.

zsh: command not found: java

0

rem Windows, Invite de commandes
where chromedriver

Si ces commandes trouvent quelque chose, c’est votre coupable : déplacez-le hors du PATH.

Vérification. Le test DiagnosticTest de la Panne 9 doit passer, quelle que soit la version de Chrome installée.

---

Votre critère de réussite

Votre poste est prêt quand ces quatre commandes répondent, dans un terminal fraîchement ouvert, et que les versions concordent :

java -version
javac -version
mvn -version
mvn -U clean test

Attendu, dans l’ordre :

1. java -version : première ligne commençant par openjdk version "11. ou java version "11.
2. javac -version : javac 11.0.x, avec le même x
3. mvn -version : première ligne commençant par Apache Maven 3., et ligne Java version: 11.0.x
4. mvn -U clean test, dans le projet contenant DiagnosticTest : une fenêtre Chrome qui s’ouvre puis se referme, et cette fin de sortie :

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Si les quatre passent, votre poste est en état pour la suite du parcours. Si une seule échoue, le tableau de diagnostic en tête de chapitre vous renvoie à la bonne fiche.

Deux réflexes à prendre

Rouvrez le terminal. Une variable d’environnement modifiée n’est lue qu’à l’ouverture d’un terminal. Sous Windows, si vous avez modifié les variables pendant que VS Code était ouvert, fermez VS Code entièrement et rouvrez-le : ses terminaux intégrés héritent de l’environnement du processus VS Code, pas du système.

Lisez la première erreur, pas la dernière. Maven affiche parfois des dizaines de lignes après l’échec initial ; celles-ci découlent généralement de la première ligne [ERROR]. Pour la retrouver dans une sortie longue, écrivez d’abord la sortie complète dans un fichier, puis cherchez dedans. N’enchaînez pas mvn directement sur grep -m : grep s’arrête après ses premières correspondances, ce qui interrompt le build avant sa fin.

# macOS / Linux
mvn clean test > sortie.txt 2>&1
grep -n "ERROR" sortie.txt | head -n 3

rem Windows, Invite de commandes
mvn clean test > sortie.txt 2>&1
findstr /n "ERROR" sortie.txt

Ce que ce chapitre ne couvre pas

Pour que vous ne cherchiez pas ici ce qui ne s’y trouve pas :

• L’installation elle-même. Ce chapitre suppose que vous avez tenté d’installer le JDK 11, Maven et VS Code et que quelque chose a résisté. La procédure d’installation complète fait l’objet d’un chapitre séparé.
• La création du projet Maven et le contenu complet du pom.xml. Les extraits donnés ici sont les morceaux nécessaires au diagnostic, pas un pom.xml entier.
• Les erreurs de compilation de votre propre code. cannot find symbol, class X is public, should be declared in a file named X.java : ce sont des erreurs Java, pas des erreurs d’installation.
• Les échecs de tests Selenium une fois que le navigateur démarre : NoSuchElementException, StaleElementReferenceException, attentes. C’est le module Selenium.
• Les proxys à authentification d’entreprise avancée (Kerberos, NTLM, jeton renouvelé) : la configuration settings.xml donnée ici couvre l’authentification simple par identifiant et mot de passe. Au-delà, il faut passer par votre service informatique.
• Docker, WSL, machines virtuelles et environnements d’intégration continue. Les symptômes s’y ressemblent, les manœuvres de sortie diffèrent.
• Firefox, Edge et Safari. Les fiches 9 et 11 sont écrites pour Chrome. Le raisonnement est transposable, les chemins de cache et les messages exacts ne le sont pas.
• Les distributions Linux hors famille Debian/Ubuntu. Les commandes apt sont à remplacer par l’équivalent de votre gestionnaire de paquets.