Native vs cross-platform : la décision de build que le fondateur non technique doit vraiment assumer

Vous n’écrirez jamais une ligne de Swift ou de Flutter. Alors arrêtez d’essayer de répondre à cette question sur le terrain technique. Native vs cross-platform est une décision de budget et de délai déguisée en question de développeur, et voici le test en quatre questions qui la tranche.

Un fondateur avec qui nous travaillons était en réunion fournisseur l’an dernier et on lui a demandé, sans détour : « Natif ou cross-platform ? » Il ne savait pas. Il avait levé un tour seed pour construire un produit de prise de rendez-vous pour cliniques, il décrivait le parcours patient les yeux fermés, et il n’avait aucune idée de savoir si la bonne réponse passait par Kotlin, Flutter ou quelque chose dont il n’avait jamais entendu parler. Alors il a fait ce qu’une personne de la finance fait quand elle est coincée : il a demandé combien coûtait chaque option. Le fournisseur a donné une réponse directe, et la question technique s’est dissoute en une question de business. C’est tout le tour de passe-passe.

Si vous cherchez native vs cross-platform, tous les résultats de la première page sont écrits par ou pour des développeurs. CircleCI, Microsoft, Kotlin, un fil Reddit, deux chaînes YouTube, quelques studios de développement. Ils débattent du taux de rafraîchissement, de la maturité du framework et de savoir si Swift bat Flutter. Tout cela est réel, et presque rien n’est votre décision. Vous ne choisissez pas un langage. Vous choisissez une contrainte, et le studio choisit le langage qui s’y ajuste.

Voici la définition débarrassée du jargon. Une app native est construite séparément pour chaque plateforme : un code dans les outils d’Apple pour l’iPhone, un second code dans les outils de Google pour Android. Une app cross-platform est construite une fois, à partir d’un seul code, et tourne sur les deux. Le développement cross-platform utilise des frameworks comme Flutter (Google) ou React Native (Meta) pour écrire l’app une seule fois et la publier sur les deux stores. Natif veut dire deux builds. Cross-platform veut dire un. Ce seul fait gouverne l’essentiel de ce qui suit, y compris la partie de la facture qui vous intéresse vraiment.

Pourquoi c’est une décision d’argent, pas de technologie

Deux codes coûtent plus qu’un. Pas dans un sens abstrait de « dette technique ». Au sens littéral où vous payez des gens pour construire, tester et maintenir le même produit deux fois, en deux langages, sur deux cycles de release. Un build natif pour iOS et Android revient en général entre 1,5x et 2x le coût et le calendrier d’un seul build cross-platform qui couvre les deux. Le multiple exact dépend de la part de l’app qui relève de la logique partagée par rapport à la surface propre à chaque plateforme, mais la direction ne change jamais : le natif est la voie la plus chère, par construction.

Cette prime achète quelque chose. La question est de savoir si vous avez besoin de ce qu’elle achète. Pour une app de rendez-vous de clinique, une marketplace, un dashboard de fintech, un outil interne d’opérations, un SaaS en phase précoce avec un companion mobile, la réponse honnête est le plus souvent non. Ces produits sont des écrans, des formulaires, des listes et des appels d’API. Un framework cross-platform rend tout cela avec qualité et le publie sur les deux stores depuis une seule équipe. Vous arrivez sur le marché plus vite, vous dépensez moins, et vous avez un code à maintenir au lieu de deux quand votre unique développeur tombe malade ou, pire, démissionne. Cela rejoint directement la décision précédente dans la même chaîne, construire ou acheter : les deux questions sont mal tranchées quand c’est l’affectation du fournisseur, et non votre produit, qui dicte la recommandation.

Les quatre questions qui tranchent vraiment

Vous ne pouvez pas évaluer Flutter. Vous pouvez répondre à ces quatre-là. Chacune déplace la décision, et ensemble elles la tranchent sans un seul argument technique.

1. De combien de plateformes avez-vous vraiment besoin au jour un ? Si vos utilisateurs sont à la fois sur iPhone et sur Android (la plupart des produits grand public et PME en Europe et aux États-Unis le sont), vous avez besoin des deux, et l’économie du code-unique du cross-platform devient très attractive. Si vous construisez un outil interne pour une équipe commerciale équipée à 100 % d’iPhones d’entreprise, vous n’avez peut-être besoin que d’iOS, et la question natif-vs-cross-platform s’évapore en partie. Une seule plateforme change le calcul.

