Sans réseau : ce que fait votre exploitation quand la connexion tombe

Un chauffeur entre dans un tunnel routier, un quai de chargement souterrain, le pont d’un ferry, ou tout simplement une vallée couverte par une seule antenne faible qui dessert trois villages, et pendant cinq minutes ou quarante, le téléphone n’a plus de signal. Ce n’est pas une panne du système, ni un cas rare aux marges — c’est une composante normale de l’exploitation de véhicules sur un terrain réel, et toute opération qui gère plus qu’une poignée de tournées la rencontrera de façon régulière. La question intéressante n’est pas de savoir si cela arrive. C’est ce que fait l’application montée sur le tableau de bord, et l’écran de suivi au bureau, face à cette situation — et si quelqu’un, en aval, peut faire la différence entre « il ne s’est rien passé ici » et « il s’est passé quelque chose ici et on n’en a pas encore été informé ».

Trois problèmes différents sous un même nom

« Hors ligne » est employé comme s’il s’agissait d’un seul état, mais une appli chauffeur perd en réalité trois choses distinctes quand le signal disparaît, et elles ne se comportent pas de la même façon à son retour.

La première, c’est l’état déjà présent en local — la liste des arrêts du jour, l’itinéraire, le manifeste de la charge actuellement à bord. Rien de tout cela n’a besoin d’une connexion active pour être utile ; il fallait seulement que ce soit téléchargé avant d’entrer dans la zone blanche, ce qui est une question de moment de la dernière synchronisation, pas de ce que fait l’appli une fois hors ligne. Un chauffeur qui consulte son prochain point de livraison dans un tunnel lit des données arrivées une heure plus tôt et n’a besoin de rien d’autre du réseau.

La deuxième, c’est une action qui doit être enregistrée au moment où elle se produit, que le réseau accepte ou non de coopérer à cet instant précis. Une livraison est refusée à la porte. Une palette arrive endommagée. Un arrêt se clôture parce que le destinataire a signé. Ce sont des faits horodatés, et l’horodatage, c’est maintenant, dans la zone blanche, pas au moment où les barres reviennent. Une appli incapable d’enregistrer le fait tant qu’elle ne peut pas aussi le transmettre demande au chauffeur soit d’attendre sur le bord de la route, soit de faire confiance à sa mémoire pour la version qu’il saisira plus tard — et « je le ferai quand j’aurai du réseau » est exactement la façon dont un enregistrement opérationnel se transforme en reconstitution.

La troisième, c’est un flux en direct qui n’a pas de réponse rétroactive possible — principalement, la position actuelle du véhicule. La position n’est pas un fait qu’on peut rattraper plus tard, en toute honnêteté : si un camion passe dix-huit minutes dans un tunnel, il n’existe pas de vraie réponse à « où était-il à la neuvième minute » au-delà de « quelque part dans le tunnel, entre les deux points qui l’encadrent ». Le bon comportement ici n’est pas de fabriquer une continuité. C’est d’afficher une dernière position connue avec son horodatage et de laisser quiconque observe en tirer la conclusion évidente, plutôt que d’interpoler silencieusement une ligne droite à travers la roche et de la présenter comme une donnée.

Le compte rendu et sa preuve ne s’entendent pas toujours sur qui passe en premier

La plupart des événements opérationnels ne sont pas une écriture unique — ce sont un enregistrement plus quelque chose qui l’étaye : une livraison plus une signature, un refus plus une photo, une inspection plus ses photos du défaut constaté. Dans une zone blanche, un seul des deux peut généralement être écrit en local et à peu de frais (l’enregistrement lui-même, qui est petit), tandis que l’autre — une photo, en particulier — est assez volumineux pour que « il suffit de relancer l’envoi » représente une vraie attente, pas un instant.

