La fonction de rapports de mon système marchait parfaitement. Elle ne servait à rien. Voici pourquoi, et ce que j'en ai retenu pour tout le reste.
Un retour d’expérience honnête commence par le défaut, pas par le résultat.
Le mien : mon système de pilotage savait générer des rapports. Techniquement, la fonction était juste. Elle allait chercher les données, elle produisait un document, elle ne se trompait pas. Et elle produisait des informations sans pertinence pour la hiérarchie, dans une mise en page qui desservait le contenu.
Le diagnostic
J’ai d’abord cru à un problème de mise en forme. Ça n’en était pas un.
Le problème n’était pas de produire l’information : c’était de choisir ce qu’il fallait retirer, et pour qui.
Un export prend tout ce qu’il y a et le déverse. Un rapport choisit. C’est même sa seule définition utile : un rapport n’est pas un déversement de données, c’est un message adressé à quelqu’un de précis. Tant que je ne savais pas qui lisait, je ne pouvais pas savoir quoi retirer. Et sans retirer, je ne produisais qu’un export mieux présenté.
Une erreur d’ingénieur, corrigée avec un réflexe de communicant. J’ai passé des années à me demander ce qu’il reste d’un message une fois qu’il a traversé une organisation. J’avais construit un outil qui ne se posait pas la question.
La correction
Elle a consisté à repartir du lecteur, pas de la donnée. Que doit décider celui qui reçoit ce document ? De quoi a-t-il besoin pour décider ? Tout le reste sort.
Cette question a fini par redessiner autre chose que les rapports. Le système repose sur trois rôles distincts, la saisie, le pilotage et la direction, et chacun ne voit que ce qui le concerne. La vue de direction ne montre que ce qui sert à décider.
C’est la même règle appliquée deux fois. Ce qu’il faut retirer compte autant que ce qu’il faut montrer, pour un rapport comme pour un accès.
Ce que je retiens, au-delà de ce projet
Trois choses.
Le défaut le plus instructif n’est presque jamais technique. Celui-là ne se voyait dans aucun journal d’erreurs. Le code faisait exactement ce qu’on lui demandait ; c’est la demande qui était mal posée.
Un outil ne se termine pas. Les défauts n’apparaissent qu’à l’usage, jamais à la conception. La maintenance n’est pas la queue du projet : c’en est une phase à part entière, qui commence le jour de la mise en service et ne s’arrête pas.
Et un outil de pilotage n’est pas un outil collectif. Le réflexe, quand on construit un système de suivi, est de vouloir que tout le monde s’en serve. C’est une erreur. Il n’a pas besoin d’être ouvert à tous : il a besoin que chaque rôle y trouve exactement ce qui le concerne.