C’est toujours la faute du réseau

À quoi peut-il bien servir d’avoir toujours un ou plusieurs boucs émissaires sous la main ? J’ose croire que vous ne vous posez pas la question ! Le truc sur lequel vous travaillez peut planter, le projet prendre du retard, et j’en passe. Certes, il faut utiliser une bonne partie de son énergie à remettre le truc en marche – ou réduire les retards –, mais il serait hasardeux de ne pas réserver une partie de cette énergie à un plan B qui tienne la route, et, honnêtement, trouver un coupable idéal fait partie des précautions élémentaires de tout bon professionnel qui se respecte.

D’autant que, pendant que le pauvre gars cherche à démontrer que le problème n’est pas de son côté, il y a des chances que le machin se remette en marche. Et double effet Kiss Cool, si le machin se remet en marche pendant que le gars en question était en train de bidouiller sa partie, on pourra toujours affirmer que c’était bien la preuve que la panne venait de chez lui.

Dans ce petit bijou qu’est l’excellent roman Saint-Germain ou la négociation [1], le négociateur désigné par le roi pour tenter de trouver une issue aux guerres de Religion (on est dans la France du xiv^e siècle et l’épisode a réellement eu lieu) amène avec lui un couillon de service qui n’a strictement aucun rôle dans l’opération (et qui bien entendu ne le sait pas), sauf celui de servir de tête à couper si la négociation échoue avec le camp adverse (qui a aussi son négociateur en chef et son couillon bis). Bref, si on vous convie à une opération du même genre et que vous ne savez pas qui va jouer le rôle du couillon… comment dire… ne soyez pas surpris d’être étonné.

Les projets informatiques, au mieux prennent du retard, au pire échouent : 50 % d’échec selon certaines études, si l’on considère comme un échec le non-respect d’au moins un des quatre critères de base que sont le périmètre, le délai, le budget et le niveau de qualité (dans les faits, je pense que le pourcentage est beaucoup plus élevé, mais les sondés n’ont pas dû oser donner leurs vrais chiffres). Bon, en même temps, ce n’est pas la peine de s’autoflageller : l’informatique existe depuis à peine 50 ans, et je vous rappelle que si le BTP a près de 3 000 ans d’existence, les délais des chantiers ne sont toujours pas respectés. Bref, il faudra bien mettre sur le dos de quelqu’un l’échec ou semi-échec du projet : la MOA incapable de spécifier ses besoins (si vous travaillez à la DSI), la DSI incapable de les traduire en spécifications techniques (si vous êtres à la MOA), le fournisseur incapable de livrer un logiciel qui fonctionne (si vous êtes du côté de l’AMOA), les équipes techniques de la DSI incapables de mettre à disposition les infras pourtant spécifiées dans la réponse à l’appel d’offres (si vous êtes du côté du fournisseur). Sincèrement, il y a l’embarras du choix. Et si vous êtes à court d’idées, il reste le sempiternel « on n’avait pas les moyens humains et financiers pour mener ce projet à bien », c’est tout aussi efficace qu’indémontrable, dans un sens comme dans l’autre.

C’est d’ailleurs à se demander si les méthodes de projets tels Scrum, Agile, Six Sigma, et j’en passe, sont destinées à augmenter la probabilité de réussite d’un projet (on peut toujours rêver) ou simplement à justifier le fait que, s’il plante, cher client, chère MOA, ayez au moins l’assurance qu’il aura planté avec les méthodes les plus modernes qui soient – ouf ! on est tous rassurés.

Bien entendu, quand on échoue, on peut toujours faire appel aux copains, à la bande, à un ami, etc. Dans toute profession, le réseau est certainement ce qui est le plus important. Mais parfois, même le réseau ne vous aide pas. Quand je vous dis que c’est toujours la faute du réseau !

[1] Saint-Germain ou la négociation, Francis Walder, Gallimard, 1958.