Les deux événements ne veulent pas du même ordre. Un enregistrement de livraison qui existe sans photo derrière lui est un risque mineur, rattrapable s’il est un jour contesté. Un chauffeur bloqué à la porte parce que l’appli refuse de clôturer l’arrêt tant qu’une image n’a pas fini de s’envoyer avec une barre de réseau est un problème plus grand et plus immédiat — l’arrêt est maintenant bloqué, le chauffeur attend ou contourne l’appli, et contourner l’appli, c’est exactement comme cela qu’un processus papier repousse discrètement à l’intérieur d’un processus numérique. L’enregistrement ne doit donc pas attendre que sa preuve ait fini de voyager ; mais la preuve ne doit pas non plus être traitée comme un chargement facultatif qu’on peut se permettre de perdre. Elle doit continuer d’essayer toute seule, en arrière-plan, jusqu’à arriver à destination ou être véritablement perdue — et si elle est perdue, cela doit être visible pour quelqu’un, pas passer inaperçu.

Cet ordre n’est pourtant pas universel, et c’est la partie qui mérite qu’on s’y arrête : pour certains événements, la priorité s’inverse. Un signalement de livraison échouée est sans doute plus utile au bureau sans aucune photo que pas déposé du tout au moment où cela arrive, parce qu’un arrêt en échec change l’allure du reste de la journée — une nouvelle tentative, un appel au client, une replanification de la tournée — et cela doit atteindre le suivi avant les photos, s’il faut choisir. L’ordre de priorité n’est pas un réglage technique que quelqu’un devrait fixer par accident, selon l’appel qui se trouve être le plus simple à déclencher en premier dans le code. C’est une décision sur quelle absence ferait le plus de mal, prise délibérément, une fois, par type d’enregistrement.

Une relance n’est pas automatiquement une répétition

Le cas délicat, c’est celui où personne ne sait réellement ce qui s’est passé : l’appli a envoyé la requête, la connexion a coupé en plein envoi, et il n’y a aucun moyen de savoir, depuis le seul terminal, si le serveur l’a reçue sans réussir à répondre, ou s’il ne l’a jamais vue du tout. Relancer à l’aveugle est acceptable pour quelque chose d’idempotent. Ça ne l’est pas pour une action qui crée un nouvel enregistrement à chaque appel — un second envoi « livré » après un délai d’attente ambigu peut se lire, pour tout ce qui est en aval, comme une seconde tentative de livraison plutôt qu’une confirmation de la première. Un système honnête doit porter cette distinction : « a échoué à coup sûr, peut être renvoyé sans risque » est un état différent de « on ne sait pas », et le second mérite plus de prudence — une confirmation humaine avant de renvoyer, plutôt qu’une relance silencieuse qui pourrait dupliquer un événement réel sur le papier.

Traiter les zones blanches connues comme connues, pas comme des incidents

Tout cela se gère surtout par anticipation, pas par ingéniosité. Si une tournée traverse chaque semaine le même tunnel ou la même zone blanche à trois villages, ce silence n’est pas une nouvelle — c’est une caractéristique connue de l’itinéraire, et traiter dix minutes de silence sur ce tronçon comme une alerte plutôt que comme une évidence attendue apprend au suivi à relancer des chauffeurs pour rien. L’habitude qui vaut la peine d’être prise, c’est de connaître ses propres zones blanches assez bien pour distinguer « silencieux à cause du tunnel » de « silencieux parce que quelque chose ne va vraiment pas », ce qui reste un jugement qu’un humain doit porter — mais qu’il ne peut bien porter que si le système devant lui dit la vérité sur ce qu’il sait et ne sait pas à l’instant présent.

Où se situe navichain

L’appli chauffeur saisit sur place le statut d’un arrêt, la signature, les photos et le motif d’un échec de livraison, et les arrêts du jour, la navigation et le manifeste de charge par arrêt sont déjà sur le téléphone avant le début de la journée — un chauffeur qui traite le prochain point de livraison lit un plan déjà présent, pas un plan qui attend une récupération en direct. La page de la plateforme couvre le reste de ce qui fonctionne à ses côtés : les contrôles quotidiens de tour du véhicule qui ouvrent une anomalie dès qu’un point échoue, et les particularités des marchandises dangereuses limitées exactement à l’arrêt où se trouve le chauffeur, afin que l’information qui compte à la porte ne dépende pas de l’état du signal au moment où la porte s’ouvre.