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.
Ce que nous avons fait
- Un socle Django portant le planning, les interventions, les clients et les bons.
- Une saisie pensée pour le terrain : parcours court, champs réduits au nécessaire, rien qui suppose une saisie confortable au clavier.
- 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é.
Ce projet illustre une conviction simple : 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.
Aperçus
Client couvert par un accord de confidentialité