Application mobile native ou multiplateforme : comment choisir en 2026 ?

Pourquoi les applications mobiles se sont construites en multiplateforme

Le coût de construire chaque fonction deux fois

Une application mobile vit sur deux systèmes, iOS et Android, qui n'utilisent ni le même langage ni les mêmes outils. Apple fait écrire les applications en Swift, Google en Kotlin, et une application dite native existe donc en deux versions, écrites chacune de son côté, qui doivent faire exactement la même chose. Chaque nouvelle fonction se développe deux fois et se teste deux fois. Les deux versions finissent aussi par s'écarter dès que l'une prend du retard sur l'autre, et l'entreprise passe alors une partie de son temps à rattraper ces écarts plutôt qu'à faire avancer son produit. Pour un projet qui lance sa première application, ce doublement pèse sur le budget, sur les délais et sur le nombre de personnes qu'il faut réunir.

React Native et Flutter, une seule base de code pour iOS et Android

Les frameworks multiplateformes répondent à ce coût. React Native, publié par Facebook en 2015, et Flutter, lancé par Google en 2018, permettent d'écrire une seule application qui fonctionne sur les deux systèmes. Le premier s'appuie sur JavaScript et sur l'écosystème React, ce qui ouvre le mobile aux développeurs web. Le second utilise son propre langage, Dart, et son propre moteur d'affichage. Dans les deux cas, l'entreprise accepte une couche supplémentaire entre son code et le téléphone, avec un peu de poids en plus et une certaine distance avec les fonctions propres à chaque plateforme, en échange d'une base de code unique. Pendant près de dix ans, une grande partie du marché a jugé cet échange raisonnable, des startups jusqu'aux grands groupes.

Le pari de Shopify sur React Native en 2020

Shopify est devenu l'exemple le plus cité de ce choix. En 2020, l'entreprise a annoncé qu'elle passait entièrement à React Native, puis a migré ses applications existantes au fil des années. Elle avançait trois raisons, ne plus construire chaque fonction deux fois, permettre à ses développeurs de travailler sur toute la pile technique, et passer moins de temps à rattraper les écarts entre iOS et Android. Six ans plus tard, son responsable mobile estime que le pari a tenu ses promesses sur ces trois points. Les trois raisons portent pourtant sur un même coût, celui de construire deux fois, et c'est cette variable que les agents IA ont fait bouger depuis.

Ce que Shopify change en revenant au natif

Le 10 septembre 2026, Shopify a publié deux billets sur son blog technique, l'un pour expliquer sa décision de revenir à Swift et à Kotlin, l'autre pour détailler la migration de son application Shop. L'annonce a beaucoup circulé, parce qu'elle venait de l'entreprise qui avait le plus défendu React Native et parce qu'elle attribuait ce revirement à l'IA. Lue de près, elle dit pourtant quelque chose de plus mesuré que ce qu'en ont retenu la plupart des commentaires.

L'hypothèse de 2020 que les agents IA ont fait bouger

Shopify ne reproche rien à React Native. Ses applications étaient rapides et stables, et l'entreprise le rappelle. Le changement porte sur le coût d'écrire la même fonction deux fois. Ses développeurs utilisent des modèles de langage depuis 2021, et ces modèles savent désormais implémenter une fonction sur Android en prenant la version iOS comme référence, et inversement. Ils aident aussi un développeur à travailler dans un langage qui n'est pas le sien, et permettent de garder les deux plateformes alignées au moyen de spécifications, de tests et de points de contrôle communs.

L'entreprise reste prudente sur la portée de ce changement. Elle écrit que le natif implique toujours de construire et de maintenir deux logiciels, que ce coût n'a pas disparu, et qu'il a seulement cessé d'être le facteur décisif qu'il était en 2020. Une seule hypothèse a donc bougé, celle qui faisait pencher la balance vers le multiplateforme, tandis que les avantages du natif, une plus grande proximité avec chaque système et ses outils, sont restés en place.

Les gains mesurés sur l'application Shop

