Développement d’application mobile en entreprise : le budget ne s’arrête pas au lancement

Développement d’application mobile en entreprise : le budget ne s’arrête pas au lancement

Faire développer une application mobile pour son entreprise commence par un arbitrage : adapter une solution existante ou créer un outil sur mesure. La bonne décision dépend des usages, des données à connecter et des contraintes du terrain. Avant de comparer les agences, définissez le service attendu, les appareils concernés et les conditions d’utilisation. Ces éléments permettent d’obtenir des propositions réellement comparables, au-delà du prix annoncé.

Partir d’un problème métier, pas d’une liste de fonctionnalités

Le développement d’une application mobile d’entreprise consiste à concevoir un logiciel utilisable sur smartphone ou tablette, connecté si nécessaire au système d’information. Il peut servir les collaborateurs, les clients ou les partenaires. Sa valeur tient moins au nombre d’écrans qu’à sa capacité à simplifier une tâche récurrente.

Étapes du développement d’une application mobile d’entreprise, du cadrage au déploiement
Étapes du développement d’une application mobile d’entreprise, du cadrage au déploiement

Un technicien peut consulter son planning et transmettre un compte rendu depuis un chantier. Un commercial peut retrouver une fiche client, un devis ou une facture pendant un rendez-vous. Pour un client, l’intérêt peut être de suivre une demande sans appeler le service concerné. Chaque usage appelle des parcours et des droits d’accès différents.

Définir une première version réellement utile

Réunissez un responsable métier, un représentant du système d’information et des utilisateurs. Décrivez la tâche actuelle, ses difficultés et le résultat recherché. Associez ensuite chaque fonctionnalité à un indicateur : délai de transmission d’un rapport, ressaisies évitées ou proportion d’interventions clôturées sur mobile.

  • Indispensable : accomplir le parcours principal et accéder aux informations nécessaires.
  • À arbitrer : notifications, recherche avancée ou documents complémentaires.
  • À différer : fonctions secondaires qui ne conditionnent pas l’utilité initiale.

Ce périmètre forme le produit minimum viable, ou MVP. Il doit permettre de travailler, pas seulement de présenter une démonstration. Vérifiez aussi si votre logiciel de gestion propose déjà une extension mobile : le sur-mesure se justifie lorsque les solutions existantes ne répondent pas suffisamment aux contraintes métier.

Choisir la technologie selon les appareils et les usages

Le choix entre iOS et Android précède celui du langage. Pour une flotte interne, partez des appareils effectivement déployés. Pour une application destinée aux clients, étudiez leur équipement. IBM indique qu’environ 70 % des smartphones fonctionnent sous Android ; cette proportion générale ne remplace toutefois pas l’analyse de votre public.

Les recommandations de la CNIL pour des applications mobiles conformes — Découvrez les bonnes pratiques officielles pour recueillir le consentement et protéger les données personnelles dans les applications mobiles.

ApprochePrincipePoint à vérifier
NativeDéveloppement spécifique à chaque système, notamment en Swift pour iOS ou Kotlin pour Android.Effort nécessaire pour développer et maintenir plusieurs versions.
HybrideTechnologies web intégrées dans une application installable.Performances et accès aux fonctions du téléphone selon les composants utilisés.
Cross-platformCode largement mutualisé avec des outils comme Flutter ou React Native.Adaptations propres à chaque plateforme et disponibilité des modules nécessaires.
PWAApplication web accessible depuis un navigateur, avec certaines capacités applicatives.Compatibilité des fonctions attendues selon le navigateur et le système.

Aucune approche n’est systématiquement la moins chère ou la plus adaptée. Une base de code commune n’élimine ni les tests sur chaque plateforme ni les adaptations spécifiques. Demandez au prestataire de justifier son choix à partir de vos contraintes : appareil photo, géolocalisation, périphériques, hors-ligne ou exigences de fluidité.

Pour une fonction critique, exigez une validation technique précoce sur les appareils visés. Un prototype ciblé est plus utile qu’une promesse générale de compatibilité.

Traiter les données, le hors-ligne et la sécurité dès le cadrage

