Application hors ligne pour équipes terrain : synchronisation, conflits, photos, signature et ERP

Une application de bureau tombe en panne quand le Wi-Fi coupe. Une application terrain, elle, vit sans réseau : sous-sol d’un parking, chaufferie, local technique en béton armé, chantier en zone rurale, cage d’ascenseur. Si l’outil affiche un écran blanc à ces moments-là, le technicien revient au papier le lendemain, et votre projet est mort sans que personne ne l’annonce.

Le mode hors ligne n’est donc pas une option pour une application mobile métier terrain : c’est la fonctionnalité qui conditionne toutes les autres. Et c’est aussi la plus sous-estimée dans les cahiers des charges. Ce guide détaille ce qu’elle implique vraiment : architecture, synchronisation, conflits, photos, signature, intégration ERP et budget.

Pourquoi « hors ligne » est une décision d’architecture

La plupart des applications sont construites en « en ligne d’abord » : chaque écran interroge le serveur, chaque bouton envoie une requête. Ajouter le hors ligne après coup revient à réécrire la moitié de l’application.

Une application terrain se construit à l’inverse, en local d’abord :

• Une base de données sur le téléphone (SQLite, ou une couche au-dessus comme WatermelonDB, Realm, Drift selon la technologie). L’interface lit et écrit uniquement dans cette base.
• Une file d’envoi : chaque action (intervention clôturée, photo prise, pièce consommée) devient une opération enregistrée localement, puis envoyée au serveur dès que possible.
• Des identifiants générés sur l’appareil (UUID) : un bon d’intervention créé dans un sous-sol doit avoir un identifiant définitif immédiatement, sans attendre le serveur.
• Un moteur de synchronisation qui descend les nouveautés du serveur et remonte la file, dans les deux sens, par petits lots, avec reprise en cas de coupure.

L’utilisateur, lui, ne doit rien voir de tout ça. Il travaille, l’application enregistre, et un indicateur discret lui dit ce qui reste à envoyer.

Définir ce qui doit être disponible hors ligne

Tout embarquer sur le téléphone est impossible et inutile. La vraie question de cadrage est : de quoi le technicien a-t-il besoin sans réseau, pour sa journée ?

Deux règles à retenir. D’abord, toute donnée affichée hors ligne doit porter sa fraîcheur (« stock au 22/09 à 7 h 40 ») : un technicien qui croit une donnée à jour prend de mauvaises décisions. Ensuite, la synchronisation doit être incrémentale : on ne retélécharge que ce qui a changé depuis le dernier passage, sinon chaque démarrage prend trois minutes en 4G faible.

La synchronisation : le cœur du projet

Montante : la file d’opérations

Côté téléphone vers serveur, le modèle le plus robuste est la file d’opérations : on n’envoie pas « l’état de l’intervention », on envoie « le technicien a ajouté telle pièce à 10 h 12 », « le technicien a clôturé à 11 h 05 ». Chaque opération porte un identifiant unique, ce qui rend l’envoi idempotent : si le réseau coupe au milieu et que l’application renvoie la même opération, le serveur la reconnaît et ne crée pas de doublon.

C’est ce détail qui évite le problème classique des applications terrain mal conçues : trois bons d’intervention identiques dans l’ERP parce que le technicien a appuyé trois fois sur « envoyer » dans une zone où le réseau allait et venait.

Descendante : le curseur de synchronisation

Côté serveur vers téléphone, chaque appareil conserve un curseur (« dernière synchro : horodatage ou numéro de version »). Au retour du réseau, il demande tout ce qui a changé depuis, y compris les suppressions, qu’on oublie souvent : une intervention annulée au bureau doit disparaître du téléphone, pas rester fantôme dans le planning.

Quand synchroniser

• Au lancement de l’application et au retour au premier plan.
• Au retour du réseau, détecté automatiquement.
• En arrière-plan, dans les limites imposées par iOS et Android (qui ne garantissent ni la fréquence ni le moment exact).
• Sur demande, avec un bouton « Synchroniser maintenant » et un compteur visible des éléments en attente.

Ce dernier point compte plus qu’il n’y paraît : le chef d’équipe veut pouvoir vérifier, avant de quitter le chantier, que zéro élément reste bloqué sur un téléphone.

Les conflits : écrire la règle métier avant le code

