Java 8 Spring : faut-il vraiment migrer vers Java 21 + Spring Boot 3 ?

#État des lieux : Java 8 en production en 2026

Selon le rapport JetBrains Developer Ecosystem 2025, Java 8 représente encore 28% des JDK en production dans les entreprises européennes. En France, cette proportion est probablement plus élevée : les ETI françaises, historiquement conservatrices dans leurs choix d'infrastructure, maintiennent des applications Java 8 déployées entre 2014 et 2019 qui fonctionnent parfaitement — du moins en apparence.

Le problème n'est pas que Java 8 soit défaillant. Le JDK lui-même reste stable. Oracle fournit un support commercial LTS jusqu'en mars 2030 via les licences Java SE Subscription. Des distributeurs alternatifs comme Azul, Red Hat et Amazon Corretto proposent des builds gratuites avec un support qui s'étend au-delà de 2030.

Le vrai problème se situe ailleurs : dans l'écosystème. Les frameworks, les bibliothèques et les outils qui entourent Java 8 ont cessé de le supporter. Et c'est là que la situation devient critique pour les équipes de développement.

Spring Boot 2.x, le framework le plus utilisé dans l'écosystème Java d'entreprise, a atteint sa fin de vie officielle en novembre 2023. Depuis cette date, aucun patch de sécurité n'est publié sur les branches 2.x. Si une CVE critique est découverte dans Spring Boot 2.7 demain, vous ne recevrez pas de correctif — sauf à souscrire un contrat de support étendu VMware Tanzu.

Mais le framework n'est pas seul concerné. Hibernate 6 requiert Java 11 minimum. Les dernières versions de Testcontainers, Flyway, Liquibase et de nombreuses bibliothèques de l'écosystème ont abandonné le support de Java 8. Même Maven et Gradle recommandent désormais Java 17 comme minimum pour les builds.

Concrètement, chaque mois qui passe rend la migration plus complexe car l'écart entre votre stack et les versions supportées continue de se creuser. Ce qui aurait été une mise à jour de dépendances en 2023 devient un projet de migration structuré en 2026.

#Ce que Spring Boot 3 change réellement

Spring Boot 3.0, publié en novembre 2022, est une rupture technique assumée. Contrairement aux montées de version mineures, le passage de Spring Boot 2 à 3 n'est pas une simple mise à jour du fichier pom.xml. Voici les changements structurants.

Jakarta EE 10 au lieu de Java EE. C'est le changement le plus visible et le plus systématique. Toutes les classes de l'espace de noms javax.* passent à jakarta.*. Cela concerne les servlets (jakarta.servlet), la persistence JPA (jakarta.persistence), la validation (jakarta.validation), les API REST (jakarta.ws.rs), les transactions (jakarta.transaction). Sur une application de 50 000 lignes, comptez entre 200 et 800 remplacements mécaniques.

Java 17 comme minimum requis. Spring Boot 3 ne compile plus avec Java 8, ni même Java 11. Le minimum est Java 17, et Java 21 est recommandé. Cela signifie que la migration du framework et la migration du JDK sont couplées — impossible de les découpler.

Observabilité native avec Micrometer. Spring Boot 3 intègre nativement Micrometer Observation API, qui unifie le tracing distribué (anciennement Spring Cloud Sleuth, désormais Micrometer Tracing). Si votre application utilise Sleuth, la migration vers Micrometer est obligatoire.

