Analyser les besoins, c'est rendre visibles des désaccords qui existaient déjà

La situation

Un organisme public décide de se doter d’un logiciel unique pour gérer ses commandes, ses prestations et sa facturation. Le fonctionnement en place est le suivant. Les prestations réalisées sont encodées dans une petite base de données bureautique, qui imprime chaque mois un relevé de ce qui doit être facturé. Une personne reprend ce relevé et le ressaisit dans le logiciel comptable, qui édite les factures. Cette ressaisie occupe dix jours par mois.

Le constat s’impose de lui-même pendant l’analyse. La nouvelle application contiendra toutes les données nécessaires à la facturation. Elle peut donc produire les factures directement et transmettre les écritures au logiciel comptable, ce qui supprime la ressaisie, et avec elle le risque d’erreur qu’elle comporte.

Le responsable du service comptable s’y oppose. Ses arguments sont techniques, nombreux et changeants. Chaque fois qu’une objection est levée, une autre apparaît. Après plusieurs semaines, il devient clair que les objections ne portent pas sur ce qu’elles prétendent : ce qui est en jeu, c’est la maîtrise de la facturation, et le poste d’une personne dont l’activité repose largement sur cette ressaisie.

Ce blocage n’est pas nouveau. La direction avait déjà tenté de faire évoluer ce fonctionnement, sans y parvenir. L’affaire se dénoue cette fois par une démonstration chiffrée, comparant les deux scénarios en coût de saisie et en taux d’erreur. Le responsable finit par accepter. La personne qui effectuait la ressaisie rejoint un autre service, sur des tâches plus utiles et plus proches de ses compétences.

Ce qui mérite attention ici, ce n’est pas l’issue. C’est que l’analyse n’a créé aucun de ces problèmes. Elle les a seulement rendus impossibles à ignorer.

Ce cas s’est bien terminé. Beaucoup d’autres non, et la suite de cet article s’intéresse autant aux uns qu’aux autres.

Pourquoi cette situation apparaît

Personne ne voit l’ensemble. Chacun répond depuis son poste, avec une vue exacte de son périmètre et une vue partielle du reste. Ce n’est ni de la mauvaise volonté ni de l’incompétence : c’est la conséquence normale de la division du travail. Un établissement de soins l’illustre bien. Lors de la conception d’un dossier patient informatisé, chaque unité demande que les dossiers de ses patients soient inaccessibles aux autres unités, ce qui se défend au regard de la confidentialité. Sauf qu’un patient traverse plusieurs unités au cours d’un séjour, et que le médecin doit pouvoir consulter l’ensemble de son parcours. Le besoin réel n’appartient à aucune unité prise séparément. Il appartient au parcours du patient, que personne n’avait mandat pour représenter.

Une analyse touche à des intérêts réels. Charge de travail, maîtrise d’un domaine, existence même d’un poste. Ces enjeux sont légitimes et rarement exprimés comme tels. Ils se traduisent en objections techniques, parce que c’est la seule langue admise dans une réunion de projet. Une objection technique qui se déplace dès qu’on y répond n’est presque jamais une objection technique.

Celui qui conduit l’analyse ne décide de rien. Il constate, il documente, il recommande. Le pouvoir de trancher appartient à la direction. Tant que celle-ci ne l’exerce pas, les désaccords remontent vers le responsable de projet, qui n’a ni la légitimité ni le mandat pour les résoudre.

Les erreurs fréquemment observées

Répondre aux objections sans chercher d’où elles viennent. Le responsable explique que le lien entre les deux logiciels est techniquement impossible. On lui montre que d’autres l’ont fait. Il répond que les volumes seront trop importants. On chiffre les volumes. Il évoque alors un risque pour la clôture comptable. On y répond aussi. Une nouvelle objection arrive. Chaque réponse est correcte et aucune ne débloque quoi que ce soit, parce que la vraie raison du refus n’a jamais été posée sur la table.

Additionner les besoins service par service. On fait le tour des services, chacun décrit ce qu’il attend, on rassemble le tout dans un document. La méthode paraît rigoureuse, et le document ressemble à un cahier des charges complet. Il ne l’est pas. Chaque service a décrit son étape, aucun n’a décrit l’enchaînement. C’est ainsi qu’on obtient un dossier patient dans lequel chaque unité protège correctement ses données, et où le médecin ne peut plus suivre son patient d’une unité à l’autre. Personne n’a demandé cela. Personne n’a non plus été chargé de l’éviter.

Reproduire une complexité que personne n’a osé questionner. Une société de services aux entreprises facture ses prestations selon des tarifs qui varient avec le type de client, les volumes commandés et l’issue des négociations commerciales, l’ensemble étant assorti de nombreuses exceptions accumulées au fil des années. Pendant l’analyse, chaque proposition de simplification reçoit la même réponse : ces règles existent, il faut les conserver. Le responsable ne les défend pourtant pas vraiment. Il ne se sent simplement pas autorisé à demander à sa direction de revoir des principes en place depuis longtemps. Le logiciel a donc tout reproduit. Il en résulte un écran de paramétrage couvert de cases à cocher, un calcul de facturation difficile à corriger et à faire évoluer, et des montants qu’il faut parfois examiner en détail pour savoir s’ils sont exacts. Le projet n’a pas créé cette complexité. Il l’a coulée dans un logiciel, où elle est devenue bien plus difficile à défaire.

