Aller au contenu principal

Applications terrain

Une application mobile pour vos équipes terrain.

Une application faite pour être utilisée debout, d’une main, avec des gants, dans un local sans réseau. Si elle ralentit le technicien, il reviendra au papier — et c’est le projet entier qui échoue.

Une journée

Ce que le technicien a réellement sous les yeux.

Pas un menu à douze entrées : ce qu’il doit faire maintenant, et le geste suivant.

Sa tournée du jour

Les interventions dans l’ordre, avec l’heure, la durée prévue et l’adresse. Un appui ouvre l’itinéraire dans l’application de navigation du téléphone.

Le site et ses accès

Code d’entrée, étage, interlocuteur, consignes de sécurité, historique du site. Ce qui évite l’appel au bureau.

Checklists et points de contrôle

Les questions propres au type d’intervention, avec les réponses attendues. Ce qui doit être vérifié l’est.

Photos et QR codes

Avant, après, et l’anomalie, rattachées à l’équipement. Un scan suffit pour l’identifier, sans le chercher dans une liste.

Pièces et temps passé

La pièce posée sort du stock du véhicule. Départ, arrivée et fin sont relevés au moment où ils se produisent, pas reconstitués le vendredi soir.

Signature du client

Sur l’écran, à la fin de l’intervention. Le compte rendu part signé, il n’attend pas le retour au bureau.

Sans réseau

Une cave, un local technique, un sous-sol.

C’est exactement là que se font les interventions, et exactement là qu’une application classique cesse de fonctionner. Le hors-connexion n’est pas une option de confort : c’est la condition pour que l’outil soit utilisé.

L’application garde son interface et ses données sur le téléphone. Le technicien ouvre sa tournée, coche ses points de contrôle, prend ses photos et fait signer le client sans réseau. Chaque saisie est écrite localement d’abord, puis mise dans une file d’attente qui se vide toute seule, dans l’ordre, au retour de la connexion.

Le plus difficile est ce qui se passe à ce moment-là. Deux appareils ont pu modifier la même donnée, une écriture a pu partir deux fois. Chaque saisie porte donc un identifiant qui la rend rejouable sans doublon, et un conflit qu’on ne peut pas résoudre automatiquement est montré à un humain plutôt que tranché au hasard.

Le technicien voit en permanence ce qui est parti et ce qui attend : un écran qui ment sur ce point est pire qu’un écran qui ne fonctionne pas. Ces mécanismes se conçoivent au début du projet ; les ajouter après coup revient à réécrire l’application.

L’autre bout

Ce que le bureau voit, et à quel moment.

Une application terrain n’a de valeur que si elle supprime la ressaisie de l’autre côté. Sinon elle déplace le travail, elle ne l’enlève pas.

Le dispatch affecte une intervention : elle apparaît sur le téléphone du technicien concerné, sans coup de fil. Il la déplace ou la refuse : le planning du bureau le sait. C’est la même donnée des deux côtés, pas deux outils qu’on rapproche le soir.

Dès que la synchronisation passe, le compte rendu remonte complet : checklist, photos, pièces, temps passé, signature. Le procès-verbal se génère à partir de cette saisie — il n’est pas retapé.

L’historique reste attaché au site et à l’équipement, pas au technicien : le suivant retrouve ce qui a été constaté la dernière fois, y compris quand ce n’était pas lui.

Comment nous la construisons

Installable, sans passer par un magasin.

Une PWA — application web progressive — s’installe depuis le navigateur : l’utilisateur ouvre un lien, ajoute l’icône à son écran d’accueil, et l’application se comporte comme une application native. Pas de validation par un magasin, pas d’attente de plusieurs jours pour corriger une anomalie, et une seule base de code pour Android, iOS, les tablettes et le poste du bureau.

Quand une fonction n’est réellement accessible qu’en natif — usage intensif du Bluetooth, traitement permanent en arrière-plan — nous le disons et nous orientons vers une application native. Le détail de cet arbitrage est dans le guide application web, mobile ou PWA.

Capacités de l’appareil

Ce que le navigateur sait faire aujourd’hui.

La liste des choses qu’une application web ne pouvait pas faire s’est considérablement réduite. Voici ce sur quoi nous nous appuyons réellement.

Stockage local

Base de données embarquée dans le navigateur. L’application garde ses données sur l’appareil et démarre sans aucune requête.

Fonctionnement hors réseau

L’application est servie depuis le cache de l’appareil. Elle s’ouvre et reste utilisable en mode avion.

Capture photo

Accès à l’appareil photo, compression sur l’appareil avant envoi — pour rester envoyable en 3G.

Géolocalisation

Position ponctuelle ou suivi pendant un déplacement, avec consentement explicite de l’utilisateur.

Notifications

Notifications poussées depuis le serveur, y compris application fermée, sur Android et sur iOS.

Mise à jour instantanée

Un déploiement met tous les appareils à jour au rechargement suivant. Pas de version bloquée sur un téléphone oublié.

Et si un téléphone se perd ?

Les données stockées sur l’appareil sont limitées au strict nécessaire — ce dont l’utilisateur a besoin aujourd’hui, pas l’historique complet — et purgées après synchronisation. L’accès est protégé, la session expire, et un appareil peut être révoqué à distance sans attendre sa restitution.

  • Données locales réduites au périmètre utile
  • Purge après synchronisation réussie
  • Session expirante et code d’accès
  • Révocation d’un appareil à distance

Vos techniciens saisissent encore sur papier ?
Voyons leur journée.

Dites-nous où vos équipes travaillent et ce qu’elles doivent pouvoir faire sans réseau. Nous vous dirons ce que l’application peut couvrir.