Comment une entreprise de service sur site de 24 personnes a mis en ligne une application pour ses employés en 10 semaines

L'entreprise qui nous a appelés ne voulait pas d'application. Elle voulait arrêter de perdre une heure chaque soir dans la même conversation : un technicien appelle le bureau et énumère les chantiers réalisés, les matériaux utilisés et le client qui n'était pas chez lui. Quelqu'un au bureau note tout, le saisit dans trois systèmes, puis découvre une semaine plus tard que deux fiches de chantier manquent et qu'une facture est erronée. C'était là le vrai problème. L'application n'a été que la forme qu'a fini par prendre la solution.

Ceci est une étude de cas portant sur un projet réel, anonymisé. Il s'agit d'une entreprise d'installation et de maintenance de 24 personnes — pensez chauffage, ventilation et les interventions associées — opérant sur toute une région, avec huit camionnettes sur la route presque tous les jours. Nous avons modifié quelques détails identifiants et ne prétendons pas que les chiffres relèvent d'une science auditée. Mais l'histoire est vraie, y compris les passages où nous nous sommes trompés et avons dû faire marche arrière. Ce sont souvent les plus utiles, alors nous les avons laissés.

Si vous dirigez une entreprise d'intervention sur site et qu'on vous a chiffré une application pour employés à six chiffres sur neuf mois, voici le contre-argument. Dix semaines, un périmètre resserré et un outil que les techniciens ouvraient d'eux-mêmes, sans qu'on ait à les relancer. Voici comment cela s'est passé.

Le problème : une entreprise qui tourne au papier et au téléphone

Quand nous nous sommes assis avec le dirigeant et la responsable de bureau, la plainte de surface était « il faut qu'on passe au numérique ». Cette phrase ne veut rien dire en soi, alors nous l'avons ignorée et avons observé le travail à la place. Nous avons passé une journée au bureau et une matinée en camionnette comme passagers. À l'heure du déjeuner, le vrai problème était évident, et il n'avait rien à voir avec une technologie vieillissante.

Chaque technicien transportait une planchette avec des fiches de chantier autocopiantes. Sur place, il griffonnait le travail réalisé, cochait quelques cases, notait les matériaux et faisait signer le client. La copie du dessus revenait au bureau finalement — parfois le soir même, parfois le vendredi en tas froissé. Le bureau ressaisissait alors chaque fiche dans l'outil de planification, à nouveau dans le logiciel de facturation, et une troisième fois dans un tableur que le dirigeant utilisait pour suivre les chantiers facturables. Trois fois la même chose saisie. Deux de ces fois avec de nouvelles erreurs à la clé.

Le coût, ce n'étaient pas seulement les heures de bureau. C'était le décalage. Un chantier terminé le lundi pouvait n'être facturé que la semaine suivante, parce que le papier n'avait pas encore refait surface. Des clients appelaient pour des travaux dont le bureau ignorait qu'ils étaient faits. Et quand une fiche disparaissait complètement — ce qui arrivait plus souvent que personne ne l'admettait —, ce chantier n'était tout simplement jamais facturé. Personne ne pouvait nous dire combien d'argent partait ainsi en fumée, et c'était précisément là le fond du problème.

Ce que nous avons délibérément choisi de ne pas construire

La façon la plus rapide de faire exploser un délai de dix semaines est de dire oui à tout. Avant d'écrire la moindre ligne de code, nous avons donc dressé une liste de ce que l'application ne ferait pas — et obtenu du dirigeant qu'il y adhère à voix haute. C'est la partie la moins flatteuse de tout projet et la principale raison, sans conteste, pour laquelle il a été livré à temps.

La liste de souhaits, réunie au fil de deux conversations, comptait une trentaine de fonctionnalités. Suivi GPS des camionnettes. Un portail de réservation client. Inventaire de tout l'entrepôt. Optimisation automatique des tournées. Un CRM complet. Des constats de dégâts photo avec annotations. Pointage avec export vers la paie. Chacune était une idée raisonnable. Chacune était aussi un moyen de ne jamais terminer.

Nous avons réduit le périmètre à une seule phrase, comme nous le conseillerions à n'importe quelle petite entreprise : un technicien doit pouvoir voir les chantiers du jour, consigner ce qu'il a fait, et que personne n'ait jamais à le ressaisir. Tout ce qui ne servait pas cette phrase est parti sur une liste « plus tard, peut-être ». Cette liste existe toujours. La plupart de son contenu n'a jamais manqué.