Constituer une équipe projet nombreuse sans désigner de responsable. Tout le monde veut être associé, ce qui part d’une bonne intention. Mais quand personne n’est désigné pour trancher, chaque question ouverte reste ouverte. Les échanges se multiplient, les délais s’allongent, et il devient impossible de savoir qui attend quoi de qui. Une équipe de dix personnes sans décideur avance moins vite qu’une équipe de trois avec un décideur.

Confondre analyser le travail et évaluer les personnes. Si cette confusion s’installe, plus personne ne décrit son travail tel qu’il est. L’analyse ne recueille alors que ce qui ne fâche personne.

Une approche plus pertinente

Arrêter de répondre aux objections quand elles se succèdent. Trois objections écartées et remplacées, c’est un signal. Il faut alors cesser d’argumenter et changer de cadre : voir la personne seule, en dehors des réunions de projet, et lui demander simplement ce que ce changement lui enlève. La réponse est rarement technique. C’est une charge de travail qui disparaît, une compétence qui ne servira plus, un contrôle qui échappe. Une fois cette raison sur la table, on peut la traiter, ce qui était impossible tant qu’elle restait déguisée en argument technique.

Attention toutefois : la plupart des objections sont fondées. Une contrainte réglementaire ou budgétaire réelle ne bouge pas. On y répond, et elle est toujours là, au même endroit, dans les mêmes termes. Ce qui doit alerter, ce n’est donc pas l’objection en elle-même, c’est le fait qu’elle change à chaque réponse.

Démontrer plutôt qu’imposer. Dans l’exemple du service comptable, la direction avait déjà essayé de faire bouger les choses par la voie hiérarchique, sans résultat. Ce qui a emporté la décision, c’est une comparaison chiffrée sur le coût de saisie et le taux d’erreur. Une démonstration a une propriété que l’autorité n’a pas : elle laisse à celui qui change d’avis une raison présentable de le faire. Un responsable qui cède à sa hiérarchie perd la face devant son équipe. Le même responsable qui se range à un calcul qu’il peut vérifier ne perd rien. C’est souvent tout ce qui sépare un blocage d’une décision.

Suivre un dossier réel du début à la fin. Plutôt que d’interroger les services les uns après les autres, on prend une commande, un patient ou un dossier, et on le suit d’un bout à l’autre de son parcours. À chaque passage d’un service à l’autre, une question : qui vérifie que rien ne se perd ici ? Bien souvent, personne ne répond, parce que personne n’en a la charge. Ce constat est plus utile que tout ce que produira l’analyse par service, et il ne relève pas de l’informatique. Il dit à une direction qu’une partie de son fonctionnement n’appartient à aucun de ses responsables.

Poser l’organisation du projet avant de poser les questions. Un interlocuteur désigné, un décideur identifié, un circuit clair pour les arbitrages. Cela paraît administratif et cela détermine la durée du projet plus sûrement que le choix de la technologie.

Poser la question des personnes comme une question de compétences. Une analyse sérieuse révèle parfois qu’une tâche occupant quelqu’un plusieurs jours par mois peut disparaître. Le sujet est souvent évité, parce qu’on l’entend comme une menace sur un emploi. C’est pourtant rarement de cela qu’il s’agit. Dans l’exemple du service comptable, la personne qui ressaisissait des factures dix jours par mois a rejoint un autre service, sur un travail plus utile et mieux accordé à ce qu’elle savait faire. L’organisation n’a pas perdu une ressource, elle l’a mieux employée.

Les questions à se poser

Cette objection technique a-t-elle changé de nature depuis que nous y répondons ? Si oui, que protège-t-elle réellement ?

Qui, dans notre organisation, a la responsabilité de l’ensemble du processus, et pas seulement d’une de ses étapes ?

Si nous additionnons les demandes de chaque service, obtenons-nous un fonctionnement que nous accepterions ?

Qui tranche quand deux services sont en désaccord, et cette personne le sait-elle ?

Combien de personnes composent notre équipe projet, et laquelle décide ?

Les personnes interrogées savent-elles que nous analysons leur travail et non leurs performances ? Qui le leur a dit, et à quel moment ?

Combien de nos exceptions sommes-nous encore capables de justifier, et qui a le pouvoir d’en supprimer une ?

Sommes-nous prêts à entendre qu’une partie de ce que nous faisons aujourd’hui n’a plus lieu d’être ?

Conclusion

Une analyse des besoins ne crée pas les désaccords qu’elle rencontre. Ils existaient avant elle, répartis entre des services qui ne se parlaient pas, absorbés par des habitudes que personne n’interrogeait, contenus par un outil trop rigide pour laisser le choix. L’analyse les rend simplement visibles, tous en même temps, ce qui la rend inconfortable.

Une organisation peut décider de ne pas les regarder. Ils ne disparaissent pas pour autant : ils sont alors transcrits dans le logiciel, où ils deviennent des règles, des écrans et des exceptions que plus personne n’osera modifier. Un désaccord traité pendant l’analyse coûte quelques réunions difficiles. Le même désaccord transcrit dans un logiciel coûte des années.