Aller au contenu
Dev App

Mis à jour le 12/09/2026 · 9 min de lecture

Application web ou application mobile : comment choisir

C’est la question posée à presque tous les premiers rendez-vous, et c’est aussi celle sur laquelle on se trompe le plus souvent. Non par manque de compétence technique, mais parce qu’elle est presque toujours abordée par le mauvais bout : on compare des technologies alors qu’il faudrait observer des situations de travail.

Nous développons les deux, ce qui nous laisse sans intérêt à pousser l’un plutôt que l’autre. Ce guide donne le raisonnement que nous appliquons en cadrage, avant même de parler d’écrans, que votre projet relève du développement web ou du mobile.

En bref

  • Le critère qui tranche n’est pas technique : c’est l’endroit où se trouve l’utilisateur au moment précis où il se sert de l’outil.
  • Assis devant un écran, l’application web gagne presque toujours : moins chère, corrigible le jour même, sans magasin d’applications.
  • En mobilité réelle, seule l’application installée tient : hors réseau, une main libre, appareil photo, notifications fiables.
  • La PWA couvre une partie du besoin mobile, mais ni le vrai hors ligne ni les notifications sur lesquelles on peut compter.
  • À périmètre égal, le web coûte 30 à 40 % de moins, surtout parce qu’il n’y a qu’une version à produire et à faire valider.
  • Le choix n’est pas définitif : le serveur est commun aux deux, ajouter le mobile ensuite ne se paie pas deux fois.

La seule question qui tranche vraiment

Où se trouve votre utilisateur à la seconde où il ouvre l’outil, et qu’est-ce qu’il a dans les mains ? Tout le reste en découle. Un comptable assis à son bureau, deux écrans devant lui, n’a aucun besoin d’une application installée. Un technicien debout sur un toit, un gant sur une main, n’ouvrira jamais un navigateur.

La raison pour laquelle cette question est la bonne, c’est qu’elle est la seule à laquelle vous connaissez déjà la réponse. Les arbitrages techniques, vous ne pouvez pas les trancher seul et vous n’avez pas à le faire. La situation d’usage de vos équipes ou de vos clients, personne ne la connaît mieux que vous.

Un test pratique : décrivez à voix haute une journée type de votre utilisateur, sans prononcer le mot application. Si votre récit comporte des déplacements, des interruptions, des lieux sans réseau ou des mains occupées, vous avez un projet mobile. Si votre récit se déroule à un poste de travail, vous avez un projet web, et probablement un budget divisé par deux.

Ce que le web fait mieux

Six avantages, qui n’ont presque rien à voir avec la technique et beaucoup à voir avec l’exploitation au quotidien.

  • Une seule version à produire : pas de déclinaison iOS et Android, donc un budget et un calendrier mécaniquement plus courts.
  • La correction le jour même : vous mettez en ligne et tout le monde a la version corrigée. Côté mobile, il faut soumettre, attendre la validation, puis espérer que les utilisateurs mettent à jour.
  • Aucune dépendance à Apple ni à Google : pas de compte développeur, pas de règles de validation qui changent, pas de commission.
  • Le grand écran et le clavier : dès qu’il s’agit de saisir beaucoup, de comparer des lignes ou de lire un tableau, le téléphone est un handicap et non un atout.
  • L’impression et l’export : sous-estimé, et pourtant c’est souvent la première chose que réclament les utilisateurs d’un outil de gestion.
  • Le partage par simple lien : envoyer une adresse à un nouveau collaborateur suffit, là où le mobile suppose une installation.

Ce que seul le mobile sait faire

La liste est plus courte, mais chaque élément est bloquant quand il est nécessaire. Le vrai fonctionnement hors ligne vient en premier : une application installée garde ses données en local et se synchronise quand le réseau revient, ce qu’un navigateur ne fait correctement qu’au prix d’une complexité rarement justifiable.

Viennent ensuite les notifications sur lesquelles on peut compter, l’accès complet à l’appareil photo et aux capteurs, la géolocalisation en arrière-plan, et l’ergonomie à une main. S’y ajoute un facteur qu’on oublie souvent : l’icône sur l’écran d’accueil. Pour un usage quotidien et rapide, ces deux secondes gagnées à chaque ouverture décident de l’adoption réelle de l’outil.

