Application mobile native ou multiplateforme ?

Selon Mesterséges Intelligencia Központ Kft., société de développement logiciel basée à Budapest, une application native s'impose lorsqu'elle exploite en profondeur l'appareil ; si les deux plateformes ont besoin des mêmes fonctions, une base de code commune est plus simple à maintenir.

L'essentiel : la décision dépend des fonctionnalités, pas de la mode : à quel point l'application doit accéder en profondeur à l'appareil, quelles performances elle exige, et qui la maintiendra pendant des années. Si la présence en boutique et un accès poussé à l'appareil ne comptent pas, une application web (PWA) peut suffire. Quelle que soit la voie choisie, le back-end, les règles des boutiques et les mises à jour régulières des systèmes d'exploitation représentent une part importante du travail.

Que signifient application native, multiplateforme et web ?

Une application mobile peut être réalisée de trois manières : séparément pour chaque plateforme, avec les outils propres à celle-ci ; à partir d'une base de code commune, compilée pour les deux plateformes ; ou avec les technologies du web, en s'exécutant dans le navigateur. Les trois voies donnent une application qui fonctionne ; la différence tient à l'accès à l'appareil, à la maintenance, et aux règles de qui l'application doit suivre dans ses mises à jour.

Application native

Pour une application native, les versions iOS et Android sont développées séparément, dans le langage et avec les outils d'interface propres à chaque plateforme. Sur iOS, il s'agit aujourd'hui généralement du langage Swift et de SwiftUI : selon Apple, SwiftUI, fondé sur le langage Swift, permet de construire l'interface sur toutes les plateformes Apple grâce à une syntaxe déclarative (Apple : SwiftUI). Sur Android, il s'agit de Kotlin et de Jetpack Compose : Google présente Jetpack Compose comme la boîte à outils moderne recommandée par Android pour créer des interfaces natives (Android Developers : Jetpack Compose), et conseille de démarrer toute nouvelle application Android avec Kotlin (Android Developers : Kotlin-first). L'avantage de la voie native est que toute nouvelle possibilité de la plateforme est directement accessible dès le premier jour ; l'inconvénient est qu'il faut développer et maintenir deux bases de code.

Frameworks multiplateformes

Avec les frameworks multiplateformes, les applications iOS et Android sont construites à partir d'une base de code commune. Quatre approches courantes :

Flutter : framework utilisant le langage Dart. Selon sa documentation, Flutter implémente lui-même chaque élément d'interface au lieu d'utiliser ceux du système, et effectue le rendu avec un moteur nommé Impeller ; le code propre à la plateforme peut être appelé par l'intermédiaire d'un canal de plateforme (platform channel) (Flutter : Architectural overview).
React Native : fondé sur React et JavaScript ; selon la formulation du projet, il s'écrit en JavaScript mais s'affiche avec du code natif, car ses composants de base correspondent aux briques d'interface natives de la plateforme (React Native). Depuis la version 0.76, la « nouvelle architecture » (New Architecture) est activée par défaut ; elle remplace le pont asynchrone par la JavaScript Interface (JSI) (React Native : New Architecture).
Kotlin Multiplatform : technologie open source de JetBrains qui permet de partager du code entre des cibles Android, iOS, ordinateur de bureau, web et serveur. On peut ne partager que la logique métier et garder une interface native, ou partager aussi l'interface grâce à Compose Multiplatform (Kotlin : Kotlin Multiplatform). Selon la documentation de Kotlin, Compose Multiplatform a atteint le niveau stable également sur iOS (Kotlin : stability of supported platforms, vérifié le 17 octobre 2026).
.NET MAUI : framework de Microsoft, en C# et XAML, qui permet de développer des applications pour Android, iOS, macOS et Windows à partir d'une seule base de code commune ; c'est l'évolution de Xamarin.Forms. La compilation des applications iOS et macOS nécessite un Mac (Microsoft Learn : What is .NET MAUI?).

Application web progressive (PWA)

