Découverte & accompagnement terrain
Observation des responsables régionaux sur le terrain, cartographie de la couverture hors ligne, examen de la posture RGPD + CCPA pour les enregistrements clients, exigences de contrôle d'accès par territoire.
Étude de cas · AgTech · Outillage interne
Farm — application de vente terrain hors ligne pour l'agriculture
Comment nous avons livré Farm — une application interne native iOS et Android pour un distributeur de produits agricoles dont les responsables commerciaux terrain passent leurs journées dans des caves, des entrepôts et des exploitations hors couverture réseau aux États-Unis et dans l'Union européenne. Construite sur un magasin SQLite hors ligne en premier, un back-office Laravel + React et une couche de reporting plan vs réel qui résiste à l'examen RGPD et CCPA — et qui est restée en utilisation continue en production pendant trois ans.
Le brief — une boîte à outils de vente terrain qui fonctionne sans signal
L'équipe produit Farm est venue avec une douleur opérationnelle spécifique. Leurs responsables commerciaux régionaux couvraient des territoires agricoles aux États-Unis et dans l'Union européenne, et le flux de travail quotidien ne ressemblait en rien à l'hypothèse que fait toute application mobile CRM prête à l'emploi. Un représentant conduisait quatre-vingt-dix minutes jusqu'au site d'un client, perdait le signal cellulaire dans une grange ou une cave de stockage d'engrais, discutait des prix pendant quarante-cinq minutes, concluait un accord, puis devait le déposer — souvent encore hors couverture. Les outils existants perdaient silencieusement le rapport ou obligeaient le représentant à se rappeler de le re-déposer depuis la voiture. Nous avons reconstruit le flux de travail de zéro comme une application interne iOS et Android native : un miroir SQLite hors ligne en premier du catalogue produits, un suivi des ventes qui se met en file d'attente localement et se réconcilie de manière déterministe, et un tableau de bord plan vs réel régional que le responsable senior ouvre au début de chaque semaine. Le résultat est une boîte à outils de vente interne qui est déployée aux États-Unis et dans l'UE sous les exigences RGPD et CCPA / CPRA dès le premier jour, fait partie du portefeuille de YuSMP Group de travaux de développement d'applications mobiles, et fonctionne sans surveillance en production depuis trois ans.
Points clés du projet
Clients iOS & Android natifs
Catalogue SQLite hors ligne en premier
Synchronisation des ventes sans conflit
Reporting plan vs réel
Tableaux de bord régionaux en React
Back-office d'administration Laravel
Contrôle d'accès basé sur les rôles
3 ans en production · US & UE
Les chiffres clés
Un aperçu de ce que le projet Farm a livré sur iOS, Android et un back-office Laravel + React lors de son premier cycle de production et des trois années d'exploitation qui ont suivi.
2plateformes natives — iOS en Swift et Android en Kotlin, bases de code entièrement séparées optimisées par OS
3 ansd'utilisation continue en production sur les territoires de vente terrain US et UE avec une télémétrie stable
100 %des ventes déposées hors ligne se réconcilent de manière déterministe lors de la prochaine synchronisation réussie — sans doublons
9 moisfenêtre de développement initiale depuis la découverte jusqu'au premier déploiement en production sur les deux stores
4catégories de produits principales — engrais, semences, agents chimiques et équipements — dans le catalogue structuré
14–20 sem.fenêtre de livraison typique pour une application interne de vente terrain comparable sur les deux stores
Pourquoi iOS et Android natifs plutôt qu'une interface multiplateforme
La décision de plateforme a dominé tous les autres choix architecturaux. Nous avons choisi Swift natif sur iOS et Kotlin sur Android plutôt qu'une interface multiplateforme unique car les compromis dans une fenêtre de production de trois ans s'alignent parfaitement avec la voie native. Les clients natifs nous ont donné un accès de première classe à la pile Core Data et SQLite native à la plateforme sur iOS et à Room sur SQLite sur Android — la fondation de toute architecture mobile hors ligne en premier défendable. Les sémantiques de synchronisation en arrière-plan diffèrent suffisamment entre BGTaskScheduler d'iOS et WorkManager d'Android pour qu'envelopper les deux dans une seule abstraction nous aurait coûté la prévisibilité dont l'équipe opérationnelle avait besoin pour des représentants sans surveillance.
Les interfaces multiplateformes — React Native, Flutter, la queue Xamarin — ont été évaluées et éliminées. Leurs abstractions sur le travail en arrière-plan et SQLite natif à la plateforme n'avaient pas la bonne forme pour un flux de travail de représentant qui passe des heures hors ligne. Opter pour le natif signifiait que l'ensemble de la pile — interface, magasin local, moteur de synchronisation, livraison de notifications push — est possédée par plateforme et citée de bout en bout contre la propre documentation d'Apple et de Google.
| Dimension | Swift / Kotlin natif (Farm) | React Native | Flutter |
|---|---|---|---|
| Accès SQLite hors ligne | De première classe — Core Data et Room | Ponté — WatermelonDB ou tiers | Ponté — sqflite ou Drift |
| Synchronisation en arrière-plan | BGTaskScheduler / WorkManager direct | Enveloppé — fiabilité variable | Enveloppé — fiabilité variable |
| Profil de batterie lors de longues sessions hors ligne | Réglable par plateforme | Plus lourd — coût du pont JS | Plus léger que RN, toujours abstrait |
| Coût de maintenance sur trois ans | Deux bases de code stables sur les API du fournisseur OS | Turnover des mises à jour du framework | Turnover des mises à jour du framework |
| Accessibilité native | VoiceOver / TalkBack de première classe | Acceptable — lacunes partielles | Acceptable — lacunes partielles |
| Fiabilité des notifications push | APNs / FCM direct | Ponté — Notifee / RNFB | Ponté — firebase_messaging |
| Comportement clavier / locale par OS | Natif à l'OS | Enveloppé — cas limites | Enveloppé — cas limites |
Références de plateforme : Documentation Apple BGTaskScheduler, Référence Android WorkManager.
Build iOS — Swift, Core Data et le flux de suivi des ventes
Le client iOS est construit en Swift avec SwiftUI pour la couche interface et Core Data sur SQLite pour le magasin local. L'ensemble de la surface de suivi des ventes se réduit à une machine à états unique — brouillon, en file d'attente, en synchronisation, réconcilié — et le représentant ne voit jamais d'erreur réseau dans le flux utilisateur car le rapport a déjà été persisté localement avant que l'écran ne termine son animation de fermeture. La recherche de clients s'exécute contre le magasin sur l'appareil sans aller-retour réseau, le catalogue est paginé dans une liste à chargement différé, et les prix sont résolus depuis la version de la liste de prix localement mise en cache qui était authoritative lors de la dernière synchronisation réussie du représentant.
Le chemin de réconciliation est là où la plupart des applications de vente internes perdent la correction, et où nous avons consacré des efforts d'ingénierie disproportionnés. Le flux est : écrire le rapport dans Core Data avec un horodatage client monotone et une clé d'idempotence UUID, le mettre en file dans BGTaskScheduler, tenter la synchronisation à chaque transition de connectivité, et laisser le serveur retourner l'enregistrement d'habilitation canonique. Les doublons sont impossibles car la clé d'idempotence est la corrélation primaire, et une vente conclue dans une cave en Suède et rouverte dans un train deux heures plus tard se réconcilie proprement. La surface iOS de bout en bout est livrée dans le cadre de notre pratique d'ingénierie iOS et Android.
Build Android — Kotlin, Room et le moteur de synchronisation
Le client Android est écrit en Kotlin avec Jetpack Compose pour l'interface et une couche Room sur SQLite pour le magasin local. WorkManager gère le planning de synchronisation en arrière-plan avec des sémantiques de backoff respectant le mode Doze et les optimiseurs de batterie Samsung, Xiaomi, OnePlus et Pixel — sans service au premier plan, le moteur de synchronisation mourrait silencieusement dans un conteneur OEM agressif en quelques minutes, rompant le contrat implicite qu'un rapport hors ligne finit par apparaître dans le tableau de bord du responsable. Une notification persistante minimale maintient la synchronisation longue durée en vie sur les familles d'appareils Android 10 à 14.
Le moteur de synchronisation est là où le client Android justifie son existence. Le delta sur l'appareil est envoyé à une API Laravel à chaque transition de connectivité, le serveur retourne la liste de prix et le registre des clients authoritative, et la résolution des conflits est déterministe — le serveur gagne sur les prix et les enregistrements clients, le client gagne sur les notes de terrain et les métadonnées attachées par le représentant. Après un transfert Wi-Fi vers LTE, le moteur reprend automatiquement le dernier jeton de synchronisation, et l'actualisation du catalogue est incrémentale plutôt qu'un rechargement complet — un représentant avec un magasin local de 250 Mo ne re-télécharge pas le catalogue tous les lundis. La même équipe technique porte iOS et Android en parallèle dans le cadre de notre pratique de développement d'applications mobiles.
Back-office, plan vs réel et posture prête pour l'audit
Le back-office Farm repose sur une API Laravel avec un administrateur React et ne conserve que les données nécessaires — registre des clients, catalogue produits, liste de prix, quotas de vente trimestriels et le flux de rapports de ventes provenant du terrain. Il n'y a pas de suivi de localisation par représentant, pas de capture de frappe au ralenti et pas de tuyau de métadonnées vers un fournisseur d'observabilité tiers. Les compteurs qui alimentent le tableau de bord plan vs réel régional sont agrégés côté serveur et envoyés sous forme de séries numériques anonymes ; les identifiants par client ne quittent pas la table des clients.
L'identité de facturation pour les propres clients du distributeur — les exploitations agricoles et les coopératives agricoles qui achètent le produit — est conservée dans le même magasin Laravel, mais est gérée par accès via un modèle de droits basé sur les rôles de sorte qu'un représentant terrain ne voit que les clients de son territoire. Les politiques d'infrastructure-as-code imposent les invariants d'accès — toute pull request qui élargirait la portée de lecture d'un représentant ou introduirait un journal de localisation par représentant fait échouer la CI. La posture est construite pour s'aligner avec les obligations du RGPD pour les utilisateurs dans l'Union européenne et du CCPA / CPRA pour les utilisateurs en Californie et aux États-Unis — et pour faire d'une future évaluation indépendante de préparation un exercice de documentation, pas une refonte architecturale.
Posture de conformité : Aligné RGPD · Prêt ISO 27001 · SOC 2 Type II en cours · Compatible HIPAA · CCPA reconnu.
Méthodologie de livraison
Un projet en cinq phases qui a conduit Farm des entretiens de recherche territoriale à la production sur iOS, Android et un back-office Laravel + React.
Catalogue & modèle de synchronisation
Schéma du catalogue produits, tarification structurée, conception du jeton de synchronisation, contrat de clé d'idempotence pour les rapports de vente, squelette de l'API Laravel, scaffold de l'administrateur React.
Builds de plateforme
Client iOS Swift / SwiftUI sur Core Data + BGTaskScheduler ; client Android Kotlin / Jetpack Compose sur Room + WorkManager ; machine à états de suivi des ventes.
Renforcement prêt pour l'audit
Politiques d'infrastructure-as-code bloquant les régressions de portée d'accès, assurance qualité des droits basés sur les rôles, pipeline de télémétrie des crashes, examen de l'enveloppe d'exploitation sur trois ans.
Lancement & télémétrie
Soumission de distribution interne App Store + Google Play sur les storefronts US et UE, déploiement du tableau de bord régional, bascule plan vs réel pour les responsables seniors.
Plan vs réel, attribution des quotas et la vue responsable
La couche de reporting de Farm a été construite pour maintenir le reporting terrain et les analyses du responsable provablement alignés, car la boucle plan vs réel s'effondre dès le moment où un responsable et un représentant voient des chiffres différents pour le même client dans la même semaine. Le quota trimestriel est défini par un responsable senior dans l'administrateur React et envoyé au magasin local de chaque représentant lors de la prochaine synchronisation. Le représentant voit sa propre progression dans l'application mobile — une sparkline unique par rapport au plan, ventilée par catégorie de produit — et le responsable senior voit l'agrégat régional dans le back-office avec un zoom jusqu'aux ventilations par représentant et par client. L'agrégation côté serveur s'exécute contre un seul flux de rapports de vente authoritative alimenté par les clients mobiles via le chemin de clé d'idempotence, de sorte que la vue du responsable et la vue du représentant se réconcilent toujours avec la même source de vérité. Le comportement de suppression-édition, les rapports hors ligne tardifs et les notes de terrain attachées par le représentant lisent tous depuis le même enregistrement, de sorte qu'une seule vente se résout proprement lors des réinstallations, changements d'appareil et l'éventuel portail web. L'ensemble du sous-système a été conçu avec l'extensibilité en tête : ajouter un niveau multi-devises, un moteur de commissions par territoire ou une extension représentant-partenaire B2B est une modification de configuration du back-office, pas une publication de code.
Lancement aux États-Unis et dans l'Union européenne
Farm a été lancé sur l'App Store d'Apple et Google Play (distribution interne) avec des storefronts actifs aux États-Unis et dans l'Union européenne. Le build en langue anglaise sert des représentants commerciaux terrain en Californie, à New York, au Texas, en Floride et à Washington aux États-Unis, et aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE, sans base de code distincte par région. Les flux de consentement sont adaptés à la région au niveau du back-office : les comptes de représentants dans l'UE et l'EEE reçoivent un écran de consentement granulaire de style RGPD pour toute télémétrie de produit optionnelle, et les comptes en Californie reçoivent une divulgation de style CCPA « Ne pas vendre ou partager mes informations personnelles » dans le même flux d'inscription. Les pratiques de traitement des données sont alignées avec le RGPD pour les utilisateurs européens et avec le patchwork de confidentialité des États américains — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. Comme l'architecture minimise les données de suivi par représentant, la conformité régionale se réduit à une divulgation honnête plutôt qu'à une ségrégation des données par juridiction.
L'API Laravel a été déployée dans les régions UE et US en parallèle — Pays-Bas, Allemagne, France, Suède et Irlande pour la couverture UE ; US East et US West pour l'Amérique du Nord — avec les workers sans état de chaque région provisionnés de manière identique. Le service d'agrégation qui alimente le tableau de bord plan vs réel régional exécute des workers sans état pouvant être épinglés indépendamment dans les régions UE ou US pour de futurs engagements de résidence des données. La distribution App Store et Google Play a été calibrée pour l'inscription en entreprise interne, et la divulgation de confidentialité intégrée à l'application documente exactement l'architecture ci-dessus, citant les obligations RGPD et les obligations CCPA de Californie directement. L'équipe technique derrière le projet est répartie sur le fuseau CET et travaille avec un chevauchement Est-US (9h–13h ET) pour les points quotidiens, la coordination des révisions du store et la gestion des incidents — le fuseau qui permet à une équipe produit US et à une équipe technique UE de partager quatre heures de chevauchement en direct chaque jour.
Stack technique et feuille de route
Swift
SwiftUI
Core Data
BGTaskScheduler
Kotlin
Jetpack Compose
Room
WorkManager
SQLite
Laravel
PHP 8
React
PostgreSQL
Redis
APNs
Firebase Cloud Messaging
Docker
Terraform
Prometheus
La feuille de route active de développement de logiciels sur mesure pour Farm comprend un moteur de commissions par territoire, une liste de prix multi-devises pour les distributeurs transfrontaliers, un transport de partage hors ligne obfusqué pour que les représentants puissent transmettre un rapport de vente d'un appareil à un autre sur le terrain sans passer par le serveur, et un client de bureau construit sur Tauri pour partager la logique métier avec la base de code mobile. Un niveau partenaire-représentant B2B avec liste de clients propre, gestion d'équipe et SSO est prévu pour les distributeurs de taille intermédiaire US et UE, le sous-système d'habilitations étant déjà structuré pour l'affectation multi-siège. Les plans d'infrastructure comprennent une automatisation cloud & DevOps accrue du pipeline de déploiement régional, un dispositif de vérification continue interne pour le contrat de correction de synchronisation hors ligne, et une future évaluation indépendante de préparation intégrée dans la cadence opérationnelle.
Construire une application de vente terrain similaire — parlons-en
Si vous planifiez une application mobile interne de vente terrain, un outil AgTech hors ligne en premier ou toute application mobile où les représentants passent des heures hors couverture et la boucle de reporting doit résister à un auditeur externe pour les publics US et UE, nous avons livré cette pile de bout en bout et pouvons réduire considérablement le délai de développement. Le produit en direct est exploité en interne par le distributeur sur yusmpgroup.ru/cases/farm (page du cas), et l'équipe technique derrière ce projet fait partie de YuSMP Group. Nous travaillons à prix fixe pour les MVP bien définis et avec des équipes dédiées pour la livraison continue, avec un horaire CET et une fenêtre garantie de chevauchement Est-US (9h–13h ET) pour les points quotidiens, les démonstrations et la gestion des incidents.
Questions fréquentes
Quel est le coût de développement d'une application mobile interne de vente terrain pour les distributeurs ?
Une application mobile interne de vente terrain avec clients iOS et Android, un catalogue de produits hors ligne, le suivi des ventes et un back-office Laravel ou Node coûte généralement entre 80 k€ et 180 k€ pour un MVP. L'ajout de tableaux de bord régionaux plan vs réel, de droits basés sur les rôles, d'une synchronisation hors ligne sans conflit, de rappels push et d'intégrations dans un ERP existant ou une pile comptable de style 1C porte un déploiement complet à 220 k€–450 k€. Le principal facteur de coût est le travail de correction de la synchronisation hors ligne et la logique de tarification par région.
Pourquoi construire des clients iOS et Android natifs plutôt qu'un framework multiplateforme ?
Les représentants commerciaux de terrain agricole travaillent pendant des heures hors ligne, dans des caves, des entrepôts et des champs sans signal. Les clients Swift et Kotlin natifs nous permettent de contrôler la consommation de batterie lors des longues sessions de synchronisation, d'intégrer proprement les stockages SQLite natifs à la plateforme et de livrer le comportement clavier et accessibilité propre à chaque OS que React Native et Flutter enveloppent encore dans des compromis. Avec une fenêtre d'exploitation de trois ans à l'esprit, le coût de maintenance de deux bases de code natives s'est avéré inférieur au coût cumulé de contournement des abstractions multiplateformes.
Comment construire une véritable application mobile de vente hors ligne en premier ?
Une posture hors ligne en premier défendable est une décision d'architecture, pas une bascule de fonctionnalité. Le catalogue complet de produits, les tableaux de tarification et la liste des clients sont mis en miroir dans un magasin SQLite local lors de la première connexion et mis à jour progressivement à chaque synchronisation réussie. Les rapports de vente rédigés hors ligne sont mis en file d'attente avec des horodatages locaux monotones et réconciliés sur le serveur à l'aide de clés d'idempotence, de sorte qu'un représentant qui clôture une vente dans une cave et rouvre l'application dans un train deux heures plus tard ne duplique ni ne perd jamais une transaction. La résolution des conflits est déterministe — le serveur gagne sur le prix, le client gagne sur les notes de terrain.
Que fait l'application Farm pour les responsables commerciaux terrain en agriculture ?
Farm est la boîte à outils interne qu'un responsable commercial régional emporte dans une visite d'exploitation agricole. Elle expose un catalogue structuré d'engrais, semences, agents chimiques et équipements avec les prix actuels ; permet au représentant de rédiger un rapport de vente en quelques secondes pour un client connu ; suit le plan vs réel par rapport aux objectifs de vente trimestriels du représentant ; et affiche un tableau de bord côté responsable ventilant les chiffres par catégorie de produit et région. Les rappels push incitent à rédiger les rapports non déposés, et un administrateur back-office en React gère les mises à jour du catalogue, les modifications de prix et l'attribution des quotas.
Combien de temps faut-il pour livrer une application de vente terrain interne sur iOS et Android ?
Un MVP ciblé avec clients iOS et Android natifs, un catalogue hors ligne en premier, le suivi des ventes et un administrateur Laravel prend généralement 14 à 20 semaines. L'ajout du tableau de bord régional côté responsable, des analyses plan vs réel, des droits basés sur les rôles pour les responsables seniors et les représentants terrain, et de la couche de synchronisation sans conflit ajoute 6 à 10 semaines. Le renforcement de l'application pour trois ans d'utilisation en production sans surveillance — télémétrie des crashes, fiabilité des push, journaux de relecture de synchronisation — est fréquemment sous-estimé et doit être budgétisé à 4–6 semaines de travail dédié.
Cas connexes
Plus de projets mobiles & d'outillage interne
CheckList
Application mobile d'audit terrain pour les inspecteurs — formulaires hors ligne, capture multi-photos, tableau de bord responsable.
Voir le cas →
SuperStep
Application interne de formation et de performance pour une chaîne de distribution — base de connaissances, suivi des performances, back-office.
Voir le cas →
ZipIt
Marketplace B2B de pièces détachées avec CRM fournisseur, catalogue structuré et flux de commande aux États-Unis & UE.
Voir le cas →Planifier un projet similaire
Réserver un appel de découverteDemander une proposition
Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvré.