Choix produit
Application web, PWA ou mobile : quelle solution pour votre projet ?
Comparez application web, PWA, mobile hybride et natif selon vos usages, vos appareils et votre existant. Une grille pratique pour cadrer la première version.
La réponse en bref
Le bon format dépend des actions à accomplir, des appareils utilisés et des contraintes de distribution. Définissez ces besoins avant de choisir entre navigateur, application installable et stores mobiles.
- Une application web convient aux parcours accessibles dans un navigateur, sur ordinateur comme sur mobile selon sa conception.
- Une PWA peut ajouter une expérience installable ; le travail hors connexion et les notifications doivent être cadrés séparément.
- Le mobile hybride et le natif ont des périmètres différents : examinez l’existant, les plateformes visées et les capacités nécessaires.
- WebUn accès par le navigateur
- PWAUne application installable
- MobileLes usages du téléphone
Commencez par trois actions concrètes
« Il nous faut une application » ne dit pas encore ce qu’il faut construire. Un client doit-il réserver une prestation depuis un lien ? Un collaborateur doit-il saisir des données sur le terrain ? Un administrateur travaille-t-il toute la journée sur ordinateur ? Décrivez les actions principales, leur fréquence et le contexte d’utilisation avant de choisir le support.
Pour une première version, distinguez ce qui est nécessaire au service de ce qui pourrait venir plus tard. Un espace connecté, des rôles et un back-office décrivent des fonctions, pas une obligation de publier sur les stores. À l’inverse, une contrainte matérielle ou un usage terrain peut demander des vérifications techniques avant de valider une solution web.
- Quelles sont les trois actions que l’utilisateur doit pouvoir terminer ?
- Sur quels appareils et dans quel contexte les réalise-t-il ?
- Dispose-t-il d’une connexion pendant ces actions ?
- Comment découvre-t-il le service : lien, recherche web, outil interne ou store ?
- Existe-t-il déjà un design, une application ou une API réutilisable ?
Web, PWA, hybride et natif : les différences utiles
Une application web s’utilise dans un navigateur. Une PWA reste une application web, à laquelle on ajoute des capacités telles que l’installation sur les appareils compatibles. Une application mobile hybride partage une base de développement entre plusieurs plateformes ; le natif est conçu spécifiquement pour la plateforme visée. Ces formats ne déterminent pas, à eux seuls, la qualité de l’expérience.
| Format | Point de départ utile | À vérifier au cadrage |
|---|---|---|
| Application web | Un service accessible depuis un lien dans le navigateur | Parcours sur chaque taille d’écran, droits et échanges de données. |
| PWA | Les usages web avec une expérience installable | Navigateurs, installation, cache et comportement sans réseau. |
| Mobile hybride | Des usages mobiles à couvrir avec une base partagée | Éléments réutilisables, capacités nécessaires et tests iOS/Android. |
| Mobile natif | Un besoin conçu pour une plateforme précise | Plateforme retenue, API disponible et fonctions propres à l’appareil. |
Une PWA installable ne signifie pas un métier disponible hors ligne
L’installation d’une application web dépend du navigateur et de la plateforme. Il faut convenir des appareils à prendre en charge et vérifier l’expérience sur ceux-ci. Le cache peut rendre certaines ressources accessibles sans réseau ; il ne transforme pas automatiquement une réservation, un paiement ou une saisie métier en opération hors connexion.
Dans l’offre PWA standard CUB3, le périmètre comprend l’installation, les icônes, le cache des ressources statiques et un écran hors connexion. La saisie sans réseau et la synchronisation ultérieure des données demandent une conception dédiée : que conserve l’appareil, quand renvoie-t-il les changements et que se passe-t-il si les informations ont changé entre-temps ?
Les notifications sont aussi un besoin à préciser. Sur les versions compatibles d’iOS et d’iPadOS, le Web Push concerne les applications web ajoutées à l’écran d’accueil et reste soumis à l’autorisation de l’utilisateur. Il faut vérifier les conditions sur les appareils visés. Une fonctionnalité techniquement possible n’est pas automatiquement comprise dans une offre de départ.
Pour le mobile, faites examiner l’existant
Une reprise mobile et une création complète ne demandent pas le même travail. Le design, les modules déjà disponibles et les API déterminent ce qui peut être réutilisé. Une API est l’interface qui permet à l’application d’échanger avec ses données et ses services : il faut connaître ses capacités réelles avant de chiffrer les écrans qui en dépendent.
L’offre hybride de départ CUB3 correspond à la reprise cadrée d’un existant, avec design conservé et modules réutilisables. L’offre native de départ vise un MVP pour une plateforme, iOS ou Android, avec une API existante exploitable. Une création hybride entièrement nouvelle, un backend à construire ou une seconde plateforme native nécessitent un chiffrage adapté. Les offres détaillent ces hypothèses.
La distribution mobile ajoute aussi des étapes : préparation des éléments demandés par les stores, soumission et validations externes. Il faut les distinguer de la fin du développement. Le planning doit préciser ce que l’équipe maîtrise et ce qui dépend de la distribution.
Promo.dev : un produit web et mobile, des livraisons distinctes
Pour Promo.dev, CUB3 a réalisé une application web React et des applications mobiles React Native, avec un système de composants partagé. Shopify portait le catalogue, les paiements et l’inventaire ; une couche API couvrait la logique métier et les intégrations. Le choix technique tenait compte de ce qui pouvait être confié à un service existant et de l’expérience à développer sur mesure.
Le web était prêt pour la production en vingt-huit jours. Les applications mobiles étaient développées, avec un délai supplémentaire lié aux validations des stores. Ce cas montre l’intérêt de distinguer le périmètre commun, les interfaces et la distribution. Il ne signifie pas que tout projet doit commencer sur trois plateformes ni reprendre cette architecture.
Préparez un budget à partir des fonctions attendues
Choisissez d’abord un format plausible, puis listez les fonctions nécessaires : comptes et connexion, gestion des rôles, administration, recherche, paiement ou notifications. Ajoutez les pages de présentation séparées des écrans nécessaires à ces fonctions. Le simulateur CUB3 donne une première référence ; le devis confirme le périmètre, les intégrations et les contraintes après échange.
Pour comparer les propositions, regardez ce qu’elles comprennent au-delà des écrans : conception, tests, mise en production, éventuelle soumission aux stores, puis suivi. Séparez les frais de services tiers et la maintenance du budget de réalisation. Si une capacité reste incertaine, demandez qu’elle soit vérifiée avant de retenir le format.
Sur le terrain
Un projet concret
Un front web sur mesure, des applications React Native et un moteur commerce existant, avec une distinction claire entre développement et validation des stores.
Le produit web et mobile de Promo.dev