Application mobile : ce que c’est, et quand une entreprise en a besoin

Une application mobile a du sens pour une entreprise quand quelqu’un revient souvent vers vous — un client qui commande chaque semaine, ou un collaborateur qui coche des interventions sur son téléphone toute la journée. Si le contact est ponctuel, ou se produit quelques fois par an, un site bien construit fera le même travail, et personne n’aura rien à installer.

Cette phrase résume tout l’article. Nous expliquons ci-dessous ce qu’est une application mobile et ce qui la distingue d’un site consulté sur téléphone, nous vérifions avec des données comment vos clients utilisent réellement le web, et nous vous donnons un test simple pour trancher : application, site ou solution intermédiaire. Nous examinons à part les deux domaines où les applications trouvent le plus souvent leur place — l’application de fidélité pour les clients et l’application pour les équipes sur le terrain — ainsi que les coûts dont les offres parlent le moins : ceux que l’on paie simplement pour être présent dans les magasins d’applications, chaque année, quel que soit le nombre d’utilisateurs.

Qu’est-ce qu’une application mobile ?

Une application mobile est un programme installé sur un téléphone ou une tablette, généralement téléchargé depuis un magasin d’applications — l’App Store sur iPhone ou Google Play sur Android. Elle a sa propre icône sur l’écran d’accueil, peut fonctionner sans connexion internet et peut utiliser les fonctions du téléphone, comme l’appareil photo, la localisation ou les notifications. Un site mobile — un site responsive — est autre chose : il s’ouvre dans le navigateur à une adresse ordinaire, sans installation et sans validation par un magasin.

Si vous cherchez une définition d’application mobile au sens le plus large, Wikipédia la décrit comme un logiciel applicatif conçu pour un appareil électronique mobile — smartphone, tablette tactile — et précise que ces applications sont pour la plupart distribuées depuis des magasins d’applications. Pour une entreprise, une répartition pratique en trois types est plus utile. Ils diffèrent sur deux points : l’endroit où l’application s’installe, et qui la valide.

Une application native est écrite séparément pour chaque système — pour iOS et pour Android — dans les langages et avec les outils fournis par Apple et Google. Elle exploite au mieux les capacités du téléphone, mais elle suppose deux bases de code, deux séries de tests et deux publications.

Une application multiplateforme est construite à partir d’une seule base de code, par exemple en React Native ou en Flutter, et part dans les deux magasins sous forme de deux applications. Pour l’utilisateur, elle ressemble à une application native ; pour vous, elle signifie une seule équipe et une seule logique. Il reste deux publications et deux examens par les magasins.

Une PWA, ou progressive web app, est un site qui se comporte comme une application : on peut l’ajouter à l’écran d’accueil, elle peut fonctionner hors ligne et envoyer des notifications. Elle ne passe par aucun magasin — vous la mettez à jour comme un site, quand vous le décidez. La contrepartie : un accès plus restreint aux fonctions du téléphone, selon le système et le navigateur.

La différence qui se perd le plus souvent dans les discussions techniques ne tient pas au code, mais au chemin vers le client. Les applications natives et multiplateformes atteignent les gens par un magasin, et le magasin a ses règles : Apple ou Google examine chaque version, correction de bug comprise, avant qu’elle n’arrive chez les utilisateurs, et les règles du magasin décident de la manière dont vous pouvez encaisser des paiements dans l’application. Un site et une PWA n’ont pas cette barrière. Ce qu’elle coûte fait l’objet d’une section à part.

Téléphone ou ordinateur : comment vos clients utilisent vraiment le web

Le premier argument en faveur d’une application est souvent : « tout le monde a un smartphone aujourd’hui ». C’est vrai, mais c’est la mauvaise question. Les données montrent quelque chose de moins évident.