Un conflit survient quand la même donnée est modifiée à deux endroits pendant que l’un d’eux était hors ligne. Exemple typique : le bureau décale une intervention au lendemain pendant que le technicien, dans un sous-sol, la clôture.

La tentation est d’appliquer partout « le dernier arrivé gagne ». C’est simple à coder et dangereux : la modification du bureau, arrivée en second, effacerait silencieusement la clôture du technicien.

La bonne approche consiste à écrire, champ par champ, qui a autorité :

Cette table est un livrable de cadrage, validé par les responsables opérationnels, pas une décision laissée au développeur. Elle tient souvent sur une page et évite des semaines de litiges après le déploiement. Pour la structurer dans un document de consultation, notre article sur le cahier des charges d’une application mobile donne le squelette.

Enfin, prévoyez un écran de conflits côté back-office : les rares cas que la règle ne sait pas trancher y remontent, avec les deux versions côte à côte.

Photos : le vrai poids du projet

Sur une application terrain, les photos représentent l’essentiel du volume de données : état avant/après, preuve de passage, relevé de compteur, réserve de chantier. Un technicien peut en produire plusieurs dizaines par jour. Sans traitement, une photo de smartphone moderne pèse plusieurs mégaoctets, et une journée entière ne remonte jamais en 4G faible.

Ce qu’il faut prévoir :

• Compression à la prise de vue : redimensionner autour de 1 600 à 2 000 pixels de large et recompresser. Pour la grande majorité des usages (constat, preuve), la différence est invisible et le poids est divisé par cinq à dix.
• Stockage local séparé des fichiers, avec le lien vers l’intervention dans la base locale.
• Envoi en arrière-plan, fichier par fichier, avec reprise : une coupure à 80 % d’une photo ne doit pas faire repartir tout le lot de zéro.
• Métadonnées utiles : date, heure, intervention, éventuellement position GPS si c’est justifié et assumé vis-à-vis des salariés (voir plus bas).
• Annotation : entourer une fuite, flécher une fissure. C’est souvent la fonctionnalité la plus appréciée des équipes, et elle se fait sur l’image locale, sans réseau.
• Nettoyage : supprimer les fichiers du téléphone une fois leur réception confirmée par le serveur, sinon l’espace de stockage sature en quelques semaines.

Un point souvent oublié : le mode de prise de vue. Si l’application renvoie vers la galerie du téléphone, les photos d’interventions se mélangent aux photos personnelles du salarié. Une caméra intégrée à l’application règle le problème et accélère le geste.

Signature client : ce qu’il faut capturer

La signature sur l’écran à la fin de l’intervention remplace le bon papier. Techniquement, la tracer au doigt est trivial. Ce qui compte, c’est ce qui l’entoure :

1. Le document signé est figé : le récapitulatif (travaux, pièces, temps passé, réserves éventuelles) est généré puis verrouillé au moment de la signature. Toute modification ultérieure crée une nouvelle version.
2. Les éléments de preuve sont attachés : horodatage, identité du technicien connecté, nom saisi du signataire, identifiant de l’intervention, et une empreinte du document.
3. Le PDF est généré sur le téléphone, pour pouvoir être signé et laissé au client même sans réseau ; l’envoi par email part automatiquement au retour de la connexion.
4. Le cas du client absent est prévu : signature différée, refus de signer motivé, ou photo du bon papier en secours.

Sur le plan juridique, une signature électronique simple est recevable en France et dans l’Union européenne (règlement eIDAS) ; sa force probante dépend de la qualité des éléments de preuve ci-dessus. Pour les documents les plus engageants (procès-verbal de réception de travaux, devis important), on s’appuie sur un prestataire de signature électronique avancée, qui nécessite en général une connexion au moment de la signature. C’est un arbitrage à faire en cadrage, document par document.

Intégration ERP : ne jamais brancher le téléphone en direct

L’application terrain doit presque toujours dialoguer avec un système existant : ERP, logiciel de gestion de maintenance, outil de facturation, logiciel métier du BTP. La tentation est de faire parler le téléphone directement avec lui. C’est une erreur quasi systématique.

Les ERP ont rarement été conçus pour recevoir des centaines de petites requêtes de téléphones intermittents. Ils ont des fenêtres de maintenance, des lenteurs, des formats qui changent à chaque mise à jour, et parfois une API limitée voire inexistante.

