Passer au contenu

Mon organisation est un spaghetti

Par nature, une organisation chargée de créer du logiciel est chaotique. En se penchant sur les modèles théoriques, au pire, on n’y comprend rien, et, au mieux, on ne voit pas le lien avec la réalité. Normal, la réalité est bien pire.

En plus d’apporter des sucres lents, les spaghettis symbolisent l’une des images les plus hurlantes du langage informatique. Je ne parle pas de leur représentation la plus terre à terre, ces enchevêtrements de câbles qui rendent le ” cul ” du PC si attrayant. Je ne parlerai pas non plus des systèmes logiciels spécifiques, montés sur du progiciel, interfacés avec d’autres spécifiques, eux-mêmes représentant des émulations bancales d’applications anciennes, le tout pour simuler le fonctionnement d’un logiciel qui n’est plus utilisé.Bon, alors, de quoi je vais parler ?Le meilleur spaghetti qui soit, c’est le spaghetti sociologique de l’organisation. Expression faussement pompeuse pour décrire l’ensemble des effets de bord, des perturbations, des contradictions inimaginables qui peuvent avoir lieu au sein d’un projet. De ce point de vue, les organisations dévolues au développement logiciel (chez les éditeurs comme dans les entreprises qui peuvent se payer des développeurs) constituent une sorte de modèle du genre.Le plus difficile, c’est de savoir où est son extrémité, à ce spaghetti. Est-ce le chef de projet, déjà bien entamé par ses obligations de plus en plus démesurées ? Peut-on aborder le problème du point de vue de la maîtrise d’ouvrage, puisqu’elle se veut désormais centrale ? Ou peut-être de l’urbaniste, ce nouveau polarisateur d’énergies, à la fois fin abstracteur et modélisateur génial… A défaut d’autre chose, partons du client et de ce qu’il veut, c’est la mode. Accrochez-vous bien, le paragraphe suivant est compréhensible mais difficile à digérer.Classiquement, un projet démarre donc avec un client. Il donne une lettre de mission ou de cadrage à un chef de projet, lequel lui retourne ses premières estimations. Il échange en parallèle avec des spécialistes métier afin de s’entendre sur les objectifs à atteindre par le logiciel. Ceux-là nous font pénétrer au c?”ur du système en fournissant les besoins initiaux à l’urbaniste et aux développeurs. Les développeurs rendent alors compte à la fois à l’urbaniste, pour les solutions validées, aux spécialistes métier, pour proposer des solutions, aux responsables d’intégration et, éventuellement, au responsable de la réutilisation. Ajoutez par-dessus tout ça un responsable de processus, que l’on va se contenter de faire communiquer avec l’urbaniste ; un responsable qualité, chien de garde prévenant les développeurs et équipes d’intégrations sur les risques qu’ils encourent…Vous aurez remarqué que chaque acteur de ce projet fictif peut revendiquer un statut d’artiste. Au final, le chantier reviendrait à faire collaborer sur un plat unique Bocuse, Coffe, Maïté et ma grand-mère. Même sans tenir compte des sensibilités gustatives, vous obtenez le début d’une idée de l’embrouillamini qu’un système théorique, pourtant supposé parfait, peut engendrer.Comme disait récemment le directeur informatique d’un grand groupe ?” en fait, il se lamentait : “Si la théorie d’une organisation est complexe, la réalité est pire encore !” Traduction : notre bel et incompréhensible plat de spaghetti est en plus très pimenté.Une fois de plus, les modèles, les règles ou les meilleures pratiques ne changeront rien. L’informatique, et particulièrement le développement logiciel, couve le chaos et on ny peut rien. On peut juste rendre son goût plus agréable.Prochaine chronique lundi 16 juillet

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Philippe Billard