Créer une application mobile pour son entreprise : le guide du dirigeant

La plupart des projets d'application commencent par une liste d'écrans. C'est le mauvais point de départ. Une application d'entreprise réussie se décide d'abord sur des questions moins visibles : qui l'utilise et dans quelles conditions, que se passe-t-il quand le réseau disparaît, quel outil la pilote depuis le bureau, et qui la fera vivre après sa publication.

Ce guide s'adresse aux dirigeants de PME et d'ETI qui envisagent une application, pour leurs équipes ou pour leurs clients. Il ne donne pas de prix : le budget dépend de ces décisions, et nous les détaillons dans la page combien coûte une application mobile.

D'abord : à qui sert l'application ?

Il existe deux grandes familles d'applications d'entreprise, et elles ne se conçoivent pas de la même façon.

Pour une application interne, la question des appareils se pose vite. Selon le Baromètre du numérique 2026 réalisé par le Crédoc pour l'Arcep, 99 % des actifs occupés disposent d'un téléphone mobile et 49 % d'un appareil professionnel. Équiper une équipe ne suppose donc pas toujours d'acheter des téléphones, mais il faut décider si l'application tournera sur des appareils personnels, ce qui pose des questions de confidentialité et de support.

La distribution aussi diffère. Une application destinée aux salariés n'a pas besoin d'être visible de tous : Apple permet de distribuer des applications personnalisées de façon privée, par Apple Business Manager. C'est ce que nous avons fait pour Cap Vert, dont l'application iOS a été publiée en application personnalisée puis déployée sur la flotte d'appareils de l'entreprise.

Natif, multiplateforme ou application web : le choix technique

Trois approches coexistent. Aucune n'est meilleure dans l'absolu.

Pour une nouvelle application, nous partons en général de Flutter. Le framework de Google utilise un seul code en Dart et son propre moteur de rendu, ce qui donne une interface identique sur les deux systèmes. React Native, publié par Meta, reste un très bon choix quand une équipe travaille déjà en React sur le web. Le détail est dans notre comparatif Flutter ou React Native.

Le natif garde sa place quand le matériel impose ses règles. Pour Sakura France Service, l'application tourne dans un robot de livraison OrionStar dont le kit de développement est prévu pour Android : nous l'avons donc écrite en Kotlin, au plus près du système du robot.

Côté parc, les deux systèmes comptent. En France, Statcounter attribue en septembre 2026 environ 65 % des pages vues sur mobile à Android et 35 % à iOS. Sauf cas particulier, une application client doit couvrir les deux, ce qui plaide pour un code unique. Quant à l'application web installable, ses limites sur iPhone (stockage, notifications, durée de conservation des données) sont détaillées dans le comparatif PWA ou application native.

Le mode hors ligne : la fonctionnalité qui décide de tout sur le terrain

Une application terrain qui exige du réseau est inutilisable dans un sous-sol, un parking, une zone industrielle ou à la campagne. Le mode hors ligne n'est pas une option à ajouter à la fin : il structure toute l'application.

Il faut décider dès le départ :

• Ce qui est disponible sans réseau : le planning du jour, les fiches clients, l'historique utile, les documents de référence.
• Ce qui est enregistré localement : rapports, photos, signatures, relevés, et dans quel ordre ils seront envoyés.
• Ce qui se passe en cas de conflit : deux personnes ont modifié la même fiche, l'une hors ligne et l'autre au bureau.
• Ce que voit l'utilisateur : un indicateur clair de ce qui reste à envoyer, pour qu'il ne se demande jamais si son travail est parti.

Pour Cap Vert, entreprise de nettoyage de stations-service, de stations de lavage et de panneaux solaires, les équipes rédigent sur place des rapports d'intervention avec photos et signatures. Le PDF est généré sur le téléphone, et les photos, les PDF et les e-mails sont mis en file d'attente puis envoyés automatiquement au retour du réseau. C'est cette mécanique, invisible quand tout va bien, qui permet à un technicien de finir son rapport sur le site plutôt que le soir.

Le back-office : la moitié invisible du projet

Chaque application a une face cachée : l'outil depuis lequel le bureau prépare le travail, suit ce qui remonte du terrain et gère les comptes. Les maquettes de l'application ne le montrent pas, et c'est souvent lui qui pèse le plus lourd dans le projet.

Chez Cap Vert, l'application mobile s'appuie sur un tableau de bord web qui regroupe le planning des équipes, les fiches clients et chantiers, les interventions et les rapports. Pour le Tapas Tour organisé par Grupo Rouleaux, l'application publique (carte, fiches, vote par QR code, cinq langues) est pilotée par un back-office qui gère l'édition, les restaurants, les QR codes, les résultats et les rôles des utilisateurs.

Un back-office bien conçu répond à trois questions : qui peut voir et modifier quoi, comment le bureau sait ce qui se passe sur le terrain, et comment les données repartent vers vos autres outils (facturation, comptabilité, ERP). Sur ce dernier point, voyez notre page sur la connexion de vos outils par API.

Publication et vie de l'application

