Quelles techniques mettre en oeuvre pour récolter les exigences de vos clients et utilisateurs ? Unisys, GIAL, CEDITI, l’université de Namur et le CETIC livrent leurs secrets d’experts.
Le 9 décembre 2003, quelques spécialistes -entreprises, universités, centres de recherche- se sont réunis autour du thème : "comment identifier les besoins des clients et utilisateurs de solutions IT ?". Plusieurs études montrent en effet que la plupart des projets informatiques souffrent de manquements dans ce domaine, qu’ils soient commandités par des entreprises privées ou des institutions publiques. Le point sur les techniques existantes.
La technique de l’interview semble d’application dans presque tous les cas de figure. Selon Paul De Neef, analyste chez GIAL, une entrevue doit privilégier les questions ouvertes, afin de laisser son interlocuteur s’exprimer le plus naturellement possible. Elle s’entame typiquement par un bavardage anodin pour mettre à l’aise et une explication claire des objectifs. L’utilisation du "Pourquoi ?" est importante pour approfondir certains points mais ne doit pas s’utiliser plus de trois fois à la suite : la réponse pourrait dépasser le cadre de la fonction de la personne interrogée.
Paul De Neef préfère se renseigner sur le personnage avant de le recontrer, histoire de mieux pouvoir interpréter ses dires. Dans le même ordre d’idées, Denis Ballant, du CEDITI, conseille d’enregistrer les interviews : réécouter celles-ci plus tard dans le projet, à la lumière d’une meilleure connaissance du problème, permet de mieux appréhender ce qui a été dit. Par ailleurs, les transcriptions d’interviews peuvent être introduites dans l’outil Objectiver du CEDITI, dans lequel le cahier des charges du projet est ensuite défini graphiquement au moyen d’arbres d’objectifs. L’outil permet de lier les objectifs à certains mots des transcriptions, afin d’en assurer la traçabilité.
Une technique complémentaire consiste à observer l’utilisateur dans son environnement de travail, par exemple en train de réaliser des tâches qui vont être automatisées. C’est ce qu’ont fait des chercheurs de l’université de Namur dans Arthur, un projet d’informatisation de services d’urgences hospitaliers. L’observation a consisté à enfiler une blouse blanche et à se fondre dans différents services pour y prendre des notes. La discrétion des observateurs est importante pour éviter toute perturbation ou modification du comportement à observer.
Selon Paul De Neef, observer permet de mieux appréhender les relations de pouvoir entre personnes, ce qui est plus difficile lorsqu’on est, comme pour le cas de l’interview, hors du processus de travail. Par ailleurs, la participation de l’observateur dans la réalisation des tâches, quand elle est possible, peut être un moyen encore plus efficace pour se rendre compte des problèmes et besoins.
Confronter le futur utilisateur à des esquisses préalables du système, qu’elles se présentent sous forme d’implémentation partielle, de diaporamas, de modèles ou de documents, permet à nouveau d’identifier des exigences difficilement décelables via les autres techniques. En effet, il semble que le seul fait de mettre un utilisateur face à un nouveau logiciel soit en soi une manière de récolter ses exigences sur ce logiciel ! Paul De Neef met en oeuvre plusieurs types d’ébauches. Le premier, utilisé avec beaucoup de succès dans les administrations communales, consiste à montrer aux fonctionnaires des modèles conceptuels de données sous une forme qui leur est bien connue : celle de registres. Par exemple, une association entre concepts devient une colonne, dans un registre, qui contient une référence vers une colonne identifiante d’un autre registre.
Le second consiste à dessiner, sur des grands panneaux, des sortes de machines à états dont les états sont des captures d’écran ; les transitions entre états montrent les chemins de navigation possibles d’un écran à l’autre. Enfin, le prototype HTML permet de concevoir très rapidement l’interface graphique d’un logiciel.
Ces techniques permettent de récolter, très tôt dans le développement et à moindre coût, le feedback des utilisateurs sur base de représentations aisément compréhensibles par des non-informaticiens. Ce feedback donne de meilleures chances d’acceptation finale du logiciel.
L’identification de flux de travail (ou workflows) est un préalable important à son informatisation ou simplement à sa redéfinition. Hilde Van Heylen, d’Unisys, a présenté la "Picture Card Design Method" (PCDM), couramment utilisée par son entreprise pour analyser les flux de travail de ses clients. Développée à l’université de Lintz, en Autriche, cette méthode consiste à faire exprimer par les utilisateurs eux-mêmes (les acteurs du workflow) les flux de travail au moyen de cartes. Celles-ci représentent des documents, activités ou personnes que les utilisateurs agencent sur une grande table afin de décrire le workflow. Typiquement, l’exercice est d’abord réalisé en interne chez Unisys ; après cette simulation, il est réalisé avec la hiérarchie puis avec les travailleurs. Après ces trois passes, on obtient la description nécessaire à l’identification de pistes pour la redéfiniton ou l’automatisation de tout ou partie des activités. Loin des déboires du reengineering de workflows des années ’80, durant lesquelles on pouvait recenser jusqu’à 90% d’échec dans ce type d’initiative, l’application de la PCDM doit probablement sont succès à l’implication active des utilisateurs et acteurs du workflow, qui dès lors comprennent et acceptent mieux les changements.
Dans le monde académique, les besoins des clients et utilisateurs de logiciels font l’objet, depuis une bonne dizaine d’années, d’une discipline à part entière : l’Ingénierie des Exigences (IE), ou ingénierie des cahiers de charge. L’identification des besoins, dont différentes formes ont été abordées dans cet article, ne constitue qu’une partie des activités d’IE. L’analyse, la modélisation, la vérification, la validation et la prise en charge de l’évolution des attentes des utilisateurs sont les autres activités nécessaires à l’établissement du cahier des charges final. Un autre article de cette newsletter présente l’approche globale de l’IE, incluant les logiciels de conception et les cavenas de cahiers de charges, et décrit les services que le CETIC vous propose dans ce domaine.
Gaëtan Delannay