PWA ou application native : un choix produit, pas technique

"PWA ou application mobile native / hybride ?" La question revient dans beaucoup de projets digitaux, et elle est presque toujours posée sous un angle technique. Quelle technologie a le plus de fonctionnalités, laquelle coûte le moins cher à développer, laquelle tient le mieux la charge. Ce n'est pas le meilleur point de départ.

Le choix entre PWA et natif n'est pas un arbitrage purement technique, c'est surtout une décision produit. Il se joue sur des critères que votre équipe technique ne peut pas connaître à votre place : qui sont vos utilisateurs, dans quel contexte ils ouvrent l'app, ce qu'ils attendent de votre marque, comment votre produit s'insère sur son marché. La technologie ne fait que traduire les réponses à ces questions en lignes de code.

Remettre le débat à l'endroit demande de passer par 7 questions, dans le bon ordre, avant d'ouvrir le moindre éditeur.

La grille de décision en 7 questions

‍

1. Qui utilise l'app, et dans quel environnement ?

‍Cette question vient en premier parce qu'elle conditionne toutes les autres. L'environnement réel de l'utilisateur (mobilité, qualité du réseau, type d'appareil, durée d'usage) éclaire à lui seul une grande partie des contraintes qui suivront. Un employé administratif qui ouvre une app depuis son poste de travail n'a pas les mêmes besoins qu'un agent qui passe sa journée sur un chantier isolé, qui lui-même n'a rien à voir avec un visiteur ponctuel devant une borne en salle d'attente. Un contexte stable et connecté s'accommode très bien d'une PWA. Un contexte terrain, en mobilité dans des zones où le réseau lâche (ouvriers sur sites distants, agents de sécurité en intervention, livreurs en milieu rural), penche plutôt vers le natif. Plus vos personas sont décrits en situation réelle plutôt qu'en théorie, plus les six questions suivantes deviennent faciles à trancher.

2. Avez-vous besoin de NFC, Bluetooth, biométrie native ou d'autres fonctionnalités hardware avancées ?

‍Certaines fonctions matérielles sont éliminatoires : si votre produit en dépend vraiment, l'éventail technologique se réduit drastiquement. Un système de contrôle d'accès par badge, une app médicale connectée à un appareil de mesure, un outil d'identification par reconnaissance faciale avec la fiabilité qu'attend un utilisateur professionnel : tous ces cas penchent fortement vers le natif (ou hybride), en particulier si l'app doit fonctionner sur iPhone. À l'inverse, beaucoup de projets supposent ces besoins par défaut alors que leur produit n'en a aucun usage réel. L'enjeu est donc d'inventorier explicitement les interactions physiques attendues entre votre app et le monde réel, sans rien présumer.

3. L'app doit-elle fonctionner totalement offline pendant de longues périodes ?

‍Le mot "offline" recouvre des réalités très différentes. Un trajet de quelques minutes dans le métro ne pose aucun problème à la grande majorité des technologies modernes, PWA comprises. Une équipe d'inspection qui passe sa journée sur un chantier sans réseau et synchronise le soir, une équipe d'intervention dans des zones reculées, un agent qui travaille en continu dans un bâtiment mal couvert : c'est autre chose. Ce cas, qu'on appelle parfois "offline durable", penche fortement du côté natif. Estimer la durée maximale pendant laquelle vos utilisateurs doivent réellement pouvoir travailler sans connexion suffit en général à trancher cette question.

4. Devez-vous être sur les stores pour des raisons métier ?

