L'expression des besoins et le système d'information

31 décembre 2001

On croit parfois qu'il faut satisfaire la demande des utilisateurs des systèmes d'information, et qu'en somme les spécifications fonctionnelles devraient être écrites sous leur dictée. Cette illusion conduit à une inflation de fonctionnalités : a posteriori les utilisateurs n'utiliseront que 20 % au plus de ce qu'ils ont demandé.

Où est l'erreur ?

C'est que l'on a confondu besoin et demande. Les utilisateurs expriment une demande, mais elle ne correspond pas nécessairement à leurs besoins. Il n'y a pas là de paradoxe mais un fait d'expérience qui s'éclaire si l'on se réfère à la vie courante. Supposons que vous vouliez vous faire construire une maison. Il faut qu'elle réponde à vos besoins ; ces besoins, ce sont les vôtres, vous en êtes le seul porteur légitime. Mais cela ne veut pas dire que vous sachiez les exprimer clairement, encore moins que vous sachiez comment il sera possible de les satisfaire. Votre demande - expression de votre besoin - est maladroite, car rien ne vous a préparé à résoudre un problème d'architecture.

Michel Morel, architecte, m'a montré le carnet où il avait noté les étapes de sa conversation avec un client. Celui-ci avait acheté un terrain en Provence et voulait y faire construire une résidence secondaire. Mon ami lui dit : "Quel type de maison voulez-vous ?" et le client fit le dessin suivant :

Mon ami posa le dessin sur la table et dit : "Parlez-moi de vous, de votre famille, de la façon dont vous vivez". Et le client s'explique. Il a cinquante ans, il est marié à sa seconde femme qui a vingt cinq ans de moins que lui, il a un fils de vingt ans, étudiant qui vit avec sa première femme mais passe de temps à autres quelques jours avec lui. Il aime à s'isoler pour réfléchir, travailler ou lire ; sa femme mène une vie mondaine, reçoit souvent des amis, etc. Pendant que le client parle, mon ami dessine des ronds représentant des espaces : salle de séjour, bureau, chambre à coucher, salle de bains, chambres d'amis, etc.

Le client aimerait à s'isoler pendant les réceptions de sa femme, mais pas totalement ; mon ami dessine un bureau dont le plancher est plus bas que le plafond de la salle de séjour ; il installe entre les deux une fenêtre que le client pourra ouvrir ou fermer à sa convenance, ou bien masquer par un rideau.

Pendant la conversation, le schéma de la maison s'élabore. Elle correspond aux besoins du client qui est ravi - mais elle ne ressemble pas du tout au dessin puéril par lequel il avait d'abord exprimé sa "demande".

Les MOAO se trouvent, devant l'utilisateur du SI, dans la même position que l'architecte face à son client. "Je voudrais automatiser les envois de courriers et disposer d'un système permettant de savoir, pour chaque client, ce qu'il nous a écrit, ce que nous lui avons répondu. Ce système doit me fournir des histogrammes reflétant la distribution de nos délais de réponse pour maîtriser la qualité ; il doit aussi me permettre d'automatiser l'envoi de lettres de relance aux clients qui n'ont pas répondu, etc." : cela, c'est une demande. Il faut la poser sur un coin de la table puis dire à l'utilisateur : "que voulez-vous faire, quel est le problème que vous cherchez à résoudre avec cette automatisation du courrier ? " On pourra ainsi remonter de la demande au besoin et aider le client à reformuler sa demande en des termes correspondant à ces besoins. Chemin faisant, on lui donnera l'occasion de tirer parti de possibilités auxquelles il n'aurait jamais pensé. On élaguera aussi, dans la formulation de la demande, les fonctionnalités dont on peut présumer qu'elles ne serviront à rien.

Il est vrai que certains clients au caractère impérieux refusent de se prêter à ce jeu. "Je sais ce dont j'ai besoin, disent-ils, je n'ai pas envie de vous raconter ma vie. Faites ce que je vous demande". Il faut alors leur dire, respectueusement mais clairement, que ce n'est pas ainsi qu'ils seront le mieux servis.