Remplacer le papier par une preuve : quatre ans d'une plateforme d'opérations terrain

Le vrai problème, c'était la preuve

Rien dans ce processus ne confirmait qu'un travail avait réellement été fait. Un formulaire rempli disait qu'une équipe était passée sur un site. Il ne disait pas que quelqu'un y était allé.

Ça compte plus qu'on pense. Quand un client appelait pour demander pourquoi son site avait été sauté, la réponse honnête était que personne ne pouvait le dire. La paperasse disait que c'était fait. Il n'y avait aucun moyen de vérifier, ni de montrer au client autre chose que la même paperasse.

Chaque visite contestée coûtait un appel, un après-midi de superviseur, et un peu de confiance.

Ce que nous avons bâti

Locspect est une plateforme d'opérations terrain : une application mobile pour les équipes et les superviseurs, et une application web pour le bureau.

Le mécanisme qui règle le problème de preuve est volontairement banal. Un employé démarre un travail dans l'application et le termine en quittant les lieux. L'application enregistre les coordonnées aux deux moments. Aucun formulaire à remplir, aucune photo à prendre, rien de plus à retenir.

Ce seul changement a transformé « la paperasse dit que c'est fait » en « le travail a commencé ici à 8 h 12 et s'est terminé ici à 9 h 47 ». Les litiges ont cessé d'être des discussions pour devenir des vérifications.

Du côté du bureau, les fichiers Excel ont disparu. Sites, bons de travail et horaires vivent au même endroit, et l'information arrive au fur et à mesure du travail plutôt que des jours plus tard, dans une pile de papier.

Simple, volontairement

Les équipes qui utilisent ça ne sont pas des employés de bureau. Elles nettoient des sites, souvent pressées, souvent sur leur propre téléphone, parfois dans une deuxième langue. Un système qui demande une formation est un système qu'on contourne.

Alors l'application fait très peu. Démarrer le travail, terminer le travail. La plupart des gens l'utilisent correctement en quelques minutes, et personne ne suit de formation.

Cette contrainte a façonné tout le reste. Chaque fonctionnalité proposée depuis doit répondre à la même question : est-ce que ça ajoute une étape pour quelqu'un debout dans une cage d'escalier à 6 h du matin? La plupart des bonnes idées ont fini du côté bureau du système, là où quelqu'un a un bureau et un écran complet.

Moins de trois mois entre la première ligne de code et des équipes qui l'utilisent tous les jours. Pas un projet pilote. Du vrai travail, sur de vrais sites.

À quoi ça ressemble quatre ans plus tard

Environ 1 000 emplacements. Autour de 500 personnes par jour. Toujours en production, toujours en développement.

Ce que c'est devenu, dans l'ordre où le travail l'a exigé :

• Des alertes d'échéance. La base de données vérifie quelles inspections approchent de leur échéance et lève des alertes avant que quelqu'un ait à s'en apercevoir.
• Des notifications poussées pour les travaux qui durent anormalement longtemps, envoyées chaque heure, pour qu'un superviseur soit au courant pendant que l'équipe est encore sur place.
• Des photos, ajoutées plus tard. Les superviseurs documentent l'état des lieux quand ça mérite une trace. Les téléphones produisent des fichiers HEIC que la plupart des systèmes ne peuvent pas lire, alors un service distinct convertit automatiquement chaque téléversement. Personne sur le terrain n'a à penser aux formats de fichiers.
• Une vue opérateur pour gérer plusieurs entreprises au même endroit, à mesure que la plateforme a dépassé un seul client.

Ce qui garde le système en vie

Quatre ans d'utilisation quotidienne par 500 personnes, c'est un problème différent que de lancer quelque chose. Ce que ça exige concrètement :

• Des alertes sur ce qui fait mal, pas sur tout. Erreurs, requêtes lentes, charge de la base de données, tâches planifiées qui échouent.
• Une piste de vérification. Chaque modification à une entreprise, un site ou un accès est enregistrée avec les anciennes valeurs et l'auteur du changement. Ça a été ajouté après qu'un site a été supprimé directement dans la base de données sans que rien n'indique qui l'avait fait. Maintenant, quelque chose l'indique.
• L'infrastructure en code, pour que l'environnement soit reproductible plutôt qu'assemblé à la main et gardé en mémoire.
• Un document de continuité. Des instructions claires sur quoi faire si je ne suis pas disponible : où tout se trouve, comment y accéder, ce qui brise en premier. Il est testé, pas seulement écrit.

Les données restent au Canada. Tout le système roule dans la région de Montréal de Google Cloud.

Ce qu'il faut en retenir

• Le problème évident est rarement le plus coûteux. Recopier du papier dans Excel était lent. Ne pas pouvoir prouver que le travail avait été fait coûtait davantage, et personne ne l'avait chiffré.
• La solution doit être passive. Demander aux équipes plus de paperasse pour prouver qu'elles ont fait leur travail, ça ne fonctionne pas. Enregistrer des coordonnées sur un bouton qu'elles appuient déjà, oui.
• Si ça demande une formation, ça demande d'être simplifié. Un logiciel terrain est en concurrence avec le papier, et le papier ne demande aucune formation. Deux boutons valent mieux qu'un formulaire mieux conçu.
• Trois mois jusqu'à l'usage quotidien, c'est possible, quand la première version fait une chose correctement au lieu de tout faire passablement. Les photos, les alertes et les notifications sont toutes venues après, une fois que les gens comptaient dessus.
• Demandez à quiconque vous engagez ce qui se passe après. Quatre ans plus tard, les parties intéressantes de ce système sont la piste de vérification, les alertes et le plan de continuité. Aucune n'était dans la portée initiale. Toutes expliquent pourquoi ça fonctionne encore.