Chaque année, des milliers d'entreprises françaises lancent un projet d'application mobile. Beaucoup posent la mauvaise question en premier. Elles demandent combien coûte une application, avant de vérifier si elles en ont besoin.
Or la différence entre une application et un site adapté au mobile ne relève pas de la technique. Elle relève de l'usage. Ce choix conditionne ensuite tout le projet de création d'application mobile, du budget au calendrier de livraison.
Voici les critères qui permettent de trancher, avant d'engager le moindre euro.
Un site adapté au mobile reste un site web. Il s'affiche dans un navigateur et se réorganise selon la taille de l'écran. L'internaute y accède par un lien, sans rien installer.
Une application se télécharge depuis un magasin, l'App Store ou Google Play. Elle s'installe sur le téléphone, y pose une icône, et fonctionne comme un programme à part entière.
La distinction commerciale tient en une phrase. Un site sert la découverte, une application sert la répétition.
Cette nuance décide de tout. Un visiteur qui vous découvre par une recherche ne téléchargera pas une application pour une visite unique. Il faudrait lui demander un effort disproportionné, pour un besoin ponctuel.
Autrement dit, une application ne crée pas d'audience. Elle retient celle que vous possédez déjà.
Cinq questions suffisent à orienter la décision. Trois réponses favorables à l'application justifient le projet. Moins de trois, et un site adapté au mobile suffit largement.
À quelle cadence votre client revient-il ? Une fois par an pour un devis de travaux, ou trois fois par semaine pour suivre une commande ?
Sous une utilisation hebdomadaire, l'application reste difficile à défendre. L'icône dort sur l'écran, puis l'utilisateur la supprime pour libérer de la mémoire.
Ce critère élimine à lui seul une bonne part des projets. Un service consulté deux fois par an ne mérite pas une place permanente sur un téléphone.
Une application stocke des données sur le téléphone. Elle continue de fonctionner dans un tunnel, sur un chantier ou dans un entrepôt sans réseau.
Un site web s'arrête net dès que la connexion tombe. Pour des équipes terrain, ce seul critère justifie parfois le projet à lui seul.
La notification reste le vrai avantage de l'application. Elle vous donne un accès direct à l'écran de votre client, sans passer par sa boîte mail.
Cet avantage se retourne vite. Une notification mal dosée provoque la désinstallation en quelques jours. Beaucoup d'entreprises sous-estiment cette fragilité.
La règle tient en une ligne. Une notification doit rendre un service au destinataire, jamais servir uniquement l'émetteur. Un rappel de rendez-vous passe. Une promotion hebdomadaire lasse.
Appareil photo, position, capteurs, lecture de codes-barres, paiement sans contact. Une application accède à ces fonctions de façon complète et fluide.
Un site web y accède partiellement, avec des limites variables selon le navigateur. Si votre service repose sur la caméra ou la géolocalisation continue, l'arbitrage penche vers l'application.
Un site adapté au mobile se livre en quelques semaines. Une application réclame plusieurs mois, du cadrage à la publication sur les magasins.
Le contrôle des magasins ajoute un délai que peu d'entreprises anticipent. Apple et Google examinent chaque version avant sa mise en ligne, et refusent celles qui ne respectent pas leurs règles.
Une fois la décision prise, une seconde question arrive. Elle porte sur la méthode de développement.
Le développement natif construit une application par système. Une version en Swift pour iOS, une version en Kotlin pour Android. Les performances atteignent leur maximum, mais vous financez et maintenez deux projets distincts.
Le développement multiplateforme repose sur un code unique, déployé sur les deux systèmes. Flutter et React Native dominent ce terrain aujourd'hui.
Pour une entreprise qui lance son premier projet, l'approche multiplateforme se défend presque toujours. Elle réduit le coût de départ et divise la charge de maintenance.
Le natif garde sa pertinence sur des usages exigeants. Les jeux, la réalité augmentée ou le traitement vidéo lourd justifient encore deux bases de code séparées.
Un repère utile pour arbitrer. Posez la question du volume d'utilisateurs attendu la première année. En dessous de quelques milliers, le multiplateforme couvre le besoin sans compromis visible.
Une erreur revient dans presque tous les projets. L'entreprise budgète le développement, puis découvre les coûts qui suivent la livraison.
Une application n'est jamais terminée. Apple et Google publient chaque année de nouvelles versions de leurs systèmes. Sans mise à jour, une application cesse de fonctionner correctement, puis disparaît des magasins.
Comptez donc une enveloppe annuelle de maintenance dès le premier devis. Les comptes développeurs des deux magasins s'ajoutent à cette ligne, avec un abonnement annuel pour Apple et des frais d'inscription pour Google.
À cela s'ajoutent l'hébergement des données et le suivi des retours utilisateurs. Un projet correctement chiffré intègre ces postes dès le départ.
Beaucoup d'entreprises veulent une application parce que leurs concurrents en ont une. Ce raisonnement produit des projets coûteux et des applications désinstallées.
La question utile est ailleurs. Que fera votre client dans cette application, qu'il ne peut pas faire sur votre site ?
Si la réponse tient en une phrase claire, votre projet a du sens. Si elle demande un paragraphe d'explications, un site adapté au mobile répondra mieux, pour une fraction du budget.