Une application métier ne doit pas devenir une base isolée. Identifiez les informations issues du CRM, de l’ERP ou de la gestion documentaire, puis les opérations autorisées : consulter, créer, modifier, valider. Les API, interfaces d’échange entre logiciels, permettent d’organiser ces communications, sous réserve que les systèmes concernés les proposent.

Prévoir ce qui se passe lorsque le réseau disparaît

Précisez les données consultables hors connexion, les actions enregistrées localement et les règles de synchronisation. Si deux personnes modifient la même fiche, laquelle fait référence ? L’utilisateur doit pouvoir distinguer un enregistrement local d’une transmission confirmée, sans risquer de perdre son travail.

Les retours de connexion peuvent produire un effet de marée : après une tournée en zone mal couverte, plusieurs appareils transmettent simultanément leurs rapports, photos et signatures. Il faut donc tester non seulement une synchronisation individuelle, mais aussi cet afflux collectif. Prévoir une file d’envoi, des reprises après échec et une protection contre les doublons évite qu’un retour du réseau désorganise le bureau.

Protéger les accès et les informations stockées

Définissez les droits par rôle, la durée des sessions et la conduite à tenir en cas de perte d’un téléphone. Faites préciser la protection des échanges et du stockage local, ainsi que la gestion des journaux techniques. Une authentification unique peut être pertinente si elle s’intègre à l’environnement existant.

Les données personnelles appellent aussi des décisions de gouvernance : finalités, informations strictement nécessaires, durées de conservation et responsabilités des intervenants. Ces sujets doivent associer les personnes compétentes dans l’entreprise, et non être abandonnés au seul développeur.

Organiser les validations jusqu’à la mise en production

Un planning crédible comporte des décisions et des validations, pas seulement une date de livraison. Adeliom présente ainsi un processus en 4 étapes : cadrage stratégique, design UX/UI, développement sur mesure, puis mise en ligne et suivi post-lancement. Dans votre projet, chaque phase doit produire un résultat vérifiable.

  1. Cadrer : valider les parcours, les intégrations, les contraintes et les critères d’acceptation.
  2. Prototyper : faire essayer les écrans à des utilisateurs avant de développer.
  3. Construire et tester : livrer progressivement, contrôler les fonctions et les échanges de données.
  4. Recetter et déployer : vérifier les scénarios métier, préparer la distribution et accompagner les utilisateurs.

La conception UX/UI doit tenir compte du tactile, de la lisibilité, de l’accessibilité et du contexte d’usage. Un formulaire confortable au bureau peut devenir pénible debout, sur un petit écran. Testez également les appareils moins puissants, les interruptions et les connexions dégradées.

La publication sur Google Play et l’App Store implique des comptes développeurs et des exigences de validation. Pour une application interne, étudiez aussi les modalités de distribution privée et de gestion du parc. Désignez dès le départ le propriétaire des comptes et le responsable des publications.

Comparer les agences sur le coût total et la capacité de suivi

Un devis dépend du périmètre, des intégrations, des plateformes, des tests et des exigences de sécurité. Sur Sortlist, les profils TheCodingMachine et Juloa affichent chacun un prix d’entrée de 5 000 € pour une application mobile. Ce montant ne constitue pas une estimation de votre projet : il ne décrit ni ses fonctionnalités ni ses contraintes.

Demandez une ventilation entre cadrage, conception, développement, intégrations, recette et déploiement. Faites chiffrer séparément l’hébergement, les services tiers, le support, la maintenance et les évolutions. Le calendrier doit également rendre visibles les dépendances : disponibilité des API, accès aux données et validations internes.

  • Références : demandez une réalisation comparable et le rôle exact de l’agence.
  • Équipe : identifiez les responsables produit, design, technique et qualité.
  • Contrat : clarifiez propriété du code, documentation, accès et réversibilité.
  • Suivi : distinguez corrections, adaptations aux systèmes mobiles et nouvelles fonctions.

Après le lancement, suivez l’adoption, les erreurs et l’accomplissement des tâches prioritaires. Pour consulter des prestataires, préparez un document commun précisant utilisateurs, parcours, intégrations et contraintes. La meilleure proposition est celle qui explique ses hypothèses et ses limites, tout en prévoyant la vie de l’application après sa livraison.