Développement d’application mobile en entreprise : le budget se joue avant le code
Faire développer une application mobile pour son entreprise commence par un arbitrage : quel usage justifie un outil supplémentaire, pour quels utilisateurs et avec quelles données ? La réponse détermine les fonctionnalités, la technologie et le prestataire à retenir. Pour comparer des propositions sérieusement, il faut définir le service attendu, les contraintes du système d’information et les dépenses après lancement, pas seulement le prix du développement.
Partir du travail à accomplir, pas d’une liste de fonctionnalités
Une application mobile d’entreprise permet à des clients, partenaires ou collaborateurs d’effectuer des actions depuis un smartphone ou une tablette. Elle peut prolonger un logiciel existant ou répondre à un besoin spécifique. Avant de choisir le sur-mesure, vérifiez si votre logiciel de gestion propose déjà une version mobile adaptée : développer n’est pertinent que si l’écart fonctionnel ou ergonomique le justifie.
Relier chaque fonction à une situation concrète
Un technicien peut avoir besoin de consulter son planning, retrouver une intervention et transmettre un compte rendu. Un commercial cherchera plutôt une fiche client, un devis ou des documents à jour. Pour une application destinée aux clients, le parcours peut concerner une demande de service ou le suivi d’un dossier. Ces usages appellent des interfaces et des droits différents.
Pour chaque fonction, précisez l’utilisateur, le lieu d’utilisation, l’information nécessaire et le résultat attendu. Associez ensuite un indicateur observable : temps de saisie, dossiers incomplets, doubles saisies ou fréquence d’utilisation. Le bénéfice métier doit pouvoir être vérifié, même sans objectif chiffré initial.
Délimiter une première version réellement utilisable
Le MVP, ou produit minimum viable, doit couvrir un parcours complet plutôt qu’accumuler des fonctions inachevées. Consulter une intervention sans pouvoir enregistrer son résultat peut laisser intact le problème opérationnel. Classez les besoins entre indispensables au parcours, utiles ensuite et hypothèses à tester.
Considérez cette première version comme une graine : son potentiel dépend aussi du terrain qui l’accueille. Une application bien conçue ne prendra pas racine si les fiches clients sont incohérentes ou si personne ne répond aux demandes transmises. Avant de développer, suivez un dossier de bout en bout et identifiez qui crée, corrige et valide chaque donnée. Ce travail révèle parfois qu’un ajustement organisationnel est nécessaire avant toute nouvelle fonctionnalité.
Choisir la technologie selon les appareils et les contraintes
Le choix entre iOS et Android dépend d’abord du parc utilisé. Dans une flotte interne, un inventaire des appareils peut suffire à orienter la décision. Pour un public externe, examinez les usages réels de vos clients. IBM évoque une part approximative de 70 % de smartphones sous Android, mais cette proportion générale ne décrit pas nécessairement votre audience.
Recommandations CNIL pour protéger les données des applications mobiles — Consultez la version modifiée des recommandations officielles de la CNIL sur la protection des données personnelles dans les applications mobiles.
| Approche | Principe | Point à vérifier avant de choisir |
|---|---|---|
| Native | Développement propre à chaque système, notamment avec Swift pour iOS ou Kotlin pour Android. | Besoins d’intégration avancée aux appareils et effort de maintenance par plateforme. |
| Hybride | Technologies web intégrées dans une application installable. | Fluidité des parcours et accès aux fonctions natives nécessaires. |
| Cross-platform | Partage d’une partie importante du code, notamment avec Flutter ou React Native. | Adaptations spécifiques et compatibilité des composants utilisés. |
| PWA | Application web accessible depuis le navigateur, avec des capacités variables selon l’environnement. | Compatibilité des notifications, du hors-ligne et des fonctions matérielles visées. |
Une base de code commune ne supprime pas les tests sur chaque plateforme. Inversement, le natif ne garantit pas à lui seul une meilleure expérience. Demandez au prestataire de justifier son choix sur vos parcours critiques : capture de photos, lecture de codes, notifications ou connexion à un équipement.
Le fonctionnement hors connexion mérite un arbitrage explicite. Il faut définir les données conservées sur l’appareil, les actions autorisées sans réseau et le traitement des modifications contradictoires lors de la synchronisation. Ce besoin touche autant l’architecture que l’interface.
Valider les parcours, les intégrations et la sécurité avant publication
Le cadrage doit réunir un décideur métier, des utilisateurs représentatifs et les responsables du système d’information. Désignez une personne habilitée à prioriser et à valider. Sans ce responsable, des demandes contradictoires peuvent allonger le projet et rendre le périmètre instable.
Faire tester un prototype avant de développer
La conception UX/UI organise les parcours et leur présentation. Un prototype permet de vérifier la compréhension des écrans avant de financer leur réalisation. Faites exécuter une tâche concrète aux futurs utilisateurs, sans leur expliquer chaque bouton. Observez les hésitations, les informations manquantes et les erreurs possibles.
Prévoyez des zones tactiles confortables, des textes lisibles, des messages d’erreur utiles et une navigation accessible. Sur le terrain, une interface doit rester exploitable avec une connexion irrégulière et dans des conditions moins favorables qu’au bureau.
Tester toute la chaîne, pas seulement les écrans
L’application échange souvent avec un ERP, un CRM ou une base documentaire par des API, interfaces permettant aux logiciels de communiquer. Vérifiez leur disponibilité, leur documentation et leurs limites. Définissez quel système fait référence et comment une erreur de transmission sera signalée puis corrigée.
Côté sécurité, formalisez les droits par profil, l’authentification, le chiffrement des échanges et la protection du stockage local. Limitez les données collectées et impliquez le responsable de leur protection lorsque nécessaire. La recette doit couvrir les appareils ciblés, les pertes de réseau, les performances et les tentatives d’accès non autorisé.
Demander un budget qui couvre aussi le lancement et la maintenance
Le coût dépend du nombre de parcours, des intégrations, du mode hors ligne, des exigences de sécurité et des plateformes couvertes. Le nombre d’écrans seul ne suffit pas à estimer la complexité. Sur Sortlist, les profils de TheCodingMachine et de Juloa affichent un prix d’entrée de 5 000 € pour une application mobile : ce repère commercial ne constitue pas un devis pour votre projet.
Demandez une ventilation comparable entre prestataires :
- Cadrage, prototype et conception des interfaces.
- Développement mobile, services serveur et intégrations.
- Tests, recette, publication et accompagnement des utilisateurs.
- Hébergement, supervision, maintenance corrective et évolutions.
Le planning doit préciser les dépendances : accès aux API, fourniture des contenus, disponibilité des utilisateurs pilotes et validations internes. Prévoyez aussi le mode de distribution : App Store, Google Play ou dispositif interne adapté. Les stores imposent des exigences de publication ; le dépôt ne vaut pas validation immédiate.
Après lancement, suivez les erreurs, les performances et l’adoption. Organisez les mises à jour liées aux systèmes mobiles et distinguez contractuellement correction d’anomalies et nouvelles fonctionnalités. Une application est un service à exploiter, pas un livrable figé.
Sélectionner une agence sur ses preuves et ses engagements
Une agence pertinente doit expliquer ses arbitrages, pas seulement présenter des technologies. Demandez une démonstration d’un projet comparable par ses contraintes : synchronisation, données sensibles, parc d’appareils ou intégration métier. Les avis clients apportent un signal utile, à compléter par un échange sur la qualité du suivi et la gestion des difficultés.
Avant de signer, clarifiez les points qui conditionnent votre autonomie :
- Composition de l’équipe et interlocuteur responsable du projet.
- Livrables, critères d’acceptation et procédure de changement de périmètre.
- Propriété du code, accès aux dépôts et comptes de publication.
- Documentation, transfert de compétences et conditions de réversibilité.
- Délais de prise en charge des incidents et périmètre de maintenance.
Pour préparer le premier échange, transmettez un dossier court : utilisateurs, problème prioritaire, parcours attendu, outils à connecter, contraintes et budget envisagé. Demandez ensuite une proposition distinguant hypothèses, exclusions et risques. Vous pourrez comparer les agences sur une même base et retenir celle qui rend les décisions compréhensibles, plutôt que celle qui promet tout dès le premier rendez-vous.