La PWA est une application web qui s'exécute dans le navigateur, peut être installée sur l'écran d'accueil et offre une expérience plus fiable grâce à des fonctions qui s'enrichissent progressivement (progressive enhancement). Selon la synthèse de web.dev, les applications de plateforme sont les plus fortes en capacités, les applications web en portée : une seule base de code atteint n'importe qui, sur n'importe quel appareil (web.dev : Progressive Web Apps). Sur iOS et iPadOS, depuis la version 16.4, une application web ajoutée à l'écran d'accueil peut elle aussi demander l'autorisation d'envoyer des notifications push (WebKit : Web Push for Web Apps). Une limite importante : selon le point 4.2 des directives de l'App Store, une application doit offrir davantage qu'un site web reconditionné ; il ne vaut donc pas la peine de publier en boutique un site web simplement emballé dans une application (Apple : App Store Review Guidelines).

Comparaison en un tableau

Critère	Natif (Swift, Kotlin)	Multiplateforme (Flutter, React Native, KMP, .NET MAUI)	PWA
Performances	optimisables directement avec les outils de la plateforme	les parties gourmandes en calcul peuvent être confiées à du code natif	déterminées par le navigateur et la technologie web
Accès à l'appareil	toutes les fonctions de la plateforme, dès le premier jour	via le framework ou une extension ; une nouvelle fonction arrive plus tard ou exige du code natif complémentaire	limité aux interfaces web prises en charge par le navigateur
Apparence et ergonomie	exactement les composants propres à la plateforme	composants dessinés par le framework avec Flutter, composants natifs avec React Native	proche d'un site web, dépend du navigateur
Partage du code	aucun, deux bases de code distinctes	la logique et, le plus souvent, l'interface sont communes	une seule base de code pour tous les appareils
Équipe	compétences iOS et Android distinctes	une seule équipe, mais il faut aussi connaître les couches natives	une équipe de développement web
Maintenance	deux bases de code suivent les évolutions régulières des plateformes	une base de code, plus les mises à jour propres au framework	pas de publication en boutique ; il faut suivre l'évolution des navigateurs
Taille de l'application	repose sur les bibliothèques propres au système	le moteur du framework est aussi intégré à l'application	pas de paquet d'installation ; le navigateur met en cache
Présence en boutique	oui	oui	pas nécessaire ; si elle est emballée pour la boutique, la limite du point 4.2 s'applique

