La plupart des projets de migration partent d’une décision : passer d’Oracle Java SE à OpenJDK, remplacer une distribution Linux arrivée en fin de vie ou regrouper des serveurs dans un cloud privé. Sur le papier, le plan paraît généralement simple. Puis l’équipe projet découvre des runtimes Java dont personne ne connaissait l’existence, des serveurs sans responsable et des applications qui dépendent discrètement d’une ancienne version. Les délais glissent et les budgets augmentent.

Pour l’éviter, il faut commencer par la découverte : un inventaire complet et factuel de ce qui est réellement installé. Cet article explique quoi collecter, comment le faire sous Windows et Linux, à quelles surprises s’attendre et comment transformer les résultats en plan de migration.

Pourquoi la découverte précède la migration

Une migration ne vaut que par les informations sur lesquelles elle repose. Sans inventaire, vous estimez le périmètre de mémoire, à partir d’anciens tableurs et de registres de licences, et aucune de ces sources ne reflète ce qui tourne réellement aujourd’hui.

Un bon inventaire vous apporte trois choses :

• Périmètre : le nombre de machines, de runtimes et d’applications concernés, pour estimer l’effort et le coût de manière réaliste.
• Risque : les systèmes qui exécutent des versions non supportées ou non corrigées, et ceux qui sont critiques pour l’activité.
• Responsabilité : qui est responsable de chaque système, afin que les tests et la validation aient un responsable clairement identifié.

Il vous protège également lors des discussions sur les licences. Si un fournisseur vous demande combien d’installations vous avez, un inventaire à jour vous permet de répondre par des faits plutôt que par des suppositions.

Quoi collecter : versions, fournisseurs, chemins et responsables

Pour chaque installation Java, collectez au minimum les éléments suivants :

• Hôte : nom de la machine, adresse IP, et s’il s’agit d’un serveur, d’une machine virtuelle ou d’un poste de travail.
• Version : la chaîne de version complète, par exemple 1.8.0_202 ou 17.0.10, et pas seulement « Java 8 » ou « Java 17 ».
• Fournisseur : l’éditeur qui a compilé le runtime, comme Oracle ou une distribution OpenJDK. La version seule ne le dit pas.
• Type et chemin : s’il s’agit d’un JDK complet ou seulement d’un JRE, et le répertoire dans lequel il est installé.
• Utilisation : les applications ou services qui l’utilisent, si vous pouvez le déterminer.
• Responsable : l’équipe ou la personne responsable de la machine ou de l’application.

Pour les serveurs Linux, collectez aussi la distribution et sa version, la version du noyau, les principaux paquets installés et les services en cours d’exécution. Vous saurez ainsi quels serveurs relèvent d’une migration Linux en plus d’une migration Java.

Windows, Linux et postes de travail : des approches différentes

Chaque environnement demande une méthode légèrement différente. Les commandes ci-dessous sont des points de départ ; en pratique, les équipes les intègrent dans un script qu’elles exécutent sur toutes les machines avec leurs outils d’administration existants.

Serveurs Windows

Les runtimes Java installés s’enregistrent souvent sous la clé de registre Windows HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft, mais pas tous. Une recherche dans le système de fichiers est plus fiable :

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

Vérifiez tous les lecteurs, pas seulement C:, car les serveurs d’applications sont souvent installés sur un lecteur de données distinct.

Serveurs Linux

Sous Linux, combinez le gestionnaire de paquets avec une recherche de fichiers, car de nombreux runtimes Java sont décompressés à partir d’une archive plutôt qu’installés sous forme de paquet :

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

Sous Debian ou Ubuntu, utilisez dpkg -l | grep -i -E 'jdk|jre' au lieu de rpm. Pour chaque binaire java trouvé, l’exécuter avec -version affiche la version et généralement le fournisseur. La plupart des répertoires JDK contiennent aussi un fichier release qui indique l’implémenteur.

Postes de travail

Les postes de travail sont la partie de l’inventaire la plus souvent oubliée. Les développeurs installent leurs propres JDK, et certaines applications métier installent un runtime Java à l’insu de l’utilisateur. Comme les postes sont nombreux, utilisez autant que possible l’inventaire logiciel de votre outil de gestion des terminaux, et n’exécutez un script léger que là où cette information manque.

Surprises fréquentes (JRE embarqués, serveurs oubliés)

Presque tous les projets de découverte révèlent des éléments inattendus. Les plus fréquents sont :

• Runtimes embarqués : de nombreuses applications commerciales livrent leur propre runtime Java privé dans leur répertoire d’installation. Il peut n’apparaître ni dans le registre ni dans aucune liste de paquets.
• Plusieurs versions sur une même machine : les anciens runtimes sont rarement supprimés lors de l’installation d’un nouveau, si bien qu’un serveur peut en compter trois ou quatre.
• Serveurs oubliés : machines de test, anciens serveurs de traitements par lots et machines virtuelles jamais décommissionnés, qui exécutent souvent des versions obsolètes et non corrigées.
• Responsables inconnus : des machines que personne ne revendique. Elles nécessitent une décision avant le début de la migration, même si cette décision consiste à les arrêter.

De l’inventaire au plan de migration

Une fois les données collectées, centralisez-les en un seul endroit et passez-les en revue avec les responsables des systèmes. Regroupez ensuite les installations par catégorie :

Groupe	Contenu	Action
Supprimer	Runtimes qui ne sont plus utilisés	Les désinstaller dès maintenant pour réduire les risques et l’exposition en matière de licences
Remplacer	Runtimes que vous gérez vous-même	Passer à une build OpenJDK supportée après tests
Coordonner	Runtimes embarqués dans des applications tierces	Obtenir d’abord la position de l’éditeur de l’application sur le support
Examiner	Tout ce qui n’a ni responsable ni finalité claire	Identifier le responsable ou décider de l’arrêter

À partir de ces groupes, vous pouvez établir un calendrier réaliste : commencez par les systèmes à faible risque pour éprouver le processus, puis passez aux systèmes critiques avec une procédure de retour arrière testée.

Comment LOGIQ peut vous aider

LOGIQ mène des projets de découverte et de migration pour les environnements Java et Linux, à l’aide de scripts et de procédures affinés lors de projets clients réels sur des serveurs Windows, des serveurs Linux et des postes de travail. Si vous souhaitez être accompagné pour établir votre inventaire ou le transformer en plan de migration, contactez LOGIQ.