Application mobile ou site web : lequel choisir pour votre projet ?

Si vos futurs utilisateurs doivent vous trouver sur Google, commencez par un site web. S'ils ont besoin du GPS, de l'appareil photo, d'un accès sans réseau ou de notifications quotidiennes, il vous faut une application mobile. Et pour une bonne partie des projets qu'on m'apporte, la meilleure décision est de commencer par le web, puis d'ajouter l'application le jour où un usage régulier est prouvé.

Voilà la version courte. La version longue, c'est que « application ou site web » n'est presque jamais une question technique. C'est une question d'usage. Je vous propose de la remplacer par sept questions concrètes, auxquelles vous pouvez répondre vous-même, sans être développeur. Ensuite, la décision se prend presque toute seule.

À quelle fréquence votre utilisateur va-t-il revenir ?

C'est la question qui tranche le plus souvent, et celle qu'on saute le plus souvent.

Installer une application, c'est un effort payé d'avance par l'utilisateur : chercher le bon nom dans le store, télécharger, créer un compte. Il accepte de payer cet effort quand il sait qu'il reviendra. Pour un usage ponctuel — commander une fois, réserver un créneau, consulter un tarif — personne ne veut installer quoi que ce soit. Le site web gagne, sans discussion.

Le test que j'utilise avec mes clients est volontairement brutal : votre utilisateur accepterait-il de garder votre icône sur son écran d'accueil, à côté de sa messagerie, pendant des mois ? Si la question vous fait hésiter, vous avez votre réponse.

Comment vos utilisateurs vont-ils vous découvrir ?

Le web et les stores sont deux mondes de découverte très différents.

Un site web est indexable : on vous trouve en cherchant votre métier, votre ville, votre problème. Un lien se partage dans un message, un mail, un QR code sur une vitrine, et il s'ouvre au clic, sans rien installer. C'est aussi ce que lisent les moteurs de recherche et les assistants IA quand ils répondent à une question.

Un store, lui, fonctionne surtout quand on connaît déjà le nom de l'application ; on s'y rend rarement au hasard. Une application se recommande, se prescrit, s'adresse à une audience qui vous connaît déjà : clients sous contrat, adhérents, collaborateurs, communauté.

Donc : si votre acquisition repose sur la recherche, le site web n'est pas une option, c'est le socle. Si vous avez déjà une audience captive, l'application devient défendable.

Avez-vous besoin du téléphone, ou seulement d'un écran ?

Certaines fonctions ne s'improvisent pas dans un navigateur : le suivi GPS continu même quand l'écran est éteint, les capteurs, le Bluetooth, un usage prolongé sans réseau, l'appareil photo intégré à un vrai flux de travail.

En Plein Air en est le cas d'école. C'est une application iOS de randonnée que j'ai conçue : elle guide sur le tracé mètre par mètre, alerte quand on sort du sentier, suggère des emplacements de bivouac et affiche la météo Météo-France corrigée de l'altitude — le tout consultable sans réseau. En montagne, il n'y a pas de réseau. Le besoin impose le mobile, il n'y a rien à arbitrer. À côté, le catalogue de sentiers vit sur le web : c'est là qu'on prépare une sortie et qu'on partage un itinéraire.

Le contre-exemple est tout aussi instructif. Omne est une boîte à outils qui tourne entièrement dans le navigateur : aucun fichier n'est envoyé sur un serveur, tout est traité sur la machine de l'utilisateur. Beaucoup croient encore que ce genre de chose exige une application installée. C'est faux depuis longtemps.

Entre ces deux extrêmes, la majorité des projets — catalogue, réservation, formulaire, espace client, paiement, prise de rendez-vous — n'a besoin de rien d'autre que d'un navigateur.

Les notifications push justifient-elles à elles seules une application ?

C'est l'argument le plus solide en faveur du mobile : une application peut revenir vers l'utilisateur, un site web l'attend. Quand votre service repose sur une alerte à un instant précis, la question est vite tranchée.

Mais posez-vous d'abord la vraie question : qu'allez-vous envoyer, et à quelle fréquence ? Si vous n'avez rien d'utile à dire chaque semaine, les notifications ne sauveront pas une application que personne n'ouvre — elles la feront désinstaller. Pour un rappel de rendez-vous ou une confirmation, un e-mail ou un SMS fait le travail.

Un paiement dans l'application ? Regardez la commission des stores

C'est le point qui surprend le plus mes clients. Quand vous vendez du contenu numérique ou un abonnement consommé dans l'application, Apple et Google imposent en général leur propre système d'achat et prélèvent une commission. Les règles évoluent selon les pays et les cas, mais le principe reste : ce n'est pas vous qui décidez.

En revanche, vendre un bien physique ou une prestation réalisée hors de l'application ne relève pas de ce système. C'est le cas du 28, un snack asiatique à Villejuif dont j'ai fait le site avec Click and Collect : on cherche le restaurant sur Google, on commande, on passe récupérer sa commande. Un site web suffit, la commission ne se pose jamais, et personne n'aurait installé une application pour ça.

