Haaa ! Qu’est ce qu’on rigole dans ce métier hein ?

Bon, ceux qui bossent en SSII rigolent un peu moins (quoi que) mais dans les services informatiques qu’est ce qu’on se marre !

Je m’amuse toujours autant à voir mes collègues d’autres services venir nous expliquer comment bosser… Non, pas qu’ils ne peuvent rien nous apporter, mais simplement qu’ils sont persuadés qu’en informatique tout est tellement simple. Ma foi ce ne sont que des machines, elles ne font que ce que tu leurs dis de faire. Et puis de l’informatique, on en a tous fait. Mais on oublie bien vite les galères que c’était pour beaucoup ! Et là, on a droit à des scènes plutôt cocasses…

Les plus drôles quand même sont ceux qui vous rappellent leur passé d’étudiant et leur TP d’informatique. Dans le genre, tous ce que tu fais, je peux le faire :

« Ha oui, je me rappelle à l’époque. On faisait des conditions if. Ça n’a vraiment pas  changé… « 

Les pires sont quand même les plus jeunes :

– Mais vous faites bien de la programmation orientée objet? Les relations sont déjà faites! Je ne vois pas pourquoi c’est compliqué…

– Heu… Là on parle de base de données…

– ??

Et il y a les meilleurs, ceux qui t’apportent la solution sur un plateau d’argent :

– Non, mais pourquoi ça prend autant de temps à charger ??!

– C’est un peu normal, tu as 16 listes à charger pour 8 000 références. Qui se charge en fonction de critères donc ça prend un peu de temps oui !

– Donc, on a qu’à les afficher mais sans les charger !

– ??

Et puis, il y a les pépites, celles qui reviennent tellement souvent qu’on sait qu’elles reviendront:

– Mais pourquoi ça bug tout le temps ?

– Parce qu’on développe toujours tout dans l’urgence et qu’il faut mettre en production immédiatement. Et donc personne ne teste correctement.

– Mais pourquoi vous ne développez pas en cycle en V ??!

– On veut bien mais…

– Ha ben voilà, il faut développez en cycle V ! Je vais en parlé au DG…

– (moi dans ma tête) : Oui bien sûr et tu feras les recettes… Allez à la prochaine…

 

Non mais sérieusement, moi aussi j’ai fait des maths, de la physique, de la méca, de la chimie, de la compta, du management…

Jamais il ne me viendrait à l’esprit de venir donner des leçons sur le métier des autres. Combien même on m’inviterait à en discuter…

Mais pour l’informatique c’est bien différent. Il est vrai que nous sommes obligés de nous mettre à disposition des autres services pour notamment recueillir les besoins, rédiger les spécifications.

Même si certains process nous semblent aberrants, la question n’est jamais de les remettre en cause. Nous nous devons de comprendre le métier des autres un point c’est tout.

Mais essayent-ils de comprendre le nôtre ?

J’ai appris à ne pas faire durer les conversations qui commence par « Mais pourtant c’est simple! ». On finit toujours par parler technique. Et dès qu’on parle technique, il n’y a pas plus personne (et c’est bien normal!) mais ça les énerve… On nous reproche de faire les choses de façon trop compliqué, d’aller trop loin dans la réflexion sur des questions qui ne nous concernent pas mais qui concernent le métier. Et alors, on nous sort les exemples simplistes pour lesquels ça fonctionne bien évidemment. Et il suffit de prendre un exemple très concret mais plus complexe et auquel l’utilisateur n’avait pas pensé pour que la conversation soit abandonnée tout en laissant l’utilisateur perplexe.

 

Mais alors ce pseudo conflit est-il inévitable ?

Globalement, il y a deux choses.

– Il y a la complexité technique de la mise en oeuvre qui va nécessiter la mise en place de certaines technologies, la connaissance de celles-ci et qui implique donc une expertise technique que seuls des professionnel peuvent avoir. Et qu’on le veuille ou non, je pense que c’est un point où il n’y a pas vraiment lieu de discuter. Pour sa curiosité personnelle, l’utilisateur ou le client (s’il n’a aucune expertise) peut être amené à se poser des questions sur les technologies choisies. Il peut également le faire pour vérifier que nous sommes nous mêmes convaincus par ce choix. Mais en aucun cas il ne peut les remettre en cause. Attention à ne pas confondre la capacité à maîtriser la technique et celle qu’a l’utilisateur à définir son besoin de façon plus ou moins proche de ce que nous faisons nous même au travers des spécifications (fonctionnelles ou techniques) via de la logique, de l’algorithmie ou du workflow.

– Effectivement, il faut prendre en compte dans un deuxième point, la capacité de l’utilisateur à formaliser en terme fonctionnel ou pseudo-technique son besoin. Et c’est ici qu’il y a cette zone de flou où l’expertise est partagée. C’est ici qu’il faut faire preuve de pragmatisme et être capable de définir les frontières entre le métier de l’utilisateur et la spécification de la demande d’une part et les choix techniques propres à la mise en oeuvre d’autre part. Et croyez moi, ça n’est pas aussi simple que ça en a l’air.

Et c’est ce dernier point qui est capital, car la réponse qu’on amène à cette relation définit l’intégration du Service Informatique au reste de l’entreprise. Il y a là encore deux choix, soit de faire du SI une sorte de boîte noire dans laquelle on fait entrer un cahier des charges et il en sort une réponse plus ou moins adaptée en occultant tout facteur technique. Soit de mettre en avant cette interaction avec l’utilisateur (avec une philosophie plus ou moins Agile) et alors on se retrouve forcément confronté, du fait de la proximité qui s’impose avec le métier de l’informatique, à une relation quelque peu conflictuelle dans laquelle l’utilisateur a l’impression de faire ou de connaître une partie de notre travail en captant quelques unes de nos problématiques.

Dans la réalité, il faut trouver le juste milieu. Il y a cette boîte noire qui existent forcément et qui représentent l’expertise, que nous amenons en tant que professionnels, que l’utilisateur ne pourra jamais appréhender (sauf reconversion). Et il y a cette zone de flou, amenée par la proximité que l’on se doit de conserver, qui permet certaines libertés à l’utilisateur, même si l’on peut lui reprocher de ne pas toujours aller jusqu’au bout de sa réflexion. Des libertés dont nous-mêmes ne devrions pas nous priver lorsque nous décelons des défauts dans les processus, le savoir faire, le métier de l’utilisateur.

 

 

Sur ce, je vous souhaite bon courage et j’espère que vous me lirez plus souvent dorénavant !

 

Post to Twitter Post to Facebook