Une application ou deux ? Ce que l'IA a changé dans la décision de votre canal mobile

Imaginez le comité où l'on approuve la nouvelle application destinée à vos clients. Deux propositions sur la table. La première dit : « Une seule base de code pour iPhone et Android ; on construit une fois et l'on économise près de la moitié. » La seconde dit : « Deux applications natives, une par plateforme ; c'est ce qui est sérieux pour une banque ou un assureur. » Chaque proposition apporte son cas célèbre. L'une cite Shopify, qui a construit ses applications avec une seule base de code, et cela lui a réussi. L'autre cite Airbnb, qui a abandonné cette même technologie en 2018.

Jusqu'à récemment, le comité aurait choisi selon le cas qui lui parlait le plus. Mais en septembre 2026, Shopify, l'exemple de la première proposition, a annoncé son retour au natif [3]. Il n'est pas parti pour la même raison qu'Airbnb : son contexte était autre, et sa raison tient à l'intelligence artificielle.

Cet article s'adresse à celui ou celle qui signe cette décision : direction générale, des systèmes, commerciale ou digitale. Ce n'est pas une question technique. C'est une décision de coût total, de rapidité, de capacités du téléphone, d'équipe et de risque, et ses hypothèses ont une date de péremption.

D'abord, trois mots

Avant de comparer, il convient que tout le monde autour de la table entende la même chose.

• Natif : on construit une application pour iPhone, avec le langage et les outils d'Apple (Swift), et une autre pour Android, normalement en Kotlin, le langage que Google recommande pour Android. Cela fait deux codes et une certaine duplication. En contrepartie, chaque application adopte directement les capacités du téléphone lorsqu'elles sont disponibles.
• Multiplateforme : on écrit une seule application et une couche intermédiaire la fait fonctionner sur les deux systèmes. Les exemples les plus connus sont React Native (né chez Facebook, programmé en JavaScript, le langage du web) et Flutter (de Google). Une base de code, une équipe, mais une couche de plus entre votre application et le téléphone.
• Logique partagée, écrans natifs : le point intermédiaire. On partage ce qui ne se voit pas (règles métier, calculs, connexion avec vos systèmes) et chaque plateforme dessine ses propres écrans. L'exemple le plus visible est Kotlin Multiplatform, de JetBrains, que Google prend officiellement en charge pour partager de la logique entre Android et iOS [5].

Et quatre termes qui reviendront. Framework : la plateforme de développement sur laquelle l'application est construite. Dépendances : composants de tiers que l'application utilise et qu'il faut mettre à jour et surveiller. Pont ou couche : le code qui traduit entre la partie partagée et les fonctions du téléphone. Nouvelle Architecture : la manière refondue dont React Native effectue cette traduction.

Deux entreprises, des contextes distincts, un résultat proche

Airbnb, 2018 : cela n'a pas fonctionné

Airbnb a intégré React Native à l'intérieur de ses applications natives, déjà volumineuses et qui continuaient de grandir. En juin 2018, l'entreprise a publié qu'elle cessait de l'utiliser [1]. Ses raisons, en langage métier :

• Le partage a été moindre qu'espéré. Seule une petite partie de l'application était en React Native, et la relier au reste exigeait beaucoup d'infrastructure de pont. Elle a fini, dit l'article, par maintenir du code sur trois plateformes au lieu de deux [1].
• Corriger les défaillances est devenu plus difficile. Compiler était plus rapide ; déboguer, bien pire [1].
• Il manquait des mains expertes, à l'intérieur comme à l'extérieur de l'entreprise, pour résoudre les problèmes techniques rencontrés [1].

La nuance que presque personne ne cite : l'article lui-même dit que beaucoup de ces difficultés venaient du modèle hybride qu'ils avaient choisi, et que 63 % de leurs ingénieurs choisiraient à nouveau React Native (avec le biais, que les auteurs signalent eux-mêmes, de n'avoir interrogé que ceux qui l'avaient utilisé) [1]. Et il porte aujourd'hui un avertissement en tête : il reflète la technologie de la fin de 2017, et demande : « Si ces articles sont cités comme unique raison de ne pas utiliser React Native, veuillez approfondir vos propres recherches avant de prendre une décision » [1].

Airbnb n'a pas dit « React Native ne sert à rien ». L'entreprise a dit : « dans notre manière de l'utiliser, avec notre équipe et notre application, nous n'avons pas atteint ce que nous cherchions ».

Shopify, 2020–2025 : cela a fonctionné

Shopify a décidé en 2020 que ses nouvelles applications mobiles seraient en React Native. En janvier 2025, un directeur de l'ingénierie de Shopify a publié le bilan de cinq années [2] : « Ne pas avoir à construire deux fois les mêmes fonctions nous a procuré un saut de productivité ». Il a rapporté des écrans qui se chargent en moins d'une demi-seconde et plus de 999 sessions sur 1 000 sans défaillance, et que natif ne signifie pas automatiquement rapide, ni React Native automatiquement lent [2].

Le même article contient les mises en garde qu'un dirigeant doit lire [2] :

• Utiliser React Native à 100 % devait être un anti-objectif : ils avaient encore besoin de code natif pour les nouveautés du matériel (numérisation en 2D et 3D, modèles d'IA qui tournent sur le téléphone), pour les widgets de l'écran d'accueil, la montre et les raccourcis vocaux, et pour les tâches longues en arrière-plan, comme la synchronisation qui permet à leur point de vente d'encaisser hors connexion.
• Mettre à jour l'application à chaque nouvelle version du framework demande un travail considérable, et les dépendances doivent être tenues à jour.
• Déboguer restait instable.

Autrement dit : cela a fonctionné, avec une équipe qui, de surcroît, a contribué activement à l'écosystème de React Native.

Shopify, 2026 : cela a fonctionné, et pourtant il revient

Le 10 septembre 2026, le même auteur a publié « Native is now the future of mobile at Shopify » [3]. La raison centrale tient en une phrase : « Les LLM ont changé l'une des hypothèses fondamentales de notre décision de 2020 » [3]. Un LLM est un modèle de langage, la technologie derrière les assistants d'IA qui écrivent aujourd'hui du code.

L'hypothèse était que construire chaque fonction deux fois, en Swift et en Kotlin, coûtait trop cher. Shopify dit que, avec les agents d'IA (des assistants qui exécutent des tâches de programmation sur commande) qui font le travail d'implémentation, de traduction, de test et de revue, ce coût a cessé d'être le facteur décisif [3]. Ce qui demeure, ce sont les avantages du natif : être plus proche des capacités de chaque plateforme et des outils du fabricant, avec moins de couches de framework et de dépendances entre les deux [3]. Et il précise : il ne part pas parce que React Native serait lent ; ses applications, dit-il, sont rapides [3].

Le résultat qu'il rapporte : son application d'achats (Shop) est passée de la preuve de concept à la publication en natif en 12 semaines ; celle des marchands sortirait avant la fin de 2026 [3].

La leçon n'est pas « passons au natif »

Mettez les deux cas côte à côte :

Des contextes distincts, un résultat proche. Si votre comité copie le choix de l'un ou de l'autre, il copie une conclusion dont l'hypothèse ne s'applique peut-être pas à votre entreprise. Ce que l'on copie, c'est la méthode : réviser périodiquement l'hypothèse économique sur laquelle la décision a été prise.

Ce que l'IA a changé, et ce qu'elle n'a pas changé

Shopify déclare que, pour ses applications et son équipe, l'IA a fait baisser le coût d'écrire deux fois la même fonction, et précise que maintenir deux plateformes continue de coûter [3]. Dans votre entreprise, cela se valide par un essai circonscrit avant de le tenir pour acquis. Et même là où il baisse, tout le reste ne baisse pas, ou baisse bien moins :

• Concevoir l'expérience, décider ce que l'application fait et ne fait pas.
• Tester sur des dizaines de modèles de téléphone et de versions de système d'exploitation.
• Vérifier que ce qui est généré est maintenable. Shopify le dit sans détour : pointer un modèle de langage sur tout son code pour le « traduire » produisait une énorme quantité de code impossible à maintenir [3]. Pour l'éviter, il a construit un système maison, par étapes, avec des tests, une revue visuelle, deux relecteurs automatiques et une approbation humaine [3].
• Publier dans les boutiques d'Apple et de Google et se plier à leurs règles.
• Connecter l'application aux systèmes qui servent réellement le client. Nous y reviendrons plus bas, car c'est souvent le plus coûteux.

En d'autres termes : l'IA n'a pas rendu gratuit le fait d'avoir deux applications. Elle a fait que le coût d'écrire deux fois a cessé d'être, pour Shopify, le facteur décisif. Que ce soit le cas chez vous dépend du contrôle de qualité que vous pouvez exercer sur le code généré.

Il n'y a pas non plus de gagnant universel en performance. Une étude publiée en septembre 2026 (un preprint, c'est-à-dire sans revue par les pairs) a construit la même application cinq fois : native sur iOS, native sur Android, Flutter, React Native et Kotlin Multiplatform, et a mesuré chaque variante 2 000 fois [4]. Le natif a enregistré les temps les plus faibles dans la partie hors interface ; Kotlin Multiplatform a été l'option partagée la plus proche ; dans ces implémentations, les variantes partagées comptaient moins de code que les deux natives additionnées, ce qui n'équivaut pas à l'effort de n'importe quel produit. Sa conclusion : aucune technologie n'est supérieure en tout ; l'avantage dépend de l'attribut mesuré, de la charge de travail et de la plateforme [4].

Cinq critères pour décider

1. Dans votre feuille de route, qu'est-ce qui touche le téléphone de l'intérieur ?

Dressez la liste de ce que votre application fera dans les deux ou trois prochaines années et marquez ce qui dépend du matériel ou du système d'exploitation :

• Biométrie : empreinte ou visage pour entrer ou autoriser une opération.
• NFC : payer en approchant le téléphone, ou lire une pièce d'identité ou une carte.
• Caméra avancée : lire des pièces d'identité, des documents ou des codes ; numériser un dommage pour un sinistre.
• Travail en arrière-plan : synchroniser, encaisser hors connexion, suivre une livraison.
• Widgets, montre, raccourcis vocaux, notifications enrichies.

Si la liste est courte, une application multiplateforme la résout bien et utilise des composants natifs ponctuels là où c'est nécessaire. Si la liste est longue et qu'elle est le cœur de votre proposition de valeur, le natif vous permet d'adopter chaque nouvelle fonction d'Apple ou de Google avec moins de couches. Shopify, même dans ses meilleures années avec React Native, maintenait du code natif précisément pour cela [2].

2. Quelle équipe avez-vous, et quelle équipe pouvez-vous retenir ?

Une équipe solide en développement web avance vite en React Native. Une équipe de spécialistes iPhone et Android tire meilleur parti du natif. Airbnb a mentionné le manque de mains expertes comme une partie de son problème [1] ; Shopify, avec une équipe mature, a fait fonctionner les deux options. La question n'est pas de savoir quelle technologie est meilleure, mais laquelle votre équipe peut soutenir pendant cinq ans, postes vacants à pourvoir compris.

3. Que priorise votre client ?

Arriver le premier sur le marché avec la même expérience sur les deux téléphones, ou bien la sensation la plus soignée, la réponse la plus immédiate et la plus petite taille d'application. Pour une application de contenu ou de catalogue, le premier critère pèse généralement davantage. Pour une application où le client déplace de l'argent plusieurs fois par jour, le second pèse plus qu'il n'y paraît.

4. Combien coûte son entretien, non sa construction ?

Le coût de construction est visible dans la proposition ; celui d'entretien apparaît ensuite. Avec le multiplateforme, il faut suivre le rythme du framework et de ses dépendances. Un exemple récent : React Native a fait de sa Nouvelle Architecture la valeur par défaut dans la version 0.76, en 2024, et depuis la 0.82, en octobre 2025, elle ne peut plus être désactivée [6]. Une application qui passe à la 0.82 sans l'avoir validée peut exiger un travail de compatibilité et de tests : budgétez-le. Avec le natif, il faut soutenir deux codes et les maintenir identiques. L'IA change le poids de ce second coût ; elle n'élimine pas le premier.