Shop, l'application d'achat de Shopify, est la première à avoir été reconstruite. Selon l'entreprise, il a fallu douze semaines pour passer d'une preuve de concept à une application native publiée sur les stores. Son calendrier montre une bêta ouverte à la mi-juillet, puis une sortie définitive fin août, après les tests de sécurité. Les chiffres qu'elle publie donnent une idée de ce qu'elle obtient en échange de deux bases de code. Le démarrage de l'application est plus rapide de 23 % sur iOS et de moitié sur Android, la part des sessions qui se terminent par un plantage a été divisée par dix, et l'application Android pèse 109 Mo de moins, soit plus d'un tiers de son poids. Sur iOS, la taille est restée la même.

Pour une application utilisée par des centaines de millions de clients, ces gains justifient de maintenir deux bases de code. Reste à savoir ce que l'IA a vraiment réduit dans le coût de cette migration, et ce qu'elle a laissé intact.

Ce que l'IA réduit dans le coût d'une application, et ce qu'elle laisse

Le coût d'une application mobile se répartit entre plusieurs postes, dont l'écriture du code n'est qu'une partie, et l'IA n'agit pas sur chacun avec la même force. La migration de Shop permet de le mesurer, parce que Shopify a publié le déroulé du projet en plus de ses résultats.

L'écriture et la traduction du code

C'est le poste sur lequel l'IA pèse le plus. Avant de s'engager, Shopify a confié à un seul ingénieur une semaine de test avec des agents, pour reconstruire en SwiftUI la plus grande partie possible de l'application existante. Le résultat n'était pas prêt pour la production, mais il a suffi à montrer qu'une migration écran par écran était réaliste. Les agents ont porté des fonctions, construit des écrans, branché les données et reproduit les animations, avec une efficacité que l'entreprise attribue au fait qu'ils disposaient d'une implémentation existante pour s'orienter.

Même sur ce poste, Shopify précise qu'il ne suffit pas de confier tout le code React Native à un agent pour obtenir une application native. Cette approche produit, selon l'entreprise, une grande quantité de code impossible à maintenir et à publier. Elle a donc construit Helix, un système qui découpe chaque écran en petites étapes, et n'autorise le passage à la suivante qu'une fois le comportement prouvé par des tests et l'affichage comparé à celui de l'application d'origine.

Les choix d'architecture

L'IA peut écrire le code de n'importe quelle architecture. Elle construit ce qu'on lui demande, et choisit une solution par défaut quand on ne lui demande rien de précis, comme nous l'avions montré dans notre article sur le développement d'un SaaS. Le choix entre natif et multiplateforme, l'endroit où vit la logique de l'application ou la façon dont elle échange avec le serveur se décident avant la première ligne de code, à partir des contraintes du projet. Shopify a d'ailleurs pris sa décision en réévaluant ses propres contraintes, et ses agents sont intervenus une fois ce choix arrêté.

Les tests, la sécurité et la publication sur les stores

Le calendrier publié par Shopify montre la place que prennent ces étapes. La construction des fondations et des fonctions occupe mai, juin et juillet. Dès la mi-juin, les équipes responsables de chaque partie de l'application viennent tester leur périmètre et combler les manques. Une bêta s'ouvre en juillet et dure jusqu'à la sortie fin août, et des tests d'intrusion occupent le mois d'août. Il fallait aussi que la migration passe pour une simple mise à jour, sans que les utilisateurs aient à se reconnecter ni perdent leurs notifications, et que chaque interaction continue d'envoyer les événements dont dépendent d'autres systèmes, comme les recommandations.

Ces étapes dépendent de personnes qui connaissent le produit, d'utilisateurs réels et d'exigences de sécurité. Les agents y contribuent, mais elles prennent à peu près le même temps qu'avant, et en natif, chaque publication passe deux fois par la validation d'Apple et de Google.

La parité entre iOS et Android dans la durée

