Revenons aux fondamentaux. Pour qui travaillons-nous ? Un client, et derrière, des utilisateurs. Le client peut exprimer directement son besoin ou il peut déléguer ce travail à un utilisateur ou à un groupe d’utilisateurs.
Donc en principe, il existe toujours un interlocuteur qui défini les besoins. En principe, la définition est faite dans un cahier des charges. Ce document défini :
- ce qu’attend le client (le besoin),
- ce qu’il fournit au prestataire pour réaliser le besoin (les entrants),
- ce qu’il attend en retour (les sortants).
En informatique, la notion de besoin est plus vague. Le client considère que c’est de l’informatique. C’est vous l’expert et donc à vous de débroussailler le terrain. Une partie du chantier est alors consacrée à l’expression des besoins avant de définir un cahier des charges (AMOA).
Il existe deux situations :
Soit il faut automatiser un élément d’un système d’information déjà en place. Par exemple, le cahier de présence d’un collège. En début de chaque cours, l’enseignant indique les élèves présents dans un cahier. L’idée est alors de remplacer le cahier de présence par une application accessible par les enseignants.
Exprimer le besoin consiste ici à décrire l’existant et ensuite apporter des outils informatiques pour l’automatiser. Une méthode de gestion de projet ancienne comme Merise ( et sa courbe du soleil) apportera des outils nécessaire à la conduite d’un tel projet.
Soit il faut implémenter un nouveau besoin. Par exemple, le collège décide d’améliorer la relation entre les parents et l’équipe scolaire (enseignants et administrations) : rapport automatique aux parents en cas d’absence non signalée d’un élève, envoi automatique des bulletins scolaires, forum de discussion entre parents d’élèves et enseignants, accès aux devoirs à faire à la maison …
Dans ce cas, il faut planifier des entretiens avec les utilisateurs pour les aider à exprimer le besoin, de méthodes de projets plus ou moins originales (avec des post-its, des gommettes, des cartes à jouer, des ficelles, … pour les plus originaux sinon papier et crayon). Cela permet de déterminer les fonctionnalités vraiment attendues par les utilisateurs.
La phase d’expression des besoins est importante. Si, elle est mal exécutée, même si les phases suivantes sont parfaitement exécutées, l’utilisateur considérera que le logiciel ne l’aide pas dans son travail et le jugera inutile.
Voici quelques règles à savoir lorsqu’on réalise un entretien :
Le client n’est pas, par définition, un informaticien. Il ne sait pas si son besoin est simple ou compliqué à réaliser et il ne doit pas le savoir. Autrement on se retrouve dans la situation où il ne va pas oser demander quelque chose dont il a besoin parce qu’il pense que c’est trop compliqué à faire.
Le client (ou son représentant) connaît son métier et vous le décrira suivant la situation où tout se passe bien – le cas nominal. Il oubliera systématiquement les cas à la marge. Il faut les évoquer avec lui, autrement, il sera surpris de ne pas voir des situations peu fréquentes non traitées par l’application.
Le client est intelligent. L’infantiliser en ne lui donnant pas d’explications sur le contexte (méthodes de travail, contexte technique cible) est toujours contre-productif. Au contraire, plus vous lui expliquez votre démarche et vos solutions techniques, et plus il sera impliqué et donnera des informations pertinentes.
Toutes les étapes d’un projet informatique sont importantes et partir sur de bonnes bases est indispensable.