Publier sur l'App Store et Google Play demande des comptes développeur au nom de votre entreprise. Selon leurs pages officielles relevées en octobre 2026, l'inscription coûte 99 dollars par an chez Apple et 25 dollars en un versement unique chez Google. Chaque version est ensuite examinée par les stores avant publication, et une application refusée doit être corrigée puis soumise à nouveau.

Nous recommandons que ces comptes soient ouverts au nom de votre entreprise, et non du prestataire : c'est une condition pour rester propriétaire de votre application. La procédure est détaillée dans comment publier une application sur les stores.

Une application ne se publie pas une fois pour toutes. Les deux systèmes évoluent chaque année et les stores imposent des minimums : Apple exige depuis le 28 avril 2026 que les applications soumises soient compilées avec Xcode 26 et le SDK d'iOS 26, et Google Play fixe un niveau d'API Android cible minimal pour les nouvelles applications et les mises à jour. Sans maintenance, une application finit par ne plus pouvoir être mise à jour, puis, sur Google Play, par ne plus être proposée aux nouveaux utilisateurs des versions récentes d'Android. La maintenance fait partie du projet dès le départ.

Trois cas réels

Cap Vert : remplacer un outil hérité sans arrêter l'activité. Un tableau de bord web et une application iOS et Android pour les équipes, la reprise de près de 10 000 enregistrements depuis l'ancienne base sans perte, un fonctionnement hors ligne complet et une bascule des équipes en août 2026.

Tapas Tour : une date d'événement impossible à décaler. Une application publique où le public vote pour ses tapas préférées par scan de QR code, avec un dispositif contre la fraude, en cinq langues, livrée avec son back-office, son API et une boutique en ligne pour la date de l'édition 2026.

Sakura France Service : une application dans un robot. Une application Android embarquée dans un robot de livraison, utilisée dans un cabinet d'orthodontie, avec un tableau de bord servi par le robot lui-même et un moteur de missions. Plus de 50 versions ont été itérées et testées sur place avant la mise en service en août 2026.

Ces projets n'ont pas grand-chose en commun en apparence. Ils partagent pourtant la même méthode : comprendre les conditions réelles d'utilisation avant de dessiner les écrans.

Ce qui fait varier le budget

Le nombre d'écrans n'explique presque rien. Ce qui fait varier le budget, ce sont :

1. Le back-office et le nombre de profils d'utilisateurs.
2. Le mode hors ligne et la gestion des conflits de synchronisation.
3. Les intégrations : paiement, cartographie, matériel (Bluetooth, lecteurs, imprimantes), et surtout vos logiciels existants.
4. La reprise de données d'un ancien outil.
5. La publication et la distribution (publique ou privée).
6. La maintenance après la mise en service.

Chez YMHB Web, ces points sont tranchés pendant le cadrage, puis le budget est fixé en forfait global ferme. Le code et les données vous appartiennent au paiement intégral. Pour réduire la première dépense sans fragiliser la suite, la bonne approche reste une première version centrée sur le parcours qui a le plus de valeur : notre guide du MVP d'une application explique comment la délimiter.

Une méthode en quatre temps

1. Cadrage : utilisateurs, conditions d'usage, parcours prioritaires, données, intégrations, indicateurs de succès.
2. Maquettes : validées par de futurs utilisateurs avant le développement.
3. Développement par versions courtes, testées sur de vrais appareils et sur le terrain.
4. Publication, mise en service et maintenance, avec un interlocuteur qui connaît l'application.

Le fondateur suit votre projet du premier rendez-vous à la mise en service. Pour en savoir plus sur l'offre, consultez notre page applications pour équipes terrain ou la page solution application mobile pour équipes terrain.

Pour aller plus loin

• Flutter ou React Native : quel framework pour votre application
• Flutter ou développement natif (Swift, Kotlin)
• Application web ou application mobile
• Digitaliser les bons d'intervention jusqu'à la facture
• Applications mobiles en France : chiffres clés 2026
• Comment récupérer le code source de son application ?

Sources

• Crédoc pour l'Arcep, l'Arcom, le CGE et l'ANCT, Baromètre du numérique, édition 2026 (mis à jour le 9 février 2026) : arcep.fr (nouvel onglet)
• Statcounter Global Stats, Mobile Operating System Market Share France, septembre 2026 : gs.statcounter.com (nouvel onglet)
• Apple, Volume Purchase and Custom Apps (distribution privée par Apple Business Manager), consulté le 8 octobre 2026 : developer.apple.com (nouvel onglet)
• Apple, Apple Developer Program (tarif relevé en octobre 2026) : developer.apple.com/programs (nouvel onglet)
• Aide Play Console, Premiers pas avec la Play Console (frais d'inscription de 25 dollars, relevés en octobre 2026) : support.google.com (nouvel onglet)
• Apple, Upcoming Requirements (Xcode 26 et SDK iOS 26 exigés depuis le 28 avril 2026) : developer.apple.com/news/upcoming-requirements (nouvel onglet)
• Android Developers, exigence de niveau d'API cible pour Google Play, consulté le 8 octobre 2026 : developer.android.com (nouvel onglet)
• Flutter, Flutter architectural overview, consulté le 8 octobre 2026 : docs.flutter.dev (nouvel onglet)
• YMHB Web, études de cas Cap Vert, Tapas Tour et Sakura France Service, publiées sur ymhb-web.com (2026).