Le contexte
Une PME dont l’activité repose sur des interventions chez ses clients : des techniciens sur la route, des plannings qui bougent, des bons d’intervention à remplir sur place et à rapporter au bureau.
Avant le projet, l’ensemble tenait sur des tableurs, des impressions et des appels téléphoniques. Ça fonctionne — jusqu’à un certain volume.
L’enjeu
Le piège, sur ce type de logiciel, est de concevoir pour la personne qui achète plutôt que pour celle qui utilise.
Le dirigeant veut de la visibilité : où sont les équipes, ce qui a été fait, ce qui reste à facturer. Le technicien, lui, est debout, dans un local technique mal éclairé, avec une seule main libre et parfois pas de réseau. Si l’outil lui prend plus de temps que le papier qu’il remplaçait, il ne sera pas utilisé — et un logiciel métier que le terrain contourne ne produit aucune donnée fiable.
Et il fallait composer avec l’existant. L’entreprise fait déjà tourner son activité sur un logiciel de gestion : ses clients, ses contrats, ses techniciens et ses bons y vivent depuis des années. Le remplacer n’était ni demandé, ni raisonnable, ni finançable. Le nouvel outil devait donc s’installer à côté, travailler sur les mêmes données, et ne jamais mettre en jeu ce qui tourne déjà.
Ce que nous avons fait
- Une API branchée sur la base du logiciel de gestion existant. Les clients, les contrats, les techniciens et les bons restent la propriété du logiciel historique : nous les lisons sans jamais en modifier la structure. Ce qui appartient en propre au nouvel outil — congés, notifications, documents internes — vit dans ses propres tables, à côté des autres.
- Une règle stricte sur la base partagée : aucune évolution automatique du schéma. Toute modification passe par un script écrit, relu et exécuté à la main. Sur une base qu’on ne possède pas, l’automatisme n’est pas un confort, c’est un risque.
- Une application mobile pour les techniciens, avec une saisie pensée pour le terrain : parcours court, champs réduits au nécessaire, rien qui suppose un clavier confortable.
- Une saisie qui survit à l’absence de réseau. Le planning, les bons et les relevés sont conservés sur le téléphone : le technicien remplit son bon dans un sous-sol, le fait signer sur place, et la synchronisation rattrape quand le réseau revient.
- Un outil de bureau, organisé autour d’un planning en calendrier, pour ceux qui affectent les interventions et suivent ce qui reste à facturer.
- Un développement itératif, livré par petits incréments plutôt qu’en un basculement unique. Un logiciel métier ne se spécifie pas correctement du premier coup : ce sont les premiers usages réels qui révèlent ce qui manque et ce qui ne servira jamais.
Le résultat
Le logiciel est développé en continu depuis 2024 et reste en évolution active — ce qui, sur un outil métier, est le meilleur signe possible : on ne continue d’investir que sur ce qui est utilisé. Le logiciel de gestion historique, lui, n’a pas bougé.
Ce projet illustre deux convictions. La première : sur un logiciel de terrain, le critère de réussite n’est pas la richesse fonctionnelle, c’est le taux d’adoption. Une fonctionnalité que personne ne remplit ne vaut rien, quelle que soit la qualité de son code.
La seconde : on n’a presque jamais besoin de remplacer le logiciel historique d’une entreprise. Il suffit le plus souvent de lui ajouter ce qui lui manque, là où ses utilisateurs en ont besoin — ce qui coûte une fraction du prix d’un remplacement et ne met pas l’activité en jeu.
Client couvert par un accord de confidentialité
