On nous demande souvent : « Il nous faut une application, ou un site suffit ? » La question est incomplète. Il faut savoir où l’on s’en sert, hors ligne ou non, avec quels capteurs, sur quels comptes de boutique, et qui mettra à jour l’outil ensuite. Voici comment nous tranchons entre une PWA et une application native, sans vocable magique, et sans commencer par les stores.
Ce que nous mettons derrière chaque mot
Une application web progressive, ou PWA, reste un site — plus précisément une application web — que l’on peut installer sur un téléphone ou un ordinateur, avec une icône, parfois des notifications, un fonctionnement hors-ligne plus ou moins poussé selon ce que l’on a vraiment développé. Elle tourne dans le navigateur, même quand elle « ressemble » à une application.
Une application native, au sens où nous l’entendons ici, est écrite pour le système : iOS d’un côté, Android de l’autre, souvent avec une API commune derrière. Sur notre page stack, nous le disons ainsi : deux clients, une API. Hors-ligne réel, pas un spinner courageux. Nous le proposons quand le terrain l’exige.
Il existe des voies intermédiaires, des coques, des bases de code partagées. Nous ne les écartons pas par principe. Nous refusons en revanche de vendre pour une application native ce qui n’est qu’un site placé dans une WebView. Nous l’écrivons sur la page de l’agence, et nous le tenons.
Les questions qui tranchent réellement
Le premier critère est l’usage réel, le mardi, pas la slide. Qui ouvre l’outil, où, dans quelles conditions de réseau ? Un commercial dans un bureau, sur du wifi stable, n’a pas les mêmes contraintes qu’une personne en entrepôt, en visite, ou en zone mal couverte. Si le travail doit continuer sans réseau, et reprendre une synchronisation fiable plus tard, nous nous rapprochons d’un client natif, ou d’une PWA dont le hors-ligne a été conçu comme un vrai mode, pas comme un espoir.
Le deuxième critère concerne les capacités du téléphone. Un appareil photo utilisé de façon ponctuelle, un partage de fichier, un paiement web : le navigateur suffit souvent. Un usage intensif du capteur, une communication avec un périphérique, un besoin fin de l’horloge système, des droits que le navigateur calibre mal : le natif redevient raisonnable.
Le troisième critère est la distribution. Publier sur les stores a un coût, un calendrier, des comptes, des revues, des mises à jour à faire accepter. Une PWA s’installe depuis le navigateur, sur un téléphone ou un ordinateur, sans passer par cette revue. Si l’équipe doit pouvoir corriger un parcours le jour même, le web a un avantage. Si les utilisateurs attendent « l’appli du store », et que l’organisation l’exige, on en tient compte, sans en faire le seul argument.
Le quatrième critère est la durée de vie et l’équipe de maintenance. Deux applications natives, plus une API, plus parfois un back-office, c’est plusieurs surfaces à faire vivre. Une PWA bien faite reste un projet web, avec une stack que beaucoup d’équipes savent déjà tenir. Nous ne choisissons pas le natif pour le prestige. Nous le choisissons quand le terrain le justifie, et quand quelqu’un pourra le maintenir.
Quand une PWA est suffisante, et même préférable
Beaucoup d’outils métier s’ouvrent plusieurs fois par jour, par les mêmes personnes, sur un téléphone ou un portable déjà en main. Une PWA installable évite de chercher le signet. Elle peut proposer un écran d’accueil, un fonctionnement dégradé si le réseau tombe un moment, des mises à jour immédiates. Pour un espace client, un back-office, un questionnaire, un suivi de dossiers, c’est souvent le bon équilibre.
Nous avons ce réflexe aussi pour des produits que nous éditons. Un outil de questionnaires, un espace de travail en ligne, une application utilisable dans le navigateur et installable si besoin : le web porte l’essentiel, l’installation est un plus, pas une fin en soi. La même logique vaut pour un client. On n’ouvre pas deux stores si un navigateur moderne fait le travail.
La PWA n’est pas « moins sérieuse ». Elle est moins adaptée quand le hors-ligne doit être un vrai mode de production, avec une file d’actions, une résolution de conflits, une base locale solide. On peut s’en approcher sur le web. Cela devient un projet, pas un simple service worker ajouté à la fin.
Quand le natif se justifie
Nous proposons iOS et Android quand le terrain l’exige : un usage hors réseau réel, une synchronisation plus tard, des contraintes d’appareil que le navigateur ne tient pas bien, parfois une présence contraignante dans les stores. Deux clients, une API. Les règles métier restent côté serveur autant que possible, pour ne pas les dupliquer dans chaque application.
Ce choix allonge le calendrier, et il doit être dit dès le devis. On ne « rajoute pas un store » en fin de projet comme on ajoute une page. Les comptes développeur, les certificats, les revues, les versions, font partie du périmètre. Si le budget ou le délai ne le permettent pas, mieux vaut une PWA honnête qu’une native sous-dotée.
Le hors-ligne, en natif, se conçoit aussi. Quelles données sont disponibles sans réseau ? Quelles actions peut-on enregistrer ? Que se passe-t-il si deux modifications se contredisent au retour de la synchro ? Tant que ces réponses n’existent pas, « on fera du hors-ligne » n’est pas une fonctionnalité. C’est une intention.
Un exemple typique d’hésitation : une équipe terrain doit saisir des informations au moment de la visite, parfois sans réseau, puis les retrouver au bureau le soir. Si l’on se contente d’un site classique, la personne attendra le réseau, ou reviendra au papier. Si l’on pose une PWA sans avoir conçu la file d’attente des saisies et la synchro, on aura une icône sur l’écran d’accueil, et la même panne dès que le signal tombe. Dans ce cas, soit on investit réellement le hors-ligne côté web, soit on parle d’un client natif, avec une API et une règle de synchronisation écrite. Les deux sont possibles. Le « presque hors-ligne » ne l’est pas.
Autre cas, inverse : un espace pour suivre des dossiers, ouvert surtout au bureau, parfois sur un téléphone dans le train, avec un réseau correct. Une PWA installable rend service. Une double publication store n’ajoutera, souvent, que du délai et de la maintenance. On peut toujours y revenir plus tard, si l’usage le justifie, à condition de n’avoir pas verrouillé toute la logique dans un client impossible à extraire.
Nous parlons aussi, dès le cadrage, des comptes et des mises à jour. Qui paie le compte développeur Apple ou Google, qui signe les versions, qui répond à une revue refusée, qui teste sur les appareils réellement utilisés ? Si ces réponses n’existent pas, le natif n’est pas prêt, même si la maquette est belle. Une PWA pose d’autres questions — navigateurs cibles, installation, cache — mais elles sont souvent plus proches du travail web déjà en cours dans l’équipe.
Une décision écrite, pas un slogan
Nous écrivons le choix dans le périmètre. PWA, native, ou parfois les deux dans le temps — un premier jet web, un client natif plus tard si le terrain le confirme. Nous n’inversons pas l’ordre par prestige. Nous lisons le métier avant le wireframe, nous tranchons une stack, nous construisons le chemin critique.
Si vous hésitez pour un outil que vos équipes utiliseront vraiment, nous pouvons poser ces questions avec vous. La page contact ou un premier échange suffisent. On part de l’usage du mardi, pas d’une maquette d’icône sur un écran de téléphone.