Fonctionnel et technique

Dans les projets de système d'information, on doit toujours avoir des "fonctionnels" et des "techniciens". Un fonctionnel sera en mesure de comprendre ce que veut l'utilisateur du système, ou ce qui sera pratique pour lui. Un technicien sera en mesure de comprendre comment fonctionne les systèmes, logiciels, languages, etc. pour le réaliser.

En effet, il est rapidement apparu dans les premiers grands projets que les informaticiens "technique" devaient consacrer un temps de plus en plus important à comprendre le fonctionnement des systèmes, et qu'il n'avaient par conséquent pas le temps d'écouter convenablement des utilisateurs, de leur faire accoucher de leur besoin, de réconcilier des points de vues ou des exigences divergentes, etc. Ce qui fait la joie du technicien, c'est la prouesse technique, l'utilisation d'une nouvelle technologie, épater ses collègues techniciens, bref toutes choses absolument dénuées d'intérêt pour l'utilisateur final. Quel intérêt d'avoir un graphique qui tourne en 3D si on n'arriva pas à lire les chiffres qui le constitue ?

Il fallait donc avoir une interface pour parler aux utilisateurs, essayer de se mettre vraiment à leur place, comprendre leur métier, et finalement le traduire en termes compréhensibles aux techniciens. Et surtout, après, s'assurer qu'ils font bien ce qui leur est demandé, et ne perdent pas leur temps en gadgets inutiles... Le "fonctionnel" est donc celui qui va parler au client, ou aux utilisateurs et qui est garant du résultat. Une sorte de "col blanc" de l'informatique.

Tout ceci marche plutôt pas mal. Néammoins, j'ai eu l'occasion de constater à plusieurs reprises les travers de ce modèle bien établi. Par exemple, on demande aux gens de se classer dans une catégorie ou une autre: poste spécifiques, équipe de "business analysis" dans les projets, etc. C'est nécessaire, mais la séparation devient forcément structurelle : équipe différentes, locaux voire localisation différente, traitements et salaires progressivement différents... En poussant ma description précédente du fonctionnel, on comprend aussi qu'il y a un embryon de "lutte des classes" entre fonctionnels et techniques. Car si l'un est col blanc, visible et valorisé, l'autre est à coup sûr col bleu. Avec le risque d'une guéguerre perpétuelle sur le mode: "ce que vous nous spécifiez est infaisable" / "vous ne vous intéressez pas à l'utilisateur". Ce dialogue de sourd arrive malheureusement assez souvent.
Pour ma part, je préferre ne pas choisir de "camp". L'informaticien idéal est celui qui est exactement entre les deux, et qui va savoir simultanément analyser le besoin fonctionnel et les contraintes techniques. Au cours de son analyse fonctionnelle, il saura anticiper les problèmes de performance, choisir une architecture adaptée, remettre en perspective des demandes de l'utilisateur et proposer un compromis entre utilité et difficulté.

Malheureusement, sur de gros projets, ceci est impossible. On ne peut pas être à la fois comptable, spécialiste de logistique, commercial, etc. Mais au moins faut-il empêcher une rupture entre les deux aspects. Pousser les techniciens à s'intéresser à l'utilisation de leur système, et les fonctionnels à la technique. Même s'ils n'en ont pas envie. Et surtout, éviter le snobisme. La communication doit être intense et poussée entre les deux aspects, et le respect mutuel.

Mots-clés : fonctionnel - technique