Kotlin Hebdo #1 : Arrivée de la préversion 2.5, extensions de companion et compilation séparée pour KMP

Cette semaine, nous passons en revue les faits marquants de l’écosystème Kotlin en ce début d’octobre 2026. Alors que le langage célèbre son quinzième anniversaire, JetBrains a dévoilé une série de préversions majeures pour Kotlin 2.5 ainsi qu’une refonte architecturale de Kotlin Multiplatform (KMP), adressant un signal d’évolution puissant à l’ensemble de l’industrie.

📦 Actualité des versions

La version stable la plus récente est la 2.4.20 (publiée le 7 septembre 2026), qui apporte des optimisations notables à la bibliothèque standard et au cœur des coroutines. Si vous n’avez pas encore découvert les gains de compilation apportés par la série 2.4.x sur les cibles Wasm et Native, n’hésitez pas à consulter notre Analyse approfondie des nouveautés de Kotlin 2.4.

Plus marquant encore, la toute première préversion de Kotlin 2.5, 2.5.0-Beta1, a vu le jour le 23 septembre. Prélude à la version annuelle majeure attendue pour décembre, cette Beta1 stabilise la syntaxe de déstructuration par nom (Name-based destructuring), scellant définitivement la fin de l’ère de la déstructuration séquentielle par position. Elle intègre également deux fonctionnalités expérimentales autour des companions et le tout nouveau pipeline de compilation KMP, détaillés ci-dessous.

📝 Articles de fond

The Companions to Come : blocs et extensions de companion

• Que s’est-il passé : Le 30 septembre, l’équipe officielle a levé le voile sur deux syntaxes expérimentales prévues pour Kotlin 2.5 : les Companion Extensions (extensions de companion) et les Companion Blocks (blocs de companion). Les premières permettent aux développeurs d’injecter des méthodes d’extension au niveau classe (statiques) directement dans des bibliothèques externes ne déclarant pas explicitement de companion object ; les seconds introduisent une structure en bloc plus proche de la portée static de Java, afin d’optimiser les implémentations multiplateformes. Elles s’activent au moyen du paramètre de compilateur -Xcompanion-blocks.
• Pourquoi c’est important : L’interopérabilité a longtemps pâti de la contrainte imposant aux fonctions d’extension de reposer sur une instance ou un objet companion préexistant. Auparavant, pour enrichir la classe java.time.LocalDate du JDK d’une méthode de fabrique telle que fromCustomFormat(), les développeurs devaient se résoudre à utiliser des fonctions de premier niveau globales polluant l’espace de noms. Les Companion Extensions brisent ce verrou, offrant aux concepteurs de bibliothèques la possibilité d’injecter des API statiques de façon fluide dans n’importe quel domaine de types. De leur côté, les Companion Blocks s’attaquent à une friction récurrente lors des interactions entre KMP et la JVM ou Objective-C : ils éliminent les instances redondantes d’objets companions générées sous le capot par l’annotation @JvmStatic, permettant d’obtenir de véritables liaisons statiques pures sans surcoût dans les correspondances actual.
• Qui est concerné : Auteurs de frameworks, développeurs de SDK et architectes multiplateformes KMP. C’est une véritable libération pour la conception d’API, encourageant le passage de fonctions utilitaires dispersées à une approche orientée objet hautement cohérente.

Nouveau schéma de compilation séparée dans KMP : fin du mystère des erreurs fantômes dans l’IDE

• Que s’est-il passé : Le 28 septembre, l’équipe de développement a officialisé le mécanisme de « compilation séparée » (Separate Compilation) introduit dans 2.5.0-Beta1. Les développeurs peuvent l’activer en ajoutant kotlin.kmp.separateCompilation=true à leurs scripts de build. Ce mécanisme impose au niveau architectural que les fichiers sources communs commonMain de KMP soient compilés exclusivement sur la base de métadonnées KLIB pures, rompant net toute dépendance physique vis-à-vis des plateformes sous-jacentes.
• Pourquoi c’est important : Dans les grands projets multiplateformes, les développeurs étaient fréquemment confrontés à l’anomalie du « code en rouge dans l’IDE » : l’éditeur ne signalait aucune erreur dans les modules communs, mais l’exécution du build Gradle échouait en raison de conflits de résolution de surcharge ou d’erreurs d’inférence de types, provoqués par des rétro-injections implicites depuis le code d’une plateforme. L’ancien pipeline de compilation manquait d’une séparation physique stricte au sein de l’arbre de dépendances. Le schéma de compilation séparée garantit une concordance à 100 % entre l’analyse statique de l’IDE et les contrôles du compilateur, tout en éliminant les recompilations en cascade du code commun déclenchées par la modification d’une seule plateforme cible.
• Qui est concerné : Les ingénieurs multiplateformes pénalisés par la lenteur des compilations incrémentales et les incohérences d’analyse de KMP. Dans les architectures monolithiques à modules fortement imbriqués, cette avancée procure un gain immédiat de vitesse de compilation et de déterminisme.

Rapport « State of Kotlin 2026 » : percée côté backend et immersion dans l’ère de l’IA

