Une application métier pensée uniquement pour un usage statique (comprenez au bureau) finit toujours par montrer ses limites dès qu’elle doit être utilisée hors des murs de l’entreprise. Nous allons voir pourquoi l’adaptation au terrain est un enjeu primordial dans la conception d’une application métier et comment optimiser vos applications pour un usage en mobilité.
Sommaire
- Pourquoi une application métier doit s'adapter à chaque terrain
- Comprendre les contraintes métier avant de concevoir votre application métier
- Concevoir l’ergonomie de votre application métier pensée pour le terrain
- Garantir la continuité de service de votre application métier, même sans connexion
- Une application métier cohérente entre bureau et mobilité
- Sécuriser et fiabiliser les données de votre application métier
- Refonte d’une application métier : Les pièges à éviter
- Une méthodologie agile pour coller aux usages réels
- Conclusion
Une application métier professionnelle, contrairement à une application grand public, est conçue pour un processus, un secteur et des usages professionnels précis : gestion de production, planification, facturation, suivi d’intervention… mais également à des environnements variés.
Le terrain fait face à des contraintes que le bureau ne connaît pas. La mobilité, la connectivité instable, port de gants, écrans de petites tailles, temps d’usage variable, environnement bruyant ou en extérieur…
Une interface pensée uniquement pour un usage sur ordinateur peut devenir rapidement inutilisable en intervention.
Trop d’informations affichées à la fois et écrit trop petit, boutons trop petits pour un doigt ganté, formulaires trop longs pour être remplis debout ou sous des conditions météorologiques compliquées sont autant de problématique qu’un employé de bureau ne rencontrera jamais.
Une application trop simplifiée prévue initialement pour un usage mobile peut frustrer les utilisateurs statiques qui ont souvent besoin de plus d’information affichée au même endroit.
Pensez également que l’utilisateur peut avoir besoin de raccourcis clavier, de vues comparatives, de tableaux complexes…`
Le défi n’est donc pas de choisir entre interface bureau ou terrain, mais de concevoir une seule expérience utilisateur (UX) cohérente qui s’adapte aux deux, sans sacrifier l’autre.
Le comportement de certains utilisateurs permet de déceler des failles dans l’outil : utilisateurs qui contournent l’outil en passant par un autre, données ressaisies plusieurs fois, informations remontées en retard au bureau parce que notées sur un bout de papier en attendant « d’avoir du réseau ».
Chez Protech Foyer par exemple, l’ancien logiciel imposait de jongler entre deux outils distincts : un pour le planning, un pour la facturation, avec une synchronisation manuelle source de conflits dans les dossiers.
La création d’un outil combinant ces fonctionnalités a permis au personnel de l’entreprise de gérer plus facilement et rapidement la gestion de leurs chantiers.
Avant tout développement, il est essentiel de mener des ateliers avec les clients pour comprendre leurs métiers et interroger directement les utilisateurs finaux, qu’ils soient sédentaires ou mobiles.
Cette immersion dans le quotidien des utilisateurs permet d’éviter de concevoir une application métier éloignée de leur réalité.
Nous nous assurons ainsi qu’ils ne délaisseront pas leur nouvel outil pour reprendre leur ancien fonctionnement.
Le risque est d’ailleurs plus grand chez les utilisateurs habitués à ce fonctionnement depuis de nombreuses années. À nous de les accompagner pour renforcer leurs adoptions à l’aide d’un onboarding performant.
C’est l’approche que nous avons suivie avec l’Agence Régionale de Santé de Normandie, qui devait adapter l’environnement de travail de ses 400 agents aux nouvelles normes de mobilité (télétravail, espaces partagés), avec une application accessible et conviviale, quel que soit leur lieu de travail.
Un projet d’application métier part souvent d’un existant, souvent un logiciel maison vieillissant, un tableur partagé ou une combinaison de plusieurs applications qui ne communiquent pas entre elles.
Comme pour l’étude du métier des utilisateurs, il faut enquêter pour identifier précisément les problématiques et les limites de l’existant en posant différentes questions :
- Où l’utilisateur perd-il du temps ?
- Où se créent les erreurs ?
- Quelles étapes sont contournées sur le terrain ?
- …
Adapter une application métier au terrain ne se limite pas à la rendre responsive. Cela implique de repenser intégralement l’ergonomie en fonction des conditions dans lesquelles elle sera réellement utilisée.
Un utilisateur terrain n’a ni le temps ni les conditions adéquates pour remplir un formulaire long.
Chaque champ superflu est un frein en plus dans la réalisation de sa tâche.
Il faut privilégier les champs pré-remplis à partir des données déjà présentes dans la base de données du client (nom du client, adresse, contact, historique d’intervention, …).
Une liste de choix plutôt que la saisie libre sera plus facile et rapide à remplir.
Enfin, vous devez repousser en fin de parcours tout ce qui n’est pas indispensable à la réalisation immédiate de la tâche (commentaire, prochain rendez-vous…).
C’est cette logique qui a guidé la fiche d’intervention de Protech Foyer.
Les données client, la localisation et l’itinéraire sont déjà disponibles à l’arrivée du technicien, qui n’a plus qu’à compléter les informations propres à son intervention avant de générer une facture aux champs pré-remplis.
Les contraintes d’environnement (un écran en plein soleil, une averse, une absence de réseaux…) ainsi que les contraintes métier (le port de gants, une seule main disponible pendant que l’autre tient un outil…), imposent des aménagements.
Des cibles tactiles plus grandes, des contrastes renforcés, et des actions atteignables sans double manipulation sont quelques exemples d’adaptations possibles.
Ce sont des détails invisibles dans un écran de bureau, mais déterminants dans l’adoption et l’efficacité de l’outil sur le terrain.
Une erreur fréquente consiste à vouloir faire tenir tous les éléments sur un seul écran pour « simplifier » et limiter le nombre de clics.
Sur le terrain, il vaut souvent mieux plusieurs écrans courts et linéaires qu’un écran unique surchargé.
De cette manière, l’utilisateur avance étape par étape, sans avoir à faire défiler ou chercher l’information dont il a besoin sur le moment.
Sur le terrain, la connectivité ne peut jamais être assurée. C’est l’un des points les plus critiques qui marque une rupture entre une application métier de bureau et une application adaptée au terrain.
La première étape consiste à permettre la saisie même sans réseau, en stockant temporairement les données sur l’appareil.
C’est ce que nous avons mis en place pour Chouette Copro, une plateforme de suivi de travaux pour syndics et gestionnaires immobiliers dont les équipes ne pouvaient auparavant pas créer de ticket d’intervention dans une cave ou un garage, faute de couverture réseau. Avec Hotwire Native, nous avons ajouté un système de cache local qui sauvegarde les données saisies hors ligne, quel que soit l’endroit où se trouve le gestionnaire.
La donnée saisie hors ligne ne sert à rien si elle reste en l’état, bloquée sur l’appareil.
Elle doit être intégrée à la base de données dès que la connexion revient, sans action manuelle de l’utilisateur, via une synchronisation automatique.
Sur l’application Chouette Copro par exemple, la synchronisation automatique associée à un indicateur de statut par ticket a permis de fiabiliser ce transfert là où une synchronisation manuelle au clic sur un bouton conduit généralement à des oublis.
Le mode offline pose une question complexe : que se passe-t-il si la même donnée est modifiée à la fois sur le terrain et au bureau pendant la coupure
La priorité dans la provenance d’une donnée doit être établie dès la conception.
On peut définir cette priorité en :
- datant systématiquement les modifications,
- appliquant une règle de priorité claire (par exemple, la donnée terrain fait foi sur les données d’une intervention, la donnée bureau fait foi sur les données de facturation),
- remontée explicitement les conflits à l’utilisateur lorsqu’il ne peut pas être résolu automatiquement.
Laisser ce sujet de côté jusqu’à la mise en production est l’une des causes les plus fréquentes d’abandon d’une application métier par ses utilisateurs terrain qui ont l’impression de faire un travail inutile si leurs données ne sont jamais utilisées.
Adapter une application métier au terrain ne veut pas dire construire deux applications séparées, mais maintenir un code unique, décliné dans une interface responsive qui s’ajuste au contexte d’usage.
Faire cohabiter une version bureau et une version terrain sur une base technique commune évite la duplication et facilite la maintenance dans le temps en plus de réduire vos coûts de maintenance en ne nécessitant qu’un hébergement.
De cette façon, une évolution métier n’a besoin d’être développée qu’une seule fois pour bénéficier à tous les utilisateurs.
C’est ensuite au web designer d’adapter les vues pour une utilisation sur terrain optimal.
Une même donnée peut s’afficher différemment selon le contexte et le rôle de chacun.
Un exemple :
- Au bureau, un planificateur a besoin de voir toutes les interventions de la journée, pour tous les techniciens, en même temps.
Pour cela, il utilisera très probablement un tableau ou un calendrier avec plusieurs colonnes pour pouvoir réorganiser une tournée si un technicien est en retard ou si une urgence arrive. - Sur le terrain, un technicien n’a besoin de voir que ses prochaines interventions, une par une, dans l’ordre. Voir le planning des collègues ou la semaine complète ne lui sert à rien à cet instant, et l’encombrerait sur un petit écran.
Le responsive ne doit donc pas être pensé comme une simple réduction de taille, mais comme une hiérarchisation différente d’une même information, propre à chaque contexte d’usage.
Une application métier utilisée à la fois en mobilité et au bureau doit garantir que les données restent fiables, cohérentes et protégées, quel que soit le point d’entrée.
Un technicien terrain, un planificateur et un responsable n’ont pas besoin d’accéder aux mêmes données ni aux mêmes actions.
Pour cela, le client doit identifier les différents profils et droits qui leur seront octroyés. Le développeur définira ensuite des rôles qui permettront d’éviter à la fois les erreurs de manipulation et les accès non justifiés à des informations sensibles.
Un point d’autant plus important quand l’application est utilisée sur des appareils mobiles susceptibles d’être perdus ou partagés.
Au-delà de la sécurité des accès, la confiance dans une application métier repose sur sa capacité à prouver ce qui s’est passé.
Quelle donnée a été saisie ? Par qui ? À quel moment ? A-t-elle bien été synchronisée ?
C’est ce que permet un indicateur de statut, mais aussi, à un niveau plus large, un historique des modifications consultable en cas de litige ou de contrôle.
Une application métier ne remplace pas toujours l’intégralité de l’écosystème existant. Elle doit souvent cohabiter avec des outils déjà en place.
Un client qui utilise une API sécurisée connectée à leur système n’a pas besoin d’une fonctionnalité équivalente dans son application.
Nous limitons les risques de désynchronisation entre systèmes et évitons de multiplier les sources de vérité sur une même donnée.
Vous voulez développer ou refondre votre application terrain ?
Contactez-nous et voyons ensemble comment optimiser vos outils de travail.
Certaines erreurs reviennent régulièrement dans les projets d’application métier destinés à un usage mixte terrain/bureau :
- Traiter le mode offline comme une option ajoutée après coup, plutôt que comme une contrainte de conception dès le départ.
- Reprendre l’interface bureau sur les appareils de terrain (mobile, tablette) en se contentant de réduire les éléments, sans repenser l’interface pour un usage tactile.
- Ignorer la gestion des conflits de données, en pariant qu’ils seront rares, jusqu’à ce qu’ils bloquent un dossier en production.
- Tester uniquement en environnement de bureau, avec une bonne connexion et un grand écran, sans jamais valider l’application dans les conditions réelles du terrain.
Concevoir une application métier adaptée à chaque terrain n’est jamais quelque chose de figé dans un cahier des charges initial.
Nous travaillons à comprendre votre métier à travers des ateliers fonctionnels, en intégrant les retours des utilisateurs finaux au fil du projet plutôt qu’une seule fois en fin de développement.
Il s’agira ensuite d’ajuster l’ergonomie après les premiers retours d’utilisation, et ce, au-delà de la mise en ligne.
Une application métier réellement performante ne choisit pas entre le bureau et le terrain : elle est pensée pour les deux dès sa conception.
C’est cette exigence, souvent invisible dans un cahier des charges, qui fait la différence entre un outil subi et un outil réellement adopté. Reste ensuite à l’éprouver dans la durée : les usages terrain et besoins évoluent. Une application métier ne s’arrête jamais vraiment à sa mise en production.
