Développement d’application mobile en entreprise : cadrer les usages avant de comparer les agences

Faire développer une application mobile pour son entreprise commence par une décision métier : quelle tâche doit devenir plus simple, pour qui et dans quelles conditions ? Le choix d’une agence, d’une technologie et d’un budget vient ensuite. Un projet solide relie les usages réels aux outils existants, prévoit la sécurité et finance aussi la vie de l’application après son lancement.

Partir d’un problème opérationnel, 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, destiné aux collaborateurs, clients ou partenaires. Sa valeur ne réside pas dans le nombre d’écrans, mais dans le service rendu : consulter un dossier chez un client, préparer une intervention ou transmettre une information sans retourner au bureau.

Avant d’envisager le sur-mesure, vérifiez si votre logiciel métier dispose déjà d’une extension mobile adaptée. JLogiciels présente notamment un accès aux devis, factures, fiches clients, plannings et documents, synchronisé avec sa version en ligne. Une solution existante mérite donc d’être comparée à une création spécifique lorsque vos besoins restent standards.

Définir un premier périmètre qui se suffit à lui-même

Réunissez un responsable métier, des utilisateurs représentatifs et votre équipe informatique. Décrivez un parcours complet plutôt qu’une accumulation de fonctions : un technicien consulte son planning, ouvre sa fiche d’intervention, renseigne son compte rendu puis le transmet au bureau. Pour chaque action, précisez les données nécessaires, les droits d’accès et les situations de connexion dégradée.

• Utilisateurs : clients, commerciaux, techniciens ou partenaires, avec leurs appareils habituels.
• Priorité métier : supprimer une ressaisie, faciliter une consultation ou accélérer une transmission.
• Critère de réussite : temps consacré à une tâche, fréquence d’utilisation ou proportion de dossiers complets.

Prenez aussi le pouls de l’activité : à quel moment l’information devient-elle vraiment utile ? Un planning doit être actualisé avant le départ d’un technicien ; un document volumineux peut être téléchargé plus tôt. Cette lecture du rythme de travail aide à distinguer ce qui exige une synchronisation immédiate de ce qui peut attendre. Elle évite de promettre du « temps réel » partout, au prix d’une consommation réseau et d’une complexité inutiles.

Choisir les plateformes et l’approche technique selon le terrain

Le choix entre iOS et Android dépend d’abord du parc réellement utilisé. Une flotte interne homogène n’impose pas les mêmes arbitrages qu’une application destinée au grand public. IBM évoque une part approximative de 70 % des smartphones sous Android ; cette indication générale ne remplace pas l’analyse de vos propres utilisateurs.

Les termes hybride et cross-platform sont parfois employés de façon interchangeable dans les offres commerciales. Demandez quelle architecture est réellement proposée, quelles parties du code seront communes et quelles adaptations resteront nécessaires sur chaque système.

Aucune approche n’est systématiquement la moins coûteuse. Une base de code partagée ne supprime ni les tests sur chaque plateforme ni les ajustements d’interface. Pour un besoin sensible, comme l’usage d’un périphérique ou un fonctionnement hors ligne complexe, demandez une validation technique précoce sur un appareil représentatif.

Prévoir les données, la sécurité et les validations avant de coder

L’application n’est souvent que la partie visible d’un ensemble plus vaste. Elle doit communiquer avec un CRM, un ERP ou une base documentaire par des API, c’est-à-dire des interfaces d’échange entre logiciels. Vérifiez leur disponibilité, leur documentation et les droits nécessaires : une intégration incertaine peut bloquer un parcours pourtant simple à l’écran.

Organiser les échanges et protéger les accès

Précisez quelles données peuvent être stockées sur le téléphone, pendant combien de temps et avec quelles protections. Prévoyez une authentification adaptée, des autorisations contrôlées côté serveur, le chiffrement des échanges et la révocation des accès. Si des données personnelles sont traitées, associez le responsable compétent aux décisions de collecte, de conservation et d’hébergement.

Le mode hors ligne mérite ses propres règles. Que se passe-t-il si deux personnes modifient le même dossier ? Comment signaler une transmission inachevée ? L’utilisateur doit pouvoir distinguer une information enregistrée sur son appareil d’une donnée effectivement reçue par le système d’information.

Valider les parcours dans les conditions réelles

Avant le développement, un prototype permet de tester la navigation et la compréhension des écrans. Travaillez l’ergonomie tactile, la lisibilité, l’accessibilité et les messages d’erreur. Ensuite, organisez des tests continus, puis une recette métier : les utilisateurs vérifient que les scénarios convenus fonctionnent réellement.

Incluez les réseaux faibles, les interruptions, les appareils moins puissants et les différentes tailles d’écran. Une démonstration sur un téléphone récent connecté au Wi-Fi ne suffit pas à valider une application pour équipes terrain.

Comparer les agences sur un périmètre et un coût total communs

Pour obtenir des propositions comparables, transmettez le même dossier à chaque agence : objectifs, utilisateurs, parcours prioritaires, intégrations, contraintes et critères de réception. Demandez un chiffrage distinguant cadrage, conception UX/UI, développement, tests, déploiement et maintenance. Le planning doit aussi faire apparaître les dépendances et les validations attendues de votre entreprise.

Sur Sortlist, les profils de TheCodingMachine et de Juloa affichent un prix d’entrée à partir de 5 000 € pour une application mobile. Ce montant n’est ni un budget moyen ni une estimation pour votre projet. Les intégrations, la sécurité, le hors ligne et la couverture des plateformes peuvent modifier fortement le périmètre à financer.

• Références pertinentes : demandez un exemple présentant des contraintes proches des vôtres, pas seulement de belles interfaces.
• Équipe identifiée : vérifiez qui assure le pilotage, le design, le développement et les tests.
• Livrables et propriété : clarifiez les droits sur le code, l’accès aux dépôts, la documentation et les comptes techniques.
• Continuité : faites préciser le support, les modalités de reprise et les conditions de changement de prestataire.

Les avis constituent un indice, pas une garantie. Sortlist indique par exemple 4,8/5 sur 21 avis pour TheCodingMachine et 4,9/5 sur 10 avis pour Juloa. Complétez ces signaux par un échange sur la méthode, les difficultés rencontrées et la maintenance des réalisations présentées.

Préparer le lancement et réserver des moyens pour la suite

Déterminez assez tôt le mode de distribution : App Store, Google Play ou dispositif interne adapté à votre organisation. Les stores imposent des comptes développeurs et des exigences de publication. IBM mentionne des frais de création de compte développeur Android de 25 USD, à vérifier lors de l’inscription. La publication doit être planifiée, et non ajoutée comme une formalité finale.

Commencez si possible avec un groupe pilote, accompagné d’instructions simples et d’un canal de remontée des incidents. Après le lancement, suivezz l’adoption, les erreurs et la réussite des parcours prioritaires. Ces observations doivent orienter les corrections et les évolutions, plutôt qu’une nouvelle liste de fonctionnalités décidée sans retour terrain.

Le budget doit couvrir le cycle de vie : hébergement, services tiers, surveillance, correctifs, mises à jour des systèmes mobiles et évolutions métier. Avant de solliciter une agence, préparez une synthèse de vos usages, contraintes et priorités. Vous pourrez alors demander une recommandation argumentée, un périmètre explicite et une estimation exploitable pour décider.