Conçu pour la productivité : ce que les données révèlent sur Kotlin, selon une étude de JetBrainsLes années passées à concevoir un langage axé sur la productivité se reflètent désormais dans les données.
Kotlin est un langage de programmation multiplateforme, de haut niveau, à usage général et à typage statique, doté d'une inférence de types. Kotlin est conçu pour interagir pleinement avec Java, et la version pour la machine virtuelle Java (JVM) de la bibliothèque standard de Kotlin s'appuie sur la bibliothèque de classes Java. Cependant, l'inférence de types permet une syntaxe plus concise. Kotlin cible principalement la JVM, mais se compile également en JavaScript (par exemple, pour les applications web front-end utilisant React) ou en code natif via LLVM (par exemple, pour les applications iOS natives partageant une logique métier avec des applications Android). JetBrains prend en charge les coûts de développement du langage, tandis que la Fondation Kotlin protège la marque Kotlin.
Le pragmatisme est au cœur de la conception de Kotlin depuis le tout début. Le langage privilégie la commodité et la productivité du développeur plutôt que la pureté théorique ou l’ambition de proposer de nouvelles fonctionnalités.
Les développeurs décrivent leur expérience avec Kotlin de manière assez uniforme : plus de temps consacré à ce qu’ils cherchent à créer, moins de temps perdu en formalités. Il y a moins de rituels à accomplir pour satisfaire le compilateur, et moins de code standard à écrire avant d'en venir à l'essentiel. Pendant des années, la question intéressante était de savoir si cet effet serait également visible à grande échelle.
Nous disposons désormais de données. Une récente étude de JetBrains Research a mesuré le temps écoulé entre la première modification et la validation sur environ 28 millions d'exemples. Pour un travail comparable, les développeurs Kotlin ont passé environ 15 % à 20 % de temps en moins que les développeurs travaillant en Java.
Cet écart est d’autant plus important aujourd’hui que de plus en plus de code est écrit par des agents IA et que les développeurs consacrent davantage de temps à lire, réviser et vérifier le code. Nous y reviendrons à la fin.
La productivité par conception : un bref historique
Le pragmatisme se concrétise lorsque l’on examine les fonctionnalités qu’il produit. Voici cinq exemples tirés de plus d’une décennie de décisions de conception du langage et de l’écosystème.
Les classes de données
Certains modèles se répètent dans toutes les bases de code. Objets de valeur, DTO, enveloppes de message et enregistrements de configuration : Kotlin capture ces formes en une seule déclaration.
| Code : | Sélectionner tout |
data class User(val id: Long, val name: String, val email: String)
Une seule ligne, un comportement de type valeur et un minimum de code standard. Vous bénéficiez automatiquement de l'égalité, du hachage, de la déstructuration structurelle, de toString() et d'un constructeur copy(). Ajouter un champ ne signifie pas réécrire six méthodes à la main.
Sécurité null
Le système de types de Kotlin vérifie si une valeur peut être absente, et le compilateur ne vous laisse pas ignorer la question. Toute une catégorie d’erreurs d’exécution devient un retour d’information à la compilation.
| Code : | Sélectionner tout |
val length: Int = user?.profile?.email?.length ?: 0
Une chaîne nullable s’exprime en une seule ligne, et le compilateur vérifie chaque étape. Les valeurs manquantes apparaissent à la compilation, et non plus tard en production.
Les petits gains
Une poignée de fonctionnalités éliminent discrètement les frictions à chaque point d'appel. Les conversions intelligentes éliminent la saisie redondante une fois que la vérification de type a déjà eu lieu. Les arguments nommés avec des valeurs par défaut rendent la configuration lisible sans passer par la cérémonie du constructeur. Les lambdas en fin de ligne transforment les API basées sur des blocs en quelque chose qui se lit comme un flux de contrôle ordinaire.
Chacune de ces fonctionnalités est mineure. Ensemble, elles façonnent l'apparence d'une fonction typique :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | fun createUser( name: String, role: Role = Role.MEMBER, email: String? = null, ) = transaction { // trailing lambda val user = Users.insert(name, role, email) if (email != null) { // smart cast: email is now String sendWelcome(email.lowercase()) } user } createUser(name = "Anton", role = Role.ADMIN) // named args + default |
Trois fonctionnalités se combinent en une seule fonction courte et lisible.
Coroutines et concurrence structurée
Le traitement asynchrone en Kotlin se lit comme du code ordinaire. Les fonctions suspendues semblent séquentielles mais s’exécutent en parallèle, et la concurrence structurée lie chaque opération asynchrone à la portée qui l’a lancée – ainsi, rien ne s’échappe pour s’exécuter en arrière-plan sans être remarqué.
Les DSL comme idiome de premier ordre
La productivité ne s’est pas arrêtée au langage. Les mêmes choix syntaxiques – lambdas en fin de ligne, fonctions d’extension, constructeurs typés – favorisent également une culture des DSL adaptés aux EDI dans tout l’écosystème : scripts de build Gradle, interface utilisateur Compose, routage Ktor, SQL exposé, et constructeurs HTML et JSON. Chacun constitue une surface de configuration que le compilateur interprète comme du code natif, et non comme un format distinct à mémoriser.
Aucun de ces éléments n’est une victoire isolée. Chacun est le fruit du même engagement envers le pragmatisme. La suite de cet article examine à quoi ressemble cet engagement dans son ensemble.
La question à laquelle les témoignages ne pouvaient répondre
Les développeurs décrivent Kotlin ainsi depuis des années : moins de formalités et plus de temps consacré au travail réel. Mais une description n’est pas une mesure. La question de savoir si le même effet se traduirait également en chiffres, à une échelle où l’opinion d’une seule équipe ne domine pas, est tout autre.
Les témoignages ne sont pas représentatifs, et l’auto-évaluation comporte des biais connus, dont le plus évident : les personnes qui choisissent Kotlin veulent que ce choix soit justifié. Un biais plus subtil est que les développeurs qui ont brièvement essayé Kotlin avant de revenir en arrière risquent de ne jamais être pris en compte dans l’échantillon. C’est là qu’une étude peut combler le fossé.
Ce qu’a révélé l’étude
Dans une étude récente, l’équipe JetBrains Research a analysé les données télémétriques d’IntelliJ IDEA Ultimate sur une période de 20 mois, de novembre 2023 à juin 2025, couvrant environ 320 000 développeurs et 28 millions de cycles de développement. Dans cette étude, un cycle correspond au temps écoulé entre la première modification d’un fichier source après un push et le push suivant sur ce fichier.
Pour les petites tâches (environ dix minutes de modification), les cycles Kotlin étaient en moyenne environ 15,7 % plus courts que ceux de Java. Pour les tâches de durée moyenne (environ une demi-heure), ils étaient environ 20,3 % plus courts. Pour les tâches volumineuses (une heure et demie à deux heures), ils étaient environ 15,1 % plus courts. En termes absolus, cela représente une ou deux minutes de gain pour une correction courte, cinq à sept minutes pour une correction moyenne et 15 à 20 minutes pour une correction longue – un gain qui se répète de nombreuses fois au cours d’une journée de travail et d’un trimestre. La même tendance s’est maintenue quelle que soit la taille des tâches et tout au long de la période de 20 mois.
Les questions qui viennent à l’esprit sont légitimes. Les projets Kotlin et Java ne sont-ils pas de tailles différentes ? Les développeurs n’ont-ils pas des niveaux d’expérience différents ? Certaines équipes Kotlin ne sont-elles pas simplement plus récentes ou mieux dotées en ressources que les équipes Java auxquelles elles sont comparées ?
Des efforts considérables ont été déployés pour écarter ces facteurs. L’étude a comparé les mêmes développeurs avant et après leur migration de Java vers Kotlin, par rapport à des développeurs restés sur Java pendant la même période – une conception longitudinale qui isole le changement de langage des différences entre équipes ou projets. Le travail a été classé par taille de tâche, de sorte que la comparaison n’opposait pas une modification d’une ligne à la création d’une fonctionnalité. La version du JDK a été utilisée comme indicateur de la culture d’ingénierie, la comparaison ayant été effectuée à la fois avec et sans ce contrôle. La tendance s’est confirmée.
La méthodologie complète – la conception longitudinale, les contrôles, les vérifications de validité et les limites de ce que l’étude peut et ne peut pas affirmer – se trouve dans l’article de JetBrains Research. Tout ce qui suit correspond à la manière dont nous, du côté de Kotlin, interprétons ces résultats.
La conclusion principale : les projets Kotlin ne ralentissent pas
Un écart de 15 % à 20 % sur les tâches individuelles est réel, mais ce n’est pas le plus important. La conclusion principale réside dans la trajectoire. En examinant comment le même type de travail évolue au cours de la durée de vie d’un projet, les données racontent une histoire différente de celle que révèlent les chiffres ponctuels.
Dans l'échantillon de l'étude, les projets Java ont ralenti au cours de la période de 20 mois. Les cycles se sont allongés de 9 % à 17 % à mesure que les bases de code s'étoffaient, qu'il s'agisse de tâches de petite, moyenne ou grande envergure. La même tendance se retrouve dans des segments indépendants des données : plus un projet Java vieillit, plus le même type de travail prend du temps. Les projets Kotlin n'ont pratiquement pas montré ce ralentissement. Certains développeurs ayant migré vers Kotlin ont même progressé au cours de la même période, travaillant plus rapidement sur des tâches comparables à la fin de la période qu’au début.
Cela correspond à ce que nous entendons depuis des années du côté de la maintenabilité : le code Kotlin est plus facile à maintenir. Vous pouvez y revenir six mois plus tard et comprendre encore ce que vous avez écrit.
Jusqu’à présent, ces rapports coexistaient avec les rapports sur la productivité en tant qu’observations distinctes. Ils apparaissent de plus en plus comme la même conclusion vue sous deux angles différents.
Voici notre interprétation de ce phénomène – il s’agit explicitement de la nôtre, et non d’une conclusion que l’étude cherchait à prouver. Le code Kotlin exprime l’intention plus clairement que le code Java équivalent. Les types contiennent davantage d’informations. Les idiomes sont plus uniformes entre les équipes et au fil du temps. Une moindre partie du travail est codée dans des modèles que le lecteur suivant doit reconstruire.
Si cette interprétation est correcte, le résultat de la trajectoire prend tout son sens. Une base de code qui reste lisible n’accumule pas le genre de friction qui transforme lentement une modification de 10 minutes en une de 15 minutes. La différence n’est peut-être pas perceptible dès le premier jour. Mais à grande échelle, l’effet cumulatif est indéniable !
Ce que cela signifie à l’ère de l’IA
À mesure que la rédaction assistée par l’IA et les workflows agentiques se généralisent, les développeurs passent plus de temps à réviser, intégrer, rejeter et ajuster le code qu’à l’écrire eux-mêmes. Même au sein des équipes qui n’ont pas adopté les agents à grande échelle, cette évolution modifie la répartition des activités quotidiennes. Une part croissante du travail du développeur consiste à décider si ce code a sa place.
Deux faits bien établis coexistent. Premièrement, les développeurs passent la majeure partie de leur temps à lire du code plutôt qu’à l’écrire. La règle des 80/20 est un lieu commun dans le secteur pour une bonne raison : elle ressort des études, des rétrospectives et de tout bilan honnête de la façon dont une journée de travail est passée. Deuxièmement, pour un travail comparable, les développeurs Kotlin parcourent leurs cycles de manière significativement plus rapide que les développeurs Java.
L'interprétation raisonnable est que le temps gagné est du temps de lecture. C'est à la lecture que passe la majeure partie du temps, et Kotlin semble accélérer ce processus.
Dans les flux de travail axés sur l'agent, cela revêt une importance encore plus grande. La révision du code d'une modification générée par l'IA consiste à lire. Vérifier qu'une implémentation proposée fait bien ce qu'elle prétend faire consiste à lire. L'intégrer dans un système existant consiste à lire. Rejeter une mauvaise suggestion commence par la lecture. La part de la semaine d'un développeur consacrée à la saisie est en baisse depuis deux décennies, et elle s'effondre aujourd'hui. Le temps passé à lire et à comprendre suit une tendance inverse.
Les langages qui vous permettent de lire plus vite – et de faire confiance à ce que vous lisez – sont bien plus intéressants pour le développement logiciel moderne.
Kotlin offre également davantage de garanties statiques dès l'installation. La non-nullabilité est appliquée au niveau des types. Le rétrécissement de type se produit automatiquement une fois que vous avez vérifié un type. Les hiérarchies scellées, associées à des expressions « when » exhaustives, permettent de répondre à la question « L'agent a-t-il oublié un cas ? » dès la phase de compilation. Les mêmes fonctionnalités qui rendent le code Kotlin plus rapide à lire le rendent également plus rapide à vérifier mécaniquement, par le compilateur avant la révision, puis par le réviseur humain par la suite.
Ce type de sécurité est vraiment payant lorsque vous n’avez pas écrit le code vous-même.
L’avantage en termes de productivité mis en évidence par les données était bien réel avant l’IA, et l’évolution du développement logiciel pourrait rendre cet avantage plus important que jamais. L'écart du premier jour, l'avantage de la trajectoire et le cas du flux de travail agentique vont tous dans la même direction.
Conclusion
Pour les développeurs : la discussion au sein de l'équipe, qui repose depuis des années sur l'intuition, s'appuie désormais sur des chiffres. La prochaine fois que la question se posera de savoir si Kotlin est réellement rentable pour une équipe Java, vous pourrez fonder votre réponse sur des données concrètes.
Pour les responsables techniques : les arguments quantitatifs en faveur d’un nouveau service JVM sont désormais visibles. L’effet « day-one » plus faible et l’effet de trajectoire plus important jouent tous deux en votre faveur. Le second est le plus important pour tout ce que vous comptez maintenir au-delà d’un an.
Le pragmatisme a donné naissance à un langage dont les avantages s’accumulent avec le temps – et qui prend de l’importance, et non l’inverse, à mesure que le rôle du développeur évolue.
En savoir plus sur le développement back-end avec Kotlin Essayer Kotlin en ligne
Vous avez lu gratuitement 3 051 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