Spring Security 6. Les changements dans Spring Security sont les plus susceptibles de générer des régressions silencieuses. La configuration par défaut a changé : les requêtes sont désormais refusées par défaut (au lieu d'être autorisées), la protection CSRF est appliquée différemment, et la chaîne de filtres a été restructurée. Testez exhaustivement l'authentification et les autorisations après migration.

GraalVM et compilation native. Spring Boot 3 apporte un support natif de GraalVM pour la compilation ahead-of-time. Si le temps de démarrage est critique pour votre application (serverless, scale-to-zero), cette fonctionnalité justifie à elle seule la migration — les temps de démarrage passent de 5-15 secondes à 50-200 millisecondes.

#Virtual threads : le vrai argument technique pour Java 21

Au-delà de la compatibilité avec Spring Boot 3, Java 21 apporte une fonctionnalité qui change la donne pour les applications d'entreprise : les virtual threads (Project Loom).

Dans le modèle traditionnel de Java, chaque requête HTTP est traitée par un thread du système d'exploitation. Un thread OS consomme environ 1 Mo de mémoire stack. Un serveur Tomcat configuré avec 200 threads (configuration par défaut de Spring Boot) peut donc traiter 200 requêtes concurrentes — au-delà, les requêtes sont mises en file d'attente.

Les virtual threads sont des threads légers, gérés par la JVM et non par l'OS. Ils consomment quelques kilo-octets de mémoire au lieu d'un méga-octet. On peut en créer des millions simultanément. Concrètement, une application Spring Boot 3.2+ configurée avec les virtual threads peut gérer 10 000 à 100 000 requêtes concurrentes sur un serveur qui en traitait 200 auparavant.

L'activation est triviale — une seule propriété dans application.properties : spring.threads.virtual.enabled=true. Aucune modification du code applicatif n'est nécessaire. Spring Boot se charge de configurer Tomcat pour utiliser des virtual threads au lieu de platform threads.

Le bénéfice est immédiat pour les applications qui font beaucoup d'I/O blocking : appels à des API externes, requêtes base de données, lectures de fichiers. En revanche, les virtual threads n'apportent pas de gain pour les tâches CPU-bound (calcul, transformation de données en mémoire).

Une ETI cliente de Nehos a mesuré un gain de 4x sur le débit de requêtes après activation des virtual threads sur une application de gestion de commandes qui effectuait en moyenne 3 appels JDBC et 2 appels REST par requête. Le temps de réponse p99 est passé de 1 200 ms à 320 ms sous charge.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Les 6 étapes concrètes de la migration

Voici la séquence que Nehos applique systématiquement sur les projets de migration Java 8 → Java 21 + Spring Boot 3.

Étape 1 — Audit et inventaire (1-2 jours). Listez toutes les dépendances du projet (mvn dependency:tree ou gradle dependencies). Identifiez celles qui utilisent des API javax.*. Vérifiez la compatibilité de chaque dépendance tierce avec Jakarta EE 10 et Java 17+. Documentez les dépendances bloquantes qui n'ont pas de version compatible.

Étape 2 — Migration du JDK (1-2 jours). Passez de Java 8 à Java 17, puis à Java 21. Corrigez les erreurs de compilation liées aux modules JPMS (les packages sun.misc.* et javax.xml.bind.* ne sont plus inclus par défaut). Ajoutez les dépendances explicites nécessaires (jaxb-runtime, javax.annotation-api). Validez que la suite de tests passe intégralement.

Étape 3 — Renommage javax → jakarta (1-3 jours). Utilisez l'outil OpenRewrite avec la recette org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta pour automatiser 90% des renommages. Traitez manuellement les 10% restants (fichiers de configuration XML, annotations dans les fichiers de mapping JPA, imports dans les tests).

Étape 4 — Mise à jour Spring Boot 2 → 3 (2-5 jours). Mettez à jour le parent POM ou la version du plugin Gradle. Appliquez la recette OpenRewrite org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_2 pour les changements automatisables. Traitez manuellement les changements de configuration Spring Security, les migrations Sleuth → Micrometer, et les changements d'API de configuration.

Étape 5 — Tests de régression (2-5 jours). Exécutez l'intégralité de la suite de tests. Ajoutez des tests d'intégration pour les flux d'authentification Spring Security si la couverture existante est insuffisante. Effectuez des tests de charge pour valider le comportement sous stress avec le nouveau JDK.

Étape 6 — Déploiement progressif (1-2 jours). Déployez en environnement de staging, puis en canary release (5% du trafic production). Surveillez les métriques de performance, les logs d'erreur et les métriques métier pendant 48 à 72 heures avant le rollout complet.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

Durée totale estimée : 8 à 19 jours-homme selon la complexité de l'application.

#Budget réaliste : 15 000 à 50 000 euros

Les coûts varient considérablement selon la taille et la complexité de l'application. Voici une grille basée sur des missions réelles réalisées par Nehos.

Application simple (microservice ou API, 5 000 à 20 000 lignes, 10-30 dépendances) : 8 à 12 jours-homme, soit à partir de 928 € HT. La migration est largement automatisable avec OpenRewrite. Les risques principaux sont les dépendances tierces incompatibles.

Application moyenne (monolithe modulaire, 20 000 à 80 000 lignes, 30-80 dépendances) : 15 à 25 jours-homme, soit à partir de 1 177 € HT. La part manuelle augmente significativement, notamment sur Spring Security et les intégrations tierces. Prévoir 3 à 5 jours de tests de régression.

Application complexe (monolithe legacy avec couche JPA étendue, intégrations multiples, 80 000+ lignes) : 25 à 40 jours-homme, soit à partir de 1 618 € HT. Les risques principaux sont la migration JPA/Hibernate (requêtes HQL, critères de recherche, lazy loading), les intégrations JMS/SOAP et la configuration Spring Security custom.

Ces coûts incluent l'audit, la migration technique, les tests de régression et le déploiement. Ils excluent les coûts d'infrastructure (mise à jour des images Docker, des pipelines CI/CD, des serveurs d'application).

À mettre en perspective : le coût de non-migration. Maintenir une application Spring Boot 2 en production sans patches de sécurité expose l'entreprise à des risques de conformité (RGPD, NIS2) et à des coûts croissants de recrutement — les développeurs Java compétents refusent de plus en plus de travailler sur des stacks obsolètes.

#Pièges courants et comment les éviter

Le piège OpenRewrite. L'outil automatise le renommage javax → jakarta, mais il ne gère pas les cas où des bibliothèques tierces exportent des classes javax.* dans leur API publique. Si une dépendance n'a pas de version Jakarta, vous devrez soit la remplacer, soit encapsuler son API derrière un adaptateur.

Le piège Spring Security. La migration de Spring Security 5 vers 6 est souvent sous-estimée. Les changements de configuration par défaut (requêtes refusées par défaut, nouvelle chaîne de filtres) peuvent provoquer des régressions silencieuses sur les endpoints non couverts par les tests. Recommandation : auditez chaque endpoint d'authentification avant et après migration.

Le piège Hibernate. Le passage à Hibernate 6 modifie le comportement de certaines requêtes HQL et des critères de recherche. Les changements sont subtils mais peuvent affecter les résultats de requêtes complexes. Exécutez les tests avec un focus particulier sur les requêtes de recherche et de reporting.

Le piège des dépendances transitives. Certaines dépendances transitives peuvent continuer à tirer javax.* même après votre migration. Utilisez mvn dependency:tree -Dincludes=javax pour identifier les imports résiduels et les éliminer un par un.

Le piège du test en production. Ne déployez jamais une migration Java directement en production sans phase canary. Même avec une suite de tests complète, les différences de comportement entre JDK 8 et 21 (garbage collection, gestion mémoire, comportement des threads) peuvent se manifester uniquement sous charge réelle.

#Faut-il migrer maintenant ou attendre ?

La réponse dépend de votre situation. Voici trois scénarios types.

Migrez maintenant si votre application est activement développée (nouvelles fonctionnalités régulières), si vous recrutez des développeurs Java (les candidats refuseront un stack Java 8/Spring Boot 2), ou si vous êtes soumis à des exigences de conformité sécurité (NIS2, DORA, audit de sécurité).

Planifiez pour les 12 prochains mois si votre application est en maintenance (peu de nouvelles fonctionnalités), mais doit rester en production pour les 3 à 5 prochaines années. Le coût de migration augmente chaque année car l'écart technologique se creuse.

Ne migrez pas si votre application a une durée de vie résiduelle inférieure à 18 mois et qu'une réécriture ou un remplacement est déjà planifié. Dans ce cas, investissez dans la surveillance des CVE et les contre-mesures réseau (WAF, isolation réseau) plutôt que dans une migration technique.

Dans tous les cas, ne sous-estimez pas le coût croissant de l'immobilisme. La dette technique s'accumule exponentiellement : ce qui coûte à partir de 873 € aujourd'hui en coûtera 40 000 dans deux ans, non pas parce que la migration devient plus complexe, mais parce que l'écosystème continue d'avancer et que le fossé avec votre stack se creuse.

Nehos accompagne les ETI françaises dans leurs migrations d'applications legacy avec une méthodologie éprouvée sur plus de 30 projets Java. Si vous évaluez une migration Java 8, un diagnostic technique de 2 jours permet de chiffrer précisément le périmètre et les risques.