Guide · 7 min
Application web, mobile ou PWA ?
La question se tranche sur les usages, pas sur la mode. Et une seule interrogation départage vraiment : que doit-il se passer quand il n’y a pas de réseau ?
Trois options, pas deux
On oppose souvent « web » et « mobile » comme s’il s’agissait de deux mondes. En pratique il y a trois voies, et la troisième — la PWA — est celle qui a le plus changé la donne ces dernières années.
L’application web s’ouvre dans un navigateur, sur n’importe quel appareil. Rien à installer, une seule version pour tout le monde, une correction déployée en quelques minutes. Elle suppose une connexion.
L’application native s’installe depuis un magasin d’applications. Elle accède à tout le matériel du téléphone et fonctionne hors réseau. Elle demande un développement par plateforme, des comptes développeur, et chaque correction passe par une validation.
La PWA est une application web qui s’installe sur l’écran d’accueil, garde son interface et ses données sur l’appareil, et fonctionne sans réseau. Elle se déploie comme un site — sans magasin, sans validation — mais n’accède pas à tout le matériel.
La question qui tranche
Avant de comparer des fonctionnalités, répondez à celle-ci : vos utilisateurs travaillent-ils là où il n’y a pas de réseau ?
Si la réponse est non — des utilisateurs au bureau, en agence, chez des clients couverts — l’application web suffit, et tout le reste est du confort. Vous économisez le développement mobile, les magasins d’applications et la gestion de parc.
Si la réponse est oui — caves, locaux techniques, chaufferies, zones blanches — alors le hors-connexion n’est pas une option de confort : c’est la condition pour que l’outil soit utilisé. Une application qui exige du réseau sera contournée dès la deuxième semaine, et le carnet reviendra.
Ce qui fait vraiment pencher vers le natif
Le natif ne se justifie pas par « c’est plus rapide » ou « c’est plus joli » : sur du logiciel métier, l’écart est devenu marginal. Il se justifie par du matériel ou du comportement système.
- Un matériel spécifique : lecteur de badge, terminal durci, imprimante Bluetooth, lecteur de codes industriel.
- Des notifications qui doivent arriver dans des conditions où une PWA n’en reçoit pas.
- Un fonctionnement prolongé en arrière-plan — suivi de position continu, par exemple.
- Une distribution par un magasin d’applications imposée par le client ou par la politique interne.
Le coût qu’on oublie de compter
Le développement n’est qu’une partie de la facture. Une application native ajoute des postes permanents : comptes développeur annuels, republication à chaque correction, validation par le magasin — quelques heures à quelques jours — et un parc d’appareils à tenir à jour. Si votre parc est hétérogène, Android et iOS, personnels et professionnels, cela se multiplie.
Une PWA se déploie comme un site : une correction est en ligne le jour même, pour tout le monde, sans que personne n’ait à mettre à jour quoi que ce soit. Sur un outil métier qui évolue souvent, c’est l’argument décisif — et il pèse plus lourd que n’importe quelle comparaison de performances.
Ce que « fonctionne hors ligne » veut dire concrètement
L’expression ne dit rien toute seule. Ce qui compte est ce qui arrive à une saisie faite sans réseau, et ce que voit l’utilisateur pendant ce temps.
Chaque saisie doit être écrite localement d’abord, puis mise dans une file d’attente qui se vide quand la connexion revient, dans l’ordre. L’utilisateur doit voir en permanence si ses données sont parties ou non — un écran qui ment sur ce point est pire qu’un écran qui ne fonctionne pas. Et une saisie ne doit jamais être perdue parce qu’elle a été envoyée deux fois.
Ces mécanismes se conçoivent au départ. Les ajouter après coup revient à réécrire l’application — quel que soit le support choisi.
Notre parti pris, et pourquoi
Dans le doute, nous commençons par la PWA. Elle se met en service plus vite, couvre la grande majorité des besoins de terrain, et ne ferme aucune porte : si un matériel spécifique s’impose plus tard, une application native peut être ajoutée pour ce seul usage, en réutilisant la même API.
L’inverse — commencer par le natif « au cas où » — engage un coût permanent pour un besoin qui ne se manifestera peut-être jamais.
Pour aller plus loin
Ce que voit concrètement un technicien, et le détail du fonctionnement sans réseau, sur application pour techniciens terrain. Notre approche du mobile sur Mobile & PWA.
Écrit par
Yoann Burel, développeur
Les guides de ce site sont écrits par la personne qui développe les applications qu’ils décrivent, chez ErmineSoft.