L’hypothèse de la connectivité est facile à faire dans un bureau, par des gens qui n’ont jamais perdu le réseau avec une planchette dans une main.
Un système opérationnel est jugé sur son pire moment, pas sur son meilleur. Le pire moment d’un logiciel de terrain n’est pas un flux compliqué ou un formulaire maladroit. C’est un technicien debout à une tête de puits, loin du premier signal, avec un appareil qui a décidé qu’il ne pouvait pas aider.
La suite est prévisible : le technicien écrit sur papier, avec l’intention de saisir plus tard. Plus tard, c’est la fin d’un long poste. Une partie est saisie. Une partie est saisie de travers. Une partie n’est pas saisie du tout. Bientôt l’organisation a un système coûteux et un processus papier parallèle, et personne ne peut dire avec confiance lequel des deux fait foi.
Le hors ligne d’abord n’est pas une stratégie de synchronisation
L’expression est facile à entendre comme un détail technique — une histoire de cache, de file d’attente ou de politique de réessai. Ce n’en est pas un. C’est une décision sur l’endroit où vit la copie qui fait foi de la journée.
Dans un système connecté d’abord, le serveur détient la vérité et l’appareil en détient une vue. Dans un système hors ligne d’abord, l’appareil détient la journée et le serveur la reçoit. Tout le reste découle de ce choix : à quoi ressemblent les identifiants, comment les conflits se résolvent, ce que signifie un rapport partiellement rempli, si un permis peut être consommé sans confirmation, et ce que le technicien a le droit de faire quand le dernier état connu date de plusieurs heures.
Ce ne sont pas des questions que l’on peut traiter après coup. Un système construit connecté d’abord, auquel on ajoute ensuite un cache, produit quelque chose de pire que l’un ou l’autre : une application qui semble fonctionner hors ligne et perd silencieusement une partie du travail. Ce mode de défaillance est plus difficile à détecter qu’un refus net, et considérablement plus dommageable, parce qu’il érode la confiance dans les données plutôt que dans le logiciel.
Ce que nous avons appris en le construisant
OPS, le produit d’opérations de terrain que nous développons en interne, est hors ligne d’abord — et pas parce qu’il a été spécifié ainsi au départ. Il l’a été après que la première équipe à utiliser un prototype a perdu le réseau, et que l’hypothèse de conception qui semblait raisonnable dans un bureau a cessé de l’être.
La version actuellement en développement porte la journée sur l’appareil. Un technicien reçoit sa tournée, traite les interventions, joint des photos prises sur site, et signe le rapport journalier là où le travail a eu lieu. Rien n’attend la couverture. La file se vide quand le réseau revient, et les écrans rendent l’état de cette file visible plutôt que de le cacher, parce qu’une personne qui ne peut pas voir si son travail a été envoyé l’enverra une seconde fois.
OPS est en développement. Les écrans montrés sur ce site portent des données de démonstration. Ce qui est transférable n’est pas le produit — c’est la séquence : l’hypothèse de connectivité doit être testée contre le pire endroit où le travail se fait, et elle doit l’être avant que l’architecture ne soit fixée, pas après.
Une question à poser avant d’acheter
Quand vous évaluez un système opérationnel, demandez au fournisseur de décrire précisément ce qu’un utilisateur peut et ne peut pas faire sans réseau, et ce qu’il advient du travail accompli dans cet état. Demandez ce que l’utilisateur voit. Demandez comment un conflit se résout quand deux personnes ont modifié le même enregistrement depuis deux zones blanches différentes.
Les réponses séparent les systèmes conçus pour le terrain des systèmes conçus pour un bureau puis emportés dehors. Il n’y a pas de honte au second — beaucoup de bons logiciels sont faits pour un bureau. L’erreur, c’est d’acheter l’un et de le déployer comme l’autre.
Recalibre · OPS est en développement. Chaque écran montré porte des données de démonstration.