L’architecture saine intercale un back-end intermédiaire :

• Le téléphone synchronise uniquement avec ce back-end, qui est conçu pour le hors ligne (idempotence, curseurs, conflits).
• Le back-end dialogue avec l’ERP à son rythme : par API quand elle existe, par échange de fichiers planifié sinon, avec une file de réessais.
• Si l’ERP est en panne, le terrain continue de travailler normalement ; les données remontent quand il revient.
• Chaque échange est journalisé : quand une facture manque dans l’ERP, on sait en deux minutes où elle s’est arrêtée.

Comptez l’intégration ERP comme un chantier à part entière, avec un temps d’étude de l’existant : c’est souvent là que se cache la plus grosse incertitude du budget. Le même back-end sert en général aussi de back-office pour le bureau (planification, suivi, écran des conflits).

Choix technique et points à ne pas négliger

Pour un usage terrain intensif, une application native ou multiplateforme (React Native, Flutter) est le choix raisonnable : stockage local volumineux, tâches en arrière-plan, caméra et fichiers pleinement accessibles. Une PWA peut suffire pour quelques formulaires légers, mais son stockage et son fonctionnement en arrière-plan restent plus limités, surtout sur iPhone. Le comparatif détaillé est dans notre article React Native, Flutter ou natif.

Quelques points qui font la différence en production :

• Les appareils : smartphones durcis ou grand public, parc Android hétérogène, écrans lisibles en plein soleil, boutons utilisables avec des gants. On teste sur les vrais téléphones des équipes, pas seulement sur les derniers modèles.
• La sécurité des données locales : chiffrement de la base sur l’appareil, déconnexion à distance d’un téléphone perdu, gestion de flotte (MDM) si l’entreprise en a une.
• La géolocalisation des salariés : elle doit être justifiée, proportionnée et connue des équipes ; en pratique, on se limite souvent à horodater le début et la fin d’intervention plutôt qu’à suivre en continu.
• Les mises à jour : quand le format des données change, les téléphones qui n’ont pas encore été mis à jour doivent continuer à synchroniser. Le back-end doit accepter au moins la version précédente de l’application.
• La supervision : savoir combien d’opérations sont en attente sur chaque appareil, et détecter un téléphone qui ne s’est pas synchronisé depuis trois jours.

Budget et planning réalistes

Le mode hors ligne n’est pas une ligne de devis isolée : il touche la base locale, la synchronisation, les conflits, les tests et le back-end. D’expérience, il représente environ 20 à 40 % de budget en plus par rapport à la même application pensée uniquement en ligne, selon le nombre d’objets synchronisés et la complexité des règles de conflit.

Ces fourchettes sont indicatives et hors taxes ; le détail de nos formules est sur la page tarifs application mobile. Pour un premier périmètre, un MVP centré sur un seul parcours (recevoir son planning, réaliser l’intervention, faire signer, remonter) est souvent le bon point de départ, avec l’intégration ERP limitée aux flux indispensables.

Côté planning, réservez deux à quatre semaines de pilote terrain avec une équipe réelle avant le déploiement général. C’est là qu’apparaissent les zones blanches imprévues, les téléphones trop anciens et les règles de conflit mal pensées. Et budgétez la suite : iOS, Android et l’ERP évoluent chaque année, et une application terrain non maintenue se dégrade vite. Notre article sur le coût de la maintenance d’une application mobile détaille ce poste.

En résumé

Une application terrain réussie se reconnaît à un détail : les techniciens ne pensent plus au réseau. Pour y arriver, il faut concevoir en local d’abord, écrire les règles de conflit avec les opérationnels, traiter les photos comme un sujet à part entière, entourer la signature de preuves et isoler l’ERP derrière un back-end conçu pour l’intermittence.

Ce sont ces choix, faits dès le cadrage, qui distinguent un outil adopté d’un outil abandonné au bout de trois semaines. Pour voir comment nous abordons ces projets pour le BTP, la maintenance et les services d’intervention, consultez notre page dédiée à l’application mobile métier terrain.

Vous avez un projet d’application pour vos équipes terrain, ou un outil existant qui ne tient pas sans réseau ? Contactez-nous : un premier échange suffit pour cadrer le périmètre hors ligne, l’intégration à votre ERP et une fourchette de budget.