La maîtrise d'ouvrage informatique pour les nuls (et les blogueurs)

Dans la vraie vie comme dans les blogs, on me demande parfois ce que je fais comme métier, mais comme il est assez rare, j’ai du mal à l’expliquer et mes interlocuteurs n’arrivent pas s’imaginer. Si j’étais barman, je dirais : je suis barman. Les gens savent ce que c’est. Si j’étais informaticien, je dirais : je suis informaticien. Les informaticiens comprendraient, évidemment. Les autres imagineraient un type plongé dans un clavier à faire « des programme ». En déjeunant avec des copains hier, j’ai trouvé la manière d’expliquer mon boulot à partir des blogs.

Pierre a un blog dans une plateforme qu’il ne supporte plus et souhaite tout migrer sous Blogger qu’il connaît bien. Il nous dit ça ainsi qu’il voulait récupérer les flux RSS de l’ancien pour le mettre dans le nouveau.

Dans mon boulot, Pierre est « l’utilisateur » (d’une application informatique). On dirait qu’il exprime un besoin (changer de plateforme de blog) et je suis le type chargé de recueillir le besoin afin de l’exprimer à l’informaticien.

Nous sommes trois à table. Pierre est l’utilisateur. Je suis la maîtrise d’ouvrage. Le troisième, Hip, représente l’informaticien (mais pour les besoins du récit, je noircis beaucoup ses traits).

L’utilisateur a exprimé un besoin : migrer son blog vers Blogger en récupérant l’historique à partir des flux RSS.

Le premier travers de l’utilisateur est de farcir sa demande de spécifications techniques alors qu’il n’y comprend absolument rien. En l’occurrence, les spécifications techniques sont :

-         l’ouverture d’un blog Blogger,

-         l’import à partir du flux RSS.

C’est toujours pareil, c’est plus fort que lui, il est persuadé connaître quelque chose en informatique et pose déjà, avant de savoir ce qu’il voulait réellement faire, des jalons techniques.

L’informaticien a généralement tendance à plonger dedans. Il a une demande d’un client et peu la facturer. Tant mieux. Souvent, l’utilisateur s’en fout du prix : ce n’est pas lui qui paye, son chef n’a qu’à se démerder auprès de la direction pour avoir du budget.

En fait, c’est même pire, sur les deux spécifications techniques de l’utilisateur, l’informaticien réussira à faire sauter la bonne, en l’occurrence Blogger, parce qu’il préfère Dotclear qu’il maîtrise mieux, mais il conserva l'intégration des flux RSS.

C’est là que j’interviens. Je connais un peu le métier (les blogs, j’en tiens 6 mais en amateur, c’est-à-dire en me foutant des aspects financiers) et je connais un peu l’informatique (j’ai été développeur pendant huit ans). Je suis la « maîtrise d’ouvrage ».

Je réponds à Pierre : « Oui, pour l’utilisation que tu vas à en faire, utiliser Blogger est un bon choix puisque tu connais déjà un peu. Par contre, ce n’est pas à partir des flux RSS que tu vas récupérer l’historique. Tu as dans l’ancien blog une fonction d’exportation et, dans le nouveau, une fonction d’importation mais je ne sais pas comment ça marche. »

A ce stade, dans une entreprise (et évidemment pour un sujet plus important), un de mes homologues aurait proposé de prendre un consultant pour étudier les différentes méthodes pour incorporer l’historique d’un blog.

Pas moi. Et c’est pour ça que mes chefs m’aiment bien : j’arrive à leur faire économiser du pognon.

J’interviens donc avant que l’informaticien, Hip, ne l’ouvre et propose d’étudier les différentes méthodes pour incorporer l’ancien blog dans l’autre et vendre la prestation correspondante.

« Pierre, ce dont tu as un besoin : ouvrir un blog sur une nouvelle plateforme pour écrire des billets mais comme tu blogues au sujet de l’actualité, comme moi, es-tu sûr d’avoir besoin de l’historique ? »

Lui : « Ah ben non, tu as raison, je vais repartir de zéro. »

L’utilisateur avait inventé un besoin (migrer un blog) alors qu’il en avait un autre (créer un blog). C’est très souvent le cas, d’autant qu’il y a généralement un tas d’intermédiaires qui ne comprennent pas vraiment ce qu’il faut mais qui tiennent à leur poste et à leur budget. Le fait que je puisse voir Pierre en face à face a fait que j’ai pu l’aider à faire le raisonnement.

Ainsi, il s’imaginait passer un week-end à galérer alors que ça va lui prendre 35 minutes.

Un week-end : ben oui, quand on ne sait pas comment faire, il faut faire des recherches. Dans la vraie vie, on fait appel à un informaticien qui va facturer très cher une prestation parce que l’utilisateur sera bloqué et pressé de changer de plateforme.