5. À quelle fréquence révisez-vous la décision ?

Shopify a pris une bonne décision en 2020 et une autre bonne décision, différente, en 2026, parce qu'une hypothèse a changé. Mettez une date au procès-verbal : quelle hypothèse soutient le choix (par exemple, « construire deux fois coûte presque le double »), comment elle se mesure, et quand elle sera révisée à nouveau.

Le point intermédiaire : partager la logique, non les écrans

Entre « une application » et « deux applications », il existe une troisième voie qui convient souvent aux entreprises réglementées : partager ce qui ne se voit pas et construire en natif ce qui se voit.

Pensez à ce qui doit être identique sur iPhone et sur Android : comment se calcule une prime ou une commission, quelles validations s'appliquent à un virement, comment l'information est stockée et chiffrée, comment l'on dialogue avec vos systèmes. Si ces règles vivent dans deux codes, le risque grandit qu'elles disent des choses différentes. Avec Kotlin Multiplatform, par exemple, ces règles s'écrivent une fois, et chaque plateforme dessine ses écrans avec ses propres outils. Google le prend officiellement en charge pour partager de la logique métier entre Android et iOS, et permet de choisir ce que l'on partage : de la seule logique jusqu'à l'application complète [5]. Dans l'étude citée, c'était l'option partagée la plus proche du natif en performance [4].

Son coût : l'équipe doit maîtriser les deux plateformes et, en plus, la couche partagée. Ce n'est pas l'option la moins chère ; c'est celle qui donne généralement une parité des règles sans renoncer à l'expérience native.

Situation et option qui convient généralement

Un guide de conversation, non une recette.

Scénario (chiffres illustratifs, sans client). Un assureur planifie son application sur trois ans : 24 fonctions. Une fois marquées, 5 dépendent du téléphone de l'intérieur (caméra pour les sinistres, biométrie, notifications enrichies, travail hors connexion du gestionnaire de sinistres et un widget de police). Les 19 autres sont des écrans de consultation et de démarches qui appellent ses systèmes. Le 5 sur 24 est un inventaire, non un verdict : chacune des 5 est pondérée selon sa criticité, sa dépendance à un SDK (le kit d'un tiers, comme un kit antifraude), son obligation réglementaire et sa performance. Une seule fonction critique peut décider : si le travail hors connexion du gestionnaire de sinistres est le pari de l'entreprise, il pèse plus que les 19 et la balance penche vers le natif ou la logique partagée. Dans tous les cas, les 19 écrans dépendent de la réponse des systèmes internes : c'est là que se trouve l'essentiel du risque.

Les risques, en langage métier

Chacune des trois options comporte des risques. Cinq pour la table.

• « Le framework a changé et il faut migrer ». Une application multiplateforme dépend du rythme d'un tiers et de nombreuses dépendances. Shopify décrit la mise à jour à chaque version comme un travail considérable [2], et la Nouvelle Architecture exige un travail de compatibilité de qui met à jour sans l'avoir validée [6]. Budgétez l'entretien, pas seulement la construction.
• « Nous ne savons pas pourquoi cela échoue ». Plus de couches entre votre code et le téléphone signifient des défaillances plus difficiles à trouver. Airbnb l'a vécu [1] et Shopify le rapportait encore en 2025 [2]. Dans une application qui déplace de l'argent, le temps nécessaire pour trouver une défaillance est du temps passé avec des clients mécontents.
• « L'IA l'a écrit et personne ne l'a relu ». Générer deux applications avec l'IA coûte moins cher ; générer deux applications impossibles à maintenir aussi. Le retour de Shopify s'est accompagné de contrôles à chaque étape [3]. Si votre fournisseur propose « deux applications natives parce que l'IA les fait », demandez-lui comment il contrôle la qualité de ce que l'IA écrit.
• « Sur Android elle fait une chose et sur iPhone une autre ». Avec deux applications natives, la parité n'est pas automatique : le risque grandit qu'une règle change dans l'une et pas dans l'autre. Décidez ce qui doit être identique (règles, montants, mentions légales), quelle est la source qui fait foi, et appuyez-le sur des contrats et des tests de parité entre les deux applications. Ne laissez sur le téléphone que ce que l'expérience ou le fonctionnement hors connexion exigent.
• « L'application est prête, mais pas le système central ». Le risque le plus fréquent et le moins discuté. Nous le traitons à part.

