Natif, React Native ou web app : comment vraiment choisir

Voici la réponse courte. Choisissez selon la distribution et les besoins matériels, pas selon la mode. Si votre utilisateur arrive par un lien ou un QR code et ne doit rien installer, construisez pour le web. S’il vous faut une vraie présence sur les deux stores avec une seule équipe et un seul code, construisez avec React Native. Si le produit dépend d’un accès profond au matériel, d’une montre ou d’intégrations santé, construisez en natif. Tout le reste de ce guide est le raisonnement derrière ces trois phrases.

La question qui tranche

La plupart des débats sur la technologie des apps commencent au mauvais endroit : par la technologie. Le point de départ utile, ce sont deux questions sur votre produit. Première question : comment votre utilisateur arrive-t-il ? En touchant un lien partagé, en scannant un code sur une table, en cherchant dans un store, ou en ouvrant quelque chose de déjà installé sur son écran d’accueil ? Deuxième question : de quoi l’app a-t-elle réellement besoin sur l’appareil ? D’un écran et d’une connexion internet, ou de la caméra, du stockage hors ligne, des notifications push, de la localisation en arrière-plan, d’une montre appairée ?

Répondez honnêtement à ces deux questions et le choix de plateforme se fait presque tout seul. Le reste, c’est le budget et le calendrier, et les deux découlent aussi de ces mêmes réponses.

Web et PWA : le choix par défaut sous-estimé

Si l’utilisateur arrive par un lien ou un QR code, toute étape d’installation est un mur entre lui et votre produit. Personne, debout devant une table de restaurant, ne va télécharger une app pour lire le menu. C’est pourquoi Smart Menu, le produit de menu digital de Cazullo, est une web app : le client scanne le code et le menu est simplement là, dans sa langue, avec des photos, en quelques secondes. Un store ajouterait de la friction et retirerait des utilisateurs.

Le web moderne va aussi plus loin que beaucoup d’acheteurs ne l’imaginent. Une progressive web app, une PWA, peut être épinglée sur l’écran d’accueil, fonctionner hors ligne et se synchroniser au retour de la connexion. Une équipe de vente sur le terrain peut faire toute sa journée sur une PWA offline-first sans que personne ne touche à un store, et l’entreprise publie ses mises à jour instantanément, sans file de validation et sans attendre que les utilisateurs mettent à jour. Pour les produits qui vivent dans un moment de navigateur, le web n’est pas l’option bon marché. C’est la bonne option.

React Native : une équipe, deux stores

Parfois, la présence sur le store est le produit. Une app de commerce de proximité que les gens cherchent par son nom, gardent sur leur écran d’accueil et ouvrent chaque semaine mérite sa place d’app installée. Le problème classique, c’est le coût : construire deux fois le même produit, une fois en Swift pour iOS et une fois en Kotlin pour Android, signifie deux équipes, deux codes et chaque fonctionnalité payée en double.

React Native résout exactement cela. Un seul code, écrit par une seule équipe, se compile en vraies apps pour les deux stores. C’est ainsi que fonctionne la Cazullo Platform : les apps de commerce local en marque blanche sont construites avec React Native et Expo, et un seul code publie de nombreuses apps de marque, chacune sous son propre nom, sur l’App Store et Google Play. Quand une fonctionnalité sort, l’app de chaque marque la reçoit. Cette économie est impossible avec deux codes natifs et inutile pour des produits qui ne poussent pas le matériel dans ses limites.

Le natif : quand il mérite son coût

Le développement entièrement natif, Swift sur les plateformes Apple ou Kotlin sur Android, est la voie la plus chère, et parfois elle vaut chaque euro. Le signal, c’est la profondeur d’intégration. Si le produit a besoin d’une app Apple Watch, lit et écrit des données de santé via HealthKit, ou s’appuie sur les fonctions de la plateforme dès leur annonce, une couche multiplateforme devient de la friction au lieu d’un levier.

Cazullo développe en Swift natif quand le produit est pensé d’abord pour l’écosystème Apple : quand la montre, les données de santé et l’intégration fine avec l’appareil sont le produit, pas un bonus. Dans cette situation, le natif n’est pas un symbole de statut. C’est le seul outil qui atteint ce que vous vendez.

Les mauvaises raisons

• Choisir le natif pour le statut : "une vraie entreprise a une app native" est une logique de marque appliquée à une décision d’ingénierie, et cela peut doubler le budget sans aucun bénéfice visible pour l’utilisateur
• Choisir le web uniquement parce que c’est moins cher, quand être trouvé sur le store EST le plan marketing : si les utilisateurs cherchent le store par nom, économiser en n’y étant pas n’est pas une économie
• Reconstruire un produit web qui marche très bien en app installée sans aucun besoin matériel derrière : une app qui aurait pu rester un site ajoute de la friction d’installation, des cycles de validation et du retard de mise à jour pour rien

Check-list

• Comment l’utilisateur arrive-t-il : par lien et QR code, ou en cherchant dans un store ?
• Une étape d’installation obligatoire ferait-elle perdre l’utilisateur au moment exact où il vous voulait ?
• Le produit a-t-il besoin de matériel hors de portée du navigateur : montre, données de santé, capteurs en arrière-plan ?
• Devez-vous être présent et trouvable sur les deux stores dès le premier jour ?
• Combien de codes votre équipe et votre budget peuvent-ils honnêtement maintenir pendant des années ?
• À quelle fréquence publierez-vous des mises à jour, et pouvez-vous tolérer les délais de validation des stores ?
• L’app doit-elle fonctionner hors ligne, et à quel point ?
• Une PWA couvrirait-elle les besoins hors ligne et écran d’accueil sans aucun store ?

Notre recommandation finale est simple. Partez du web, et restez-y tant qu’il sert votre utilisateur. Passez à React Native quand la présence sur les stores et la relation d’app installée comptent vraiment, et laissez un seul code porter les deux plateformes. Réservez le natif aux produits où l’appareil lui-même est le sujet. La meilleure plateforme n’est pas la plus impressionnante. C’est celle à laquelle votre utilisateur n’a jamais à penser.