Une fois l'application lancée, le doublement continue. Shopify s'est fixé pour règle que les versions iOS et Android aient toujours les mêmes fonctions. React Native imposait cette parité par sa base de code commune, et l'entreprise l'impose désormais par son processus de développement et de publication. Ce coût se paie à chaque évolution, pendant toute la vie de l'application. L'IA réduit le temps d'écrire la seconde version d'une fonction, mais il faut toujours tester les deux, les publier ensemble et corriger les problèmes propres à chacune.

Pourquoi le calcul tombe du côté du natif chez Shopify

En somme, l'IA réduit fortement un poste et laisse les autres presque inchangés. Pour que le natif devienne intéressant malgré cela, il faut pouvoir absorber ces autres postes, et Shopify réunissait trois conditions qui le lui permettaient.

Une application existante qui sert de modèle

Shopify a choisi de tout reconstruire plutôt que de migrer progressivement, en partie parce que les modèles construisent efficacement une fonction en Swift ou en Kotlin à partir de sa version React Native. L'application existante joue le rôle d'une spécification complète, où chaque écran, chaque comportement et chaque événement existent déjà et peuvent servir de comparaison. Un projet qui démarre n'a pas cette référence. Il doit d'abord décider de ce que l'application fera, et cette étape reste la plus longue.

Cinq ans de pratique et d'outillage autour des agents IA

Shopify utilise des modèles de langage pour développer depuis 2021, un an avant la sortie de ChatGPT. Pour cette migration, l'entreprise a construit Helix, mais aussi Tardis, un outil qui donne aux agents un accès structuré aux événements, aux journaux et à l'état de l'application en cours d'exécution. Ces outils servent à donner aux agents le contexte qui leur manque, une question que nous avons abordée sous un autre angle avec la mémoire partagée de nos propres agents. Elle a même revu l'architecture de ses applications pour que leur logique puisse tourner sans interface et que les agents la testent en quelques millisecondes plutôt qu'en plusieurs minutes. Le tout a été porté par une équipe mobile dédiée de six ingénieurs, rejointe en cours de route par les équipes produit. Cet outillage représente donc un projet à part entière, que peu d'entreprises peuvent financer pour une seule application.

Un chantier React Native à financer de toute façon

Pour Shop, la décision a coïncidé avec un autre investissement lourd, l'adoption de la nouvelle architecture de React Native, qui aurait obligé l'équipe à revoir les modules natifs, l'affichage et la frontière entre code commun et code propre à chaque plateforme. Face au natif, l'alternative était donc un autre chantier coûteux. Retirer une seule de ces trois conditions suffit à changer le résultat du calcul.

La logique métier, le coût caché de deux applications

Un dernier poste apparaît moins dans les chiffres de Shopify, alors qu'il pèse lourd dans la durée. Il tient à la logique métier, c'est-à-dire aux règles qui décident de ce que l'application fait et de la façon dont elle le fait.

Deux applications qui parlent au même serveur

Une application mobile embarque une partie de cette logique. Elle valide ce que saisit l'utilisateur, garde en mémoire l'état de sa session, synchronise ses données avec le serveur et gère les erreurs. En natif, cette logique existe en deux exemplaires, l'un en Swift, l'autre en Kotlin. Chaque évolution du serveur doit être répercutée dans les deux, et le moindre écart produit deux applications qui ne réagissent pas de la même façon à la même réponse. Ces écarts ressemblent souvent à des problèmes du serveur, si bien qu'on les cherche au mauvais endroit. Comme tous les utilisateurs ne mettent pas leur application à jour, le serveur doit en plus accepter plusieurs versions de chaque application à la fois, publiées à des rythmes différents.

Où placer la logique métier d'une application mobile

Trois architectures reviennent le plus souvent, et elles se distinguent par le nombre de fois où cette logique s'écrit.

     iPhone              Android
+---------------+   +---------------+
| Interface     |   | Interface     |
| SwiftUI       |   | Compose       |
+---------------+   +---------------+
| Logique       |   | Logique       |
| Swift         |   | Kotlin        |
+-------+-------+   +-------+-------+
        |                   |
        +---------+---------+
                  |
                  v
               Serveur

  Interface x2   Logique x2

     iPhone              Android