L'application est le visage ; le plus difficile est derrière

Au comité, la discussion porte en général sur une application ou deux. Mais le client ne juge pas la technologie de l'application : il juge si son paiement a été appliqué, si sa police apparaît, si son solde est le bon. Tout cela est décidé par le système central (le core) et par les intégrations qui le relient à l'application.

Une application impeccable, native ou multiplateforme, qui interroge un système central lent ou qui ne reçoit qu'un « reçu » quand le client attend un « fait », est perçue comme une mauvaise application. C'est pourquoi la décision du canal mobile s'accompagne d'autres décisions :

• Ce que fait l'application et ce que font vos systèmes. Les règles qui doivent être identiques dans tous les canaux (application, web, agence, conseiller), il convient qu'elles aient leur version de référence dans les systèmes internes, une seule fois ; dans l'application, seulement le nécessaire.
• Comment elle s'intègre au système central. Quelles consultations se font en ligne et quelles opérations avec un numéro de suivi. C'est le sujet de l'article « En ligne ou asynchrone ? Comment choisir la manière d'intégrer vos systèmes ».
• Ce qui se passe quand le système interne ne répond pas. Ce que voit le client, ce qui est conservé sur le téléphone et comment l'on réessaie sans dupliquer un paiement.

Si l'intégration est bien résolue, changer la technologie de l'application, comme l'a fait Shopify, est un projet de canal. Si elle ne l'est pas, tout changement d'application entraîne avec lui le problème des systèmes internes.

Cinq questions pour votre prochain comité

1. Quel pourcentage de notre feuille de route mobile dépend du téléphone de l'intérieur (biométrie, NFC, caméra, arrière-plan, widgets), et combien est de l'écran qui consulte nos systèmes ?
2. Quelle équipe pouvons-nous soutenir pendant cinq ans, postes vacants compris, pour l'option que nous choisirons ?
3. Quelle hypothèse économique soutient notre décision actuelle, et quand l'avons-nous mesurée pour la dernière fois ?
4. Si nous utilisons l'IA pour construire, comment contrôlons-nous la qualité de ce qu'elle génère avant que cela n'arrive en production ?
5. Où vit l'unique version des règles qui doivent être identiques sur iPhone, Android et les autres canaux ?

Si, à deux de ces questions ou plus, la réponse est « je ne sais pas », votre risque peut se trouver là.

Par où commencer cette semaine

Prenez la feuille de route de votre application et marquez chaque fonction de l'une de deux étiquettes : « touche le téléphone de l'intérieur » ou « est un écran sur nos systèmes ». Comptez combien il y en a de chaque sorte et signalez les critiques. Cet inventaire, ajouté à l'équipe dont vous disposez, vous en dit plus sur l'option qui convient que n'importe quel cas célèbre.

Ce que fait Hábil

Hábil est une société mexicaine de conseil en ingénierie, fondée en 2006, qui conçoit et construit des canaux digitaux (applications web, mobiles et de bureau) connectés aux systèmes que l'entreprise possède déjà. Nous ne venons pas avec la technologie déjà choisie : nous aidons à décider entre natif, multiplateforme ou logique partagée selon votre feuille de route, votre équipe et vos systèmes, et nous construisons avec l'option qui convient. Voyez la page Des canaux digitaux que vos clients utilisent vraiment.

La première conversation est sans frais : elle part de votre feuille de route mobile et de la manière dont elle sera connectée à vos systèmes actuels. Écrivez-nous sur WhatsApp.

Les affirmations des entreprises reflètent leurs publications au 13 octobre 2026 ; ce sont des déclarations de chaque entreprise, non des mesures propres. Les citations sont traduites de l'anglais.