La validation par l'App Store et le Play Store

Sur le web, quand je corrige un bug, je déploie et c'est corrigé pour tout le monde, immédiatement.

Sur mobile, chaque version passe par une revue avant publication. Le délai ne dépend pas de vous. Un refus est toujours possible — confidentialité, suppression de compte, connexion, paiement, contenu — et il faut alors corriger puis repasser en revue. Ajoutez que vos utilisateurs ne mettent pas tous leur application à jour : plusieurs versions cohabitent dans la nature. Une contrainte de rythme, à connaître avant de s'engager.

La maintenance : deux régimes très différents

Un site web vieillit lentement. Les navigateurs évoluent en restant compatibles, et personne ne vous impose de calendrier.

Une application mobile vit sous un calendrier imposé : iOS et Android sortent une version majeure chaque année, les stores exigent régulièrement des mises à jour techniques pour rester publiable, les certificats et les comptes développeur se renouvellent. Même une application « finie » demande un entretien périodique pour rester téléchargeable. C'est un poste de budget récurrent, pas un détail.

La PWA, la voie intermédiaire — et ses limites sur iOS

La PWA (Progressive Web App) est un site web qui peut s'installer sur l'écran d'accueil, s'ouvrir en plein écran sans barre de navigateur et continuer de fonctionner hors ligne grâce à un cache. Une seule base de code, référencée par Google, sans passer par un store.

En pratique, je la recommande dans un cas précis : une audience connue, à qui vous pouvez expliquer comment l'installer — outil interne, back-office, application métier.

Ses limites méritent d'être dites franchement, surtout sur iOS. L'installation se fait à la main depuis le navigateur, une manipulation que beaucoup d'utilisateurs ne feront jamais spontanément, et les notifications n'y sont possibles qu'après cet ajout à l'écran d'accueil. L'accès aux capteurs et le travail en arrière-plan restent plus restreints qu'en natif, et le système peut faire le ménage dans les données stockées après une longue période sans ouverture. Enfin, pas de présence dans les stores : ni découverte, ni facturation, ni l'effet de crédibilité que certains dirigeants attendent d'une fiche App Store.

Si vous comptez sur le store pour être trouvé, ou si votre produit a besoin du matériel en profondeur, la PWA n'est pas la réponse. Sinon, elle évite beaucoup de complexité.

Si vous avez tranché pour le mobile

Si vous avez tranché pour le mobile, la question suivante est le choix de la technologie : elle a des conséquences directes sur le coût comme sur le délai.

Dans tous les cas, ce qui fait la différence, c'est la qualité de ce que vous transmettez au départ : voici comment préparer le brief avant de consulter un développeur. Vous pouvez aussi parcourir mes réalisations pour voir ces arbitrages une fois livrés.

Ma grille de décision

Ce que vous constatez	Ce qui l'emporte
Usage ponctuel, quelques fois par an	Site web
Découverte par la recherche Google	Site web
Usage quotidien ou hebdomadaire	Application mobile
Besoin de fonctionner sans réseau	Application mobile
GPS en continu, capteurs, Bluetooth	Application mobile
Notifications à un instant précis	Application mobile
Vente d'abonnement numérique	Site web (paiement direct)
Audience captive, installation explicable	PWA
Budget de maintenance serré	Site web ou PWA

Prenez un site web si…

• votre acquisition passe par la recherche et le bouche-à-oreille en ligne ;
• l'usage est ponctuel, saisonnier ou lié à un achat précis ;
• vous vendez un produit physique ou une prestation réalisée hors de l'écran ;
• vous voulez pouvoir corriger et faire évoluer sans attendre une validation ;
• c'est votre premier lancement et vous devez encore valider la demande.

Prenez une application mobile si…

• l'usage est fréquent et fait partie d'une routine ;
• le service a besoin du hors-ligne, du GPS, des capteurs ou de l'appareil photo ;
• les notifications sont au cœur de la valeur, pas un ajout cosmétique ;
• votre audience vous connaît déjà et vous n'avez pas à la conquérir dans un store ;
• vous acceptez le rythme des stores et le budget d'entretien qui va avec.

Prenez les deux si…

• la découverte se fait sur le web mais l'usage quotidien se fait sur le terrain, comme pour En Plein Air ;
• vous devez d'abord convaincre un large public, puis équiper un noyau d'utilisateurs fidèles ;
• vos statistiques web montrent déjà qu'une part importante de vos visiteurs revient souvent : l'application répond alors à un besoin observé, pas supposé.

En discuter sur votre projet

Cette grille couvre l'essentiel, mais chaque projet a son détail qui change tout : une contrainte de terrain, un mode de facturation, un public particulier. Si vous hésitez encore, décrivez-moi votre cas et je vous dirai franchement ce que je ferais, y compris si la réponse est « vous n'avez pas besoin d'une application ». Écrivez-moi.