+---------------+   +---------------+
| Interface     |   | Interface     |
| SwiftUI       |   | Compose       |
+-------+-------+   +-------+-------+
        |                   |
        +---------+---------+
                  |
        +---------+---------+
        | Logique commune   |
        | Kotlin (KMP)      |
        +---------+---------+
                  |
                  v
               Serveur

  Interface x2   Logique x1

+-------------------------------------+
| Interface et logique                |
| React Native, Flutter ou            |
| Compose Multiplatform               |
+------------------+------------------+
                   |
          +--------+--------+
          |                 |
          v                 v
       iPhone            Android
          |                 |
          +--------+--------+
                   |
                   v
                Serveur

  Interface x1   Logique x1

En natif séparé, la logique s'écrit deux fois. Avec Kotlin Multiplatform, elle s'écrit une seule fois en Kotlin et se partage entre les deux applications, qui gardent chacune leur interface native. En multiplateforme, interface et logique s'écrivent une seule fois. Shopify, de son côté, a séparé sa logique de l'interface pour la rendre testable par ses agents. Pour une autre application, la question se pose ainsi. Plus la logique reste sur le serveur, avec des applications légères qui affichent et transmettent, plus le natif devient envisageable. Plus l'application porte de règles en local, pour fonctionner hors connexion ou effectuer ses propres calculs, plus le partage de cette logique compte.

Natif ou multiplateforme, comment trancher pour votre application

Ainsi, la décision de Shopify n'apporte pas de réponse toute faite aux autres applications. Elle donne une méthode, qui consiste à reprendre chaque poste de coût et à regarder lesquels le projet peut absorber.

Les moyens et les délais du projet

Maintenir deux applications natives demande de financer deux bases de code pendant toute la vie du produit, et de réunir des compétences sur les deux plateformes. Comme pour un site web, ce sont souvent les choix d'architecture faits au départ qui fixent ce coût dans la durée, un mécanisme que nous avons détaillé dans notre article sur le coût des sites internet. Un projet qui doit sortir vite, ou qui cherche d'abord à vérifier que son application sera utilisée, gagne du temps avec une base de code unique. Il pourra toujours revenir sur ce choix quand l'usage et les revenus le justifieront, comme Shopify l'a fait après six ans de React Native.

Les fonctions de l'application et leur évolution

Une application qui s'intègre profondément au téléphone, avec des widgets, une version pour montre connectée, des raccourcis vocaux ou des animations exigeantes, tire davantage parti du natif. Une application de réservation, de fidélité, de commande ou de suivi de compte en tire moins souvent un bénéfice que ses utilisateurs remarquent. Il faut aussi regarder la façon dont l'application va évoluer. Une application qui reçoit de nouvelles fonctions chaque mois paie le doublement à chaque version, alors qu'une application stable le paie surtout au lancement.

La place de l'IA dans le calcul d'une petite structure

L'IA change plusieurs choses pour un projet modeste. Un prototype natif sur les deux plateformes devient réaliste en peu de temps, porter une fonction d'iOS vers Android coûte beaucoup moins qu'avant, et une application multiplateforme peut plus facilement intégrer un module natif quand une fonction l'exige. Elle laisse en revanche les tests, les publications, la parité dans la durée et les choix d'architecture à la charge du projet. Le calcul se fait donc poste par poste, en fonction de ce que l'entreprise peut porter, et sa conclusion peut changer au fil de la vie de l'application.

Chez Nualt

Nous construisons nos projets web en React et en Next.js, et Expo, qui s'appuie sur React Native, prolonge cette base vers le mobile. Une application et un site peuvent alors partager une partie de leur code, comme la validation des données ou les échanges avec le serveur. Avant d'écrire la moindre ligne, nous reprenons avec le porteur de projet les postes décrits dans cet article, ce que l'application doit faire, l'endroit où doit vivre sa logique, ses délais et ses moyens, pour choisir l'approche qui lui correspond. Comme pour nos autres projets, le code, les comptes développeur et la documentation appartiennent au client, qui peut faire évoluer son application avec nous ou sans nous.