Contexte
Application terrain B2B, secteur Industrie. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
realisations/2:Project
Fieldwise
- Client
- Application terrain B2B
- Secteur
- Industrie
- Stack
- Mobile · .NET
Résultat clé0incident en 8 mois
Le projet
App mobile offline-first pour techniciens itinérants, back-end .NET & sync robuste.
Notre approche
App mobile offline-first pour techniciens itinérants, back-end .NET & sync robuste.
Résultats
0 sur « incident en 8 mois ». Derrière ce chiffre : une base de code couverte par des tests, une documentation à jour dans le dépôt, et une équipe interne capable de reprendre la main.
Stack technique
Réalisé avec Mobile, .NET, sur une chaîne d'intégration et de déploiement continue montée avec le projet. Les technologies ont été choisies pour ce contexte-là, pas parce que nous les préférons.
Le problème d'ingénierie
Une application de terrain se juge sur ce qu'elle fait quand le réseau n'est pas là, et pas sur ce qu'elle fait quand tout va bien. Le sous-sol, le hangar, la zone blanche : ce sont les conditions normales de travail, pas des cas limites. Toute conception qui traite la connexion comme acquise se découvre inutilisable à la première tournée.
La difficulté réelle n'est pas le stockage local, qui est un problème résolu. Elle est dans ce qui se passe au retour du réseau, quand deux personnes ont modifié la même chose hors ligne. Cette question n'a pas de réponse technique universelle : elle dépend de ce que représente la donnée pour le métier.
Les décisions qui ont compté
Écrire en local, synchroniser ensuite, ne jamais bloquer
L'interface enregistre immédiatement et localement, puis une file de synchronisation s'occupe du reste quand elle peut. L'utilisateur ne voit jamais de roue qui tourne en attendant un serveur, parce qu'aucune de ses actions ne dépend d'une réponse distante pour aboutir.
Cela impose de concevoir des identifiants créés côté client, sans quoi rien ne peut être enregistré avant d'avoir joint le serveur. C'est une décision qui paraît mineure au démarrage et qui conditionne tout le reste : elle se prend au premier jour ou elle se paie par une reprise complète du modèle.
Les conflits se tranchent avec le métier, pas avec le code
« La dernière écriture gagne » est un choix, pas une évidence. Il convient à un relevé de compteur, où la valeur la plus récente est la bonne. Il est dangereux sur un compte rendu d'intervention, où écraser la saisie d'un collègue fait disparaître une information que personne ne pourra reconstituer.
Nous posons la question par type de donnée, avec les personnes qui l'utilisent, et nous acceptons que la réponse diffère d'un champ à l'autre dans la même fiche. Certains conflits doivent remonter à un humain, avec les deux versions affichées, plutôt qu'être arbitrés silencieusement.
Rendre la synchronisation observable par l'utilisateur
Un technicien doit pouvoir savoir, sans comprendre la technique, ce qui est parti et ce qui attend encore. Une application qui synchronise en silence produit une inquiétude légitime, et cette inquiétude se traduit par des doubles saisies « au cas où », qui créent exactement les doublons qu'on cherchait à éviter.
Nous affichons donc l'état par élément et pas globalement, avec une action manuelle pour forcer l'envoi. Cette action ne sert presque jamais techniquement ; elle sert à rendre le contrôle à la personne, et c'est ce qui fait qu'elle cesse de contourner l'application.
Ce que ce type de projet apprend
- Les identifiants créés côté client sont une décision du premier jour.
- La règle de résolution des conflits est une décision métier, jamais technique.
- Un état de synchronisation visible évite les doubles saisies de précaution.
- Ce qui est conçu pour la coupure fonctionne aussi en ligne, l'inverse est faux.
Ce que le chiffre annoncé mesure
Le zéro incident porte sur les incidents bloquants de production sur la période annoncée, c'est-à-dire ceux qui empêchent un utilisateur de travailler. Il n'affirme pas qu'aucune anomalie n'a été corrigée pendant ces huit mois : il y en a eu, et elles ont été traitées sans interruption de service. Un compteur d'incidents à zéro sur une durée donnée dit surtout que le dispositif de détection existait et que les corrections sont passées sans coupure ; il ne prédit rien sur les mois suivants.
Et ce qu'il ne mesure pas. Un indicateur qu'on n'explique pas ne vaut rien.
Continuer:Project[3]
Autres réalisations
Un projet en tête ? Donnons-lui vie.
Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.