Les quatre questions qui tranchent vraiment
Un comparatif ne décide pas à votre place. Lors de nos cadrages, quatre questions font émerger la bonne approche en moins d'une heure.
1. Qui utilise le produit, et dans quel contexte ?
Un commercial en déplacement qui doit consulter une fiche client dans un entrepôt sans réseau n'a pas les mêmes besoins qu'un gestionnaire derrière son écran huit heures par jour. Le contexte d'usage réel prime sur les préférences déclarées. C'est exactement ce que révèle une phase de recherche utilisateur menée en amont du développement : les usages observés contredisent souvent les intuitions du comité de pilotage.
2. L'usage est-il quotidien ou occasionnel ?
Une règle simple que nous appliquons systématiquement : un usage occasionnel ne justifie presque jamais une application mobile. Personne n'installe une appli pour déclarer un sinistre une fois tous les trois ans. Une application web bien conçue, accessible en un clic depuis un email ou un QR code, convertira mieux.
À l'inverse, un usage quotidien avec notifications, géolocalisation ou mode hors ligne penche nettement vers le natif.
3. Vendez-vous le logiciel, ou sert-il votre activité ?
Si le logiciel est le produit que vous facturez, vous entrez dans une logique SaaS, avec tout ce qu'elle implique : onboarding self-service, gestion des abonnements, sécurité contractuelle, roadmap produit continue. Si le logiciel sert votre activité (outil interne, portail client), une application web sur mesure suffit dans la grande majorité des cas, pour un budget et une complexité bien moindres.
4. Quel est votre budget de vie, pas seulement de lancement ?
Le développement initial représente rarement plus de la moitié du coût total sur trois ans. Maintenance, évolutions, mises à jour des stores, montée en charge : budgétez le produit sur sa durée de vie, pas sur son lancement. Nous avons vu trop de projets mobiles ambitieux s'essouffler faute d'avoir anticipé le coût de deux plateformes à maintenir en parallèle.
Ce que nous recommandons sur le terrain
Après des dizaines de cadrages sur ce sujet, quelques convictions se sont installées chez nos équipes.
L'application web est le meilleur point de départ dans la majorité des cas. Elle valide l'usage vite, à coût maîtrisé, sans fermer aucune porte. Un produit web solide peut ensuite être décliné en application mobile une fois la traction démontrée. L'inverse est beaucoup plus douloureux.
La PWA est une étape intermédiaire souvent sous-estimée. Une Progressive Web App ajoute à votre application web l'installation sur l'écran d'accueil, une partie du mode hors ligne et les notifications push, sans passer par les stores. Pour beaucoup de PME, c'est le meilleur rapport valeur/investissement avant d'envisager du natif.
Le SaaS se construit comme un produit, pas comme un projet. Lancer un SaaS, c'est s'engager sur une roadmap continue, un support structuré et une architecture pensée pour la montée en charge dès le départ. Honnêtement, il n'y a pas de raccourci ici : un SaaS bâti sur un socle d'outil interne finit presque toujours par être refondu.
Et parfois, la réponse n'est ni l'un ni l'autre. La semaine dernière encore, un prospect nous consultait pour "une appli de prise de rendez-vous". Après cadrage, un module intégré à son site existant répondait au besoin, pour un quart du budget envisagé. C'est aussi le rôle d'une refonte de site web pensée comme une plateforme évolutive : absorber des usages applicatifs sans multiplier les outils.
Le choix technologique vient en dernier. Il découle des usages identifiés, d'une interface conçue à partir des parcours utilisateurs réels, et d'une architecture dimensionnée pour la suite, pas l'inverse.