Selon StatCounter Global Stats, en août 2026, les ordinateurs représentaient en Suisse 55,30 % des pages vues, les téléphones 42,88 % et les tablettes 1,82 %. Parmi les téléphones, le tableau est inhabituel pour l’Europe : iOS domine avec 57,58 %, Android en compte 42,41 % (StatCounter, systèmes d’exploitation mobiles en Suisse) — à l’échelle de l’Europe, c’est l’inverse. Pour une entreprise suisse, la conséquence est pratique : la plupart des téléphones de vos clients sont des iPhone, et l’examen, les règles et les frais d’Apple décrits plus bas pèsent donc plus lourd dans la décision qu’ailleurs.

Une réserve, sans laquelle ces chiffres se lisent facilement de travers : StatCounter mesure la part des pages vues sur les sites qui portent son code, pas le nombre d’utilisateurs. Quelqu’un qui navigue au bureau toute la journée pèse davantage dans cette mesure que quelqu’un qui consulte le web sur son téléphone une fois par jour. Ce que ces proportions signifient pour la mise en page d’un site, nous le traitons dans l’article sur le responsive design.

Une moyenne nationale cache aussi ce qui compte pour vous : votre propre public. Un client professionnel qui prépare un achat est plutôt à son bureau ; quelqu’un qui réserve une coupe de cheveux est plutôt sur son téléphone. Votre outil d’analyse vous dira en une minute auquel des deux vous avez affaire — et c’est un meilleur point de départ que n’importe quel chiffre national ou européen.

On en arrive à la question qui mérite d’être posée à la place de « nos clients ont-ils un téléphone ? ». La voici : reviennent-ils vers nous depuis leur téléphone — et à quelle fréquence ? La cliente d’une boutique de vêtements regarde les nouveautés sur son téléphone en allant au travail. Un acheteur qui vous commande des pièces une fois par trimestre le fait à son ordinateur, avec un tableur ouvert à côté. Pour la première, une application peut être une commodité, si elle revient régulièrement. Pour le second, c’est une installation inutile.

Application, site ou PWA : le test de fréquence

La décision se ramène à trois questions. Posez-les séparément pour chaque groupe d’utilisateurs — clients et collaborateurs donnent presque toujours des réponses différentes.

1. À quelle fréquence cette personne revient-elle vers vous ? C’est la question qui tranche le plus. L’installation est un coût pour l’utilisateur : aller dans le magasin, télécharger, se connecter, accepter les notifications. Une icône sur l’écran d’accueil ne rembourse cet effort que si elle sert souvent — chaque jour ou chaque semaine. Quand le contact a lieu quelques fois par an, les gens préfèrent un lien depuis un moteur de recherche ou un e-mail à un programme de plus sur leur téléphone, et une application inutilisée pendant des mois finit en général supprimée la prochaine fois qu’il faut libérer de la place.

2. Avez-vous besoin de fonctions du téléphone que le navigateur gère mal ? C’est là que les malentendus sont faciles. Un site peut aussi prendre une photo, lire la position ou envoyer une notification. La différence apparaît avec le travail continu et en arrière-plan : scanner des codes pendant toute une journée de travail, enregistrer la position le long d’une tournée, des notifications qui doivent arriver quel que soit le système et le navigateur, et surtout travailler sans réseau pendant des heures. Si vous n’avez besoin de rien de tout cela, une application n’apporte aucun avantage qui justifierait un magasin et deux publications.

3. L’utilisateur a-t-il un compte et des données qui lui appartiennent ? Une application est la plus utile quand elle se souvient de quelque chose : l’historique des commandes, le solde de points, la liste des interventions du jour, un abonnement. Sans connexion, elle devient un catalogue, qu’un site affiche plus vite et pour moins cher.

Ces réponses mènent à trois voies. Si la personne revient rarement, un site qui fonctionne bien sur téléphone suffit. Si elle revient souvent et a un compte, mais n’a besoin d’aucune fonction particulière du téléphone, une PWA ou un portail client sur le site font la même chose sans magasin. Une application a du sens quand les trois réponses sont oui : retour fréquent, fonctions du téléphone que le navigateur gère mal, et données propres à l’utilisateur.