2. À quel point le produit est-il gourmand en matériel ? Soyez précis sur ce que l’app fait avec le téléphone. Une app de rendez-vous lit un calendrier et appelle une API. Un éditeur vidéo pousse le GPU, une app de fitness lit des capteurs à haute fréquence, une app sociale camera-first vit et meurt sur le pipeline natif de l’appareil photo. Plus votre produit s’enfonce dans le matériel de l’appareil, et plus il doit tourner au plus près du métal, plus le natif justifie sa prime. Les produits d’écrans-et-formulaires n’atteignent presque jamais cette profondeur.

3. Combien de temps ce produit va-t-il vivre ? Un MVP jetable que vous comptez valider et possiblement abandonner dans six mois devrait être cross-platform à chaque fois. Vous achetez de la vitesse et de l’optionnalité, pas une architecture sur 10 ans. Un produit dont vous savez déjà qu’il est l’entreprise, que vous allez maintenir et étendre pendant des années, mérite une conversation plus délibérée, car l’écart de coût s’accumule sur une vie de maintenance plus longue, dans les deux sens.

4. Une expérience propre à la plateforme est-elle le vrai produit ? Parfois le feel natif est le sujet. Si votre différenciation est une interaction fluide, à 120 ips, profondément idiomatique d’iOS qu’un utilisateur Android ne verrait jamais, le natif est défendable. Mais soyez impitoyable ici. « Ça doit faire premium » n’est pas la même chose que « le feel natif premium est la raison pour laquelle le client nous choisit plutôt que l’alternative ». La plupart des fondateurs se persuadent d’être dans le second camp alors qu’ils sont confortablement dans le premier.

Si vous avez répondu « les deux plateformes, pas gourmand en matériel, durée incertaine ou courte, aucune expérience propre à la plateforme comme produit », vous avez votre réponse, et c’est cross-platform. Cela couvre la grande majorité des produits en phase précoce. La règle à noter : partez sur cross-platform par défaut, et faites en sorte que le natif mérite la montée en gamme avec une raison précise, nommée, que vous pouvez défendre en conseil d’administration.

Ce que le natif vous coûte vraiment (les inconvénients que personne dans la recherche ne met en avant)

Les pages de studios listent les inconvénients du natif dans une petite colonne bien rangée de puces et passent à autre chose. Ceux qui mordent un fondateur non technique sont ceux-ci. Deux codes, c’est deux de chaque décision future : deux revues de release sur deux stores, deux jeux de bugs, deux endroits où une fonctionnalité doit être construite avant de sortir. Votre vélocité est divisée par deux sur tout ce qui touche les deux plateformes, ou votre coût double pour occuper deux développeurs. Votre problème de recrutement double aussi, car il vous faut désormais des compétences iOS et Android, pas un seul savoir-faire cross-platform. Et votre risque du développeur unique devient plus tranchant : avec deux codes natifs, perdre la mauvaise personne peut laisser la moitié de votre produit orpheline. Rien de tout cela n’apparaît dans un benchmark de framework. Tout cela apparaît dans votre runway.

Là où le natif gagne encore

Ce n’est pas un article anti-natif. Il existe un ~20 % réel de produits pour lesquels le natif est le bon choix, le choix d’adulte, et prétendre le contraire serait exactement le genre de conseil taille-unique que le reste d’internet fournit déjà. Le natif justifie sa prime quand le produit est vraiment gourmand en matériel : jeux à haut taux de rafraîchissement, vraies apps caméra ou AR, outils audio, tout ce qui pousse les capteurs ou le GPU. Il gagne quand une UX propre à la plateforme est le différenciateur, pas la garniture. Et il gagne à une échelle où la plupart des lecteurs de ces lignes ne sont pas encore, où vous avez des équipes iOS et Android séparées, où les codes ont divergé exprès, et où l’abstraction cross-platform a commencé à coûter plus qu’elle n’économise.

« Netflix est-elle une app native ? » est la question que la recherche pose sans cesse, et la réponse est instructive. Les apps mobiles de Netflix sont en grande partie natives, et c’est le bon choix pour Netflix : une entreprise à cette échelle, avec autant en jeu sur la performance vidéo et la lecture propre à chaque plateforme, peut se payer deux équipes de tout premier plan et a besoin de ce que le natif achète. Vous, avec tout le respect dû, n’êtes pas encore Netflix. La leçon n’est pas « faites comme Netflix ». C’est « le natif est le bon choix quand vos contraintes ressemblent à celles de Netflix, et pas un jour avant ».