‍Les stores remplissent trois fonctions distinctes : un canal de distribution (comment le produit arrive sur l'appareil), un canal d'acquisition (comment vos utilisateurs vous découvrent) et un marqueur de crédibilité grand public. Un outil interne d'entreprise ou une plateforme B2B utilisée uniquement par des clients qualifiés peut très bien s'en passer, et même y gagner en agilité de déploiement. À l'inverse, une app grand public dont la visibilité dépend du téléchargement (jeu mobile, service consommateur, marketplace) aura beaucoup de mal à exister hors des stores.

Une PWA peut d'ailleurs être empaquetée pour apparaître elle aussi sur les stores via des outils comme Capacitor ou Ionic : la présence sur les stores ne dicte donc pas automatiquement un développement natif, et cette voie intermédiaire mérite d'être envisagée. L'exercice consiste à identifier laquelle de ces trois fonctions, le cas échéant, est vraiment nécessaire à votre produit.

5. Avez-vous besoin de couvrir desktop, tablette et mobile avec la même application ?

‍Un projet multi-surface n'a pas la même équation économique qu'un produit mobile pur. Maintenir plusieurs bases de code distinctes (web, iOS, Android) coûte plus cher en développement, en tests et en évolutions, mais permet de tirer le meilleur de chaque support. Mutualiser une seule base de code qui sert toutes les surfaces réduit le coût et accélère les évolutions, au prix de quelques compromis sur chaque rendu. Un projet qui combine un back-office admin, un portail web public et une vue mobile pour les utilisateurs finaux (typiquement un outil métier, une plateforme citoyenne, un SaaS interne) tire presque toujours avantage d'une PWA. Une app strictement mobile, sans surface web à prévoir, ne paie pas ce bénéfice et peut assumer le natif sans regret.

6. Voulez-vous un look & feel uniforme entre plateformes, ou respecter les codes UI iOS et Android ?

‍Ce sont deux philosophies opposées de design produit. La première privilégie l'identité de marque sur tous les supports : votre produit ressemble à votre produit, qu'il soit ouvert sur iPhone, sur Android ou sur le web. C'est souvent le choix des marques à forte identité visuelle (retail, luxe, médias) ou des outils qui jouent la cohérence entre équipe terrain et équipe bureau. La seconde cherche à ce que l'utilisateur retrouve les codes natifs de sa plateforme, parce qu'un utilisateur iOS attend des animations, des contrôles et une typographie qu'il connaît déjà. C'est le choix classique des apps grand public très ancrées dans l'usage mobile, comme la messagerie ou les apps bancaires. Aucune des deux options n'est meilleure dans l'absolu, mais cette décision de marque autant que de produit mérite d'être tranchée tôt avec votre équipe UX.

7. Quelle est votre exigence de mise sur le marché ?

‍La cadence de release n'est pas la même selon la technologie retenue. Le web se déploie en continu : un correctif poussé le matin est en ligne dans la minute. Les stores imposent un rythme dicté par leurs revues, qui peuvent prendre de quelques heures à plusieurs jours selon les périodes et la complexité de la mise à jour. Pour un produit qui itère beaucoup en début de vie (MVP à valider, campagne courte à tester en conditions réelles, outil interne à ajuster au jour le jour), l'écart cumulé se chiffre en semaines de retard. C'est votre vraie contrainte de temps qui dictera la friction acceptable au déploiement.

Trois projets Nubios, trois choix produit très différents

Pour ancrer la grille dans le concret, voici trois projets que nous avons menés et les arbitrages qui ont guidé chaque choix.

‍

Mouscron, application citoyenne : PWA‍

L'application permet aux citoyens d’évaluer leurs projets à travers les Objectifs de Développement Durable (ODD) de l’ONU. L’application intègre de l’IA pour proposer des suggestions et des conseils personnalisés. Pas de présence store nécessaire (outil public, aucune logique d'acquisition par téléchargement), besoin de couvrir web et mobile pour les citoyens, sans interaction avec le hardware, et un back-office pour les administrateurs de la ville. Ces derniers points ont tranché en faveur d'une PWA.

Beoogo Kiosk, bornes de prise de rendez-vous médicaux : PWA‍

Application déployée sur des kiosques en centres médicaux privés. Pas de présence store, besoin de piloter à distance tout le parc de bornes, et de pousser des mises à jour instantanément sans repasser borne par borne. La PWA fait exactement ça, sans la complexité d'une application native à déployer sur chaque machine.

CSP, agents de sécurité au Congo : Flutter (hybride)‍

Cas inverse. Les agents travaillent sur le terrain dans des zones où le réseau peut lâcher. Ils ont besoin de scanner des tag NFC, de s'authentifier avec reconnaissance faciale, de recevoir des notifications fiables, et bénéficier d'un mode hors connexion sur une durée indéterminée. Le mobile natif s'impose.

Trois projets, trois contextes, trois décisions opposées. Aucun ne s'est joué sur une préférence technologique. Tous se sont joués sur les réponses à ces sept questions, posées en amont, avec le client dans la pièce.

Guider avant de coder

C'est exactement ce type d'arbitrage que Nubios mène avec ses clients en amont, avant la moindre ligne de code. Comme Nubios opère aussi bien sur la stack PWA Angular que sur Flutter, le conseil n'est pas orienté par la stack disponible : il l'est par votre projet. Vous voulez trancher proprement entre PWA et natif sur votre prochain produit ?

‍Prenons 30 minutes.