Une application publiée sur l’App Store et le Play Store coûte plus cher à concevoir, doit être validée par Apple et Google, doit être installée par vos clients, et doit être maintenue à chaque nouvelle version d’iOS et d’Android. Ce sont quatre contraintes réelles.
Elles se justifient parfaitement dans certains cas. Mais si votre besoin est « qu’on puisse commander depuis un téléphone », un site conçu pour le mobile fait le travail, coûte nettement moins cher, et ne demande à personne d’installer quoi que ce soit.
Répondez franchement — l’outil ne vend rien, il compte des points.
Question 1 sur 6
À quelle fréquence un même utilisateur s’en servira-t-il ?
C’est le critère le plus déterminant. Une icône sur l’écran d’accueil ne se justifie que par l’habitude.
Question 2 sur 6
Avez-vous besoin de notifications push ?
Sur iPhone, les notifications web restent limitées et supposent que le site soit ajouté à l’écran d’accueil.
Question 3 sur 6
Avez-vous besoin du matériel du téléphone ?
Appareil photo avancé, Bluetooth, NFC, géolocalisation en arrière-plan, lecture de codes-barres intensive.
Question 4 sur 6
L’outil doit-il fonctionner sans réseau ?
Sous-sol, chantier, zone blanche, avion.
Question 5 sur 6
À qui s’adresse l’outil ?
Un public captif installe volontiers. Un public de passage, non.
Question 6 sur 6
Que voulez-vous qu’il se passe si quelqu’un vous découvre sur Google ?
Une application ne se référence pas dans les résultats de recherche. Un site, si.
Verdict
Un site conçu pour le mobile suffit.
Votre besoin ne demande ni installation, ni notifications natives, ni accès au matériel. Un site rapide et pensé pour le pouce coûtera nettement moins cher, sera trouvé sur Google, et ne demandera rien à vos utilisateurs. C’est la réponse la plus fréquente, et de loin.
Voir la création de siteVerdict
Commencez par le site, gardez l’application en seconde étape.
Quelques critères plaident pour une application, mais pas assez pour en faire le point de départ. La démarche saine : un site mobile d’abord, on observe l’usage réel, et on développe l’application une fois qu’on sait précisément ce que les gens font. Beaucoup d’applications meurent d’avoir été conçues avant.
Commencer par le siteVerdict
Une application se justifie.
Usage fréquent, notifications, matériel du téléphone ou fonctionnement hors réseau : vous cumulez les critères qui rendent le navigateur insuffisant. Reste à décider entre iPhone seul, Android seul ou les deux — et ça, ça se tranche sur votre parc réel d’utilisateurs, pas sur les parts de marché nationales.
Voir le développement d’applicationLes trois options, sans jargon
Du plus léger au plus lourd. Chaque marche ajoute des possibilités, du coût et de la maintenance.
La marche du milieu est la grande oubliée des projets. Elle couvre une bonne part des besoins réels pour une fraction du coût d’une application.
Ce qu’une application coûte après la livraison
C’est le poste que les devis oublient. Une application n’est pas un livrable figé : elle vit dans un environnement qui change deux fois par an, sans vous demander votre avis.
- Les comptes développeurApple et Google facturent l’accès à leurs stores, à l’année.
- Les mises à jour d’iOS et d’AndroidUne par an chacune, qui peut casser des fonctions ou imposer des changements.
- Les règles des storesElles évoluent, et une application non conforme est retirée sans négociation.
- La double publicationChaque correction doit être soumise, validée, puis installée par les utilisateurs.
- Le serveur derrièreUne application sans back-office ne fait pas grand-chose. C’est souvent la moitié du projet.
iPhone, Android, ou les deux ?
La question se tranche sur votre parc, pas sur les statistiques nationales. Une application destinée à vos équipes se cible sur les téléphones qu’elles ont réellement. Une application grand public part généralement sur les deux, mais rien n’empêche de sortir d’abord sur la plateforme majoritaire chez vos utilisateurs et d’observer.
Techniquement, un même code peut alimenter les deux stores. Cela coûte nettement moins cher que deux développements séparés, et convient à la grande majorité des applications métier. Le développement natif séparé ne se justifie que sur des besoins graphiques ou matériels très poussés.