Native vs cross-platform vs hybride, et la confusion avec la web app

Deux termes brouillent cette recherche, alors clarifiez-les vite. Hybride veut généralement dire une app qui enveloppe une web view dans une coque native (l’approche plus ancienne, type Cordova/Ionic). C’est une troisième option distincte et en général de moindre fidélité, et la plupart des équipes modernes choisissent un vrai framework cross-platform comme Flutter ou React Native plutôt qu’un wrapper hybride, parce que le résultat se rapproche du natif pour le même prix du code-unique. Quand quelqu’un dit « cross-platform » aujourd’hui, supposez qu’il s’agit de Flutter ou React Native, les deux frameworks qui dominent l’usage professionnel cross-platform dans l’enquête Stack Overflow, pas d’un wrapper web.

Une app native par rapport à une web app est une tout autre bifurcation : une web app tourne dans le navigateur, sans installation sur le store, alors que le natif comme le cross-platform produisent une app installable. Si vos utilisateurs n’ont pas besoin d’être sur les stores, c’est une conversation à avoir avant celle-ci. Mais c’est une décision séparée, et la confondre avec natif-vs-cross-platform, c’est ainsi que des fondateurs finissent perdus en réunion fournisseur.

Quoi faire concrètement en réunion

Entrez en ayant répondu aux quatre questions, pas en ayant googlé des comparaisons de frameworks. Dites au studio quelles plateformes vous voulez, à quel point le produit est gourmand en matériel, la durée que vous prévoyez, et si un feel propre à la plateforme est central. Puis faites-leur justifier leur recommandation au regard de vos réponses, pas de leur affectation. Un bon partenaire partira sur cross-platform par défaut et vous dira clairement le jour où le natif vaut la prime, de la même manière qu’il devrait être transparent sur ce qu’une app coûte vraiment à construire. Un fournisseur qui commence par « natif, évidemment » avant d’avoir entendu vos contraintes répond à une question différente de celle que vous le payez pour trancher.

La décision technique n’a jamais été la vôtre. La contrainte, si. Posez la bonne contrainte et le framework se choisit tout seul.

FAQ

Quels sont les inconvénients des apps natives ?
Pour un fondateur, les inconvénients sont presque tous économiques, pas techniques. Vous maintenez deux codes, vous publiez via deux revues de store, vous construisez la plupart des fonctionnalités deux fois, et il vous faut des compétences iOS et Android dans l’équipe. Cela double à peu près le coût et le risque du développeur unique par rapport à un build cross-platform. Le plafond de performance est plus haut, mais la plupart des produits ne s’en approchent jamais.

Dans quels cas le natif serait-il meilleur que le cross-platform ?
Quand le produit est gourmand en matériel (jeux à haut taux de rafraîchissement, caméra/AR sérieuse, audio, usage intensif des capteurs), quand une expérience propre à la plateforme est le vrai différenciateur, ou à une échelle où vous faites déjà tourner des équipes iOS et Android séparées exprès. Pour des produits d’écrans-et-formulaires en phase précoce, le cross-platform gagne presque toujours sur le coût et la vitesse.

Les apps natives sont-elles plus performantes ?
Aux extrêmes, oui : le natif a un plafond de performance plus haut parce qu’il parle directement à chaque plateforme. Mais les frameworks cross-platform modernes comme Flutter et React Native sont assez rapides pour que la plupart des utilisateurs ne voient pas la différence dans une app métier typique. L’écart de performance compte pour une minorité de produits et reste invisible dans le reste.

Netflix est-elle une app native ?
Les apps mobiles de Netflix sont en grande partie natives, ce qui est le bon choix pour une entreprise à cette échelle, avec de lourdes exigences de performance vidéo et le budget pour deux équipes de premier plan. C’est un très mauvais modèle pour un produit en phase précoce, où la prime du natif n’achète en général rien que vos utilisateurs remarqueraient.

Le développement cross-platform est-il moins cher ?
En général, oui. Un code couvrant les deux plateformes coûte d’ordinaire nettement moins cher à construire et à maintenir que deux codes natifs, souvent de l’ordre de 1,5x à 2x moins, parce que vous ne construisez et ne maintenez pas le même produit deux fois. L’économie est la plus forte sur la durée de maintenance du produit, pas seulement au lancement.