Des hommes, obstacles à la transformation numérique ?

Dès mon premier stage dans une DSI, j’ai été frappé par le cloisonnement existant entre la DSI et le reste de l’entreprise et, surtout, au sein même de la DSI. Même si la bonne humeur règne, dès qu’il s’agit du travail, chacun reste cantonné autour de son domaine métier. Au début des années 90, j’ai travaillé dans une DSI mais pour un industriel. Cette séparation était le même. Actuellement, tous les midis je bouffe dans une brasserie de la défense, cerné par des braves gens travaillant dans des DSI… J’écoute. L’informaticien ignore ce que font ses collègues.

Réussir la transformation numérique nécessite de passer outre ces clivages. Des raisons peuvent paraitre évidentes (efficacité,…) mais les plus importantes ne le sont pas. Chacun se croyant meilleur que l’autre empiète sur le secteur d’activité d’autrui. Je racontais récemment l’anecdote d’un bigboss qui voulait que l’on passe nos machines en client léger sans même savoir réellement de quoi il s’agit.

Toujours est-il que le fonctionnement d’une grosse entreprise ou d’une administration fait que les acteurs

Faisons le tour des fonctions ou des postes autour de l’informatique.

On va partir d’un exemple fictif : la patronne de la Comète veut faire développer un système pour que ses serveurs puissent passer des commandes avec leurs iPhone et que les commandes soient imprimées sur des tickets en cuisine ou au bar. J’insiste sur l’aspect fictif de cet exemple, pour une fois : un bistro ne peut supporter le coût d’un développement et achètera donc des produits clés en main.

Le métier	C’est la personne qui va représenter les utilisateurs principaux de la solution informatique. Dans notre exemple, c’est la patronne du bistro vu qu’elle est également serveuse. Dans beaucoup de projet, c’est la direction marketing vu que les relations avec le client sont en jeu. Généralement, les gens du marketing sont dénigrés parce qu’on ne sait pas ce que c’est. Il s’agit pourtant des braves gens qui définissent « l’offre », c’est-à-dire ce qui génère du chiffre d’affaire.
Les métiers associés	Ce sont les représentants des autres utilisateurs. Dans notre exemple, on aura le barman et le cuisinier qui vont recevoir des commandes sur une imprimante.
Le sponsor	C’est celui qui va payer (ou le représentant des payeurs) et qui prend donc les décisions importantes, à savoir celles qu’il ne peut pas déléguer au métier ou à sa maîtrise d’ouvrage. Dans notre exemple, ce sera le propriétaire du fonds de commerce vu que l’investissement est trop important pour la patronne mais il est très fréquent que le sponsor soit le métier.
La maîtrise d’ouvrage (MOA)	Ce sont les petites mains du sponsor ou du métier, chargées de coordonner le projet, de faire l’interface entre les métiers et l’informatique. Dans notre exemple, cela pourrait être moi : le copain de la patronne qui connait l’informatique et va pouvoir l’assister dans ses relations avec les fournisseurs. Notons que « maitrise d’ouvrage » est souvent perçu comme un gros mot, notamment au sein des DSI et est utilisé de manière générique pour tout ce qui n’est purement informatique. De fait, maitrise d’ouvrage n’est pas une fonction formelle dans l’entreprise.
L’assistance à maîtrise d’ouvrage	Voila un truc qui porte bien son nom. D’une part, les MOA n’ont pas forcément les compétences pour piloter des projets informatiques (voir les méthodes, ci-dessous) et, d’autre part, lors des projets, elles doivent faire face à des surcharges temporaires de travail. Généralement, elles font appel à des consultants mais des grosses entreprises ont des départements spécifiques d’assistance à maîtrise d’ouvrage.
Les méthodes	Les braves des méthodes disent comment doivent être gérés les projets et mettent à disposition différents outils, présentations, modèles,… Je les cite ici pour faire joli mais ils n’interviennent évidemment pas dans le projet sauf en y faisant peser des contraintes pas toujours adaptées notamment pour les projets geeks. Ils sont très souvent rattachés à la DSI.
Le RSSI	Le Responsable de la sécurité des systèmes d’information porte assez bien son nom.
Les pilotes	C’est moi qui les appelle comme ça ! Ce sont ceux qui font fonctionner les applications au quotidien d’un point de vue fonctionnel. S’il faut trouver un exemple, on pourra penser aux types qui font la modération des commentaires sur les sites d’information.
Le juridique, les achats et la communication	Je les mets dans le même panier alors qu’ils n’ont pas grand-chose à voir mais interviennent à différents stades du projet, pour valider les écrans affichés au client, les contrats avec les fournisseurs, la légalité des actions,… On pourrait ajouter les opérations, les RH, le marketing et un tas de braves gens. Tiens ! Dans mon exemple, on change les méthodes de travail (les opérations doivent s’assurer que le travail reste possible, les RH que les serveurs peuvent l’utiliser, le marketing qu’il est bien possible de vendre le plat du jour, les juristes que des informations personnelles des clients ou du personnel ne sont pas stockées,…).
Les auditeurs	Pour résumer, ce sont des gens qui s’assurent que vous travaillez correctement, selon les normes en vigueur dans l’entreprise, selon la réglementation et la législation,…
La maitrise d’œuvre	La MOE représente toute l’informatique alors qu’on l’associe généralement à ce que j’appelle ci-dessous la maîtrise d’œuvre principale. C’est un peu comme si vous pensiez que le maçon est la maîtrise d’œuvre pour la construction d’une maison, il n’en est qu’une partie. Tours les postes ci-dessous sont au sein de la maîtrise d’ouvrage, de même, souvent, que les RSSI (par nature) et les pilotes (du fait du fonctionnement opérationnel, 24h/24, proche de la production informatique, voir ci-dessous).
La maîtrise d’œuvre principale	Celle que j’appelle ainsi est le service qui va porter un projet : coordination, budget, relations avec la maîtrise d’ouvrage, les autres maîtrises d’œuvre. Dans notre exemple, c’est a priori le fournisseur de l’application iPhone.
Les maîtrises d’œuvre associées	Ce sont les autres services de la DSI concernés par un projet informatique, notamment ceux qui ont en charge des développements, comme, dans notre exemple, les fournisseurs des logiciels pour les imprimantes du bar et de la cuisine. Elles n’ont pas de relation hiérarchique avec la maîtrise d’œuvre principale.
Le PMO	Le Project Office Managment qui, en parallèle de la maîtrise d’œuvre principale, comme s’il l’assistait mais avec une certaine liberté hiérarchique, gère le projet, s’assure de la cohérence des plannings, du suivi des actions,…
La direction technique et ses architectes	Ils portent aussi assez bien leurs noms et sont en charge de la définition des socles techniques pour les applications. Tiens ! Dans mon exemple, c’est le type qui va décider si les iPhone vont communiquer avec les imprimantes en Wifi ou en Bluetooth… ou les deux pour permettre d’avoir un circuit de secours si l’un ne fonctionne plus ce qui empêcherait les serveurs de prendre des commandes.
Les architectes applicatifs et urbanistes	Ce sont ses braves gens qui vont s’assurer de la cohérence générale du Système d’Information de l’entreprise. Toujours l’exemple : si un jour, la patronne veut que les iPhone parlent aussi avec les terminaux de paiement et les logiciels de comptabilité, les applications doivent être construites selon des normes et autres machins, dans une cohérence globale.
Les développeurs	Proches de la maîtrise d’œuvre principale ou des maîtrises d’œuvre associées ce sont évidemment ceux qui développent les applications, se basant sur les principes définis par les architectes. Ils sont évidemment très importants, presque les plus importants mais sont un peu perdus dans la masse. Ils peuvent être internes à l’entreprise (ou considérés comme tels s’ils bossent en prestations) ou externes (ce qui implique d’ailleurs une relation supplémentaire, avec des fournisseurs).
Les intégrateurs	Proches de la maîtrise d’œuvre principale ou des maîtrises d’œuvre associées, comme les développeurs, ils assurent l’intégration des différentes couches de logiciels dans l’environnement technique. Proches de la maîtrise d’œuvre principale ou des maîtrises d’œuvre associées Proches de la maîtrise d’œuvre principale ou des maîtrises d’œuvre associées Dans notre exemple, ça serait un peu l’Apple Store.
Les homologateurs	C’est eux qui vont s’assurer que les applications sont opérationnelles et répondent aux besoins des utilisateurs, conformément aux cahiers des charges et autres dossiers de conception élaborés lors du projet. Dans ce tableau, il serait intéressant de multiplier les lignes « homologateurs » puisqu’ils y a différents niveaux : ceux qui testent les applications une par une, tous les cas d’incident possible jusqu’à ceux qui font les tests dans un environnement intégré au SI de l’entreprise.
La production informatique	Dans le monde des blogs, la production informatique serait un peu l’hébergeur. C’est elle qui s’assure que le Système d’Information reste opérationnel 24 heures sur 24, que les serveurs de secours prennent bien la main en cas de panne du nominal, gèrent les incidents pour les transmettre aux maîtrises d’ouvrage.