35 minutes : j’avais fait le test, tout compris, dont la blogroll et le compte twitter pour balancer le flux (et le passage chez Feedburner mais c’est dépassé, semble-t-il).

Voila mon métier : simplifier et économiser. Et voila pourquoi mes chefs m’aiment bien : je le fais à fond et sans avoir besoin de consultant…

Ce n’est pas fini mais je vais m’attarder un peu.

Dans la pratique, une tache que Pierre aurait probablement mis douze heure à accomplir aurait pu être faite en deux heures pas Hip mais il l’aurait facturée 8 (dans la vraie vie, Hip étant un copain, il aurait fait ça pour une bouteille de vin). En passant à une demi-heure, j’abuse un peu. Pierre n’ayant pas mon habitude de créer des blogs et des comptes Twitter, il aurait mis une heure. J’ai donc fait diviser la facture finale par huit.

Dans la vraie vie, ça veut dire que j’aurais pu faire passer un projet informatique de 400 000 euros à 50 000, soit une économie de 350 000… en y consacrant une demi-heure au cours d’un déjeuner.

Ce n’est pas fini, disais-je…

Pierre : « Oui, mais je fais comment pour récupérer mon nom de domaine ? » Et là, je suis sec. Je ne sais pas quoi lui répondre mais j’ai immédiatement une idée : « Mais qu’est-ce que tu en as à foutre ? On est moins de 10 à le connaître, je suppose. Tu peux en prendre un nouveau ! »

Pierre : « Oui, mais j’y tiens, moi, à mon nom de domaine. » Me voila emmerdé. L’informaticien, Hip, voyant qu’il a presque tout perdu intervient alors, puisque c’est bien son domaine de compétence. « Ah ! Mais je vais te le faire, moi, ça va me prendre quelques minutes mais ton blog sera hors service environ 48 heures. »

Je cède. Il faut toujours céder un peu. L’utilisateur aura l’impression d’avoir remporté une victoire et obtenu gain de cause. L’informaticien ne me détestera pas et accèdera à mes prochaines demandes.

Le plan d’action est défini :

-         Pierre va créer son nouveau blog,

-         Pierre et Hip vont prendre rendez-vous pour paramétrer le nom de domaine.

Mais je suis un vieux briscard. Je sais à peu près comment ça va se passer : ils ne prendront jamais rendez-vous parce qu’ils n’auront pas le temps. En fait, je n’en sais rien mais dans la vraie vie, ce qui va se passer est que le chef de l’informaticien va gonfler un peu le devis. Même s’il n’est pas trop élevé, Pierre ne trouvera personne dans sa hiérarchie pour un truc aussi peu important.

Alors, c’est là que je reviens. En fin de projet, quand on tombe sur un os.

Pierre va lancer son nouveau blog mais sans nom de domaine, je vais aller voir son nouveau blog puisque ça fait partie de mon job et je vais constater qu’il n’aura pas récupérer le nom de domaine. Je vais lui demander : « Bon, qu’est-ce qu’il se passe ? » Lui : « Bah ! On n’a pas encore fait, trop chiant… ».

Moi : « Mais au fait, pour ton nom de domaine, tu n’as qu’à garder le nom et remplacer le « .com » en « .net », il sera toujours aussi chouette ! » Lui : « Ah ben oui, tiens ! »

Il sera content et me bénira (ce qui veut dire qu’il m’invitera à nouveau à déjeuner), le service qu’il voulait lui sera totalement rendu. Le besoin qu’il avait exprimé au départ aura été oublié et il pourra avoir l’usage qu’il voulait de son nouveau blog.

Le besoin et l’usage…

Hip, l’informaticien sera également content et me bénira (je vais prendre du ventre, si ça continue). Il avait promis de résoudre le problème de Pierre mais il n’a pas pu le faire à cause de leurs hiérarchies respectives, il n’était pas fier de lui. J’ai trouvé un palliatif. Il est sauvé.

Résumons…

Dans la vie, il y a les utilisateurs d’applications. Concrètement, ce sont généralement des « services marketing » qui doivent proposer des nouveaux produits ou services aux clients et des « services organisation » qui doivent organiser le travail des employés.

Ils font des expressions de besoin mais qui :

-         coûteraient extrêmement chers,

-         ne correspondraient pas exactement aux besoins que pourraient en avoir les utilisateurs parce qu’ils n’ont pas nécessairement le recul nécessaire,

-         contiendraient des contraintes techniques totalement inutiles.

Dans la vie, il y a les informaticiens qui :

-         ne connaissent pas le métier du client donc ne sont pas à même d’apporter le conseil nécessaire : ils répondent aux demandes,

-         ont tendance à surfacturer, notamment pour se couvrir (mais aussi pour plein d’autres raisons).

Il faut un gugusse pour que les deux se comprennent et pour modérer leurs ardeurs réciproques.