Kotlin ou Java pour une application Android, le choix en pratique
Kotlin ou Java : pour une nouvelle application Android, la question est largement tranchée, mais elle reste bien réelle pour qui doit reprendre un projet existant, recruter un développeur ou faire évoluer une base de code ancienne. Google a pris position en faveur de Kotlin depuis plusieurs années, et l’essentiel de l’écosystème moderne s’est construit dans ce sens. Java n’a pas disparu pour autant : des millions de lignes de code Android ont été écrites dans ce langage, et elles tournent toujours. Comprendre ce qui distingue les deux, et comment ils cohabitent, aide à prendre de bonnes décisions techniques et budgétaires.
Kotlin ou Java : ce que Google a décidé
Pendant les premières années d’Android, Java était le langage de référence pour développer des applications. Kotlin, créé par la société JetBrains, éditrice d’outils de développement, a été officiellement pris en charge par Google pour Android en 2017. En 2019, Google a annoncé que le développement Android deviendrait « Kotlin-first », c’est-à-dire que les nouvelles API, bibliothèques et documentations seraient pensées d’abord pour Kotlin.
Cette orientation se voit concrètement. La documentation officielle pour les développeurs Android présente ses exemples en Kotlin en priorité. Les bibliothèques Jetpack exploitent des fonctionnalités propres à Kotlin, comme les coroutines pour la programmation asynchrone. Surtout, Jetpack Compose, la boîte à outils déclarative recommandée pour construire les interfaces, s’écrit en Kotlin : il n’est pas possible de l’utiliser directement depuis du code Java.
Java reste néanmoins pris en charge. Une application écrite entièrement en Java peut toujours être compilée, publiée et mise à jour sur le Google Play Store. Google ne l’a pas abandonné ; il a simplement cessé d’en faire la priorité.
Ce que Kotlin apporte au quotidien
Le choix de Google ne relève pas de la mode. Kotlin répond à plusieurs faiblesses que les développeurs Android rencontraient avec Java.
Null maîtrisé. Le système de types de Kotlin distingue les valeurs qui peuvent être nulles de celles qui ne le peuvent pas. Une grande partie des erreurs liées aux références nulles, responsables de nombreux plantages d’applications Java, est ainsi détectée dès la compilation plutôt qu’à l’exécution chez l’utilisateur.
La concision. Kotlin permet d’exprimer la même logique avec nettement moins de code : classes de données, fonctions d’extension, inférence de types, valeurs par défaut des paramètres. Moins de code signifie moins d’endroits où un bug peut se cacher, et une lecture plus rapide lors des revues.
Les coroutines. La gestion des tâches asynchrones (appels réseau, accès à la base de données) est au cœur d’une application mobile. Les coroutines de Kotlin offrent une manière plus lisible et plus sûre de les écrire que les approches classiques à base de rappels, et elles s’intègrent aux composants Jetpack liés au cycle de vie.
L’écosystème moderne. Jetpack Compose, de nombreuses bibliothèques récentes et Kotlin Multiplatform, qui permet de partager du code entre Android et d’autres plateformes, reposent sur Kotlin. Rester en Java, c’est se priver d’une partie croissante de ces outils.
| Critère | Kotlin | Java |
|---|---|---|
| Position de Google pour Android | Langage privilégié depuis 2019 | Toujours pris en charge, plus prioritaire |
| Gestion du null | Intégrée au système de types | Dépend des annotations et de la discipline |
| Verbosité | Faible | Plus élevée |
| Programmation asynchrone | Coroutines natives | Rappels, bibliothèques externes |
| Jetpack Compose | Utilisable directement | Non utilisable directement |
| Documentation officielle récente | Exemples en priorité | Exemples parfois absents |
| Base de code existante | Majoritaire sur les projets récents | Très présente sur les projets anciens |
Ce que Java garde comme intérêt
Affirmer que Java n’a plus aucune place dans le développement Android serait faux. Il conserve plusieurs atouts, surtout dans un contexte d’existant.
Le premier est la base installée. De nombreuses applications d’entreprise, lancées il y a dix ans ou plus, reposent sur des centaines de milliers de lignes de Java. Les réécrire intégralement en Kotlin coûterait cher pour un bénéfice qui n’est pas toujours visible pour l’utilisateur final. Dans ce cas, maintenir le code Java existant et écrire le code nouveau en Kotlin est souvent la solution la plus raisonnable.
Le deuxième est la familiarité. Java est l’un des langages les plus enseignés et les plus répandus dans le monde, bien au-delà du mobile. Une équipe qui travaille aussi sur un back-end Java peut trouver confortable de garder un langage commun, même si Kotlin s’apprend rapidement pour un développeur Java.
Le troisième tient à certaines bibliothèques ou certains SDK tiers, plus anciens, documentés uniquement en Java. Ce point compte de moins en moins : Kotlin appelle du code Java sans difficulté, et la plupart des fournisseurs ont mis à jour leurs exemples.
Reste la question des performances, souvent posée par les clients. À l’exécution, la différence entre une application Kotlin et une application Java est généralement imperceptible pour l’utilisateur : les deux langages produisent du code exécuté par le même environnement d’exécution d’Android. Les écarts tiennent bien davantage à la qualité de l’architecture, à la gestion des tâches en arrière-plan et au poids des bibliothèques embarquées qu’au langage lui-même. Côté développement, la compilation de Kotlin a longtemps été jugée plus lente que celle de Java sur les gros projets ; JetBrains a beaucoup travaillé ce point, notamment avec le nouveau compilateur introduit par Kotlin 2.0, et l’écart s’est réduit.
Les tests suivent la même logique. Les outils de test unitaire et d’interface utilisés sur Android fonctionnent avec les deux langages, et un projet mixte peut tester du code Java avec des tests écrits en Kotlin. Le langage ne constitue donc pas un frein à la mise en place d’une stratégie de qualité, que l’application soit ancienne ou récente.
La cohabitation dans Android Studio
C’est l’un des grands avantages pratiques de Kotlin : il est interopérable avec Java. Les deux langages compilent vers le même type de code exécutable et peuvent coexister dans le même projet, voire dans le même module.
Une classe Kotlin peut appeler une classe Java et inversement. Android Studio, l’environnement de développement officiel, propose même un outil de conversion automatique d’un fichier Java en Kotlin. Le résultat n’est pas toujours idiomatique et mérite une relecture, mais il fournit une base de travail.
Cette interopérabilité permet une migration progressive, qui est la stratégie la plus courante sur les projets existants :
- écrire tout nouveau code en Kotlin, sans toucher à l’existant ;
- convertir les fichiers Java au fil des évolutions, quand un écran ou un module doit de toute façon être modifié ;
- introduire Jetpack Compose écran par écran, l’ancien système de vues et Compose pouvant cohabiter ;
- réserver les réécritures complètes aux parties du code les plus fragiles ou les plus coûteuses à maintenir.
Cette approche évite le « grand chantier » qui immobilise une équipe pendant des mois sans livrer de nouvelle fonctionnalité. Elle a un coût : pendant la transition, les développeurs doivent maîtriser les deux langages et gérer quelques subtilités aux frontières, notamment sur la gestion du null entre code Kotlin et code Java.
L’effet du choix sur le recrutement et le budget
Pour un client qui cherche un développeur ou une entreprise qui gère une application, le choix du langage a des conséquences directes au-delà de la technique.
Sur un projet neuf, partir en Kotlin est la recommandation quasi unanime. C’est ce que maîtrisent la grande majorité des développeurs Android formés ces dernières années, ce que la documentation officielle met en avant et ce qui ouvre l’accès à Jetpack Compose. Choisir Java aujourd’hui pour une nouvelle application Android exposerait à un code plus difficile à faire évoluer et à un vivier de profils qui se réduit sur ce créneau.
Sur un projet existant en Java, il faut recruter un profil à l’aise dans les deux langages, capable de maintenir l’ancien code et de piloter une migration progressive. Ces profils, souvent expérimentés, sont recherchés. Le guide pour recruter un freelance en application mobile donne des questions utiles pour vérifier cette double compétence en entretien.
Côté budget, une migration de Java vers Kotlin représente un investissement à planifier. Elle se justifie quand elle réduit le coût de maintenance, accélère le développement des nouvelles fonctionnalités ou facilite le recrutement. Elle se discute quand l’application est en fin de vie ou n’évolue presque plus. Les ordres de grandeur de prix sont détaillés dans l’article sur le TJM d’un développeur mobile.
Enfin, la question du langage s’inscrit dans un choix plus large : rester en natif Android ou partir sur une solution multiplateforme. Kotlin Multiplatform permet de partager la logique métier entre Android et iOS tout en restant dans l’univers Kotlin, une option à mettre en regard de Flutter et React Native dans le comparatif Flutter ou natif.
Kotlin ou Java : la réponse selon la situation
En pratique, la décision se résume à quelques cas de figure assez clairs.
- Nouvelle application Android : Kotlin, avec Jetpack Compose pour l’interface.
- Application existante en Java qui évolue activement : nouveau code en Kotlin, migration progressive au fil des évolutions.
- Application existante en Java peu modifiée : maintien en Java, avec les mises à jour imposées par les nouvelles versions d’Android et les règles du Play Store.
- Équipe très ancrée dans Java : formation à Kotlin, qui reste accessible pour un développeur Java et s’amortit rapidement.
Le débat Kotlin ou Java n’oppose pas un bon et un mauvais langage. Il oppose un écosystème en mouvement, que Google pousse activement, à un héritage solide mais qui n’est plus la priorité. Pour une application destinée à vivre plusieurs années, s’aligner sur la direction prise par la plateforme reste le choix le plus sûr.