D'où proviennent les besoins d'un système informatique ?

Un système informatique permet de répondre à des besoins fonctionnels : saisir les noms et adresses des clients, exécuter des tâches précises comme le calcul d’une indemnité, ou même réaliser des tâches d’intelligence artificielle comme la reconnaissance faciale. Ces tâches proviennent toutes d’un besoin inhérent à une organisation, du désir de créer quelque chose de différent, ou tout simplement d’une idée qu’une personne croit utile et rentable.

Ces besoins viennent de quelque part. Pour un analyste qui doit les structurer et les rendre compréhensibles au développeur, cela suppose un processus d’identification — et ces besoins sont souvent de sources différentes.

Parfois, les besoins sont contradictoires et doivent être contre-vérifiés pour trouver le besoin réel. Or ce besoin réel ne devra pas nécessairement aboutir dans les mains d’un développeur. Le besoin d’un utilisateur n’est pas nécessairement celui du patron, et même si le patron est conscient du besoin de l’utilisateur, cela ne signifie pas qu’il voudra payer pour le combler.

L’analyste se retrouve parfois entre l’arbre et l’écorce : il doit bien comprendre les besoins de tous, les confronter et faire un choix pour le développement du produit, en accord avec les différents intervenants.

Voici quelques exemples de provenance des besoins.

Le client

Le client offre à l’analyste des besoins qui lui sont souvent propres et qui tiennent compte de ce qu’il voit ou perçoit dans son entreprise. Une bonne discussion avec lui est nécessaire : c’est la personne qui paye pour combler les besoins en matière d’application logicielle. Le client est une bonne source d’information, mais l’analyste ne doit pas s’arrêter là ; il doit chercher des besoins ailleurs pour vérifier et en découvrir d’autres.

L’utilisateur

L’utilisateur est une source très précieuse : il connaît l’application, il l’utilise tous les jours et il sait ce dont il a besoin. Pour les applications destinées à des utilisateurs occasionnels, ceux-ci peuvent aussi donner d’importantes informations sur la facilité d’utilisation.

Les architectes

Qu’ils soient architectes fonctionnels, logiciels ou d’affaires, ces personnes des équipes de développement sont des sources de besoins à ne pas négliger : grâce à leur expérience, elles peuvent avoir des idées précieuses pour le développement d’une application.

L’analyste

Bien que l’analyste soit souvent la personne désignée pour trouver les besoins, il peut aussi en être acteur : suggérer des idées et se faire contre-valider par les autres membres de l’organisation.

Le développeur

Il ne faut pas oublier les développeurs : ils peuvent avoir de bonnes idées, car ils connaissent l’application — surtout lorsqu’ils sont en mode entretien.

Le marché

La concurrence offre des applications déjà toutes faites, et plusieurs de ces idées peuvent être intégrées à l’application sur laquelle on travaille. Si une idée vient du marché, il peut être nécessaire d’offrir le même genre de service. C’est à analyser avec l’équipe.

Les lois et règlements

Un aspect important : les lois et règlements. Ils régissent nos vies et doivent absolument être considérés lors de la recherche des besoins.

En conclusion, les besoins proviennent de sources différentes et sont parfois contradictoires. Pour l’analyste, il est primordial de faire le tri, de confronter ces besoins avec plusieurs membres de l’organisation — et parfois en dehors de celle-ci. Tous les besoins ne sont pas égaux : certains peuvent être éliminés s’ils sont à peine nécessaires, d’autres priorisés lorsque le besoin est urgent.