Digitaliser les processus de terrain : du papier à l’application mobile.

Demandez à une direction où naît sa donnée la plus importante. La réponse est rarement « dans l’ERP ». Elle naît chez l’agent qui visite une boutique de quartier, sur le chantier où l’on réceptionne du ciment, dans l’entrepôt où l’on compte les palettes, dans l’agence rurale qui ouvre un compte ou verse une aide, chez l’enquêteur qui recense des ménages. Ce que le système enregistre ensuite est une copie, ressaisie plus tard, par quelqu’un d’autre, avec un délai et des erreurs. Digitaliser le terrain, c’est faire naître la donnée juste, une seule fois, à l’endroit où elle se produit.

Pourquoi le papier et WhatsApp persistent

Il serait facile d’y voir un retard. C’est plutôt une réponse rationnelle à des contraintes réelles. Le papier ne tombe jamais en panne de réseau. Il ne demande ni compte, ni mot de passe, ni formation. WhatsApp est déjà installé, la photo part en un geste et le responsable la voit tout de suite. Face à cela, bien des applications d’entreprise ont échoué pour des raisons prévisibles : elles exigeaient une connexion permanente, elles reproduisaient un formulaire de bureau sur un petit écran, elles ajoutaient du travail à l’agent sans rien lui rendre, et elles parlaient une langue qui n’était pas la sienne.

Le papier et WhatsApp ont pourtant un coût que l’on finit toujours par payer. La donnée arrive en retard, incomplète, impossible à rapprocher du client ou de la commande dans le système. Les photos se perdent dans des conversations. Les stocks du système ne correspondent jamais aux stocks réels. Les bailleurs et les auditeurs demandent des preuves que personne ne retrouve. Et la connaissance du terrain reste dans la mémoire des agents, qui partent avec elle.

Ce qu’une application de terrain doit savoir faire

Une application de terrain n’est pas un ERP en plus petit. C’est un outil conçu pour un contexte précis : un téléphone souvent d’entrée de gamme, une main disponible, un réseau incertain, un utilisateur pressé. Cinq exigences en découlent.

• Fonctionner hors connexion. La première condition, et celle que l’on sacrifie le plus souvent. L’agent doit pouvoir saisir et consulter ses clients, ses tournées, ses stocks, sans réseau, toute une journée s’il le faut. L’application est locale d’abord, connectée ensuite.
• Synchroniser proprement. Quand le réseau revient, les données partent et reviennent sans intervention, dans le bon ordre, sans doublon, avec des règles claires quand deux personnes ont modifié la même chose. La synchronisation est le vrai cœur technique du projet ; il faut la concevoir, pas la subir.
• Capturer la photo et la position. Une photo horodatée et géolocalisée vaut mieux qu’un long formulaire : preuve de livraison, état d’un compteur, avancement d’un chantier, présence d’un point de vente. La position aide aussi à organiser les tournées et à vérifier, sans fliquer, que la visite a eu lieu.
• Rester simple. Peu d’écrans, de gros boutons, des listes déjà remplies plutôt que des champs à taper, des valeurs par défaut intelligentes. Chaque champ ajouté doit se justifier par un usage réel en aval. Si personne ne lit la donnée, on ne la demande pas.
• Parler les langues du terrain. Français, wolof ou autre langue nationale selon les équipes, avec des pictogrammes et, quand c’est nécessaire, des messages audio. Une application que l’agent comprend sans traduire est une application qu’il utilise.

Relier le terrain au cœur de gestion et au CRM

Une application de terrain isolée ne fait que déplacer le problème : au lieu de ressaisir depuis un carnet, on ressaisit depuis une base à part. La valeur naît de l’intégration. Côté cœur de gestion, la réception en entrepôt met à jour le stock dans SAP ou dans Odoo ; la commande prise en tournée devient une commande de vente ; la fiche de chantier alimente le suivi du projet. Côté relation client, la visite, la réclamation ou le relevé d’un point de vente enrichissent la fiche dans Salesforce, pour que le siège et le terrain regardent le même client.

Quelques principes cadrent cette intégration. Les référentiels restent dans le système maître : la liste des clients, des articles, des sites vient de l’ERP ou du CRM, l’application ne les recrée pas. Les échanges passent par des API documentées, avec une gestion explicite des erreurs et des reprises. Et l’on décide dès le cadrage de ce qui remonte en temps réel et de ce qui peut attendre la prochaine synchronisation. C’est le terrain de notre offre Applications sur mesure, de l’écran mobile jusqu’à l’intégration avec SAP, Odoo et Salesforce.

