Avant d’automatiser le rapport, demandez ce qui manquerait sans lui

Avant d’automatiser un rapport, je veux savoir ce qui ne fonctionnerait plus si personne ne le rédigeait.

Ce n’est pas une objection aux rapports. Certains conservent des preuves, expliquent des décisions ou fournissent à une personne des renseignements qu’elle ne trouve nulle part ailleurs. Les supprimer ferait perdre quelque chose d’important.

Mais lorsqu’une équipe dit « ce document nous prend trop de temps », une autre possibilité mérite d’être examinée : le document est peut-être une façon coûteuse de transmettre des renseignements entre des outils ou des personnes qui en possèdent déjà une bonne partie.

Automatiser sa rédaction peut rendre cette façon de travailler moins coûteuse. Cela peut aussi la rendre plus difficile à remettre en question, puisque le nouvel outil semble avoir réglé le problème.

Le document et sa raison d’être sont deux choix distincts

Prenons trois façons d’aider une adjointe à décider si un dossier est prêt pour la facturation.

La première produit un rapport bien rédigé à partir des notes du technicien. La deuxième rassemble les travaux effectués, les pièces utilisées et l’approbation encore attendue dans un même écran. La troisième change la collecte pour que les renseignements nécessaires arrivent ensemble, avec une exception clairement signalée lorsqu’il manque quelque chose.

Ce ne sont pas trois variantes d’une même fonctionnalité. Elles reposent sur des hypothèses différentes quant à l’origine de la difficulté.

Prenons une installation de ventilation fictive. Les travaux sont terminés, mais le bureau attend l’accord du client et une photo pour compléter le dossier de facturation. Un outil de rédaction peut améliorer le rapport. Il ne peut fournir ni la photo manquante ni l’accord du client.

La question de conception devient alors beaucoup plus intéressante : de quoi la prochaine personne a-t-elle besoin pour prendre sa décision?

Le rapport peut encore être la meilleure réponse. Mais il devrait être retenu parce qu’il remplit bien ce rôle, pas simplement parce qu’il fait partie du processus actuel.

Un travail devenu moins coûteux n’est pas forcément devenu utile

Une automatisation se prête facilement à une comparaison : combien de temps fallait-il pour produire le document avant, et combien en faut-il maintenant?

Cette mesure est utile. Elle ne dit toutefois pas si le document est le bon résultat à produire.

Supposons qu’une équipe puisse désormais générer dix résumés dans le temps auparavant nécessaire pour en rédiger un. Si une autre personne doit ensuite lire les dix pour retrouver le même renseignement manquant, la production supplémentaire n’a pas réglé le problème de fond. C’est une possibilité illustrative, pas un résultat mesuré chez un client.

L’amélioration pourrait plutôt consister à rendre ce renseignement visible, à transmettre l’exception à la personne qui peut la résoudre ou à retirer une approbation devenue inutile. Ces options ne transforment pas le travail de la même manière. La plus impressionnante en démonstration n’est pas nécessairement la plus utile.

C’est là que l’exploration technique dépasse l’ajout d’un modèle à un formulaire. Elle permet de distinguer ce qui est réellement nécessaire de ce qui existe surtout parce que les anciens outils rendaient cette organisation pratique.

Comprendre les dépendances avant de supprimer le rapport

L’erreur inverse serait de déclarer tous les rapports inutiles et de les éliminer.

Un document peut avoir des lecteurs absents de la première discussion. Il peut expliquer une décision plusieurs mois plus tard, faciliter une relève ou conserver une exception qu’un tableau de bord ne montre pas. L’équipe responsable doit confirmer ces dépendances et les exigences de conservation applicables avant de modifier le processus.

Le guide de recherche utilisateur de GOV.UK propose une distinction pertinente : comprendre ce que les personnes cherchent à accomplir, y compris celles qui fournissent le service ou le soutiennent, plutôt que de confondre le besoin avec une solution déjà imaginée.

« Personne autour de la table ne le lit » ne prouve donc pas que le document est inutile. À l’inverse, « nous l’avons toujours produit » ne prouve pas que son format actuel soit nécessaire.

Un prototype devrait aider à choisir, pas seulement à impressionner

Je préférerais comparer deux façons de terminer le travail à l’aide d’un petit prototype plutôt que de perfectionner une automatisation dont la raison d’être reste floue.

Une version pourrait générer le rapport. Une autre présenterait les faits utiles et les exceptions non résolues. Il faudrait alors voir si la personne peut prendre la bonne décision, quels renseignements elle doit encore chercher et ce qui doit rester consultable par la suite.

Si le rapport s’avère plus utile, son automatisation repose sur une raison plus solide. Si l’autre approche fonctionne mieux, le projet a trouvé une meilleure cible. Si aucune ne convient, on apprend quelque chose sur les renseignements ou les pouvoirs de décision manquants, pas seulement sur le modèle.

Cette démarche ne réduit pas l’ambition technique. Elle lui donne un meilleur objet. L’IA, les connexions entre outils et les interfaces sur mesure peuvent changer la façon dont le travail circule. Se limiter à « rédiger la même chose plus vite » peut laisser cette occasion de côté.

Je partirais de la décision à prendre ensuite. Le document n’est qu’une des façons possibles de la rendre réalisable.

Cela change aussi la façon de mesurer le temps gagné : il faut regarder ce que le travail terminé permet d’accomplir, pas seulement la vitesse à laquelle un résultat apparaît.