Trois façons de mettre votre service dans une poche
Quand une entreprise dit « on veut une appli », trois chemins techniques s'ouvrent, avec des budgets qui varient du simple au quadruple. Le natif : une application par plateforme (Swift pour iOS, Kotlin pour Android), les performances maximales, le budget maximal aussi. Le cross-platform (React Native, Flutter) : un seul code pour les deux stores, l'approche dominante aujourd'hui pour les applications d'entreprise. Et la PWA, Progressive Web App : un site web qui se comporte comme une application, installable depuis le navigateur, sans passer par les stores.
Nous avons déjà comparé natif et cross-platform en détail ; ce guide ajoute la troisième option, la PWA, que les prestataires mentionnent rarement... parce qu'elle est souvent la moins chère.
La PWA a énormément mûri, surtout côté Apple
Longtemps, le talon d'Achille des PWA s'appelait iPhone : Safari bridait les notifications et l'installation restait confidentielle. La situation a changé, sous la pression réglementaire européenne notamment : les notifications web fonctionnent sur iOS depuis 2023, l'installation sur l'écran d'accueil s'est simplifiée, et les capacités hors-ligne sont solides sur les deux plateformes. Une PWA de 2026 sait faire : fonctionnement hors connexion, notifications, accès caméra et géolocalisation, paiement en ligne, plein écran sans barre de navigateur.
Ce qu'elle ne sait toujours pas faire : accéder à certaines API profondes du téléphone (Bluetooth avancé, NFC en écriture, widgets, capteurs spécialisés), tourner en tâche de fond de manière fiable, et surtout exister dans les stores avec la visibilité que ça donne. Ces limites dessinent précisément sa zone de pertinence.
Les vrais critères de choix, un par un
Le budget, d'abord. Ordres de grandeur constatés sur nos projets : une PWA bien conçue démarre autour de 8 000 à 15 000 euros quand l'application reprend un service web existant. Le cross-platform double la mise, rarement moins de 20 000 euros pour une application sérieuse avec back-office. Le natif double encore, puisqu'on développe deux fois. Ces écarts se retrouvent à l'identique sur la maintenance annuelle : comptez 15 à 20 % du budget initial par an, quelle que soit l'approche.
La distribution, ensuite, et c'est le critère le plus discriminant. Votre application vise le grand public qui doit vous découvrir ? Les stores sont incontournables : on n'installe pas ce qu'on ne trouve pas, et « cherchez-nous sur l'App Store » reste un réflexe ancré. Votre application vise des utilisateurs déjà acquis, clients, salariés, adhérents ? La PWA brille : un lien envoyé par email ou SMS, deux secondes, installée. Pas de validation Apple, pas de commission de 15 à 30 % sur les paiements, pas de délai de publication à chaque mise à jour.
L'expérience utilisateur enfin. Pour des parcours de consultation, de commande, de réservation ou de suivi, une PWA soignée est indiscernable d'une application classique pour 95 % des utilisateurs. Pour de l'animation lourde, du jeu, de la réalité augmentée ou de l'audio-vidéo poussé, le natif garde une avance nette que le cross-platform comble en partie.
Les cas types, tranchés
Un restaurant, un commerce, un réseau de salles de sport qui veut fidéliser : PWA, sans hésiter. Le carnet de commandes, les points de fidélité et les notifications de promo n'exigent rien que le web ne sache faire, et le budget économisé finance un an de marketing.
Un outil métier interne, pour vos équipes terrain : PWA encore, dans la plupart des cas. Déploiement instantané sans gestion de flotte ni comptes développeur, mises à jour invisibles. Exception : si l'outil dépend d'un matériel spécifique (scanner professionnel, capteurs), le natif s'impose.
Une marketplace, un réseau social, un service grand public avec ambition d'acquisition : stores obligatoires, donc cross-platform en premier choix, natif si le budget suit et que l'expérience est le cœur du produit. C'est le terrain de notre équipe applications, et le sujet mérite un vrai cadrage : les six questions à se poser sont détaillées dans notre guide sur le choix d'un prestataire mobile.
La stratégie d'escalier, notre recommandation par défaut
Pour la majorité des PME, le chemin le plus sain est progressif : d'abord un site mobile irréprochable (c'est le socle de tout, y compris de la future PWA), puis la transformation en PWA quand la récurrence d'usage le justifie, et seulement ensuite, si les stores deviennent stratégiques, une application publiée, en réutilisant une partie de l'investissement. Chaque marche se finance par les résultats de la précédente, et on ne découvre jamais trop tard qu'on a construit une application que personne n'installe, le scénario noir que nous voyons trop souvent arriver avec les projets « full natif » lancés sur enthousiasme.
Un doute sur la marche où se situe votre projet ? Décrivez-nous l'usage, pas la technique : qui l'utilisera, combien de fois par semaine, pour faire quoi. La réponse technique découle de ces trois réponses, et on vous la donnera franchement, même si c'est « commencez par votre site mobile, il freine tout le reste ».
Les questions à trancher avant d'écrire une ligne de code
Combien d'utilisateurs, et à quelle fréquence ? Une application utilisée deux fois par an (prise de rendez-vous annuelle, par exemple) ne justifie aucune installation : une bonne page web mobile fait mieux, sans friction. L'application, quelle que soit sa technologie, se justifie à partir d'un usage au moins mensuel. C'est la question qui élimine le plus de projets, et c'est tant mieux : elle évite les budgets à cinq chiffres pour des icônes que personne n'ouvre.
Qui maintient, et avec quel budget annuel ? Une application n'est jamais finie : les systèmes d'exploitation évoluent, les bibliothèques aussi, et les stores retirent les applications non maintenues. Si le budget de maintenance n'existe pas, le projet n'est pas mûr, et la PWA, qui vit sur l'infrastructure du site, est la seule option raisonnable.
Le hors-ligne est-il réellement nécessaire ? On nous le demande souvent par principe. Dans les faits, seuls les outils terrain (chantiers, zones blanches, entrepôts) en ont un vrai besoin. Le hors-ligne complet complexifie tout, synchronisation des données en tête ; ne le payez que s'il sert.
Deux exemples pour fixer les idées
Un réseau de boulangeries voulait « son appli » pour le click and collect et la fidélité. Devis natif reçu ailleurs : 45 000 euros. Réalisé en PWA adossée au site e-commerce existant : moins du tiers, notifications de commande prête comprises. Deux ans plus tard, 40 % des commandes passent par elle ; personne n'a jamais demandé pourquoi elle n'était pas sur l'App Store.
À l'inverse, une startup sport-santé visant le grand public avec suivi de capteurs Bluetooth : là, pas de débat, cross-platform d'emblée, avec modules natifs pour les capteurs. La PWA aurait buté sur les API matérielles et sur l'acquisition, qui passait par les classements des stores. Le bon choix n'est pas une religion, c'est une lecture du cas d'usage.
Ce que ça change côté référencement et acquisition
Détail rarement mentionné : une PWA est un site web, donc elle est indexée par Google, ses contenus travaillent votre SEO, et chaque page se partage par simple lien. Une application native est une boîte noire pour les moteurs : son acquisition repose sur l'App Store Optimization et la publicité, des disciplines à part entière et à budgets propres. Pour une PME dont le site est déjà le premier canal d'acquisition, ce point pèse lourd dans la balance, et il est presque toujours absent des comparatifs techniques.