Une application de terrain réussie se reconnaît à un signe : les agents l’ouvrent parce qu’elle leur rend service, pas parce qu’on le leur a demandé.

La conduite du changement avec les équipes de terrain

C’est là que se jouent la plupart des échecs, et ils ne sont presque jamais techniques. Les équipes de terrain ont vu passer des outils imposés par le siège, puis abandonnés. Elles savent que l’application peut servir à les contrôler autant qu’à les aider. On ne les convainc pas avec une note de service.

Ce qui fonctionne, à notre expérience : associer quelques agents dès la conception, pas seulement à la recette ; leur rendre quelque chose dès la première version, une tournée déjà préparée, un historique client sous la main, la fin d’un rapport à refaire le soir ; désigner des relais sur le terrain, des collègues qui forment leurs collègues dans leur langue ; accepter une période où le papier et l’application coexistent ; et corriger vite à partir des retours de chaque semaine. L’encadrement intermédiaire compte autant que les agents : si le chef d’agence ou le conducteur de travaux continue de demander la fiche papier, l’application est morte.

Sécurité et données personnelles

Un téléphone qui circule sur le terrain porte des données sensibles : identités de clients ou de bénéficiaires, coordonnées, positions, photos, parfois des montants. Il peut être perdu, volé, prêté. L’application doit donc chiffrer ce qu’elle stocke localement, s’ouvrir avec une authentification adaptée aux usages, ne garder sur l’appareil que ce qui sert à la journée, et pouvoir être effacée à distance. Les droits suivent le rôle et le périmètre : un agent voit sa zone, pas le pays.

Dès que l’application collecte des données sur des personnes, elle entre dans le champ de la loi n° 2008-12. Le traitement se déclare auprès de la CDP, les personnes sont informées de la finalité, la collecte se limite à ce qui sert cette finalité, la durée de conservation est définie. Pour une collecte de données de bénéficiaires, ces règles comptent d’autant plus que les personnes concernées sont souvent vulnérables. Tout cela se conçoit au cadrage, pas après la mise en production. Notre offre Sécurité & risques IT intervient dès cette étape.

Une méthode par itérations, avec un pilote

Nous ne croyons pas au grand déploiement d’une application conçue en chambre. On choisit un processus et une zone : une équipe de tournée, un entrepôt, une agence. On observe le travail réel, sur place, avant de dessiner le moindre écran. On construit une première version limitée au strict nécessaire, hors connexion dès le départ, reliée au système sur un flux au moins. On la met entre les mains des agents pilotes en quelques semaines, et l’on corrige à leur rythme. On mesure ce qui compte pour le métier : délai entre la visite et la donnée dans le système, part des saisies complètes, stocks concordants, temps rendu aux agents. Puis on étend, zone par zone, en emmenant les relais formés lors du pilote.

Cette manière de faire est cohérente avec ce que nous sommes : un cabinet de Dakar, dont les équipes peuvent aller sur le terrain, tester avec les agents dans leur langue et revenir la semaine suivante. Concevoir une application de terrain pour la sous-région depuis la sous-région est la condition pour qu’elle tienne compte des réseaux, des téléphones, des langues et des habitudes réelles. La donnée qui en sort alimente ensuite le reporting, sujet de notre offre Data & Analytics, et parfois les premiers cas d’usage d’IA & automatisation, lecture des documents photographiés en tête.

Nos recommandations

1. Partir d’un processus, pas d’une application. Quel geste de terrain produit la donnée dont l’entreprise a le plus besoin ? C’est par lui que l’on commence.
2. Exiger le hors connexion et la synchronisation dès le cadrage. Ce sont les deux points que l’on ne rattrape pas après coup.
3. Décider tôt de l’intégration. Quels référentiels viennent de SAP, d’Odoo ou de Salesforce, quels flux remontent, à quel rythme.
4. Concevoir avec les agents et l’encadrement de terrain. Leur rendre du temps dès la première version.
5. Traiter la sécurité et la loi n° 2008-12 comme des exigences du produit. Chiffrement, droits, déclaration auprès de la CDP, information des personnes.
6. Piloter, mesurer, étendre. Une zone, quelques semaines, des indicateurs métier, puis le déploiement par vagues.

Du papier à l’application mobile, le chemin n’est pas d’abord technologique. Il consiste à respecter le travail de terrain tel qu’il est, à lui donner un outil qui le sert, et à relier enfin ce que l’entreprise fait à ce qu’elle enregistre.