• Écarté : le suivi GPS des camionnettes — un parfum de surveillance dont personne dans l'équipe ne voulait, pour un problème qu'ils n'avaient pas.
• Écarté : le portail de réservation client — un projet à part avec un public à part ; l'y intégrer aurait doublé le délai.
• Écarté : l'inventaire complet de l'entrepôt — utile un jour, mais hors du chemin critique vers une facturation plus rapide.
• Écarté : l'optimisation des tournées — forte complexité, faible retour réel pour la géographie de cette entreprise.
• Retenu : liste des chantiers du jour, fiches numériques, saisie des matériaux, signature client, photos, synchronisation instantanée avec le bureau.

Ce que fait réellement l'application

Ramenée à son cœur, l'application est presque ennuyeusement simple — et c'est un compliment. Un technicien l'ouvre le matin et voit ses chantiers du jour, dans l'ordre, avec l'adresse, le client, l'historique du site et ce qu'on attend de lui. Il appuie sur un chantier, et tout ce qui vivait sur la planchette vit désormais à l'écran.

Sur place, il consigne le travail réalisé à partir d'une courte liste de contrôle, ajoute des matériaux depuis une liste avec recherche (de sorte que « coude cuivre 22 mm » se fait en deux appuis, sans deviner l'orthographe), prend une photo ou deux s'il y a quelque chose à documenter, et tend le téléphone au client pour une signature au doigt. Il appuie sur « terminé ». C'est tout. Dès qu'il a du réseau, tout se synchronise avec le bureau — pas d'appel, pas de papier, pas de ressaisie.

Le détail qui a le plus compté : ça marche sans réseau

Les applications de terrain vivent ou meurent sur une chose que la démo ne montre jamais : ce qui se passe dans une chaufferie de sous-sol sans réception. Si l'application se fige ou perd les données à la seconde où les barres disparaissent, les techniciens l'abandonneront en une semaine et vous aurez construit un presse-papiers hors de prix. Nous l'avons donc bâtie hors ligne d'abord dès le premier jour. Tout fonctionne entièrement sans connexion ; l'appareil conserve les données et les synchronise dès qu'il le peut. Le technicien n'y pense jamais, et c'est exactement le but.

Côté bureau : un seul écran, aucune ressaisie

Le bureau n'a pas eu droit à un tableau de bord tentaculaire. Il a eu un écran montrant les chantiers à mesure qu'ils se terminent, chacun avec sa fiche, ses matériaux, ses photos et sa signature joints. De là, un chantier terminé devient une facture aux données déjà remplies — le bureau la vérifie et l'envoie, au lieu de la ressaisir de zéro. Nous l'avons reliée au logiciel de facturation déjà utilisé plutôt que de le remplacer, car remplacer un logiciel qui fonctionne en plein projet, c'est ainsi qu'un délai de dix semaines devient un délai de dix mois.

Les dix semaines, honnêtement

Dix semaines n'est pas un chiffre magique ; c'est ce qu'a demandé ce périmètre avec un binôme designer-développeur et un client véritablement impliqué. Voici à peu près comment le temps s'est réparti — y compris la semaine que nous avons perdue, car faire croire que les projets se déroulent parfaitement n'aide personne.

1. 1
   Semaines 1–2 : observer, pas demander

   Nous avons accompagné les tournées, occupé le bureau et cartographié le flux de travail réel sur un mur. Nous avons rédigé le périmètre en une phrase et la liste « on ne construit pas », et obtenu la validation des deux avant tout design.
2. 2
   Semaines 3–4 : une forme cliquable

   Nous avons construit un prototype cliquable — pas de vrai code, juste des écrans — et l'avons mis entre les mains de deux techniciens. Leurs retours ont tué trois de nos hypothèses très tôt, l'endroit le moins coûteux pour se tromper.
3. 3
   Semaines 5–7 : construire le cœur

   La liste des chantiers, les fiches numériques, les matériaux, la signature, les photos et le moteur de synchronisation hors ligne. La synchronisation a été la partie difficile et a englouti l'essentiel de la semaine 7.
4. 4
   Semaine 8 : la semaine perdue

   L'intégration avec la facturation nous a résisté. L'interface du logiciel existant était plus capricieuse que ne le prétendait sa documentation, et nous avons brûlé une semaine à faire correspondre proprement les champs. Cela en valait la peine — la ressaisie était tout le problème que nous résolvions.
