Bon d'intervention sans réseau : l'app terrain qui ne perd ni photo ni signature

Il est 16 h, le technicien termine une intervention dans une chaufferie au deuxième sous-sol. Plus une barre de réseau. L'application tourne dans le vide, puis perd la saisie. Alors il fait comme d'habitude : il note sur le bon papier, prend les photos avec son téléphone personnel et fait signer le client sur un carbone. Le soir, quelqu'un au bureau ressaisit tout. Une photo manque, la signature est illisible, et la facture part avec plusieurs jours de retard.

Ce scénario ne vient pas d'un manque de bonne volonté sur le terrain. Il vient d'un outil conçu comme si le réseau était toujours là. Voici, étape par étape, comment concevoir une application d'intervention offline-first : le téléphone enregistre d'abord tout en local, une file d'attente envoie les données dès que le réseau revient, les photos partent en différé, la signature est capturée à l'écran et le bon validé déclenche la facture dans l'ERP. Le guide s'adresse au dirigeant opérationnel ou au DSI d'une PME ou d'une ETI qui doit décider quoi construire, ou quoi acheter. Aucune compétence de développement n'est requise.

Le périmètre est volontairement serré : le cycle du bon d'intervention, de la tournée chargée le matin jusqu'à la facture. Le planning, le stock de pièces et les contrats de maintenance restent hors champ. Et les limites auront autant de place que les bénéfices, parce que c'est là que se jouent les mauvaises surprises. Le schéma ci-dessous résume ce cycle : la partie gauche fonctionne sur le téléphone, même sans réseau, la partie droite se déclenche côté serveur au retour de la connexion.

Prérequis : ce qu'il faut avoir sous la main

Avant de parler technique, rassemblez cinq éléments. Ils servent à chaque étape et évitent de concevoir l'outil à l'aveugle.

• L'inventaire du bon actuel : champs, cases à cocher, pièces posées, temps passé, photos attendues, qui signe.
• Le circuit du bon après l'intervention : qui le reçoit, qui le ressaisit, où il atterrit (ERP, GMAO, outil de facturation, tableur).
• La carte des zones blanches réelles (sites clients, sous-sols, bâtiments industriels) et le parc d'appareils : iOS ou Android, téléphones personnels ou d'entreprise.
• Deux ou trois chiffres mesurés chez vous : délai entre intervention et facture, nombre de bons ressaisis par semaine, litiges liés à une photo ou une signature manquante.
• Un interlocuteur qui connaît l'ERP ou la GMAO et sait s'il existe une API ou un import de fichiers.

Étape 1 : mesurer ce que coûte le papier et réduire le bon au strict nécessaire

Le point de départ n'est pas la technologie, c'est la douleur chiffrée. Combien de jours séparent la fin d'une intervention de l'envoi de la facture ? Combien d'heures par semaine passe-t-on à ressaisir des bons ? Combien de litiges clients tiennent à une photo absente ou à une signature contestée ? Ces chiffres sont les vôtres : notez-les tels quels, ils serviront de référence au moment du pilote.

Ensuite, figez un bon minimal pour la première version, le fameux MVP (produit minimum viable). Posez une seule question à chaque champ : est-il indispensable pour facturer ? Client, équipement, travaux réalisés, pièces posées, temps passé, photos avant et après, signature. Le reste (relevés détaillés, questionnaires de satisfaction, préconisations commerciales) peut attendre une version 2.

Résultat attendu : une liste courte de champs obligatoires et une ligne de base mesurée. Ce périmètre réduit sert aussi à comparer honnêtement développement sur mesure et logiciel du marché à l'étape suivante.

Étape 2 : choisir entre logiciel terrain du marché, PWA et app mobile

Trois voies s'offrent à vous, et aucune n'est mauvaise par principe.

Un logiciel de gestion d'interventions du marché (on parle de FSM, pour field service management) est une option légitime. Il convient bien si votre bon ressemble à celui de tout le monde, si les intégrations dont vous avez besoin sont déjà proposées et si la licence par technicien reste acceptable dans le coût total sur plusieurs années. Comparez-le avec le bon minimal de l'étape 1 : s'il le couvre sans contorsion, c'est souvent le chemin le plus court.

Une PWA (application web installable depuis le navigateur) séduit par son coût : un seul code, pas de passage par les magasins d'applications. Mais deux limites pèsent lourd pour un usage terrain sans réseau. D'abord, l'API Background Sync, qui permet de renvoyer des données en arrière-plan au retour du réseau, n'est pas prise en charge par Safari, y compris sur iOS. Ensuite, WebKit, le moteur de Safari, indique que le stockage des sites est par défaut en mode « best-effort » : les données peuvent être effacées par le navigateur en cas de pression sur le stockage ou si le site n'est pas utilisé pendant un certain temps. Le site peut demander un stockage persistant, mais Safari ne l'accorde que selon ses propres critères, par exemple si l'application a été ajoutée à l'écran d'accueil. Sur un parc d'iPhone, confier des bons non encore envoyés à ce stockage reste un pari risqué.

