De Java à Kotlin : ce qu’on observe en mission chez nos clients

Kotlin n'est plus le petit nouveau qu'on associe uniquement au développement Android. Officiellement supporté par Google depuis 2017, il s'est aussi imposé côté serveur, notamment via des frameworks comme Spring, qui le prend en charge presque au même niveau que Java. Sur nos missions chez différents clients, on voit de plus en plus d'équipes Java se poser sérieusement la question. Voici ce qu'on observe concrètement quand elles franchissent le pas.  

Pourquoi les équipes se lancent

Le déclencheur est presque toujours le même : des NullPointerException récurrentes en production, du code verbeux à maintenir, et une envie de moderniser sans pour autant réécrire tout le système ni sortir de l'écosystème Java (JVM, librairies, outils de build). Kotlin, interopérable avec Java à 100 %, permet justement une migration progressive, fichier par fichier, sans big bang. C'est souvent ce qui rassure le plus les équipes qui hésitent.  

Ce qui change concrètement

Le premier changement, le plus immédiat, concerne la gestion du null. En Kotlin, la nullabilité fait partie du système de types : une variable qui peut être nulle doit être déclarée comme telle explicitement, et le compilateur refuse de compiler du code qui l'utiliserait sans vérification. Résultat observé chez plusieurs clients : les fameuses NullPointerException, qui représentaient une part non négligeable des incidents en production côté Java, chutent nettement sur le code migré. Deuxième changement, plus discret mais très concret au quotidien : la réduction du code. Les classes de données (les fameux DTO ou entités simples) qui demandaient des dizaines de lignes en Java (constructeur, getters, setters, equals, hashCode, toString) tiennent en une ligne avec les data class de Kotlin. Moins de code à écrire, mais surtout moins de code à relire en review et moins d'endroits où une erreur peut se glisser. Enfin, les fonctions d'extension et les coroutines Kotlin changent la façon d'écrire du code asynchrone. Ce qui demandait auparavant des callbacks imbriqués ou des CompletableFuture peu lisibles en Java s'écrit de façon quasiment séquentielle avec les coroutines, sans sacrifier la performance.  

Ce qui ne change pas (ou pas dans le bon sens)

L'interopérabilité avec Java, souvent présentée comme parfaite, a ses angles morts. Certaines librairies Java anciennes, pas pensées pour la nullabilité stricte de Kotlin, obligent à ajouter des vérifications manuelles aux points de jonction entre les deux langages. Ce n'est pas bloquant, mais ça demande de la vigilance, surtout sur un legacy volumineux. Le temps de compilation, lui, ne s'améliore pas franchement, parfois même l'inverse sur de gros modules, ce qui surprend souvent les équipes qui s'attendaient à un gain généralisé sur tous les fronts. Et surtout, la richesse du langage (extensions, syntaxe concise, plusieurs façons d'écrire la même chose) demande un vrai travail de convention d'équipe. Sans règles claires dès le départ, deux développeurs peuvent écrire des solutions très différentes au même problème, ce qui complique la review et l'homogénéité du code.  

Le témoignage terrain

« Je suis actuellement en mission chez un client dont l'astreinte recevait en moyenne deux ou trois alertes de NullPointerException par semaine sur un module particulier. On a proposé de migrer ce module en Kotlin en priorité. Un mois plus tard, plus une seule alerte de ce type dessus. Ça a été le meilleur argument pour convaincre le reste de l'équipe de continuer la migration, bien plus efficace que n'importe quel article sur la concision du langage. » Un Olymppien  

Notre avis, sans filtre

Passer de Java à Kotlin n'est pas une révolution, c'est une évolution à faible risque et à bénéfice réel, surtout sur un projet déjà sur la JVM. L'interopérabilité totale permet une migration progressive, sans réécriture complète ni rupture d'écosystème, ce qui change de la plupart des changements de langage. Ce n'est pas non plus une solution miracle : sans discipline d'équipe sur les conventions d'écriture, on peut se retrouver avec un code plus concis mais plus hétérogène qu'avant. Le vrai gain se joue surtout sur la fiabilité (la gestion du null) et la lisibilité au quotidien, pas sur une promesse de vitesse de développement démultipliée. La question à se poser avant de se lancer n'est pas « Kotlin est-il meilleur que Java ». C'est « est-ce que notre équipe a la discipline nécessaire pour profiter de sa flexibilité sans en payer le prix en incohérence de code ».