Quand IBM a publié Suite d'applications Maximo (MAS) 9.1 en juin 2025, la plupart des gros titres ont été adressés à Assistants alimentés par IA, des améliorations apportées aux applications mobiles et des fonctionnalités d'intégration étendues. Mais sous le capot, un changement se démarque pour les équipes informatiques et opérationnelles : le passage de Java 11 à Java 17.
‍

À première vue, cela peut sembler être une mise à niveau de routine de l'exécution. En réalité, il modifie les paramètres de sécurité, modifie le comportement en matière de performances et introduit des considérations de compatibilité qui peuvent avoir un impact sur tout, des scripts personnalisés aux intégrations d'entreprise. Si vous la traitez comme une mise à jour silencieuse, vous risquez de mauvaises surprises en production.

Pourquoi Java 17 est important

Java 17 est une version LTS (Long-Term Support), ce qui signifie une stabilité au moins jusqu'en 2029. C'est une bonne nouvelle pour les administrateurs qui souhaitent réduire le nombre de mises à niveau forcées et bénéficier d'un cycle de vie plus prévisible. Il s'aligne également sur la feuille de route MAS d'IBM, garantissant que les améliorations futures, en particulier celles relatives à l'IA et au déploiement natif du cloud, sont pleinement prises en charge dans votre environnement.
‍

Au-delà des avantages du cycle de vie, Java 17 offre :

• Sécurité renforcée avec des paramètres TLS par défaut plus stricts et la suppression des algorithmes cryptographiques obsolètes.

• Améliorations des performances grâce à un démarrage plus rapide, à une gestion de la mémoire plus efficace et au ramasse-miettes G1 par défaut.

• Compatibilité de développement moderne afin que les nouveaux modules et extensions MAS puissent fonctionner sans recourir à des API obsolètes.
  ‍

Ce ne sont pas des choses « simples à avoir ». Elles sont essentielles pour garantir la sécurité, les performances et la disponibilité de votre instance MAS pour les années à venir.

Qu'est-ce qui pourrait se briser

Les changements ne sont pas tous positifs. Java 17 applique des règles plus strictes et supprime les fonctionnalités existantes sur lesquelles certains environnements s'appuient encore. Par exemple, si vous avez des classes MBO personnalisées ou des scripts d'automatisation qui appellent des API obsolètes, il est possible que ces méthodes aient complètement disparu. De même, les intégrations tierces basées sur d'anciens pilotes JDBC ou clients SOAP peuvent échouer avec les paramètres de sécurité renforcés par défaut de Java 17.
‍

Vous pouvez également rencontrer :

• Indicateurs JVM non pris en charge (par exemple, UseConcMarkSweepGC) qui ne sera tout simplement pas reconnu.

• Extensions d'interface utilisateur basées sur la réflexion qui tentent d'accéder à des classes Java internes, désormais bloquées par défaut.
  ‍
  

En fin de compte, si vous n'identifiez pas ces dépendances avant la mise à niveau, elles peuvent apparaître comme des erreurs de production, parfois uniquement en cas de charge.

Préparation de la mise à niveau

Abordez cette transition comme vous le feriez pour tout changement stratégique, en combinant planification, tests et déploiement par étapes. Commencez par auditer votre environnement MAS, en documentant chaque personnalisation, intégration et dépendance. Une fois que vous savez ce qui est en jeu, créez une instance sandbox MAS 9.1 avec Java 17 et exécutez-la comme si elle était en direct : testez les ordres de travail, les rapports, la synchronisation mobile et les intégrations dans le cadre de charges de travail réelles.
‍

Dans le cadre de ce processus :

• Mettre à jour Pilotes, bibliothèques et connecteurs JDBC vers des versions compatibles avec Java 17.

• Remplacer drapeaux JVM obsolètes avec équivalents pris en charge.

• Révision vos politiques java.security pour confirmer le maintien des paramètres de cryptage.
  ‍
  

Enfin, planifiez votre interruption de production pendant les heures à faible impact, en mettant en place à la fois un chemin de retour en arrière et un plan de communication clair avec les parties prenantes.

Vérification après la mise à niveau

Une fois que vous avez changé, la vigilance est importante. Surveillez les journaux de votre système pour détecter les erreurs de classe introuvables, les incohérences entre les méthodes ou les échecs de prise de contact SSL. Comparez les mesures relatives au processeur, à la mémoire et aux transactions par rapport à vos données de référence avant la mise à niveau afin de détecter de subtiles régressions de performances. Plus important encore, maintenez les canaux de feedback ouverts avec les équipes opérationnelles : elles seront souvent les premières à détecter les anomalies fonctionnelles.
‍

Une bonne période de révision après la mise à niveau devrait également permettre de saisir toutes les « leçons apprises » afin que la prochaine modification majeure de l'exécution ou de la version du MAS soit plus fluide.

Principaux points à retenir

La migration de Java 17 vers MAS 9.1 est un changement fondamental, et pas seulement une mise à jour d'arrière-plan. En combinant un inventaire complet, des tests ciblés et un déploiement minutieux, vous pouvez éviter les interruptions tout en bénéficiant des avantages de sécurité et de performances qu'IBM a conçus dans cette version.