Le cas de la PWA

La PWA est une application web qui s’installe sur l’écran d’accueil et s’affiche sans barre de navigateur. Elle règle donc l’argument de l’icône et une partie de celui du confort. À ce titre, c’est un excellent compromis pour un outil consulté depuis un téléphone de temps en temps, et nous la proposons régulièrement.

Ce qu’elle ne règle pas, il faut le savoir avant de s’engager : les notifications restent moins fiables qu’en natif, en particulier sur iOS, le hors ligne reste limité et fragile, l’accès aux capteurs est partiel, et elle n’apparaît pas dans les magasins d’applications. Si votre projet dépend de l’un de ces quatre points, la PWA vous fera perdre du temps plutôt que de l’argent.

Ce que le choix change sur le budget

À périmètre fonctionnel identique, une application web revient en général 30 à 40 % moins cher qu’une application mobile publiée sur les deux plateformes. L’écart ne vient pas du code de l’interface, qui représente une part modeste du travail, mais de tout ce qui l’entoure : une seule version à tester, aucune procédure de publication, aucun compte développeur, et pas de reprise annuelle pour rester conforme aux nouvelles exigences des magasins.

Sur nos grilles, un premier outil métier web démarre autour de 6 000 € quand un MVP mobile démarre autour de 4 500 €, mais les périmètres ne sont pas comparables : le MVP est volontairement réduit à un parcours. Pour un outil complet, l’écart se creuse en faveur du web. Le guide des prix détaille les postes, et le guide des délais montre où passe le temps, la validation par les stores étant le poste le plus souvent oublié dans un planning mobile.

La trajectoire la moins chère

Quand les deux se défendent, nous recommandons presque toujours de commencer par le web. Non par facilité, mais parce que c’est le chemin qui coûte le moins cher en apprentissage : vous mettez un outil entre les mains de vos utilisateurs en quelques semaines, vous observez ce qu’ils en font réellement, et vous ajoutez ensuite une application mobile sur le périmètre précis qui le justifie.

Ce n’est pas payer deux fois. Le serveur, la base de données et les règles métier sont communs aux deux : ce qui s’ajoute, c’est l’interface mobile et sa publication. L’inverse est vrai aussi, mais moins confortable, car un projet mobile lancé d’emblée engage un budget plus lourd sur des hypothèses encore non vérifiées. C’est exactement la logique de notre offre de première version.

Trois erreurs de raisonnement fréquentes

La première consiste à choisir le mobile parce que « tout le monde est sur téléphone ». C’est vrai pour le grand public et faux pour la plupart des usages professionnels, où le travail se fait encore devant un écran. La bonne question n’est pas où sont les gens en général, mais où ils sont quand ils utilisent votre outil.

La deuxième consiste à croire qu’une application dans un magasin est plus crédible. Pour un outil interne ou un portail client, personne ne le remarquera, et vous aurez payé la publication, la validation et la maintenance de conformité pour un bénéfice d’image nul.

La troisième, la plus coûteuse, consiste à trancher avant d’avoir décrit les situations d’usage. Un choix fait sur une préférence esthétique ou sur ce qu’a fait un concurrent se paie six mois plus tard, quand on découvre que l’outil ne s’utilise pas là où il aurait dû.

Et ensuite

Si votre récit de journée type se déroule à un poste de travail, notre page sur le développement d’applications web détaille cette activité. S’il comporte des déplacements, c’est le développement mobile multiplateforme qui vous concerne.

Et si vous hésitez encore après avoir lu ceci, c’est souvent le signe que le périmètre n’est pas stabilisé, ce qui est une information utile en soi. Décrivez-nous la situation : nous vous dirons franchement lequel des deux formats correspond, y compris quand la réponse nous oriente vers la prestation la moins chère.

Prêt à donner vie à votre application ?

Discutons de votre projet et voyons ensemble comment créer un produit utile, rentable et durable. Réponse sous 24 h ouvrées, y compris si votre projet ne nous correspond pas.