Gestion d'un projet d'application mobile

1. Introduction

Cette réalisation s'est déroulée dans le cadre de mon alternance. L'entreprise souhaitait déployer une application mobile afin d'optimiser la logistique et le transport de la collecte de céréales. J'ai eu pour mission de piloter le projet de A à Z pour la partie fonctionnelle et matérielle de l'application : tests fonctionnels de l'application, retours aux développeurs externes, choix et configuration du matériel (smartphones), et accompagnement au changement pour une flotte de 20 chauffeurs.

2. Les objectifs

2.1. Objectifs techniques

• Réaliser les recettes (tests de l'application) et centraliser les rapports de bugs
• Sélectionner un modèle de smartphone adapté (budget, couverture réseau)
• Déployer une flotte de 20 téléphones mobiles prêts à l'emploi pour un secteur métier non habitué aux outils numériques

2.2. Objectifs non techniques

• Gérer la communication avec l'agence de développement externe
• Gérer la conduite du changement auprès de chauffeurs réticents à la technologie
• Optimiser les axes d'analyse de performances en récupérant les données de l'application

3. Le contexte et les enjeux

Avant ce projet, l'entreprise n'avait aucune visibilité ni statistiques sur la partie transport. Les agriculteurs appelaient un technicien au dépôt, qui devait lui-même appeler un chauffeur pour l'envoyer dans un champ. Ce système générait une perte de temps immense et ne permettait pas de mesurer les performances (distances, temps de trajet). L'application devait automatiser et simplifier ce flux.

Enjeux principaux : Le premier enjeu était matériel et financier : il fallait équiper 20 chauffeurs (10 titulaires et 10 intérimaires en période de forte demande) avec un smartphone performant, capable de capter la 4G au milieu des champs, sans exploser le budget. L'autre enjeu, crucial, était humain : faire accepter cet outil à des professionnels habitués à travailler uniquement au téléphone.

Risque principal : Le rejet de l'application par les utilisateurs finaux. Si l'application buggait sur le terrain ou si le téléphone captait mal, les chauffeurs retourneraient immédiatement à l'ancien système par appel téléphonique, faisant échouer tout le projet de numérisation. Il était donc crucial de concevoir une application aussi fonctionnelle et simple d'utilisation que possible.

4. Les différentes étapes du projet

4.1. Cadrage métier et rédaction du cahier des charges

Le projet a démarré par une immersion avec la partie métier, c'est-à-dire les logisticiens et les chauffeurs, afin d'observer concrètement le fonctionnement quotidien. J'ai cherché à comprendre à quel moment les appels téléphoniques créaient des pertes de temps, quels échanges étaient répétés inutilement et quelles informations étaient indispensables au bon déroulement des tournées. Cette phase m'a permis de faire ressortir les besoins les plus récurrents : la rapidité de prise de mission, la traçabilité des trajets, la limitation des erreurs de communication et la remontée fiable des informations vers le bureau.

J'ai ensuite synthétisé les besoins de la direction, comme la traçabilité et la géolocalisation, et ceux du corps de métier, comme la gestion des tournées et la simplicité d'utilisation, dans un cahier des charges détaillé. J'y ai précisé les contraintes de terrain, les attentes de fonctionnement hors des zones de couverture idéales et les usages attendus par les chauffeurs. Ce document a servi de socle technique et contractuel pour exprimer notre besoin exact à l'agence de développement externe Send-Up, en définissant les fonctionnalités incontournables avant même la première ligne de code et en limitant les ambiguïtés lors des échanges ultérieurs.

4.2. Assurance Qualité (QA) et tests terrains embarqués

La phase de recette n'a pas pu se limiter à des tests en laboratoire, car les comportements observés en bureau ne reflétaient pas la réalité des champs et des déplacements. J'ai d'abord utilisé une application de spoofing GPS au siège pour vérifier la logique générale de l'application, puis je suis rapidement passé aux tests en conditions réelles afin de mesurer ce qui se passait lorsque le réseau devenait instable ou lorsque les missions s'enchaînaient rapidement. Je conduisais dans les zones agricoles mal couvertes par la 4G, pendant que ma collègue utilisait la console logisticienne pour m'envoyer des missions, ce qui nous permettait de tester à la fois la réception, l'affichage des informations et la réactivité de la synchronisation.

Je documentais chaque perte de session, échec de synchronisation ou comportement inattendu dans des rapports détaillés, en précisant le contexte, l'heure, le lieu et le scénario de test. Ce travail de suivi nous a permis d'avoir une base d'échange claire lors des réunions hebdomadaires avec les développeurs de Send-Up. Je pouvais leur présenter des cas concrets plutôt que des impressions générales, ce qui facilitait la priorisation des correctifs et la validation des nouvelles versions. Cette méthode de QA m'a appris à penser en termes de reproductibilité des bugs, de conditions d'apparition et de hiérarchisation des anomalies.

4.3. Étude matérielle et configuration logicielle de la flotte

Pour équiper la flotte, j'ai commencé par comparer plusieurs modèles en prenant en compte la couverture réseau, la robustesse, la batterie et le coût total. L'objectif n'était pas seulement d'acheter un smartphone correct, mais de trouver un appareil capable de rester fiable dans un environnement agricole, souvent exposé à la poussière, aux déplacements répétés et aux pertes de réseau. J'ai sélectionné le OnePlus Nord CE 3 Lite parce qu'il intégrait le maximum de bandes de fréquences 4G dans notre budget, notamment les bandes basses 700/800 MHz, ce qui était essentiel pour limiter les zones d'ombre en pleine campagne.

Sans solution MDM, l'enrôlement a été manuel, ce qui a rendu la phase de préparation particulièrement chronophage. Pour les 20 téléphones, j'ai activé les options développeurs, autorisé l'installation d'applications tierces, téléchargé le package .apk via un lien privé hébergé par le prestataire, créé ou vérifié les comptes locaux et contrôlé le bon lancement de l'application sur chaque appareil. J'ai aussi vérifié les paramètres de base comme le volume, la connectivité, la charge initiale et l'association à l'utilisateur final, afin que chaque téléphone soit immédiatement opérationnel au moment de la distribution.

4.4. Ingénierie des flux de données et Business Intelligence

Pour rapatrier les données de géolocalisation et de kilométrage dans notre système d'information, nous avons mis en place un flux de transfert sécurisé avec le cloud du prestataire. Ce dernier générait des exports bruts au format CSV que nous récupérions de manière automatisée via le protocole SFTP. Avant l'intégration dans MyReport, j'ai vérifié la structure des colonnes, la fréquence d'export, la cohérence des identifiants et la correspondance entre les données de transport et les données de l'ERP, afin d'éviter les doublons ou les ruptures de suivi.

Ces fichiers étaient ensuite ingérés localement dans notre logiciel de Business Intelligence, MyReport, qui générant des tableaux de bord pour calculer le coût de revient kilométrique par chauffeur en croisant ces données avec les tonnages de l'ERP. J'ai participé à la définition des indicateurs utiles pour la direction, comme les distances parcourues, le coût par tournée, la comparaison entre chauffeurs et l'évolution de l'activité selon les périodes. Cette étape a donné une vraie valeur métier au projet, car elle ne se limitait plus à l'utilisation de l'application sur le terrain : elle permettait aussi d'exploiter les données pour piloter l'activité.

4.5. Conduite du changement et formation des utilisateurs

Pour faciliter l'adoption de l'application par les chauffeurs, qui n'étaient pas habitués aux outils numériques, j'ai remplacé la traditionnelle documentation papier par la création d'un tutoriel vidéo clair et dynamique. J'ai voulu que ce support soit suffisamment concret pour rassurer les utilisateurs avant même la première prise en main, tout en restant assez court pour être regardé rapidement sur le terrain. Ce support visuel a permis de démystifier l'outil instantanément lors de la distribution des smartphones, en montrant les gestes simples à reproduire et les erreurs à éviter.

Ensuite, j'ai organisé et co-animé une journée complète de démonstration et de formation sur site. L'entreprise développeuse était présente, ce qui nous a permis de former directement les logisticiens à leur nouvelle interface web, de former les chauffeurs à l'application mobile et de répondre à toutes leurs interrogations de manière immédiate. J'ai également pris le temps de reformuler les réponses avec un vocabulaire adapté aux différents profils présents, afin que chacun reparte avec des repères clairs. Cette journée a joué un rôle décisif dans l'acceptation de l'application, car elle a transformé un outil perçu comme imposé en solution concrète et utile.

5. Les résultats

5.1. Pour moi

D'un point de vue technique, j'ai assimilé la méthodologie rigoureuse de l'Assurance Qualité (QA) logicielle et j'ai affûté ma compréhension des flux d'intégration de données via SFTP et CSV. D'un point de vue personnel, j'ai énormément progressé en communication : j'ai appris à traduire des frustrations de chauffeurs en requêtes techniques précises pour des développeurs, et j'ai développé ma pédagogie pour faire accepter un outil numérique à un public réfractaire.

5.2. Pour l'entreprise

Malgré une forte réticence initiale, l'adoption par les chauffeurs a été un succès. L'application leur a permis d'optimiser leurs trajets de manière autonome. Pour la direction, le projet a permis une mise en place du suivi financier. L'entreprise dispose désormais d'indicateurs précis dans MyReport permettant de calculer le coût de revient réel des missions logistiques, ainsi qu'un calcul plus précis du secteur du transport dans l'entreprise, une donnée devenue stratégique avec la hausse des coûts du carburant.

6. Ce que je retiens

Ce projet m'a enseigné que la composante matérielle et la conduite du changement sont souvent plus critiques que le développement logiciel lui-même. Mon apport majeur a été l'exécution des tests en conditions réelles dans les champs et la création d'un tutoriel vidéo qui a brisé la résistance technologique des chauffeurs. Mon regard critique se porte sur le déploiement matériel : j'ai configuré les 20 téléphones manuellement un par un. C'était une erreur stratégique et chronophage. Si c'était à refaire, j'utiliserais une solution de MDM (Mobile Device Management) pour automatiser l'enrôlement des appareils et gérer les mises à jour de l'application à distance de manière centralisée.

7. Les lendemains du projet

Dans l'immédiat, le projet s'est poursuivi par la journée de formation sur site, suivie de quelques semaines d'assistance rapprochée où je répondais aux questions d'utilisation quotidiennes des logisticiens. À distance, les appels au support ont totalement cessé, l'outil étant parfaitement adopté. Aujourd'hui, l'application Send-Up est un standard dans les processus de Qualisol. Le matériel sélectionné tient la charge. Il est cependant prévu de mettre en place une solution MDM (le choix se portant pour l'instant sur Microsoft Intune) afin de pouvoir gérer plus efficacement le déploiement des nouvelles versions, des mises à jour logicielles et du cloisonnement de l'utilisation du smartphone. Ce choix est dû à une autre application qui vient d'être déployée et qui nécessite aussi une flotte mobile. Nous prévoyons aussi de mettre nos smartphones en mode kiosque, afin de limiter leur usage annexe et de réduire les coûts de données mobiles apparus, étant donné que nous n'avions pas limité ces accès.