Le test a un piège : la fréquence se mesure, elle ne se suppose pas. Chaque dirigeant croit que ses clients reviennent souvent. L’outil d’analyse du site montrera quelle part des visiteurs revient dans le mois, et depuis quels appareils — et c’est ce chiffre qui ouvre la discussion sur une application, pas la liste des fonctions. Si vous voulez parcourir des questions de ce type étape par étape, faites le quiz « Site web, application web ou mobile ? ».

Il arrive aussi souvent que le test donne deux résultats différents dans une même entreprise. Les clients d’un grossiste commandent une fois par mois, depuis leur bureau : pour eux, un portail sur le site suffit. Mais ces mêmes clients sont servis par des représentants qui sont sur la route tous les jours et ont besoin de la liste de prix sans réseau : pour eux, une application se justifie. Ce n’est pas une contradiction, simplement deux groupes d’utilisateurs aux habitudes différentes, servis par le même système en arrière-plan.

Une application pour les clients : fidélité, commandes, réservations

Parmi les applications destinées aux clients, celle qu’on envisage le plus souvent est l’application de fidélité : une carte de fidélité dans le téléphone, des points à chaque achat, des bons, une notification sur une promotion dans un magasin proche. Qui tape cette expression dans un moteur de recherche verra surtout des produits standards par abonnement — et c’est un bon indice de l’endroit où commencer.

Pour la plupart des entreprises, un système de fidélité standard suffit. Un café, un salon, une chaîne de quelques magasins ou un cabinet ont des besoins semblables : attribuer des points, remettre des récompenses, envoyer des messages aux clients réguliers. Un système standard se lance rapidement, sans équipe propre et sans application à vous dans les magasins, parce que l’éditeur s’occupe de la publication et des mises à jour. Certains de ces systèmes fonctionnent même sans application séparée, par exemple avec une carte dans le portefeuille du téléphone, ce qui supprime la barrière de l’installation. Avant de choisir, vérifiez deux choses : si le système se connecte à votre caisse ou à votre boutique en ligne, et si vous pouvez exporter les données de vos clients le jour où vous voudriez changer de fournisseur.

Un module de fidélité propre a du sens dans un nombre plus restreint de situations. Quand les points doivent être calculés à partir de données que vous seul possédez — le système de commandes, l’entrepôt, l’historique du service après-vente. Quand les règles du programme sortent de l’ordinaire, qu’elles sont justement ce qui vous distingue et que les outils standards ne les prennent pas en charge. Ou quand le programme de fidélité doit faire partie d’une application plus large que les clients utilisent de toute façon. Comment trancher ce genre de choix fonction par fonction, nous le décrivons dans l’article logiciel sur mesure ou standard.

Les commandes sont le deuxième domaine naturel. Une application trouve sa place là où le client commande régulièrement les mêmes choses : un restaurant qui livre, un grossiste pour ses acheteurs réguliers, une boutique de produits achetés par cycles. Un panier, une adresse et un moyen de paiement mémorisés réduisent une commande répétée à quelques gestes. Un détail important des règles d’Apple : pour les biens physiques et les services consommés en dehors de l’application, le paiement doit passer par une autre voie que l’achat intégré, par exemple par carte ou Apple Pay (App Store Review Guidelines, section 3.1.3(e)). La commission du magasin concerne donc les contenus et fonctions numériques, pas la commande du repas de midi.

Les réservations — dans un salon, un cabinet ou une salle de sport — sont un domaine où un site avec un module de réservation et un rappel par e-mail ou SMS suffit en général. Une application ne prend l’avantage que lorsque le client réserve chaque semaine, veut voir le solde de son abonnement et l’historique de ses visites, et que vous voulez lui envoyer une notification sur un créneau qui vient de se libérer.

Une application pour les collaborateurs : service, entrepôt, tournées

