Répondez à 12 questions sur votre produit, votre équipe et vos contraintes. Vous obtenez une recommandation argumentée, une comparaison du coût et de la première version avec le natif, et les points de vigilance.
Trouver ma stack
L’outil montre quelle stack correspond le mieux à vos réponses et ce qui a fait pencher la balance. Le coût et les délais sont relatifs au natif et tirés de nos articles publiés : ce sont des repères de planification, pas un devis. Nous développons sur les cinq stacks, donc le résultat suit vos réponses, pas nos préférences.
Chaque réponse ajoute des points à certaines stacks et en retire à d’autres, de −2 à +2. Les points sont multipliés par le poids de la question (1 à 3), puis additionnés. Le total est ramené à un score d’adéquation de 0 à 100. Les réponses « Je ne sais pas » n’ajoutent rien et réduisent la confiance ; elles sont exclues de l’échelle pour ne pas tirer les scores vers le milieu.
Certaines réponses fixent des limites strictes. Si l’app a besoin du Bluetooth en arrière-plan, de données de santé, de widgets, du NFC, de CarPlay ou d’une caméra sur mesure, la PWA est plafonnée à 20 : une web app n’accède pas à ces fonctions comme une app native. Les limites plus souples retirent quelques points et apparaissent comme points de vigilance.
La confiance est élevée quand la stack en tête a 12 points d’avance ou plus et que vous étiez sûr de presque toutes vos réponses. Quand les deux premières sont à moins de 6 points, l’outil le signale : vous avez deux options proches, et le choix dépend de votre équipe et de votre roadmap.
| Question | Poids |
|---|---|
| Quelles plateformes au lancement ? | 3 |
| De quel type de produit s’agit-il ? | 2 |
| Quel rendu attendez-vous pour l’interface ? | 2 |
| De quelles fonctions de l’appareil l’application a-t-elle besoin ? | 3 |
| Comment l’application doit-elle fonctionner sans connexion ? | 1 |
| Exigences de sécurité et de conformité | 1 |
| Quelles compétences votre équipe possède-t-elle déjà ? | 3 |
| De quoi disposez-vous déjà ? | 2 |
| Comment les utilisateurs obtiendront-ils l’application ? | 2 |
| Quand vous faut-il la première version ? | 2 |
| Qu’est-ce qui compte le plus pour le budget ? | 2 |
| Combien de temps l’application doit-elle vivre sans refonte ? | 1 |
| Stack | Quand | Effet |
|---|---|---|
| PWA | L’app a besoin du Bluetooth en arrière-plan, de RA ou d’une caméra sur mesure, de données de santé, de widgets ou d’apps montre, du NFC ou de CarPlay | plafonné à 20 · Inadaptée : une PWA n’accède pas à cette fonction de l’appareil comme une app native. |
| PWA | L’app doit être sur l’App Store et Google Play | −10 points · Une publication en store nécessite un wrapper (Capacitor ou Trusted Web Activity). |
| PWA | Offline-first avec synchronisation | −8 points · Sur iOS, le stockage hors ligne des web apps est limité et peut être effacé par le système. |
| Natif iOS + Android | Première version sous 3 mois et coût le plus bas | −10 points · Deux bases de code collent rarement à un brief de 3 mois au coût le plus bas. |
| Kotlin Multiplatform | Pas de compétences Kotlin dans l’équipe et pas de prestataire | −8 points · Nécessite des compétences Kotlin dans l’équipe. |
| Kotlin Multiplatform | Première version sous 3 mois | −6 points · Écosystème plus jeune : prévoyez du temps en plus. |
| Flutter | Le web est nécessaire et le produit est du contenu ou du média | −8 points · Flutter sur le web est moins adapté au contenu porté par le référencement. |
| React Native | Produit très graphique ou proche du jeu | −8 points · Pour une UI à rendu intensif, Flutter ou le natif conviennent mieux. |
Flutter / Dart : une base de code pour iOS et Android, plus web et desktop
Le toolkit UI de Google, en Dart. Il dessine lui-même chaque pixel : un design de marque sur mesure et ses animations ont le même rendu sur iOS et Android. Une équipe, une base de code, et des builds web et desktop à partir du même code. Les contreparties : un vivier de recrutement plus petit qu’en JavaScript, et les nouvelles fonctions des plateformes arrivent via des plugins, parfois avec du retard.
React Native (Expo inclus) : JavaScript / TypeScript, composants UI natifs
Le framework de Meta en JavaScript ou TypeScript, avec Expo comme outillage par défaut et la nouvelle architecture activée par défaut. Il affiche de vrais composants de la plateforme : les écrans standards semblent à leur place sur chaque OS. Il excelle quand votre équipe écrit déjà du React ou quand l’app partage de la logique avec un produit web. Les graphismes sur mesure lourds sont son point faible.
Swift / SwiftUI pour iOS et Kotlin / Compose pour Android : deux bases de code
Deux applications, chacune dans le langage et le toolkit UI de sa plateforme. Vous profitez de chaque nouvelle fonction de l’OS dès le premier jour, du meilleur accès au matériel (Bluetooth, données de santé, widgets, caméra) et du ressenti le plus familier. Le prix : deux bases de code, soit environ 1,4 à 1,8 fois le coût de développement d’une app cross-platform, et deux équipes à synchroniser.
Kotlin Multiplatform : logique métier partagée, UI native ou Compose Multiplatform
Partage la logique métier, le réseau et les données en Kotlin, tandis que chaque plateforme garde une UI native ou utilise Compose Multiplatform pour des écrans communs. Convient aux équipes qui ont déjà des apps natives ou des ingénieurs Android et veulent moins de duplication sans tout réécrire. L’écosystème est plus jeune : prévoyez du temps pour l’outillage et l’intégration iOS.
Progressive Web App, éventuellement packagée avec Capacitor ou TWA pour les stores
Une application web qui s’installe sur l’écran d’accueil et fonctionne hors ligne dans les limites du navigateur. C’est la voie la moins chère et la plus rapide quand un lien ou un QR code suffit et que l’app se compose surtout de contenu et de formulaires. Sur iOS, les notifications push, les tâches en arrière-plan, le stockage et l’accès à l’appareil sont plus limités que dans une app native, et une publication en store nécessite un wrapper.
| Source | Ce que nous en retenons |
|---|---|
| Développement natif vs cross-platform en 2026 | Le cross-platform coûte 55 à 70 % du natif ; la première version sort 30 à 40 % plus vite ; le natif demande 8 à 14 semaines |
| Web app vs natif vs PWA en 2026 | Une PWA demande 5 à 8 semaines et 40 à 100 k$, contre 80 à 250 k$ pour le natif ; limites des PWA sur iOS |
| Coût de maintenance d’une app mobile en 2026 | La maintenance représente 15 à 25 % du coût de développement par an, et 30 à 50 % la première année ; le cross-platform est 20 à 35 % moins cher à maintenir |
| React Native vs Flutter en 2026 | Où chaque framework est pertinent, et où intervient Kotlin Multiplatform |
Les valeurs pour Kotlin Multiplatform et PWA sont nos estimations entre les chiffres publiés ; elles doivent encore être validées par notre lead mobile.
Cela dépend de votre équipe et de votre interface. React Native convient aux équipes qui écrivent déjà du React ou partagent du code avec une app web ; Flutter convient à un design de marque sur mesure et aux animations. L’outil pèse les deux selon vos réponses, et notre comparatif React Native vs Flutter va plus loin.
Quand l’app dépend de fonctions de la plateforme comme le Bluetooth en arrière-plan, les données de santé, les widgets, CarPlay ou une caméra sur mesure, quand elle doit se comporter exactement comme l’OS, ou quand une sécurité stricte et une longue durée de vie comptent plus que le coût de développement. C’est aussi le choix naturel pour une seule plateforme.
Kotlin Multiplatform partage la logique métier entre iOS et Android, chaque plateforme gardant une interface native. Il convient aux équipes qui ont déjà des apps natives ou des ingénieurs Android et veulent moins de code dupliqué sans tout réécrire. L’écosystème est plus jeune : prévoyez du temps en plus.
Souvent oui pour du contenu, des formulaires et des outils internes ouverts depuis un lien. Sur iOS, les web apps sont plus limitées pour les notifications push, les tâches en arrière-plan, le stockage et l’accès à l’appareil, et dans l’UE la prise en charge des web apps sur l’écran d’accueil iOS a évolué avec le Digital Markets Act. Vérifiez le comportement actuel avant de vous engager.
Flutter et React Native coûtent en général 55 à 70 % de deux apps natives, soit 30 à 45 % d’économie. Plus l’app a besoin de code spécifique à la plateforme, plus l’économie diminue. L’outil ajuste ce chiffre à vos réponses et affiche la fourchette.
D’après nos projets : le natif demande 8 à 14 semaines, Flutter et React Native sont 30 à 40 % plus rapides, soit environ 5 à 9 semaines, et une PWA demande 5 à 8 semaines. Kotlin Multiplatform se situe entre les deux. Le périmètre influe davantage sur ces chiffres que la stack.
Chaque réponse ajoute ou retire des points à chaque stack, pondérés selon l’importance de la question. Les limites strictes plafonnent une stack qui ne peut pas satisfaire une exigence. La section « Comment l’outil décide » ci-dessus liste chaque question, chaque poids et chaque limite.
Oui. Nous développons en Flutter, React Native, natif Swift et Kotlin, Kotlin Multiplatform et en web apps. C’est pourquoi l’outil montre son raisonnement au lieu de pousser une option.
Une base de code pour iOS, Android et le web.
Des apps mobiles pour les équipes qui travaillent déjà en React.
Apps natives en Swift et SwiftUI.
Apps natives en Kotlin et Jetpack Compose.
Du premier prototype à la publication en store et au support.