Application native, hybride ou PWA : comment choisir ?
Application native ou PWA, ou hybride ? Accès matériel, performance, budget, stores, mises à jour, hors ligne : les critères pour bien choisir.
Avant de parler de budget ou de design, un projet mobile commence par un choix technique qui conditionne tout le reste : application native, hybride ou PWA. Ce choix décide de ce que votre application pourra faire avec le téléphone, du nombre de développeurs à payer, de la vitesse à laquelle vous publierez une correction et de la présence ou non dans les stores. La bonne réponse n'est pas la plus moderne ni la moins chère : c'est celle qui colle à l'usage réel de vos utilisateurs. Voici comment trancher entre application native ou PWA, avec l'hybride au milieu.
Trois approches, trois définitions courtes
L'application native
Une application native est écrite dans le langage propre à chaque système : Swift pour iOS, Kotlin pour Android. Deux bases de code, souvent deux équipes. En échange, l'application a un accès complet et immédiat à tout ce que le téléphone sait faire, avec les meilleures performances possibles.
L'application hybride (ou multiplateforme)
Une application hybride est écrite une seule fois, avec un framework comme Flutter ou React Native, puis compilée pour iOS et Android. Elle s'installe depuis les stores comme une application native et accède à la caméra, au GPS, aux notifications ou au Bluetooth via des modules. C'est aujourd'hui l'approche la plus répandue pour les applications d'entreprise et de services.
La PWA (Progressive Web App)
Une PWA est un site web conçu pour se comporter comme une application : elle s'ajoute à l'écran d'accueil, s'ouvre en plein écran, peut fonctionner partiellement hors ligne et envoyer des notifications. Elle ne passe pas par les stores (sauf emballage particulier) et se met à jour comme un site, instantanément.
Les critères qui font vraiment la différence
Comparer les trois approches dans l'absolu ne sert à rien. Ce qui compte, c'est de passer votre projet au crible de six critères, dans cet ordre.
L'accès au matériel du téléphone
C'est le critère éliminatoire. Faites la liste de ce dont votre application a besoin : appareil photo, scan de code-barres, géolocalisation, notifications, Bluetooth, NFC, capteurs de santé, accès aux contacts.
Une PWA couvre bien l'appareil photo, la géolocalisation au premier plan et les notifications (avec des limites sur iPhone). Elle bute vite sur le reste : pas de suivi GPS quand l'application est fermée, pas de Bluetooth sur Safari, pas d'accès aux données de santé. Si votre liste contient l'un de ces éléments, la PWA sort de la course. L'hybride couvre presque tout. Le natif couvre tout, y compris les fonctions sorties la semaine dernière.
La performance ressentie
Pour une application qui affiche des listes, des fiches, des formulaires et des cartes, l'hybride est aussi fluide que le natif à l'usage. La PWA est rapide si elle est bien construite, mais elle dépend du navigateur et se ressent davantage sur les téléphones d'entrée de gamme, très présents sur le marché marocain.
Le natif garde un avantage net sur trois terrains : les jeux, la vidéo et la réalité augmentée, et les interfaces très animées. Si votre produit en relève, ne cherchez pas d'économie à cet endroit.
Le budget de développement et de maintenance
Le natif coûte le plus cher, parce qu'il faut écrire et maintenir deux applications. L'hybride réduit fortement ce coût avec une seule base de code. La PWA est la moins chère, surtout si vous avez déjà un site ou une application web dont elle peut réutiliser une grande partie.
N'oubliez pas la maintenance : chaque nouvelle version d'iOS ou d'Android demande des ajustements, et deux applications natives demandent deux fois ce travail. Pour les montants, nous avons détaillé les fourchettes par type de projet dans notre article sur le prix d'une application mobile au Maroc.
La présence dans les stores
Être sur l'App Store et Google Play rassure, se recherche par nom et donne de la visibilité. Cela a aussi un coût : un compte développeur Apple payant chaque année, un compte Google à frais unique, des règles de publication strictes et une validation à chaque version. Apple, en particulier, peut refuser une application jugée trop proche d'un simple site web.
Une PWA échappe à tout cela : un lien, un QR code, et l'utilisateur l'installe. Pour un outil interne ou un public déjà captif (vos clients, vos équipes, vos livreurs), l'absence de store est souvent un avantage. Pour une application grand public qui doit être découverte, c'est un handicap.
Les mises à jour
Une correction sur une PWA est en ligne dès qu'elle est déployée, pour tous les utilisateurs. Une application native ou hybride passe par la validation des stores, qui prend de quelques heures à quelques jours, puis attend que l'utilisateur mette à jour. Vous aurez toujours une partie de vos utilisateurs sur une ancienne version, et votre serveur doit le supporter.
L'hybride a un atout ici : avec React Native, une partie des changements d'interface peut être poussée sans repasser par les stores, dans les limites fixées par Apple et Google.
Le fonctionnement hors ligne
Si vos utilisateurs travaillent dans un entrepôt mal couvert, sur un chantier ou sur la route entre deux villes, le hors ligne n'est pas un détail. Les trois approches savent stocker des données et les synchroniser au retour du réseau. Mais l'hybride et le natif le font de façon plus robuste, avec une vraie base de données locale et une synchronisation en arrière-plan. Une PWA peut perdre son cache si le téléphone manque d'espace, et sur iPhone le système nettoie plus agressivement les données des sites peu utilisés.
Trois scénarios types pour vous situer
Les trois cas suivants sont hypothétiques. Ils illustrent comment les critères ci-dessus se combinent dans des situations que nous rencontrons souvent.
Une enseigne de restauration et son programme de fidélité
Imaginons une chaîne de cafés à Casablanca qui veut permettre à ses clients de cumuler des points, consulter la carte et recevoir des offres. Besoin matériel : afficher un QR code, éventuellement recevoir une notification. Les clients ne téléchargeront pas une énième application pour un café.
Le bon choix est une PWA, partagée par un QR code sur les tables et les tickets. Elle s'installe en deux secondes, se met à jour sans friction et coûte une fraction d'une application de store. Si l'usage décolle, une version hybride pourra suivre.
Une société de livraison et ses livreurs
Imaginons maintenant un transporteur dont les livreurs doivent scanner les colis, prendre une photo de preuve de livraison, encaisser en paiement à la livraison et être suivis en temps réel, même quand l'application est en arrière-plan. Le réseau est intermittent sur certaines tournées.
Ici, la PWA est éliminée dès le premier critère : le suivi GPS en arrière-plan n'est pas possible. Le natif serait surdimensionné. Une application hybride, distribuée via les stores ou en interne, coche toutes les cases avec une seule base de code. Elle se branche sur la même API que la plateforme web de suivi de colis, du type de celle que nous avons réalisée pour Wimo Delivery.
Une application de coaching sportif connectée
Dernier cas : une application qui se connecte à une ceinture cardiaque en Bluetooth, affiche des courbes en direct pendant l'effort et lit les données de santé du téléphone. L'expérience doit être irréprochable, car l'utilisateur la compare aux applications des grandes marques.
Le Bluetooth et les données de santé excluent la PWA. L'hybride reste possible, avec Flutter notamment, à condition de vérifier que chaque capteur visé dispose d'un module fiable. Si le projet repose sur des fonctions très récentes des systèmes ou sur des animations exigeantes, le natif devient le choix raisonnable, budget compris.
Application native ou PWA : décider en une réunion
Prenez une feuille et répondez à quatre questions. De quelles fonctions du téléphone avez-vous besoin, au minimum, pour la première version ? Vos utilisateurs doivent-ils vous trouver dans un store, ou les connaissez-vous déjà ? À quelle fréquence comptez-vous publier des changements ? Vos utilisateurs travaillent-ils souvent sans réseau ?
Si aucune fonction matérielle avancée n'est requise et que votre public est déjà à vous, commencez par une PWA. Si vous avez besoin du GPS en arrière-plan, du Bluetooth, d'un hors ligne solide ou d'une présence en store, partez sur l'hybride. Réservez le natif aux produits où la performance ou un accès matériel pointu fait partie de la promesse.
Dans les trois cas, construisez une API et un back-office propres dès le départ : c'est ce qui vous permettra de changer d'interface plus tard sans tout refaire. Si vous hésitez encore, notre article sur le choix entre site vitrine, e-commerce ou application web aide à poser le périmètre global, et vous trouverez nos offres mobiles et web sur la page services.
Envoyez-nous la liste de vos fonctions indispensables à contact@nocido.ma : nous vous répondons avec l'approche recommandée et ce qu'elle implique, avant tout devis.
Questions fréquentes
Une PWA peut-elle être publiée sur l'App Store ou Google Play ?
Sur Google Play, oui, en l'emballant dans une coque légère. Sur l'App Store, Apple refuse en général les applications qui ne sont qu'un site web dans une coque, il faut donc apporter de vraies fonctions natives.
Une application hybride est-elle plus lente qu'une application native ?
Pour la grande majorité des applications de gestion, de commande ou de contenu, l'utilisateur ne voit pas la différence. L'écart devient sensible sur les jeux, la 3D, le traitement vidéo ou les animations très lourdes.
Peut-on commencer en PWA et passer à une application mobile ensuite ?
Oui, et c'est souvent un bon calcul. Le back-office et l'API restent les mêmes, seule l'interface mobile est refaite, ce qui limite la dépense à ce qui a été validé par l'usage.
Les notifications push fonctionnent-elles avec une PWA sur iPhone ?
Oui, mais seulement si l'utilisateur a ajouté l'application à son écran d'accueil et accepté les notifications. Sur Android, elles fonctionnent depuis le navigateur.