S’il y a un domaine où l’application l’emporte le plus souvent, c’est celui-ci. Le test de fréquence est réussi d’emblée : un collaborateur l’utilise chaque jour, pendant toute sa journée de travail. Le compte va de soi. La barrière de l’installation disparaît aussi, puisque c’est l’entreprise qui décide de ce qui se trouve sur un téléphone professionnel, et une application interne peut être distribuée en dehors de la vitrine publique du magasin, par des canaux prévus pour les entreprises.

La fonction la plus importante d’une telle application est de fonctionner hors ligne. Un technicien descend dans une chaufferie au sous-sol, un magasinier travaille dans une halle où le réseau disparaît entre les rayonnages, un représentant parcourt une tournée dans des vallées sans connexion stable. Une application hors ligne bien conçue enregistre d’abord tout sur le téléphone — l’intervention, les photos, la signature du client, les codes scannés — et transmet les données au serveur dès que la connexion revient. Le collaborateur n’attend pas le réseau et ne perd pas un rapport à moitié rempli parce qu’une page du navigateur n’a pas pu se recharger. C’est précisément la fonction que le navigateur gère le moins bien, et c’est pourquoi l’argument en faveur d’une application est ici le plus facile à défendre.

Le travail hors ligne a un coût de conception qu’il faut nommer avant de construire : que se passe-t-il quand deux personnes sans réseau modifient la même intervention ? La règle de résolution de ces conflits — qui l’emporte, ce qui doit être fusionné, quand le système demande l’avis d’une personne — doit figurer dans le cahier des charges, et non être découverte après le premier rapport perdu.

Les usages typiques se ressemblent d’un secteur à l’autre :

• service et installation — la liste des interventions du jour, un rapport avec photos et signature du client, la commande de pièces depuis le lieu de la réparation ;
• entrepôt — le scan des codes à l’entrée et à la sortie des marchandises, l’inventaire sans listes papier ;
• vente sur le terrain — le catalogue et la liste de prix disponibles sans réseau, l’historique du client avant la visite, une commande prise sur place et transmise au système de l’entreprise dès que le réseau revient ;
• équipes de construction et de rénovation — le relevé des heures, les photos de l’avancement, les listes de contrôle de sécurité.

Dans chacun de ces cas, l’application pour les collaborateurs n’est que le point d’arrivée. Sa valeur dépend de l’endroit où vont les données : le système de gestion des interventions, celui de l’entrepôt, le CRM ou le logiciel comptable. L’intégration avec ces systèmes représente en général une plus grande part du travail que les écrans du téléphone — et c’est elle qui décide si le bureau cesse de ressaisir les rapports à la main.

Ce que coûte la simple présence dans l’App Store et Google Play

Le coût de développement d’une application reçoit beaucoup d’attention. Les coûts que l’on paie uniquement parce que l’application est dans les magasins n’en reçoivent presque aucune — et ce sont eux qui la distinguent d’un site dans un calcul sur plusieurs années.

Les frais de compte développeur. La publication dans l’App Store exige l’adhésion à l’Apple Developer Program, qui coûte 99 USD par année d’adhésion. Un compte Google Play demande des frais d’inscription uniques de 25 USD. Ce sont de petites sommes, mais les frais d’Apple reviennent chaque année, et sans eux l’application disparaît du magasin.

Les commissions sur les ventes numériques. Si vous vendez dans l’application un abonnement, des contenus premium ou des fonctions débloquées, les règles d’Apple imposent l’achat intégré, sur lequel Apple prélève une commission de 30 %, ou de 15 % dans l’App Store Small Business Program. Apple mentionne des taux de commission et des frais différents pour certaines applications au Brésil, dans l’Union européenne, au Japon, aux Pays-Bas, en Russie et en Corée du Sud ; la Suisse ne figure pas sur cette liste, et les options de paiement alternatives qu’Apple propose dans les vitrines de l’UE ne s’étendent pas à l’App Store suisse. Faites vos calculs de revenus sur les conditions standards. Comme indiqué plus haut, les commandes de biens physiques et de services consommés en dehors de l’application passent par une autre voie de paiement.