Une application mobile, native ou multiplateforme avec Flutter ou React Native (souvent avec Expo, la boîte à outils de référence pour React Native), dispose d'une vraie base de données sur l'appareil et de tâches de fond gérées par le système. C'est plus cher qu'une PWA, mais c'est la base la plus solide pour ne rien perdre hors ligne.

Résultat attendu : une décision argumentée sur quatre critères. Le parc d'appareils (beaucoup d'iPhone rend la PWA risquée), la spécificité de votre bon, les intégrations nécessaires avec vos outils et le coût total, licences comprises, sur trois à cinq ans. La suite du tutoriel suppose une application mobile, mais les principes valent aussi pour évaluer un logiciel du marché.

Étape 3 : concevoir offline-first, le téléphone enregistre d'abord

Le principe tient en une phrase : chaque saisie est écrite d'abord dans une base locale sur l'appareil, avant toute tentative d'envoi. L'écran du technicien lit uniquement cette base locale ; le serveur la met à jour quand il le peut. La documentation officielle Android sur l'offline-first décrit ce modèle : la source locale est la seule que lit l'application, et le réseau vient l'alimenter. Parmi les stratégies d'écriture qu'elle présente, écrire d'abord en local puis envoyer dès que possible est celle qu'elle recommande quand les données sont critiques, ce qui est le cas d'un bon signé.

Chaque plateforme a son outil standard pour cette base locale : Room sur Android, SwiftData ou Core Data sur iOS, expo-sqlite côté React Native avec Expo, drift côté Flutter. Le choix revient à l'équipe technique ; ce qui compte pour vous, c'est la règle : une coupure de réseau ne bloque jamais la saisie et ne fait rien perdre.

Deuxième réflexe : précharger la tournée. Au départ du matin, quand le réseau est bon, l'application télécharge les interventions du jour, les fiches clients et l'historique des équipements concernés. Dans la chaufferie, le technicien a donc déjà tout sous les yeux.

Résultat attendu : en mode avion, le technicien ouvre son intervention, remplit le bon, prend ses photos et le clôture comme s'il avait du réseau.

Étape 4 : mettre en place la file d'attente et la synchronisation en arrière-plan

Une fois la saisie enregistrée en local, il faut l'envoyer. Chaque modification rejoint une file d'envoi, qui se vide au retour du réseau. Si un envoi échoue, il repart plus tard, avec des délais de plus en plus longs entre les tentatives (on parle de backoff exponentiel) pour ne pas vider la batterie à force de réessayer.

Voici à quoi peut ressembler une ligne de cette file. C'est un exemple de schéma : les noms des champs sont libres, ce n'est pas une API standard.

{"id":"op-0192","type":"bon.cloture","bon_id":"BI-2041","horodatage":"2026-11-03T14:32:08Z","tentatives":2}

Chaque champ a un rôle concret. L'identifiant d'opération permet au serveur de reconnaître un envoi déjà reçu : à condition que le serveur garde la trace des identifiants déjà traités, une ligne qui arrive deux fois après une coupure n'est traitée qu'une fois, et le client ne reçoit pas deux factures pour le même bon. L'horodatage servira à arbitrer les conflits à l'étape suivante. Le compteur de tentatives permet d'alerter le bureau si un bon reste bloqué.

Le point sensible est que cette file doit survivre à tout : application fermée, téléphone redémarré, batterie à plat. Sur Android, ce travail revient à WorkManager, dont la documentation précise que les tâches planifiées persistent après un redémarrage de l'appareil et respectent les modes d'économie d'énergie. Sur iOS, le framework BackgroundTasks permet de planifier ces envois en arrière-plan, mais c'est le système qui choisit le moment de les exécuter : l'envoi au premier lancement de l'application reste donc indispensable.

Enfin, rendez la file visible. Un simple indicateur « 3 bons en attente d'envoi » rassure le technicien : il sait que rien n'est perdu et n'a plus de raison de garder un double papier.

Résultat attendu : le technicien clôture trois bons hors ligne, reprend la route, et les trois bons arrivent au bureau d'eux-mêmes après le retour du réseau. Le délai dépend du système du téléphone (sur iPhone, c'est lui qui choisit le moment) : au pire, les bons partent à la prochaine ouverture de l'application, et l'indicateur d'attente montre ce qui n'est pas encore parti.

