Le scénario est classique. Le logiciel est livré, la formation a eu lieu, et trois mois plus tard le tableur d’origine circule toujours. Ce n’est presque jamais un problème de motivation : c’est un problème de conception.
Le logiciel a été conçu avec les mauvaises personnes
Un outil validé uniquement par la direction reflète la vision de la direction. Or les gestes quotidiens — les cas particuliers, les urgences, les raccourcis — sont connus de ceux qui font le travail. S’ils découvrent l’outil à la livraison, ils y trouveront ce qui manque, pas ce qui aide.
Impliquez deux utilisateurs de terrain dès la maquette. C'est le meilleur investissement du projet.
Le nouvel outil demande plus d’efforts que l’ancien
Si saisir une intervention prend huit clics au lieu de trois lignes dans un tableur, l’équipe reviendra au tableur. La règle est simple : sur le geste le plus fréquent, le nouvel outil doit être plus rapide que l’ancien, dès le premier jour.
Personne n’a expliqué le « pourquoi »
Une saisie supplémentaire acceptée par une équipe est une saisie dont elle comprend l’usage. Montrez ce que la donnée permet : un planning fiable, une facturation sans litige, moins d’appels le vendredi soir.
Ce que nous faisons systématiquement
- Des ateliers avec les utilisateurs réels avant la première ligne de code.
- Un prototype cliquable testé sur les vrais cas, y compris les cas tordus.
- Une mise en service progressive, service par service, plutôt qu’un basculement général.
- Un référent interne formé, capable de répondre sans nous appeler.