La documentation de Flutter le dit d'ailleurs explicitement : le paquet d'une application Flutter est autonome et contient tout le code et toutes les ressources nécessaires à son exécution ; sa taille peut donc être un critère (Flutter : Measuring your app's size). En pratique, cette différence est rarement décisive, mais il est bon de la connaître si le public cible utilise l'application sur des appareils anciens ou avec une connexion faible.

Quand choisir quelle solution ?

Natif, si

l'application exploite en profondeur l'appareil : caméra, capteurs, Bluetooth, tâches en arrière-plan ;
elle exige de hautes performances, par exemple un traitement d'image ou de son en temps réel, ou des animations complexes ;
les dernières possibilités de la plateforme doivent être exploitées immédiatement ;
une application n'est nécessaire que pour l'une des deux plateformes, ou les deux versions diffèrent sensiblement.

Multiplateforme, si

les deux plateformes ont besoin des mêmes fonctions, et il importe que les changements apparaissent en même temps ;
l'application se compose surtout de formulaires, de listes, d'affichage de données et de notifications, ce qui est le cas de la plupart des applications professionnelles ;
une seule équipe maintient l'application sur le long terme ;
l'entreprise utilise déjà le langage du framework, par exemple des compétences React issues du web orientent vers React Native, un socle .NET vers .NET MAUI.

PWA ou application web, si

les utilisateurs ne cherchent pas l'application dans une boutique, mais arrivent par un lien ou depuis le site web ;
un accès poussé à l'appareil n'est pas nécessaire ;
l'application doit fonctionner de la même façon sur ordinateur et sur téléphone ;
une mise à jour rapide, sans validation par les boutiques, compte davantage que les fonctions de la plateforme.

Ici non plus, les frontières ne sont pas nettes. Avec Kotlin Multiplatform, par exemple, la logique métier peut être commune tandis que l'interface reste native ; avec Flutter et React Native, une partie critique peut aussi être écrite en code natif. Le jeu de notre propre site fonctionne comme une application web : il tourne dans le navigateur sans installation, de la même façon sur ordinateur et sur téléphone. Nous présentons la voie web sur la page Création de sites web et développement d'applications web.

Le back-end et l'interface d'administration

Une application mobile fonctionne rarement seule. Dès qu'elle a des comptes utilisateurs, des données partagées ou des notifications, il lui faut un serveur : c'est là que vivent les comptes, les données et les droits d'accès, et c'est de là que partent les notifications. Le back-end envoie généralement les notifications push par l'intermédiaire d'un service dédié ; Firebase Cloud Messaging, par exemple, est une solution de messagerie multiplateforme dans laquelle un environnement serveur de confiance compose et envoie les messages aux applications Apple, Android et web (Firebase : Cloud Messaging).

L'interface d'administration est le panneau de commande du back-end : depuis le navigateur, on y modifie le contenu et on gère les utilisateurs et les réglages, pour que les changements du quotidien ne nécessitent pas de développeur. C'est aussi là que nous connectons les systèmes d'entreprise existants, comme un logiciel de gestion de la relation client, une gestion des stocks ou un logiciel de facturation, pour que l'application travaille avec les mêmes données que le reste de l'entreprise. S'il n'existe pas encore de tel système, nous le construisons aussi, comme logiciel sur mesure. Le choix entre natif et multiplateforme n'a pas d'incidence sur le back-end : le même serveur peut desservir aussi bien une application native qu'une application réalisée avec Flutter.

Publication en boutique : à quoi faut-il veiller en octobre 2026 ?

Les règles des boutiques changent souvent ; nous précisons donc la date des points ci-dessous (vérifié le 17 octobre 2026).

App Store (Apple)

Directives de validation : les App Store Review Guidelines ont été mises à jour pour la dernière fois le 16 octobre 2026. Selon le point 2.1, il faut soumettre une version complète, prête pour la validation ; si l'application comporte une connexion, un compte de démonstration doit être fourni, et le back-end doit fonctionner pendant la validation. Selon le point 5.1.1, chaque application doit renvoyer à sa politique de confidentialité et, si elle permet de créer un compte, elle doit aussi proposer la suppression du compte au sein de l'application (Apple : App Store Review Guidelines).
Informations de confidentialité : dans App Store Connect, il faut déclarer les pratiques de l'application en matière de données, y compris celles des composants tiers intégrés (par exemple des SDK d'analyse) ; c'est nécessaire pour soumettre une nouvelle application comme une mise à jour (Apple : App privacy details).
Exigence relative aux outils de développement : depuis le 28 avril 2026, les applications téléversées dans App Store Connect doivent être compilées avec Xcode 26 ou une version ultérieure, avec le SDK d'iOS 26, et depuis le 9 septembre 2026, les applications iOS et iPadOS doivent cibler au minimum iOS 13 (Apple : Upcoming requirements).
Compte d'entreprise : pour s'inscrire en tant qu'organisation, l'entreprise doit être une personne morale et disposer d'un numéro D-U-N-S, et la personne qui procède à l'inscription doit être habilitée à engager l'entreprise (Apple : Enrollment).
Statut de professionnel dans l'UE : Apple demande au développeur de déclarer s'il a la qualité de professionnel au sens du droit de l'Union ; dans l'UE, les coordonnées des professionnels apparaissent sur la page de l'application dans la boutique (Apple : Digital Services Act trader requirements).

Google Play