Étape 5 : décider qui gagne en cas de conflit

Cas typique : le bureau corrige l'adresse du client pendant que le technicien, hors ligne, clôture le bon. Au retour du réseau, deux versions du même bon se rencontrent. Laquelle garder ?

La documentation Android présente le last write wins (la dernière écriture l'emporte) comme une approche courante sur mobile : chaque modification porte un horodatage et le serveur garde la plus récente. C'est simple, mais il faut le dire clairement : avec cette règle, une modification peut être écrasée et perdue sans que personne ne s'en aperçoive.

La bonne nouvelle, c'est que quelques règles métier évitent la plupart des conflits avant même qu'ils n'arrivent :

• Un bon clôturé est verrouillé : le bureau ne le modifie plus, il crée un avoir ou un nouveau bon.
• Chaque champ a un propriétaire : l'adresse et le contrat appartiennent au bureau, les constats et les pièces posées au terrain.
• Photos et notes sont seulement ajoutées, jamais écrasées : deux personnes qui ajoutent une note ne se marchent pas dessus.

Il existe aussi des moteurs de synchronisation du marché qui gèrent ces mécanismes à votre place. Ils font gagner du temps, mais ils créent une dépendance (le vendor lock-in). Exemple concret : MongoDB, éditeur de bases de données, a mis fin à son service Atlas Device Sync : déprécié en septembre 2024, il est arrivé en fin de vie le 30 septembre 2025, et les applications qui s'appuyaient dessus ont dû migrer. Avant d'adopter un moteur, demandez-vous ce qu'il en coûterait d'en changer.

Résultat attendu : un tableau simple, champ par champ, qui dit qui a le droit de modifier quoi et ce qui se passe en cas de double modification.

Étape 6 : gérer les photos sans saturer le téléphone ni le forfait

Les photos sont le poids lourd du bon d'intervention. Une photo brute d'un smartphone récent pèse lourd, et un technicien peut en prendre des dizaines dans la journée. Trois règles suffisent à garder la maîtrise.

Compresser à la prise de vue. L'application réduit la taille et la qualité de l'image au moment où elle l'enregistre. Côté Expo, par exemple, le module expo-image-manipulator propose un réglage de compression de 0 à 1 et un enregistrement en JPEG, PNG ou WebP. Le bon niveau se règle avec vos équipes : une photo de plaque signalétique doit rester lisible.

Envoyer les photos à part. Les données du bon partent tout de suite, elles sont légères. Les photos suivent dans une file séparée, éventuellement seulement en Wi-Fi si le forfait mobile est limité. Le bureau peut ainsi préparer la facture sans attendre les images.

Purger après confirmation. La copie locale n'est effacée qu'une fois que le serveur a confirmé la réception, et d'ici là elle est rangée dans un dossier permanent de l'application, pas dans le cache temporaire que le système peut vider quand l'appareil manque de place. Ajoutez un garde-fou : quand l'espace libre de l'appareil passe sous un seuil, l'application prévient le technicien avant qu'il ne puisse plus rien enregistrer.

Résultat attendu : quarante photos prises dans la journée n'empêchent ni l'envoi rapide des bons, ni la prise de nouvelles photos le lendemain.

Étape 7 : faire signer le client sur l'écran, en sachant ce que ça vaut

La signature tracée au doigt sur l'écran remplace le carbone, mais il faut savoir ce qu'elle vaut juridiquement. Le règlement européen eIDAS distingue trois niveaux de signature électronique : simple, avancée et qualifiée. Une signature manuscrite dessinée sur une tablette relève en pratique de la signature électronique simple.

La FAQ eSignature de la Commission européenne pose deux principes. Une signature électronique, quel que soit son niveau, ne peut pas être écartée comme preuve au seul motif qu'elle est électronique. Mais seule la signature qualifiée a explicitement l'effet juridique d'une signature manuscrite dans toute l'Union. Autrement dit, la signature sur écran est recevable, mais sa force dépendra des éléments qui l'entourent.

Renforcez donc la preuve autour de la signature : nom du signataire saisi en clair, horodatage, position GPS si elle se justifie (et si elle est prévue dans votre politique de données personnelles), empreinte numérique du PDF généré pour prouver qu'il n'a pas été modifié, et copie envoyée automatiquement au client par e-mail. Pour un engagement contractuel fort, comme un devis signé sur place ou un avenant, passez plutôt par un prestataire de signature avancée. En cas de doute sur votre situation, demandez l'avis d'un juriste.

Résultat attendu : un PDF de bon signé et horodaté, envoyé au client dès que le bon est synchronisé, avec un dossier de preuve que vous pouvez produire en cas de litige.

Étape 8 : prévoir le téléphone oublié sur un chantier

Un téléphone finira par rester sur le capot d'une camionnette. Il contient des adresses, des noms, des photos de domiciles. La protection repose sur quatre couches.

Le chiffrement natif d'abord : iOS chiffre les fichiers via sa Data Protection, et Android prend en charge le chiffrement par fichier depuis Android 7.0. Vérifiez simplement que les appareils de la flotte ont un code de verrouillage actif. Vient ensuite la gestion de flotte (MDM, pour mobile device management) : côté Apple, un administrateur peut effacer un appareil à distance, ce qui rend les données illisibles. Côté Android, les solutions de gestion de flotte proposent des fonctions équivalentes ; vérifiez-les auprès de votre fournisseur.

Côté application, faites expirer les sessions après une période d'inactivité et gardez en local le minimum de données personnelles nécessaires à la tournée, ce qui rejoint le principe de minimisation du RGPD. Enfin, purgez automatiquement les bons déjà synchronisés : un bon envoyé n'a plus rien à faire sur le téléphone.

Résultat attendu : un appareil perdu ne contient que la tournée en cours, chiffrée. La demande d'effacement à distance part tout de suite, mais elle ne s'exécute qu'au retour en ligne de l'appareil : d'ici là, le code de verrouillage protège les données, et sur iPhone la gestion de flotte peut imposer un effacement automatique après plusieurs codes erronés.

Étape 9 : brancher le bon validé sur l'ERP, la GMAO et la facturation

C'est ici que se gagnent les jours de délai entre l'intervention et la facture. Un bon signé et synchronisé déclenche trois actions automatiques côté serveur : la génération du PDF définitif, la mise à jour de l'historique de l'équipement dans la GMAO, et la préparation de la facture dans l'ERP ou l'outil de facturation, via son API ou, à défaut, son import de fichiers.

Gardez l'identifiant d'opération de l'étape 4 jusqu'au bout de la chaîne, connecteur ERP compris : c'est en le vérifiant à chaque étage qu'un bon renvoyé deux fois ne produit qu'une seule facture. Pensez aussi au cadre réglementaire, déjà en place. Selon le calendrier de l'administration fiscale, toutes les entreprises doivent pouvoir recevoir des factures électroniques depuis le 1er septembre 2026, et l'obligation d'en émettre, déjà en vigueur pour les grandes entreprises et les ETI, arrive le 1er septembre 2027 pour les PME et les micro-entreprises. Pour un client professionnel établi en France, la facture passe alors par une plateforme agréée ; pour un particulier, il s'agit d'une transmission de données à l'administration (e-reporting). Dans les deux cas, autant que le bon d'intervention alimente directement cette chaîne. Nous avons détaillé ce branchement dans notre article sur la facturation électronique obligatoire.

Résultat attendu : dès que le bon signé est synchronisé, la facture est prête à être validée au bureau, sans aucune ressaisie.

Étape 10 : tester dans une vraie cave, puis piloter avec quelques techniciens

Un test au bureau, avec un bon Wi-Fi, ne prouve rien. Faites passer à l'application les scénarios qui cassent les outils mal conçus :

• mode avion pendant toute une intervention, de l'ouverture à la signature ;
• redémarrage du téléphone en pleine saisie ;
• batterie faible et mode économie d'énergie activé ;
• deux personnes qui modifient le même bon, l'une au bureau, l'autre hors ligne ;
• quarante photos prises d'un coup ;
• retour du réseau en voiture, avec une connexion qui va et vient.

Ensuite, lancez un pilote avec 3 à 5 techniciens volontaires pendant quelques semaines. Recueillez leurs retours chaque semaine et comparez les indicateurs de l'étape 1 : délai entre intervention et facture, bons ressaisis, litiges. Ne généralisez que si ces chiffres bougent dans le bon sens.

Résultat attendu : les six scénarios passent sans perte de données, et le pilote produit des indicateurs comparables à la ligne de base de l'étape 1, pour décider du déploiement sur des faits.

Vérification : à quoi ressemble le résultat

Revenons à la chaufferie du deuxième sous-sol. Le technicien ouvre son intervention, préchargée le matin. Il remplit le bon, prend ses photos, fait signer le client sur l'écran. L'application affiche « 1 bon en attente d'envoi ». Dix minutes plus tard, sur le parking, le réseau revient : le bon part, les photos suivent, le client reçoit son PDF signé par e-mail et la facture attend sa validation au bureau. Personne n'a ressaisi quoi que ce soit le soir.

Si l'un de ces maillons manque pendant le pilote, vous savez exactement à quelle étape revenir.