Vous avez deux applications mobiles, une en Swift pour iOS et une en Kotlin pour Android. Elles font la même chose, mais chaque fonctionnalité se développe, se teste et se corrige deux fois. La question finit par s’imposer : faut-il migrer cette application vers Kotlin Multiplatform, ou continuer à payer la duplication ?
Chez Playmoweb, Kotlin Multiplatform (KMP) est notre technologie de référence, sur les projets neufs comme sur les migrations. Nous mesurons une économie de 20 à 40 % par rapport à deux développements natifs séparés. Cet article vous donne les critères pour décider, notre méthode progressive, les durées, un tableau avant/après sur le coût d’une évolution et les pièges qui font échouer les migrations mal préparées.
Sommaire
La migration se justifie quand le coût de la duplication dépasse durablement le coût du chantier. Trois signaux reviennent chez les entreprises que nous accompagnons.
Deux équipes ou deux prestataires pour un seul produit. Chaque évolution passe par deux cadrages, deux développements, deux recettes et deux mises en production. Les applications divergent au fil du temps : un écran existe sur iOS mais pas sur Android, une règle de calcul diffère, et personne ne sait plus laquelle fait foi.
Des fonctionnalités largement dupliquées. Logique métier, appels réseau, gestion des données, synchronisation : si c’est l’essentiel de votre application, c’est autant de code écrit deux fois. C’est précisément ce que KMP permet de partager.
Un budget de maintenance qui pèse. Nous recommandons de prévoir 15 à 25 % du coût initial par an pour maintenir une application. Avec deux bases de code natives, ce poste est doublé : deux jeux de dépendances à mettre à jour, deux cycles d’OS à suivre, deux séries de bugs à traiter. Notre article sur le coût de maintenance d’une application mobile en 2026 détaille ce calcul.
À l’inverse, nous déconseillons la migration dans trois situations. Une application en fin de vie, remplacée à moins de deux ans, n’amortira jamais le chantier. Une application qui n’évolue presque plus (une ou deux mises à jour par an) ne génère pas assez de développement dupliqué pour que le partage rapporte. Et une application dont l’interface est très spécifique à une plateforme (widgets iOS avancés, Android Auto ou CarPlay, forte dépendance aux composants système) gardera une part native importante, ce qui réduit le gain sans le supprimer.
Le cas favorable se résume en une phrase : deux applications vivantes, aux fonctionnalités jumelles, avec au moins deux ans d’évolutions devant elles.
L’atout décisif de Kotlin Multiplatform pour une migration, c’est qu’on n’arrête rien. Contrairement à une réécriture en Flutter ou React Native, qui repart d’une page blanche sur les deux plateformes, KMP s’insère dans vos applications existantes : un module Kotlin partagé se compile en bibliothèque Android et en framework iOS, que l’application Swift consomme comme n’importe quelle dépendance. Nous avons comparé ces trois approches dans KMP vs Flutter vs React Native en 2026.
Concrètement, nous partageons par couches, de la moins visible à la plus visible.
La logique métier d’abord. Règles de calcul, validation, états, workflows : ce code n’a aucune dépendance à la plateforme et il est le plus rentable à unifier. C’est aussi celui où les divergences entre iOS et Android font le plus de dégâts.
Le réseau et les données ensuite. Appels API, sérialisation, cache, base locale, synchronisation hors ligne : l’écosystème KMP couvre ces besoins avec des bibliothèques matures, et c’est là que se cachent les bugs les plus coûteux à reproduire sur deux plateformes.
L’interface en dernier, et seulement si c’est pertinent. Avec Compose Multiplatform, l’UI peut aussi être partagée, écran par écran. Ce n’est pas obligatoire : beaucoup de nos clients conservent une UI native SwiftUI et Jetpack Compose au-dessus du socle partagé, ce qui garde une expérience strictement native sur chaque plateforme.
Pourquoi l’application Android est-elle souvent le point de départ ? Parce qu’elle est déjà écrite en Kotlin : une part significative de sa logique se déplace dans le module partagé avec des adaptations limitées, là où le code Swift doit être réécrit. Android devient le premier consommateur du module commun, iOS le rejoint dans un second temps. Ce séquençage réduit le risque et donne des résultats visibles rapidement.
Les durées ci-dessous sont des ordres de grandeur pour une application métier de taille moyenne, avec des évolutions qui continuent en parallèle.
1. Audit des deux bases de code (2 à 4 semaines). Nous cartographions les fonctionnalités, mesurons la part de logique dupliquée, listons les bibliothèques natives et identifions les écarts entre les deux applications. Cet audit technique produit un plan de migration chiffré.
2. Socle partagé et première tranche (1 à 2 mois). Création du module KMP, intégration dans les deux projets, chaîne de build, puis migration d’un premier périmètre à faible risque (l’authentification ou un module de calcul, par exemple). L’objectif : livrer sur les deux stores avec du code partagé dès cette phase.
3. Migration progressive de la logique et des données (3 à 9 mois selon la taille). Fonctionnalité par fonctionnalité, au rythme des évolutions : chaque nouvelle demande métier est développée dans le module partagé, ce qui finance une partie de la migration avec le budget d’évolution existant.
4. Partage de l’UI, optionnel (3 à 6 mois supplémentaires). Écran par écran avec Compose Multiplatform, en commençant par les écrans simples et souvent modifiés, en gardant natifs ceux qui dépendent fortement de la plateforme.
Au total, comptez 6 à 12 mois pour atteindre un socle partagé complet, sans jamais interrompre les livraisons. C’est la différence fondamentale avec une réécriture : le retour sur investissement commence dès la deuxième étape.
Prenons une évolution classique : un nouveau parcours métier avec un appel API, une règle de validation, une persistance locale et deux écrans. Voici la répartition du coût, en base 100 pour deux applications natives.
| Poste | Deux apps natives (Swift + Kotlin) | Socle KMP, UI native | Socle KMP + Compose Multiplatform |
|---|---|---|---|
| Cadrage et spécifications | 2, souvent désynchronisés | 1 | 1 |
| Logique métier | 2 fois | 1 fois | 1 fois |
| Réseau, données, cache | 2 fois | 1 fois | 1 fois |
| Interface | 2 fois | 2 fois | 1 fois, ajustements par plateforme |
| Tests | 2 campagnes complètes | 1 campagne, vérifications par plateforme | 1 campagne, vérifications par plateforme |
| Correction des écarts iOS/Android | Fréquente | Rare sur la logique | Rare |
| Coût total (base 100) | 100 | 70 à 80 | 60 à 70 |
Ces ordres de grandeur correspondent à l’économie de 20 à 40 % que nous observons par rapport à deux développements natifs séparés. Le gain est le plus fort sur les fonctionnalités riches en logique et en données, le plus faible sur les écrans purement visuels. S’y ajoute un bénéfice moins visible : un seul comportement métier sur les deux plateformes, donc moins de tickets « ça marche sur iOS mais pas sur Android ».
Important : ces chiffres portent sur les évolutions après migration. Le chantier lui-même est un investissement, à mettre en regard du volume d’évolutions prévu sur les deux à trois prochaines années.
La différence entre une migration qui aboutit et une qui s’enlise tient rarement à la technologie, presque toujours à la préparation.
La technologie est-elle assez mûre pour engager une migration ? En septembre 2026, la réponse est oui, avec quelques nuances.
Kotlin Multiplatform est stable depuis novembre 2023. Compose Multiplatform pour iOS est stable depuis mai 2025 (version 1.8.0), et les versions 1.10 (janvier 2026) puis 1.11 (mai 2026) ont surtout travaillé l’expérience iOS : rendu concurrent par défaut, rechargement à chaud stable, et une saisie de texte native encore expérimentale, que la feuille de route JetBrains prévoit de rendre par défaut. Le web via Kotlin/Wasm est en bêta et vise le stable.
Côté interopérabilité, Swift Export, qui expose le code Kotlin directement en Swift sans passer par Objective-C, est en alpha et doit passer en bêta selon la feuille de route mise à jour en août 2026. Bonne nouvelle pour le point faible historique des migrations : l’intégration iOS.
Côté adoption, les enquêtes annuelles de JetBrains indiquent que l’usage de Kotlin Multiplatform est passé de 7 % en 2024 à 18 % en 2025. Google soutient officiellement la technologie et l’utilise dans Workspace, avec des performances et une taille d’application iOS jugées équivalentes au natif. Netflix, McDonald’s, Cash App, Forbes ou Duolingo l’utilisent en production, et Philips indique avoir divisé par deux le temps de développement de ses fonctionnalités sur les deux plateformes.
Notre lecture : le socle partagé (logique, réseau, données) est mûr sans réserve, et c’est lui qui porte l’essentiel de l’économie. L’UI partagée sur iOS est en production chez de grands éditeurs, mais quelques sujets (saisie de texte native, débogage dans Xcode) se finalisent encore. Une raison de plus pour la traiter en dernier.
Si vous répondez oui aux deux premières questions et que la troisième vous fait grimacer, un audit des deux bases de code est la prochaine étape : état des lieux, périmètre de première tranche et budget, avant tout engagement. Pour aller plus loin, voyez notre approche du développement d’applications mobiles et les principes du code commun avec Kotlin Multiplatform.
Vous avez deux applications natives et vous payez chaque évolution deux fois ? Contactez-nous pour un échange gratuit et sans engagement : nous évaluons ensemble si une migration vers Kotlin Multiplatform a du sens pour votre produit. 👉 playmoweb.com/nous-contacter