• Que s’est-il passé : Révélé le 29 septembre, le State of Kotlin in 2026 Report dresse un bilan impressionnant pour le 15e anniversaire du langage. Pas moins de 50 % des développeurs Kotlin interrogés sont désormais activement impliqués dans le développement de backends et de microservices. Parallèlement, en plein essor de l’IA, 93 % des répondants utilisent quotidiennement des outils d’assistance au code par IA, et 81 % ont commencé à déployer des agents d’IA autonomes dans leurs flux de travail.
• Pourquoi c’est important : Dépasser le cap des 50 % côté serveur consacre l’émancipation définitive de Kotlin vis-à-vis de son étiquette de « langage réservé à Android ». Soutenu par une intégration étroite avec Spring Boot et l’essor de l’écosystème Ktor, Kotlin a conquis une part solide du marché du backend d’entreprise sur JVM. Par ailleurs, ce taux d’adoption de l’IA supérieur à 90 % confirme que le typage statique fort et la sémantique rigoureuse de Kotlin confèrent un avantage net face aux langages de script dynamiques pour la génération de code par LLM et la réduction des hallucinations, consolidant sa position comme socle de choix pour l’infrastructure d’IA.
• Qui est concerné : Les décideurs techniques évaluant leurs choix d’architecture logicielle. Les données confirment que choisir Kotlin pour des backends d’entreprise critiques n’est plus un pari risqué, mais une stratégie éprouvée, forte d’un vaste vivier de talents et d’une remarquable efficacité d’ingénierie.

🔥 Discussions brûlantes de la communauté

Du désengagement de React Native au retour au natif pur et à l’alternative KMP

L’un des sujets les plus débattus de la semaine sur Hacker News (1 275 points, 957 commentaires) a mis en lumière la tendance d’entreprises technologiques de premier plan, telles que Shopify, à revenir progressivement de React Native vers des architectures natives (Swift / Kotlin).

• Principal point de désaccord : Les partisans du retour au natif rappellent que la motivation initiale des frameworks UI multiplateformes — la compression des coûts salariaux — s’érode rapidement. En 2026, les modèles d’IA de génération de code conçoivent du code d’interface natif pour chaque plateforme avec une rapidité impressionnante, amortissant les coûts de développement d’interface. Associer KMP pour mutualiser la logique métier sous-jacente avec un rendu natif pur via Swift et Jetpack Compose apparaît comme la formule idéale pour concilier fluidité de l’expérience utilisateur et productivité de développement. Les contradicteurs répliquent avec vigueur : même si l’IA produit du code de vue en un instant, elle ne saurait remplacer les experts de domaine indispensables pour résoudre les anomalies de bas niveau du système. Des dysfonctionnements spécifiques comme les fuites de mémoire sous iOS ou les défauts de rendu sur des ROMs Android personnalisées exigent toujours des profils natifs expérimentés. Abandonner le multiplateforme au niveau de l’interface reporte immanquablement la charge humaine d’une double couverture de tests et de validation qualité sur l’équipe.

La riposte de Java moderne menace-t-elle « l’âge d’or » de Kotlin ?

Avec la généralisation des threads virtuels (Virtual Threads) et du filtrage par motif avancé de Java 21 à Java 27, la communauté JVM sur Reddit et Hacker News a relancé un débat animé, suscité par un article intitulé The Golden Age of Kotlin and Its Uncertain Future (48 points, 76 commentaires).

• Principal point de désaccord : Le camp pro-Java avance qu’avec la modernisation des parcs applicatifs vers des JDKs récents, bon nombre d’avantages autrefois réservés à Kotlin (les records face aux data classes, les threads virtuels suppléant les coroutines sur certains scénarios backend) sont désormais pris en charge nativement. Au vu de la dette technique et des contraintes d’interopérabilité, le retour sur investissement d’une adoption de Kotlin sur de nouveaux projets s’amenuise. Les fervents défenseurs de Kotlin ripostent en mettant en avant la cohérence architecturale et la complétude du langage. Ils rappellent trois atouts fondamentaux que Java peine à égaler : le cast intelligent (Smart Casts), la sécurité face aux pointeurs nuls dès la compilation (Null Safety) et les récepteurs d’extension. Le modèle d’évolution par correctifs successifs de Java, contraint par la rétrocompatibilité, ne pourra jamais éradiquer totalement les NullPointerExceptions de son système de types. Dès lors, Kotlin conserve une avance considérable en matière d’ergonomie pour le développeur et d’expressivité syntaxique.

📅 À suivre la semaine prochaine

Tandis que le cycle de la version Beta de Kotlin 2.5 s’accélère, il conviendra de surveiller de près les prochaines versions de compatibilité de kotlinx.coroutines et du framework Ktor, qui devraient être les premières à adopter le schéma de compilation séparée. Par ailleurs, l’équipe officielle a indiqué qu’elle dévoilerait très prochainement de nouveaux résultats de tests de performance pour le compilateur K2 ciblant WebAssembly (Wasm), un rendez-vous à ne pas manquer pour les développeurs web attentifs à l’écosystème Wasm.