Les exigences annuelles de mise à jour — c’est le poste le plus cher. Les systèmes d’exploitation des téléphones changent chaque année, et les magasins vous obligent à suivre. Depuis le 31 août 2026, Google Play n’accepte les nouvelles applications et les mises à jour que si elles ciblent Android 16, et les applications existantes qui ne ciblent pas au moins Android 15 ne sont plus proposées aux nouveaux utilisateurs sur les versions récentes du système (exigences de Google Play). L’exigence avance chaque année. Cela signifie qu’une application ne peut pas être « construite puis laissée » : même sans ajouter de fonctions, quelqu’un doit la recompiler régulièrement, la tester sur les nouvelles versions du système et la republier, séparément pour chaque magasin.

Un site a ses propres coûts — le domaine, le serveur, la maintenance —, mais il n’a ni barrière de magasin, ni commission de magasin, ni échéance après laquelle il cesse d’être visible pour de nouveaux utilisateurs.

Ce que coûte le développement de l’application elle-même dépend avant tout du périmètre — le nombre d’écrans, les intégrations, le travail hors ligne, une plateforme ou deux. Nos propres fourchettes de prix pour les applications natives et multiplateformes figurent sur la page consacrée à nos applications mobiles pour les entreprises.

Par où commencer

Pour une application destinée aux clients, l’ordre le plus sûr est d’abord le site ou la PWA, ensuite l’application. Construisez d’abord sur le site la fonction que vous aimeriez avoir dans l’application — la commande répétée, le portail client, le solde de points. Après quelques mois, votre outil d’analyse montrera combien de clients l’utilisent, à quelle fréquence ils reviennent et depuis quels appareils. S’ils reviennent souvent, depuis leur téléphone, et qu’il leur manque quelque chose que le navigateur ne peut pas leur donner, vous tenez un argument en faveur d’une application fondé sur des données plutôt que sur une intuition. Aucun de ces travaux n’est perdu : la logique côté serveur, les données et les intégrations restent les mêmes, et l’application devient une fenêtre de plus sur le même système.

Pour une application interne, l’ordre peut s’inverser, puisque le test de fréquence est réussi d’emblée. Commencez toutefois par un seul processus — un rapport d’intervention ou la réception des marchandises, par exemple — plutôt que par un système qui pilote toute l’entreprise. Un seul parcours qui fonctionne hors ligne et envoie les données là où elles doivent aller en montrera davantage qu’un cahier des charges de plusieurs dizaines de pages. Vous ajoutez d’autres fonctions quand l’équipe les demande. Avant de construire, parlez à trois ou quatre des personnes qui utiliseront l’application : où perdent-elles du temps aujourd’hui, et où n’ont-elles pas de réseau ?

Plus largement, quels problèmes les applications résolvent dans une entreprise et quand un outil standard suffit, nous le traitons dans le guide des logiciels d’entreprise. Et la manière dont nous concevons et développons des applications mobiles pour les entreprises — natives et multiplateformes, avec intégrations et travail hors ligne — est décrite sur la page de service.

D’où viennent ces chiffres

• La part des ordinateurs, des téléphones et des tablettes, et celle des systèmes d’exploitation mobiles, en Suisse — StatCounter Global Stats, août 2026 ; part des pages vues sur les sites suivis par StatCounter, pas nombre d’utilisateurs.
• Frais et commissions des magasins — les pages Apple Developer Program et Google Play Console, les règles de paiement des App Store Review Guidelines (sections 3.1.1 et 3.1.3(e)), la page d’Apple sur les applications dans l’UE et les exigences de version Android de Google Play, vérifiées le 22 septembre 2026.
• Définition d’une application mobile — Wikipédia, article « Application mobile ».