Native, multiplateforme ou PWA : quelle application choisir pour votre entreprise

Les trois approches, en termes simples

Quand une entreprise décide de créer une application, la première question technique est généralement celle-ci : native, hybride ou PWA ? Les trois peuvent se trouver sur l’écran d’accueil avec votre logo, mais elles sont construites différemment. Cela influence ce que l’application peut faire, où elle est distribuée et le travail nécessaire pour la maintenir.

« Hybride » est un mot trompeur. Il désignait autrefois un site web enveloppé dans une application. Aujourd’hui, quand on dit hybride, on parle presque toujours de multiplateforme : un seul code source qui produit de vraies applications pour iPhone et Android.

• Native : une application écrite dans le langage officiel de chaque plateforme, Swift pour l’iPhone et Kotlin pour Android. Cela représente deux projets distincts, distribués via l’App Store et Google Play.
• Multiplateforme : un seul code source, développé avec React Native ou Flutter, qui est compilé en une application pour chaque plateforme. React Native utilise les composants d’interface du système ; Flutter dessine sa propre interface. Ces applications sont aussi distribuées via les stores.
• PWA (application web progressive) : une application construite avec des technologies web et installée directement depuis le navigateur, sans passer par un store. Elle s’ouvre en plein écran, a une icône sur l’écran d’accueil et peut fonctionner hors ligne.

Comment l’expérience utilisateur diffère

Les applications natives offrent la plus grande fluidité et suivent exactement les conventions de chaque plateforme : le geste de retour, les menus et les animations sont ceux que les utilisateurs connaissent déjà. C’est important pour les applications très sollicitées comme les éditeurs de photos, les jeux ou la navigation.

Une application multiplateforme bien réalisée s’en approche beaucoup. Dans la plupart des applications métier, comme la commande, la réservation ou un portail client, les utilisateurs ne remarqueront pas la différence. Ce qui sépare une bonne application d’une mauvaise dans ces cas, c’est le soin apporté, pas le framework.

Les PWA ont un avantage que l’on sous-estime : l’accès commence par un lien. Le client ouvre l’URL, utilise tout de suite l’application dans le navigateur et l’installe s’il le souhaite, sans compte de store ni téléchargement volumineux. Sur Android, le navigateur propose un bouton d’installation. Sur iPhone, l’installation passe par le menu de partage du navigateur, il faut donc une courte indication à l’écran pour expliquer cette étape.

Appareil photo, notifications, Bluetooth et autres fonctionnalités

C’est souvent ici que se prennent les décisions. Les navigateurs ont gagné beaucoup de capacités, et plusieurs limites répétées dans d’anciens articles ne s’appliquent plus. D’autres subsistent. Voici où en sont les choses :

• Appareil photo et images : fonctionnent dans les trois approches. Une PWA peut ouvrir l’appareil photo, prendre des photos, envoyer des images et scanner des QR codes.
• Notifications push : fonctionnent sur Android et, sur iPhone depuis 2023, à condition que la PWA ait été ajoutée à l’écran d’accueil. Les applications natives et multiplateformes les reçoivent sans cette condition.
• Géolocalisation : une PWA peut lire la position tant qu’elle est ouverte. Suivre la position en arrière-plan, comme le fait une application de livreur, nécessite une application native ou multiplateforme.
• Bluetooth et NFC : dans le navigateur, ils ne fonctionnent que sur Chrome pour Android, et Safari sur iPhone ne les prend pas en charge. Si votre application communique avec une balance, une imprimante ou un autre matériel, optez pour du natif ou du multiplateforme.
• Les tâches en arrière-plan, les widgets et l’intégration avec Santé d’Apple ou Google Health Connect restent le domaine des applications de store.

Publication et règles des stores

Être sur l’App Store et Google Play apporte de la crédibilité et un canal de recherche au sein du store. En contrepartie, il faut un compte développeur payant sur chaque store, chaque version passe par une validation et vous suivez les règles de chacun. Apple, en particulier, tend à refuser les applications qui ne sont qu’un site web dans un cadre, sans fonctionnalité propre.

Les paiements sont ce qui surprend le plus. Pour les biens physiques et les services du monde réel, comme un repas, une coupe de cheveux ou une box livrée à domicile, l’application peut utiliser votre propre prestataire de paiement. Pour les contenus numériques consommés dans l’application, comme des cours, des vidéos ou des fonctionnalités débloquées par un abonnement, les stores exigent généralement leur propre système de facturation et prélèvent une commission sur la vente. Ces règles connaissent des exceptions, varient selon les pays et ont évolué ces dernières années : vérifiez votre cas précis avant de choisir un modèle tarifaire.

