Kotlin Multiplatform permet de partager une partie du code entre Android, iOS, web, desktop et serveur, sans imposer une interface unique partout. Pour un décideur, l’intérêt est clair : réduire les doublons, stabiliser la logique métier et rapprocher les équipes, tout en gardant une expérience native là où elle compte. Ce n’est pas une baguette magique, mais c’est souvent un meilleur compromis qu’une refonte mobile entièrement séparée.
Kotlin Multiplatform : ce que ça change vraiment pour votre projet
Kotlin Multiplatform, souvent abrégé KMP, est une technologie open source portée par JetBrains. Elle sert à écrire une logique commune en Kotlin, puis à l’utiliser sur plusieurs plateformes : Android, iOS, desktop, web ou serveur. Le mot important ici est logique. On ne parle pas forcément de copier-coller toute l’application.
Dans une application de réservation, par exemple, les règles de calcul du prix, la gestion du compte utilisateur, l’accès aux données et certaines validations peuvent être partagés. L’écran iPhone reste construit avec les outils Apple, l’écran Android avec les outils Android, si c’est le meilleur choix. Résultat : moins de divergences fonctionnelles entre les versions, moins de corrections en double, et une base plus cohérente.
Depuis Kotlin 1.9.20, publié le 1er novembre 2023, Kotlin Multiplatform est considéré comme stable par l’écosystème Kotlin. En 2026, la documentation Kotlin affiche la ligne stable 2.4, avec Kotlin 2.4.0 publié le 3 juin 2026. Ce niveau de maturité ne supprime pas les arbitrages techniques, mais il change la discussion : KMP n’est plus seulement une option de laboratoire.
Pour situer KMP parmi les options mobiles, vous pouvez aussi comparer les approches avec un panorama des frameworks utilisés pour créer des applications mobiles. La question n’est pas seulement “quelle techno est moderne ?”, mais “quelle partie du produit mérite d’être mutualisée ?”.
Pourquoi JetBrains parle d’une organisation d’ingénierie unifiée
En avril 2026, JetBrains a relayé, avec Touchlab, l’idée de Kotlin Multiplatform comme plateforme stratégique permettant une organisation d’ingénierie unifiée. La formule peut sembler abstraite. Elle décrit pourtant un problème très concret : deux équipes mobiles qui réécrivent les mêmes règles, chacune dans son langage, finissent souvent par livrer deux produits légèrement différents.
Avec KMP, les développeurs Android et iOS peuvent partager un socle commun. Les discussions portent davantage sur la règle métier elle-même que sur sa traduction séparée dans Swift et Kotlin. Selon l’enquête KMP Survey Q2 2024 citée par JetBrains, 55 % des utilisateurs déclarent une meilleure collaboration après adoption de KMP, et 65 % une amélioration de la performance et de la qualité. Ces chiffres restent déclaratifs, mais ils correspondent à un vrai signal de marché.
Sur les projets que nous menons, nous voyons souvent le même symptôme avant refonte : l’application Android valide un cas limite, l’application iOS le refuse, et personne ne sait plus quelle version reflète la règle officielle. Une couche partagée oblige à clarifier cette règle. C’est moins spectaculaire qu’une nouvelle interface, mais beaucoup plus rentable sur la durée.
Google a aussi renforcé le cadre. En 2025, la documentation Android indique que les bibliothèques Jetpack officiellement prises en charge pour les plateformes KMP Android et iOS conservent les mêmes exigences de qualité et de compatibilité. L’Android Gradle Plugin a également reçu un support officiel de Kotlin Multiplatform comme cible de plateforme pour le code partagé. Pour un dirigeant, cela signifie surtout moins de solitude technique qu’il y a quelques années.
Quels blocs partager, et lesquels garder natifs ?
Le piège classique consiste à vouloir tout partager trop tôt. KMP autorise plusieurs niveaux : partager seulement la logique métier, partager des modules d’accès aux données, ou aller plus loin avec une interface commune via Compose Multiplatform. Compose Multiplatform est un framework d’interface (la partie visible de l’application) qui permet d’écrire des écrans pour plusieurs plateformes avec une logique proche.
Honnêtement, partager l’interface ne se justifie que si votre produit a des écrans relativement standards, une forte contrainte budgétaire ou une équipe déjà très à l’aise avec Compose. Pour une application grand public où l’expérience iOS doit suivre finement les usages Apple, mieux vaut souvent garder l’UI native et mutualiser le reste. C’est moins vendeur sur une slide, mais plus sûr.
Voici une lecture simple des choix possibles :
- Logique métier partagée : bon compromis pour les PME, car les règles sensibles sont centralisées sans bouleverser toute l’expérience utilisateur.
- Accès aux données partagé : utile quand l’application dialogue avec les mêmes API (interfaces de connexion entre logiciels) et doit gérer cache, erreurs réseau ou authentification de façon identique.
- Interface partagée avec Compose Multiplatform : intéressante pour des outils internes, des MVP ou certains produits B2B, mais à valider écran par écran.
- Tout natif séparé : reste pertinent pour une app très orientée expérience plateforme, ou quand les équipes iOS et Android sont déjà robustes et bien synchronisées.
Cette logique rejoint les arbitrages plus larges entre mobile, web et produit hybride. Pour cadrer le canal prioritaire avant de choisir la technologie, un comparatif entre développement mobile et web en 2026 aide souvent à éviter une décision prématurée.
Coûts, délais et dette technique : l’arbitrage réel
Kotlin Multiplatform ne divise pas mécaniquement le budget par deux. C’est une erreur de pilotage fréquente. Vous payez toujours la conception produit, l’UX, les écrans natifs si vous les conservez, les tests, la publication App Store et Google Play, la sécurité, le backend et la maintenance.
Le gain apparaît surtout sur les fonctionnalités qui auraient été recodées deux fois. Pour une application mobile professionnelle avec Android et iOS, un budget français réaliste démarre souvent autour de 40 000 à 80 000 € pour un premier produit sérieux, et peut dépasser 150 000 € si le périmètre inclut comptes utilisateurs, paiement, synchronisation hors ligne, back-office et sécurité avancée. À ce budget, mieux vaut économiser sur les doublons invisibles plutôt que sur les tests.
JetBrains et Touchlab évoquent aussi, dans leur publication 2026, une baisse typique de 30 à 50 % du temps d’onboarding quand une seule couche logique remplace plusieurs implémentations séparées. À prendre comme un ordre de grandeur, pas comme une garantie contractuelle. L’effet dépend beaucoup de la documentation, de l’architecture et du niveau de l’équipe.
| Approche | Ce qui est partagé | Délai indicatif pour un MVP mobile | Budget France indicatif | Risque principal |
|---|---|---|---|---|
| Natif séparé iOS / Android | Peu ou pas de code | 3 à 6 mois | 50 000 à 120 000 € | Fonctions divergentes et maintenance double |
| Kotlin Multiplatform logique partagée | Règles métier, données, API | 3 à 6 mois | 45 000 à 110 000 € | Architecture initiale à cadrer avec soin |
| KMP avec UI partagée | Logique et certains écrans | 2,5 à 5 mois | 40 000 à 100 000 € | Écarts d’expérience avec les habitudes iOS/Android |
| Application web mobile | Une base web | 2 à 4 mois | 25 000 à 70 000 € | Accès limité à certaines capacités natives |
Ces fourchettes varient selon les prestataires, la qualité attendue et les contraintes métier. Elles ont surtout une utilité : montrer que KMP est un levier de coût total de possession, pas seulement un moyen de réduire le devis de départ.
Les risques que les non-techniciens sous-estiment
Le premier risque est l’effet “nouvelle stack” mal accompagné. Kotlin Multiplatform demande une vraie compétence d’architecture : séparation des couches, gestion des dépendances, tests partagés, compilation pour plusieurs cibles. Si l’équipe apprend tout en produisant une application critique, le planning devient fragile.
Autre point discret : le tooling. JetBrains a annoncé en 2025 un plugin Kotlin Multiplatform pour IntelliJ IDEA 2025.1.1.1 et Android Studio Narwhal 2025.1.1, disponible sur macOS au lancement, avec Windows et Linux prévus. Ce genre de détail compte si votre équipe travaille sur des environnements hétérogènes. Un outil non stabilisé dans le quotidien peut coûter cher en friction.
La sécurité et le RGPD ne disparaissent pas parce que le code est partagé. Une couche commune peut même propager plus vite une erreur si elle est mal conçue. Authentification, chiffrement local, gestion des consentements, minimisation des données : ces sujets doivent être pensés dès le départ, notamment pour une application manipulant des données personnelles. Sur ce point, la démarche privacy by design appliquée au mobile reste une bonne grille de lecture.
Côté agence, le réflexe est de faire un audit court avant de choisir KMP : quelles règles sont communes, quelles interfaces doivent rester natives, quelles librairies sont déjà utilisées, quelle équipe maintiendra le produit dans deux ans. Une semaine de cadrage peut éviter trois mois de compromis subis.
Quand Kotlin Multiplatform est le bon choix, et quand l’éviter
Kotlin Multiplatform devient intéressant quand votre produit doit vivre longtemps sur plusieurs plateformes avec des règles identiques. Banque, assurance, santé, logistique, marketplace B2B, outil métier connecté : dès que la logique est riche, les doublons coûtent cher. Le bénéfice augmente encore si Android est déjà important dans votre organisation, car Kotlin y est largement installé.
À l’inverse, KMP n’est pas toujours le meilleur départ pour un prototype très incertain. Si votre priorité est de tester une proposition de valeur en quatre semaines, une application web mobile ou un no-code bien choisi peut suffire. La solution évidente, “faire tout de suite une vraie app iOS et Android”, est parfois la mauvaise : elle consomme du budget avant d’avoir validé l’usage.
Pour comparer les options de production d’un premier produit, un guide sur les outils de développement d’application mobile donne un complément utile. Et si votre projet exige une forte performance native, capteurs, notifications, hors ligne ou intégration système, les enjeux d’ingénierie mobile iOS et Android doivent être analysés avant le choix final.
Une bonne décision KMP commence rarement par “on veut Kotlin”. Elle commence par une cartographie : quelles fonctions changent souvent, lesquelles doivent être identiques partout, quelles erreurs coûtent cher, quelles compétences existent déjà. Ensuite seulement, la technologie devient un accélérateur.
Cadrer ce type de projet en amont évite la plupart des mauvaises surprises : budget mal placé, architecture trop ambitieuse, ou promesse de mutualisation irréaliste. C’est souvent là qu’un regard extérieur fait gagner du temps, surtout quand le projet engage plusieurs années de maintenance.
FAQ sur Kotlin Multiplatform
Kotlin Multiplatform remplace-t-il Flutter ou React Native ?
Pas exactement. Flutter et React Native visent souvent une application complète avec interface partagée, tandis que Kotlin Multiplatform permet aussi de partager seulement la logique et de garder des interfaces natives iOS et Android.
Kotlin Multiplatform est-il stable en 2026 ?
Oui, KMP est stable depuis Kotlin 1.9.20 en 2023, et Kotlin 2.4.0 est la ligne stable documentée en juin 2026. Certaines briques de l’écosystème peuvent toutefois évoluer, d’où l’intérêt de vérifier les bibliothèques utilisées.
Combien coûte une application avec Kotlin Multiplatform ?
Pour un MVP mobile sérieux en France, comptez souvent entre 45 000 et 110 000 € selon le périmètre. Le gain se mesure surtout sur la maintenance et les évolutions, pas uniquement sur le devis initial.
Peut-on utiliser Kotlin Multiplatform pour iOS ?
Oui. KMP permet de partager du code avec iOS tout en conservant une interface native Swift ou SwiftUI si nécessaire. C’est précisément l’un de ses intérêts pour les produits Android et iOS.
Faut-il choisir KMP pour une PME ?
Oui si l’application doit durer, évoluer sur plusieurs plateformes et respecter des règles métier communes. Pour un test de marché très rapide, une option web ou un prototype plus simple peut être plus raisonnable.