Quand le système marche et que personne ne s’en sert
C’est la forme d’échec la plus coûteuse d’un projet, parce qu’elle arrive après que tout l’argent a été dépensé et qu’elle ne ressemble pas à un échec. Le système est juste, rapide, intégré ; la démonstration s’est bien passée ; personne ne s’en plaint. Trois mois plus tard, les gens ont repris leur ancienne méthode, et l’abonnement continue de courir. Les causes se réduisent presque toujours à trois, et aucune n’est technique. La personne concernée est évaluée sur l’ancienne façon de faire, et aucune note de service ne change un indicateur de performance. Elle ne fait pas confiance au résultat, parce qu’elle a vu le système se tromper une fois, avec assurance, sur un cas qu’elle connaissait bien. Ou personne ne lui a jamais dit ce qu’elle devait faire du temps ainsi libéré, et ce temps s’est reconstitué ailleurs sans que quiconque puisse dire où. Ces trois causes se corrigent, mais pas par une formation ni par une obligation d’usage, et elles se corrigent seulement si on les cherche dans les semaines qui suivent la mise en service, pendant que les habitudes se forment.
Première cause : la mesure de performance n’a pas bougé
Un conseiller évalué sur le nombre de dossiers traités à la main ne gagnera rien à laisser une machine les traiter. Un responsable dont la taille d’équipe justifie le niveau hiérarchique n’a aucune raison d’accélérer un processus qui la réduirait. Ces situations sont fréquentes, rationnelles, et rarement énoncées à voix haute.
Le repérage est simple et demande d’être fait avant la construction : à qui ce changement coûte-t-il quelque chose. La réponse est presque toujours quelqu’un, et le projet doit savoir qui.
La correction ne relève pas de l’équipe technique. Elle consiste à modifier l’indicateur avant la mise en service, ce qui est une décision de direction et prend du temps. Un projet qui découvre cette nécessité au moment du déploiement a déjà perdu un trimestre.
Deuxième cause : la confiance a été perdue tôt
La confiance dans un système se joue dans les premiers jours et se perd en une fois. Une personne voit une sortie fausse sur un cas qu’elle maîtrise, énoncée avec la même assurance que les sorties justes, et elle en tire la conclusion raisonnable qu’elle ne peut pas se fier au reste.
Ce qui répare cela n’est pas d’améliorer la justesse moyenne, qui était déjà bonne. C’est de rendre visible ce que le système sait et ce qu’il ignore : signaler les cas hors de son domaine plutôt que de répondre quand même, montrer d’où vient l’information, et reconnaître l’incertitude au lieu de la lisser.
Un système qui dit « je ne sais pas » sur cinq pour cent des cas est davantage utilisé qu’un système qui répond à tout avec la même voix, même si le second est plus juste en moyenne. Ce n’est pas irrationnel de la part des utilisateurs : c’est la seule façon dont ils peuvent décider quand vérifier.
Troisième cause : le temps libéré n’avait pas de destination
Gagner deux heures par semaine sur dix personnes ne produit rien de mesurable si personne n’a décidé à l’avance à quoi ce temps servirait. Il est absorbé par l’activité existante, et un an plus tard nul ne peut dire où il est passé.
Cette décision appartient au métier et se prend avant la construction : traiter un volume supérieur, réduire un délai client, ou rendre possible une activité qu’on n’avait pas le temps de mener. Elle est simple à formuler et systématiquement remise à plus tard, parce qu’elle n’est pas urgente tant que le système n’existe pas.
Son absence a un effet secondaire qui aggrave l’adoption. Quand personne n’a dit ce que le temps libéré devient, les personnes concernées formulent leur propre hypothèse, et cette hypothèse est rarement favorable au projet.
Ce qui fonctionne réellement
Être présent après la mise en service. Quelques jours passés à côté des utilisateurs, à regarder ce qu’ils font quand le résultat les surprend, en apprennent plus que tout ce qu’une enquête de satisfaction remonte. C’est du travail réel et cela doit figurer au planning.
Livrer devant quelqu’un très tôt. La première version sera fausse sur un point que personne n’avait anticipé. Le découvrir en semaine trois coûte deux jours, en semaine douze cela coûte le projet.
Choisir un premier utilisateur qui veut que cela marche. Pas le plus critique, pas le plus important : celui qui souhaite le changement. Son usage rend le système crédible auprès des autres d’une manière qu’aucune communication interne n’obtient.
Prévoir un chemin d’escalade nommé. À qui s’adresse une personne qui trouve une sortie aberrante, et sous quel délai obtient-elle une réponse. Sans cela, les utilisateurs cessent simplement de s’en servir, et personne n’apprend jamais pourquoi.
Un problème, trente minutes
Décrivez une tâche qui prend trop de temps aujourd’hui, exceptions comprises. Nous vous dirons si elle vaut la peine d’être construite, et nous le dirons franchement quand ce n’est pas le cas.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