J’espère que je n’ai oublié personne mais cela importe peu dans la mesure où chaque entreprise aura sa propre organisation.

Vous vous imaginez bien qu’avec un tel bordel, faire avancer des projets n’est pas osé. Le fonctionnement est très lourd mais chaque acteur est important. Imaginons qu’un développeur veuille faire  une application dans une version d’UNIX qui n’est pas l’AIX utilisé habituellement par la boite et donc recommandé – voire imposé – par la direction technique, personne, à la production informatique, ne saura le maintenir opérationnel 24h/24.

Je vais un peu tirer mon exemple par les cheveux mais si l’application pour l’iPhone n’est pas conforme aux normes imposées par Apple (la direction technique), elle sera refusée par l’Apple Store (les intégrateurs). La patronne pourra alors décider de « jailbraker » son iPhone mais elle prend le risque d’avoir un système de prise de commande qui tombe en panne pendant le service, de trouver personne pour faire la maintenance,… Et le coût final sera beaucoup plus important que si elle avait travaillé, avec sa maîtrise d’œuvre, en respectant les normes.

Et c’est tout le défi du numérique ! Faire avec des acteurs souvent réticents. Pourquoi la production informatique devrait-elle gérer un système de gestion de base de données libre alors que son Oracle est au top ? Pourquoi accepterait-elle d’être montrée du doigt pour une augmentation des coûts de production, du fait de la maintenance, en parallèle de deux SGBD, alors que cela ne lui apporte rien ?

Pourquoi le développeur irait-il penser au système de secours alors que c’est la direction technique qui a en charge de le concevoir et la production de le mettre en œuvre ? Pourquoi la direction technique irait-elle faire un système de secours si on ne lui dit pas qu’il faut le faire, que c’est vital pour le service, que le gain est important ?

Reprenez le paragraphe et « inversez les négations ». Pour le développeur ne concevrait-il pas un système de secours puisque la direction technique est un ramassis d’imbécile ? Pourquoi la direction technique ne ferait-elle pas un système de secours alors que si cela tombe en panne, on va lui tomber dessus ?

Bien du courage. La transformation numérique nécessite que tous ces braves gens bossent en même temps.