Application native ou cross-platform : comment choisir avant de demander un devis
Choisissez une application native quand l’expérience dépend fortement d’une plateforme, d’une intégration système profonde, de performances prévisibles ou d’une équipe déjà spécialisée. Choisissez une approche cross-platform quand iPhone et Android doivent partager la majorité du produit, que les différences natives restent limitées et que votre équipe peut maintenir la couche commune sans masquer les particularités de chaque système.
Le bon choix ne vient pas d’un duel abstrait entre Swift, Kotlin, Flutter ou React Native. Il vient de votre parcours principal, de vos appareils, de vos intégrations, de votre calendrier et de l’équipe qui maintiendra le produit après la sortie.
Commencez par les risques du produit
Listez les fonctions qui rendent votre app difficile : caméra en temps réel, audio, Bluetooth, traitement local, synchronisation hors ligne, widgets, extensions de partage, paiements, notifications, tâches en arrière-plan, accessibilité et animations complexes. Ajoutez les appareils et versions système que vous devez réellement prendre en charge.
Une interface de formulaire avec une API simple laisse plusieurs options ouvertes. Une app qui dépend d’une extension iOS, d’un pipeline vidéo à faible latence et d’un comportement précis en arrière-plan demande une validation technique avant le devis.
Quand le natif devient le choix le plus clair
- vous lancez sur une seule plateforme ;
- le produit utilise rapidement les nouvelles API système ;
- la performance, la mémoire ou la latence font partie de la valeur ;
- l’équipe maîtrise déjà Swift et iOS, ou Kotlin et Android ;
- vous voulez limiter les couches entre votre code et le système.
Le natif ne garantit pas un bon produit. Il donne un accès direct aux outils de la plateforme et réduit certains compromis d’intégration. Vous payez en revanche deux implémentations si vous devez livrer iOS et Android.
Quand le cross-platform crée un vrai avantage
- les deux plateformes partagent le même parcours et le même modèle de données ;
- la majorité des écrans utilise des composants classiques ;
- une petite équipe doit livrer et maintenir les deux versions ;
- vous acceptez d’écrire du code natif pour les intégrations qui l’exigent ;
- vous testez l’app sur de vrais appareils des deux écosystèmes.
Cross-platform ne signifie pas « un seul code sans différence ». Flutter documente ses intégrations de plateforme, React Native utilise des modules natifs, et Kotlin Multiplatform partage du code tout en laissant l’interface ou certaines capacités natives. Le devis doit inclure ces frontières.
Comparez le coût de maintenance, pas seulement le premier build
| Question | Natif | Cross-platform |
|---|---|---|
| Deux interfaces très différentes | Plus direct | Partage moins utile |
| Parcours presque identique | Deux implémentations | Partage potentiellement fort |
| Nouvelle API système | Accès immédiat | Dépend du framework ou d’un module |
| Compétence de l’équipe | Deux spécialités possibles | Une équipe commune, plus les bords natifs |
| Tests | Par plateforme | Toujours par plateforme |
Demandez qui mettra à jour les dépendances, traitera les changements Apple et Google, corrigera une régression propre à un appareil et surveillera les performances. Une base partagée peut réduire du travail, mais elle crée aussi une dépendance au framework et à ses plugins.
Faites un prototype sur le point risqué
Avant de signer un périmètre complet, testez la fonction qui peut invalider l’architecture. Mesurez la caméra, l’audio, le Bluetooth, le hors-ligne ou l’extension système sur les appareils cibles. Un prototype technique de quelques écrans apprend plus qu’un débat général sur les frameworks.