Une PWA reste en dehors de ce système. Il n’y a pas de validation, les mises à jour sont en ligne dès leur déploiement et les paiements passent par le prestataire de votre choix. En contrepartie, vous renoncez au store comme vitrine.

Maintenance, délai et coût relatif

Le natif est la voie la plus chère et la plus lente, car vous construisez deux applications avec deux codes sources. Chaque nouvelle fonctionnalité est développée deux fois, tout comme chaque correction. Cela devient rentable quand la performance ou l’accès approfondi à l’appareil justifient l’investissement.

Le multiplateforme réduit considérablement l’effort, puisque le même code sert les deux plateformes. Il reste un travail propre à chaque store : configuration, validations et mises à jour des systèmes d’exploitation qui exigent des ajustements de temps à autre.

Une PWA est généralement la plus rapide à lancer et la plus simple à maintenir : un seul code source, un seul déploiement, et le même système peut servir à la fois de site web et d’application. Si vous validez une idée, cela signifie atteindre les utilisateurs plus tôt et dépenser moins avant de savoir ce qui fonctionne.

Quelle option pour quel type d’activité

En pratique, la décision suit le cas d’usage. Voici ceux que nous rencontrons le plus souvent :

• Réservation (salons, cliniques, studios) : une PWA fonctionne très bien. Les clients réservent via un lien, reçoivent des notifications de rappel une fois l’application installée et l’entreprise gère tout depuis un tableau de bord. Ajoutez un rappel par e-mail ou par messagerie pour les clients qui ne l’ont pas installée.
• Commande (restaurants, livraison, cafés) : une PWA est le choix le plus courant. Le lien se place dans votre bio, sur la carte et sur le QR code de la table, et les paiements par carte ne sont pas soumis aux règles des stores.
• Clubs d’abonnement : cela dépend de ce que vous vendez. Les abonnements à des produits physiques ou à des services en personne fonctionnent bien en PWA. Les abonnements à du contenu numérique dans une application de store se heurtent aux règles de facturation, ce qui favorise la PWA ou impose de bien planifier le modèle tarifaire.
• Applications internes pour les équipes : une PWA couvre la plupart des cas, comme les listes de contrôle, les ordres de travail, les photos de terrain et le travail hors ligne, sans passer par un store. Si l’exploitation exige la géolocalisation en arrière-plan ou du matériel Bluetooth, optez pour du multiplateforme.
• Produits d’IA : dans la plupart des cas, le modèle s’exécute sur le serveur et l’application ne fait qu’envoyer et recevoir des données, donc une PWA ou une application web suffit. Le natif ou le multiplateforme se justifient quand l’IA doit s’exécuter sur l’appareil, traiter le flux de la caméra en temps réel ou fonctionner hors ligne. Quelle que soit l’approche, les clés d’API d’IA restent sur le serveur, jamais dans l’application.

Les questions qui tranchent

Avant de parler technologie, répondez à ces questions. Elles écartent la plupart des options :

• L’application a-t-elle besoin de quelque chose que le navigateur ne sait pas faire, comme le Bluetooth, la géolocalisation en arrière-plan ou les widgets ?
• Être dans le store compte-t-il pour votre public, ou les clients arriveront-ils par votre site, les réseaux sociaux et la messagerie ?
• Vendez-vous des biens physiques, des services en personne ou du contenu numérique ?
• Devez-vous valider rapidement l’idée, ou avez-vous déjà des utilisateurs qui dépendent du produit au quotidien ?
• Qui maintiendra l’application après le lancement et à quelle fréquence évoluera-t-elle ?

Comment BG Coding recommande une voie

Aucune approche ne convient à tous les projets. Il y a celle qui couvre les fonctionnalités dont votre application a besoin, la façon dont les clients y accèdent et le budget dont vous disposez. Commencer par une PWA puis passer à une application de store quand l’usage le justifie est un chemin courant et sensé.

Chez BG Coding, la recommandation découle de la phase de découverte. Nous apprenons à connaître l’activité, le public et les fonctionnalités nécessaires, puis nous suggérons seulement si le projet fonctionne mieux en PWA, avec la publication sur les stores comme étape facultative, ou s’il exige une application multiplateforme ou native. Si vous hésitez, nous pouvons réaliser ce diagnostic avec vous.