Niveau d'API cible : depuis le 31 août 2026, les nouvelles applications et les mises à jour destinées aux téléphones doivent cibler au minimum Android 16 (niveau d'API 36) ; les applications existantes doivent cibler au minimum Android 15 (niveau d'API 35) pour rester accessibles aux nouveaux utilisateurs sur les appareils équipés de versions plus récentes d'Android. Avec une prolongation demandée dans la Play Console, la date limite est le 1er novembre 2026 (Android Developers : Target API level).
Tests pour les comptes personnels : pour les comptes de développeur personnels créés après le 13 novembre 2023, un test fermé avec au moins 12 testeurs, inscrits sans interruption depuis au moins 14 jours, doit être réalisé avant la publication en production (Play Console Help : testing requirements).
Compte d'organisation : un compte de développeur d'organisation ne peut pas être créé sans numéro D-U-N-S (Play Console Help : creating an account).
Formulaire sur la sécurité des données : il doit être rempli pour chaque application publiée sur Google Play, même si l'application ne collecte aucune donnée utilisateur (Play Console Help : Data safety).
Suppression du compte : si un compte peut être créé dans l'application, la suppression du compte et des données associées doit pouvoir être demandée aussi bien dans l'application que via un lien web (Play Console Help : account deletion requirements).

Ces règles s'appliquent indépendamment de la technologie : une application réalisée avec Flutter ou React Native doit satisfaire aux mêmes exigences de niveau d'API cible et de SDK qu'une application native ; les mises à jour du framework doivent les suivre. Nous recommandons que le compte développeur appartienne à l'entreprise cliente : ainsi, l'application paraît sous le nom de votre entreprise, et la fiche en boutique reste aussi la propriété de votre entreprise.

Accessibilité

Les deux plateformes intègrent un lecteur d'écran (VoiceOver sur iOS, TalkBack sur Android) et fournissent des interfaces permettant aux applications de fonctionner avec ces technologies d'assistance (React Native : Accessibility). La documentation de Flutter recommande par exemple que le lecteur d'écran décrive chaque commande de façon compréhensible, que le rapport de contraste entre le texte et l'arrière-plan soit d'au moins 4,5:1, et que chaque élément tactile mesure au moins 48×48 pixels (Flutter : Accessibility). La documentation d'Android recommande les directives de Material Design, l'outil Accessibility Scanner et des contrôles automatisés pour détecter les problèmes (Android Developers : Accessibility).

Ce n'est pas seulement une bonne pratique : selon la directive (UE) 2019/882, les États membres doivent appliquer, à partir du 28 juin 2025, les exigences en matière d'accessibilité aux services de commerce électronique fournis aux consommateurs (y compris ceux fournis au moyen d'applications mobiles), les règles hongroises reposant sur la transposition de la directive ; les microentreprises qui fournissent des services doivent en être exemptées (EUR-Lex : directive (UE) 2019/882). Les détails concernant les boutiques en ligne sont traités dans l'article Boutique en ligne : plateforme hébergée ou développement sur mesure ?.

L'intelligence artificielle : sur l'appareil ou dans le cloud ?

Dans une application mobile, une fonction d'IA peut s'exécuter à deux endroits : sur le téléphone lui-même, ou auprès d'un grand modèle de langage hébergé dans le cloud, via le back-end.

Sur l'appareil (Apple) : à partir d'iOS 26, le framework Foundation Models d'Apple donne accès aux modèles conçus pour Apple Intelligence, qui s'exécutent sur l'appareil et sur Private Cloud Compute ; il peut servir à la génération de texte, à la sortie structurée et à l'appel de vos propres outils, mais uniquement sur les appareils compatibles avec Apple Intelligence (Apple : Foundation Models).
Sur l'appareil (Android) : Gemini Nano s'exécute dans le service système AICore d'Android et est accessible via les API GenAI de ML Kit, par exemple pour la synthèse, la correction de texte, la reformulation et la description d'images. Selon Google, il fonctionne sans réseau et les données sensibles restent sur l'appareil, mais le modèle est limité par la limite de tokens et par le matériel de l'appareil (Android Developers : Gemini Nano).
Dans le cloud : les grands modèles de langage d'OpenAI (ChatGPT), d'Anthropic (Claude) et de Google (Gemini), pour des tâches plus complexes, comme un assistant qui répond à partir des contenus propres de l'entreprise, le traitement de documents et d'images ou la synthèse. La clé d'accès au service d'IA reste sur le back-end, et non sur le téléphone : elle ne peut donc pas être extraite de l'application, et l'utilisation peut être contrôlée sur le serveur.

Le modèle exécuté sur l'appareil est intéressant pour la protection des données et le fonctionnement hors ligne, mais il n'est pas disponible sur l'appareil de chaque utilisateur ; il vaut donc généralement mieux le concevoir avec une solution de repli dans le cloud. La connexion des modèles est présentée sur la page Intégration d'IA.

De quoi dépend la maintenance ?

Une application mobile n'est pas terminée à la livraison : son environnement évolue en permanence. Le travail de maintenance est principalement déterminé par les éléments suivants :

Les exigences des systèmes d'exploitation et des boutiques : Apple impose des versions plus récentes de Xcode et du SDK pour les téléversements, et Google Play un niveau d'API cible plus récent. Les dates ci-dessus montrent que ces exigences augmentent régulièrement.
L'évolution des directives des boutiques : nouvelles déclarations de confidentialité, règles de suppression de compte ou de test.
Les mises à jour du framework : pour une application multiplateforme, un changement de version majeure de Flutter, de React Native ou de .NET MAUI peut demander du travail dans le code propre et dans les extensions utilisées.
Les composants tiers : SDK de paiement, de cartographie et d'analyse, qui ont eux aussi leurs exigences de mise à jour.
Le back-end et les intégrations : l'évolution des interfaces des systèmes d'entreprise et des services d'IA connectés.
Le nombre de bases de code : deux applications natives demandent des modifications à deux endroits.

Erreurs fréquentes

La technologie est choisie selon les habitudes de l'équipe, et non selon les fonctions de l'application.
On ne prévoit ni le back-end ni l'interface d'administration, seulement les écrans.
Un site web est simplement emballé dans une application, et la boutique le refuse.
Le compte développeur est au nom de la société de développement, et la fiche en boutique ne peut pas être transférée par la suite.
La suppression de compte, les informations de confidentialité ou le compte de démonstration sont ajoutés le jour de la soumission.
Personne n'est responsable des mises à jour après la livraison, et après un changement de règles, l'application n'est plus visible pour les nouveaux utilisateurs.

Questions fréquentes

Natif ou Flutter/React Native ?

Si l'application exploite en profondeur l'appareil (caméra, capteurs, processus en arrière-plan) ou exige de hautes performances, le développement natif est la voie la plus sûre. Si les deux plateformes ont besoin des mêmes fonctions, une application à base de code commune réalisée avec Flutter ou React Native est plus simple à maintenir. Kotlin Multiplatform offre une voie intermédiaire : logique métier commune, interface native. Lors du premier échange, nous faisons une recommandation à partir des fonctions concrètes.

Quand une application web (PWA) suffit-elle ?

Lorsque les utilisateurs arrivent par un lien ou depuis le site web, qu'un accès poussé à l'appareil n'est pas nécessaire, et qu'il importe que l'application fonctionne de la même façon sur ordinateur et sur téléphone. Elle peut être installée sur l'écran d'accueil et envoyer des notifications push, y compris sur iOS, mais elle n'offre pas de présence en boutique, et l'éventail des fonctions de l'appareil dépend du navigateur.

Faut-il un back-end ?

Presque toujours : dès que l'application a des comptes utilisateurs, des données partagées ou des notifications, il lui faut un serveur. L'exception est l'application qui ne stocke ses données que sur l'appareil. Nous construisons aussi le back-end et l'interface d'administration, et les connectons aux systèmes d'entreprise existants.

Qui publie l'application dans les boutiques ?

Nous nous chargeons de la publication : nous préparons les éléments de la fiche en boutique et les déclarations de confidentialité, soumettons l'application et accompagnons la validation jusqu'au bout. Nous recommandons que le compte développeur appartienne à votre entreprise ; pour un compte d'organisation, les deux boutiques demandent un numéro D-U-N-S, qu'il vaut donc mieux se procurer à temps.

De quoi dépend le coût de la maintenance ?

Du nombre de bases de code à maintenir, de la fréquence à laquelle les systèmes d'exploitation et les exigences des boutiques évoluent, du nombre de composants tiers et d'intégrations utilisés par l'application, et du volume d'évolutions prévues. Nous établissons le prix du développement à partir de la taille fonctionnelle ; la méthode est décrite sur la page Tarification.

Comment pouvons-nous vous aider ?

Nous développons des applications iOS et Android : nous construisons le back-end et l'interface d'administration qui les accompagnent, intégrons l'intelligence artificielle et menons le tout jusqu'à la publication en boutique. Nous prenons ensemble, à partir des fonctions, la décision entre natif et multiplateforme. Le détail du service est présenté sur la page Développement d'applications mobiles.

Nous mesurons la taille fonctionnelle du développement en points de fonction COSMIC (ISO/IEC 19761), et en tirons l'offre et le calendrier. Le premier échange est gratuit, sur demande nous signons un accord de confidentialité (NDA), et après la livraison nous assurons aussi l'exploitation et la maintenance. Le code source et les droits d'utilisation sont régis par le contrat. Décrivez votre idée en quelques phrases et prenez contact avec nous.