5. 5
   Semaines 9–10 : pilote et finitions

   Deux camionnettes ont utilisé l'application pour de vrai pendant que les six autres restaient au papier. Nous avons corrigé ce que le pilote a fait remonter, puis l'avons déployée à tout le monde avec une seule courte session de formation.

Amener le personnel de terrain à l'utiliser réellement

Vous pouvez construire la meilleure application de terrain du monde et la voir mourir parce qu'un technicien de 55 ans, avec vingt ans de mémoire musculaire de la planchette, décide que ce n'est pas pour lui. L'adoption n'est pas un problème technique et ne se règle pas par des fonctionnalités. Nous l'avons traitée comme le vrai projet qu'elle est.

Trois choses ont fait l'essentiel du travail. Premièrement, nous avons rendu le déroulé sur site plus rapide que le papier, pas seulement numérique — moins d'appuis que de gribouillis, des matériaux qu'on sélectionne au lieu de les épeler, une signature plutôt que la course à une signature lisible. Si l'application avait été ne serait-ce qu'un peu plus lente que la planchette, elle aurait échoué, à juste titre. Deuxièmement, nous avons choisi les deux techniciens pilotes avec soin : l'un discrètement respecté des autres, l'autre ouvertement sceptique. Convaincre le sceptique valait plus que tout marketing.

Troisièmement, personne n'a été mis en situation de se sentir bête. La formation a duré vingt minutes, l'application était volontairement évidente, et la responsable de bureau est devenue le point de contact pendant les deux premières semaines, pour qu'aucun technicien ne se retrouve livré à lui-même. En trois semaines, les fiches de chantier papier avaient disparu — non pas interdites, simplement abandonnées, parce que l'application était sincèrement le chemin le plus facile.

Ce qui a changé — les résultats

Nous serons prudents ici, car les études de cas adorent citer des chiffres précis qui s'effondrent au moindre interrogatoire. Ces chiffres sont ceux de l'entreprise elle-même, relevés quelques mois après le déploiement, et ils sont indicatifs plutôt que de laboratoire. Mais la tendance est sans ambiguïté, et elle correspond à ce que le dirigeant ressent au quotidien.

Le chiffre qui comptait pour le dirigeant ne figurait pourtant pas dans ce tableau. C'était la trésorerie. Quand les factures partent le jour même au lieu d'une semaine plus tard, l'argent rentre environ une semaine plus tôt sur toute l'entreprise — pour chaque chantier, sans exception. Pour une entreprise de 24 personnes aux marges serrées, ce glissement dans le temps a compté davantage que n'importe quel gain d'efficacité isolé. Les heures de bureau récupérées, c'était bien. Être payé une semaine plus tôt, à chaque fois, c'était le vrai trophée.

Ce que nous vous dirions si vous envisagez la même chose

La plupart des enseignements ici ne sont pas propres au service de terrain. C'est ce que nous dirions à n'importe quelle petite entreprise tentée de commander un logiciel sur mesure, et ils valent plus que l'application elle-même.

Découpez le périmètre sans pitié, et rédigez votre liste « on ne construit pas » avant votre liste de construction. Observez le travail réel avant de dessiner quoi que ce soit — les dirigeants décrivent le processus qu'ils aimeraient avoir, pas celui qu'ils mènent vraiment. Pilotez petit et laissez les sceptiques convaincre les autres. Et reliez-vous aux outils que vous utilisez déjà au lieu de les remplacer, du moins au début. Rien de tout cela n'est ingénieux. Tout cela est ce qui a rendu possibles dix semaines au lieu de dix mois.

Un dernier, le discret : l'application n'a jamais été le but. Le but était d'être payé plus vite et d'arrêter de saisir trois fois les mêmes données. Nous aurions pu en résoudre une partie avec des outils du commerce, et pour certaines entreprises c'est le bon choix. Pour celle-ci, le mélange brouillon de saisie sur site, de réalité hors ligne et d'un système de facturation existant a fait qu'un développement sur mesure ciblé s'est remboursé vite. La réponse honnête à « sur mesure ou prêt à l'emploi ? » est : ça dépend, et quiconque répond instantanément cherche à vous vendre quelque chose.

Questions fréquentes