Définir les besoins des utilisateurs tient souvent plus du parcours du combattant dans la jungle de Cayenne et du dressage de crocodile affamé que de la réunion corporatiste entre gens de bonne compagnie.

On tombe souvent sur l’un des cas extrêmes que j’abordais dans mon billet sur la typologie des émetteurs d’appels d’offres, le client qui se retrouve face à un problème non métier dont il cerne les effets les plus visibles, sans pour autant en saisir les tenants et les aboutissants. Si le client ne cherche pas à étaler sa méconnaissance des nouvelles technologies sous la forme d’une bouillie de mots lus dans le dernier 01 Informatique, il se peut que cela se passe bien et qu’il exprime les besoins sous une forme simple :

Il y a trop de spam et de virus dans les emails que nous recevons, il faut faire quelque chose.

Ou bien :

Nous avons eu 3 pannes d’Internet la semaine dernière, cela ne peut pas continuer comme ça, il nous faut une solution de secours.

Malheureusement, on rencontre aussi souvent des cas plus problématiques ou folkloriques :

Nous avons des problèmes récurrents de ralentissements réseau dus à des problèmes de permissions sur les DSP des switchs placés en frontal devant les baies SAN.

Ou encore

Je voudrais mettre en place un CMS sous SAP pour gérer l’input flow des assets de notre division saucisse sèche.

Traiter ces clients demande un doigté particulier afin de ne jamais créer d’incident diplomatique qui pourrait remettre le contrat en question. Le plus simple reste de proposer les bonnes idées en persuadant le plus haut placé hiérarchiquement qu’elles viennent de lui, tout en attribuant les mauvaises soit à un subalterne en vacances, soit à soi-même sans toutefois se décrédibiliser. Cela donne des situations comme :

– Comme vous l’avez fait remarquer lors de notre dernière réunion, le problème vient d’une mauvaise topologie du réseau.
– Il me semblait que le ralentissement venait du dernier ver Microsoft ?
– C’est ce que j’avais avancé en première hypothèse, et je vous remercie de m’voir éclairé à ce sujet.

Comme on le voit, ça relève plus de l’exercice de funambule que de l’ingénierie pure et dure.

Je rencontre aussi un autre type d’extrême tout aussi délicat à traiter : celui qui arrive avec une solution pré étudiée en interne par d’autres lecteurs assidus de 01 Informatique, et reposant sur des solutions sans commune mesure ni avec ses besoins ni avec son budget.

Le discours entendu pourrait ressembler à ça :

Nous avons 5 pc en réseau, et nous voudrions une ligne dédiée 20MB avec une ligne de secours 2MB chez un autre fournisseur en backup, une solution double firewall redondant actif / actif, proxy de filtrage SMTP et HTTP transparent…

La direction financière accueille généralement bien mon intervention qui consiste généralement à recadrer les besoins réels du client tout en planifiant les évolutions futures. Là aussi, je dois faire tout un travail d’analyse afin de déterminer si je me retrouve face à une exagération due à l’ignorance ou à la fantaisie d’un DSI qui cherche à s’offrir un beau jouet. Et dans ce cas, les choses sont loin d’être gagnées.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: