Une gouvernance informatique disruptive

Préambule

Il y a 30 ans, lorsque je finissais mon cycle d’ingénieur en Électromécanique, je ne me doutais pas que j’allais passer toute ma carrière dans les labyrinthes des Directions des Systèmes Informatiques (DSI) des entreprises. Durant ces années, j’ai travaillé comme consultant indépendant sur des missions opérationnelles, organisationnelles et de gouvernance.
Même si ces expériences étaient d’ordre technique, ces années m’ont permis aussi d’avoir une compréhension globale des processus au sein des Directions Informatiques. Mon vernis d’ingénieur me murmurait toujours qu’il fallait trouver des solutions aux problèmes et non apprendre à vivre avec.
Ainsi, j’ai toujours été en quête d’une efficacité dans mes actions que mes différentes postures ne m’ont pas permis d’atteindre comme je le souhaitais. À cause, peut-être, des contextes, ou simplement parce que je n’étais qu’une pièce des rouages qui peuvent laisser présager l’existence d’équations complexes. J’en était arrivé à ne plus faire confiance à l’explication du dictionnaire du terme efficacité parce que je ne parvenais pas à visionner ces contours dans le contexte d’une Direction Informatique.
Même si je butte sur la traduction du terme efficacité dans le management informatique dans les entreprises, j’ai une conviction qui ne peut se réaliser qu’à des conditions particulières, notamment dans le Challenge, la responsabilisation et la mesure.
Le Challenge est un élément essentiel de la solution théorique optimale, il ne peut y avoir d’efficacité sans disposer de la machine performante dans le sens figuré du terme, capable de produire le bien ou le service avec le minimum de déchets dans le sens LEAN du terme. Une idée individuelle aussi géniale qu’elle puisse être, ne saurait à elle seule être une solution efficace.
La responsabilisation est le principe qui définit à chaque partie prenante son niveau de responsabilité ou d’implication sur chaque choix ou décision. Elle assure la bonne tenue du cadre global qui permettra la maturation des idées pour arriver à la solution théorique puis réelle. Elle permet aussi de capitaliser l’expérience pour faire de mieux en mieux dans le temps par un processus de contrôle à postériori qui en fait partie intégrante.
On dit que ce qui n’est pas mesurable ne pourrait être efficace pour parapher le principe : ce qui n’est pas mesurable n’est pas gérable. La bonne mesure et l’exhaustivité des mesures sont les piliers de ce principe. Il faut que les mesures soient pertinentes mais aussi couvrent entièrement toute la structure.
Nous essayons dans ce livre de matérialiser l’état de l’application de ces principes dans les Directions Informatiques, et de déterminer les leviers existants, ou à créer pour une efficacité incontestable et durable.
Nous proposons avec cet ouvrage une approche de rupture dans la gestion des Directions Informatiques qui prône une stratégie englobant toutes les parties prenantes notamment les strates opérationnelles qui sont la force de production informatique. Un développement particulier est mis sur l’organisation, les nouveaux profils de métiers, d’expertise et les indicateurs de mesures pour y amener l’efficacité. Mais aussi sur les différents cadres de gouvernance qui doivent accompagner ce mouvement pour rendre effective cette efficacité.
Les stratégies des Directions Informatiques sont très orientées sur la maîtrise des coûts avec des résultats très mitigés du fait essentiellement de l’approche top-down assez brutale. Tenter de maîtriser les coûts sans vouloir cerner la chose technique qui est le cœur de la question. Dans ce livre, j’aborde la question autrement : c’est l’efficacité qui amène la maîtrise des coûts comme le développe bien la théorie sur le « Lean Manufacturing (TPS) ». Plusieurs leviers sont détaillés pour amener à la productivité opérationnelle qui de facto aura des incidences positives sur les finances.
Au-delà des grands titres, les parties prenantes ont conscience de la nécessité d’amener plus d’efficacité dans les fonctions informatiques, c’est pour ces raisons que l’on est en transit sur la transformation digitale en attendant de trouver mieux. Cependant, les penseurs des stratégies des entreprises abordent les questions d’une manière très macroscopique et surtout n’abordent pas la question sous l’angle opérationnel sans laquelle il ne pourrait y avoir d’efficacité. L’un des intérêts de ce livre est donc de combler ce gap en prolongeant la stratégie jusqu’aux couches opérationnelles les plus basses, qui représentent le savoir-faire et le savoir transformer.
L’objectif est aussi de faire un livre que toutes les parties prenantes techniques ou non, puissent lire aisément. Il ne faudrait pas que les futurs lecteurs se laissent influencer par les quelques exemples techniques que j’aborde pour simplement poser les contextes. Dans le fond, je cherche juste à interpeller le bon sens et la logique cartésienne de chacun de nous, d’autant que la chose informatique est trop importante pour la laisser seulement entre les mains des techniciens.
J’encourage donc toutes les parties non techniques au sein de la Direction Informatique mais aussi aux autres partenaires métiers qui interagissent avec elle, à prendre le temps d’aller au bout de la lecture. Ils pourront ainsi améliorer leurs connaissances de comment la structure opérationnelle technique fonctionne, quels sont les points importants qui peuvent permettre sa gestion fonctionnelle sans s’embourber dans la technique.
Enfin, d’aucuns pourront penser que l’ouvrage est pessimiste ou trop caricatural parce que les exemples ne sont pas assez édulcorés. Mais au contraire, je suis de nature très optimiste à la limite de la naïveté. Il s’agit juste de bien nommer les choses pour que les solutions aient une chance d’être aussi bien nommées. Je propose donc tout au long de l’ouvrage de nouveaux leviers de rupture pour rendre la Direction Informatique plus transparente et moins complexe pour toutes les parties prenantes.



Introduction

Je viens de finir, il y a juste quelques semaines, une mission de 14 mois dans une PME en région parisienne spécialisée dans le commerce électronique. C’était une mission en tant qu’architecte en cybersécurité. Lors de mon premier jour, j’ai eu à échanger avec des chefs de projets qui m’ont parlé du programme phare du moment qui tenait en haleine toute la Direction Informatique.
Ce programme, qui avait déjà duré deux ans, avait comme objectif de recréer toute l’infrastructure dans un nouvel environnement afin de garantir la sécurité du système informatique, qui aurait pu être compromis à la suite d’une cyber-attaque. Ainsi, l’objectif était de transférer l’ensemble des applications et services de l’ancienne infrastructure vers cette nouvelle, théoriquement plus sécurisée.
Mon sentiment, dès le départ, était que c’était un programme voué à l’échec. Même si je n’avais pas voix au chapitre. Mon état d’esprit permanent durant les mois que j’ai eu a passé sur cette mission : quand est-ce que les dirigeants vont se rendre compte que ce sera une faillite ? Ça a pris presque 12 mois. Le Directeur des Systèmes d’Information a été remercié pour des raisons qui n’ont pas été formellement énoncées. Il y a juste quelques semaines, c’était au tour du Directeur des Infrastructures. Globalement, la Direction Informatique a été décapitée d’une certaine manière.
C’est un projet qui est voué à l’échec parce que le seul moyen de le réussir est en mode big-bang, donc tout migrer en une vague afin de conserver l’étanchéité sécuritaire entre l’ancien et le nouvel environnement. Ce qui est impossible. Le seul moyen réaliste d’y arriver est une migration au fil de l’eau. Donc, un processus dans le temps, où les applications et les utilisateurs sont migrés au fur et à mesure. Dans un tel scénario, qui reste complexe à mettre en œuvre si on veut garder la continuité des services, même en cas de succès, on aura fait sauter l’étanchéité sécurisée entre les deux environnements. C’est le principe des vases communicants.
Malheureusement, des millions d’euros ont déjà été dépensés dans l’infrastructure et des dizaines de milliers de jours de prestation en régie ou au forfait. La totalité du budget, plus des rallonges, ont été consommés. Il reste deux infrastructures dont l’une est dans l’état de l’art avec les technologies à la pointe entre autres : Openshift, Nutanix, Containérisation, etc. Mais cette infrastructure n’apporte rien fonctionnellement aux métiers.
Par ailleurs, les applications au cœur du métier de commerce électronique ont un retard technologique d’au moins une quinzaine d’années. Elles ont réellement besoin d’un grand programme de transformation avec tous les moyens qui sied. Malheureusement, l’essentiel des ressources financières et humaines ont été mobilisées sur la partie infrastructure. De toute manière, il n’est pas possible d’avancer sur les questions applicatives sur une infrastructure non stabilisée, alors que ces applications sont la raison d’être de l’entreprise.
Ce cas typique résume la problématique au cœur des Directions Informatiques qui tourne autour de ces trois points :
Les dirigeants sont généralement changés sur un cycle de 3 à 5 ans d’où une instabilité au niveau stratégique, sans que l’on essaye d’analyser les causes profondes.
Les choix stratégiques ne sont pas assez discutés, soupesés et contrôlés.
Il y a trop d’obsolescence sur les applications métiers.

J’essaye, à travers ce livre, d’analyser les causes premières de cette problématique pour proposer des solutions de rupture (disruptive). À ce jour, la seule qui est proposée est le changement des hommes quid de l’organisation. Je suis passé par ces étapes de réflexion avant de me lancer dans ce projet de livre qui est un point de capitalisation de 30 ans d’expérience dans l’informatique, après un parcours très atypique qui a commencé par un cycle d’ingénieur en génie mécanique au Sénégal.
J’ai fait mes débuts en tant qu’administrateur système et réseau au Sénégal où le scope du travail d’informaticien est tellement large que le bon fonctionnement de la machine à café relève parfois aussi de notre responsabilité. Puis, j’ai fait du consulting dans des domaines aussi variés que l’architecture d’entreprise, la gestion de projets et l’élaboration de schémas directeurs informatiques dans les grandes administrations africaines. J’ai ainsi eu à parcourir une bonne dizaine de pays d’Afrique durant cette période de dix ans, avant que le hasard ne m’amène à Paris en 2006, dans le cadre d’un partenariat.
Cette étape m’a permis de renforcer mon expérience technique dans la conception et l’administration des infrastructures informatiques d’envergures notamment sur des postes d’administrateur de niveau 3, d’architecte et de chef de projet technique, dans des grands groupes du CAC 40. J’ai aussi renforcé mon expérience pratique par une série de certifications dans des domaines techniques, de management des projets et de l’organisation de l’opérationnel informatique.
J’ai aujourd’hui la volonté de partager cette expérience parce que d’une part, il y a très peu de contributions intellectuelles des acteurs techniques dans la pensée des stratégies informatiques des entreprises. D’autre part, parce que l’avènement de la transformation digitale requiert de faire de l’informatique d’entreprise autrement tout en évitant de tomber sur les mêmes erreurs, en faisant appel à nos expériences.
Dans cette perspective, j’essaye toujours de confronter mon expérience à celle de mes pairs. Je constate généralement une convergence sur les problèmes de fonds qu’il y a sur l’organisation opérationnelle des Directions Informatiques. Même si la différence dans nos profils et nos expériences se reflètent dans les pistes de solutions pour chacun de nous, qui couvrent un spectre assez large. Les conclusions restent les mêmes. Cet ouvrage se veut donc, outre le partage de mon expérience, être un point de synthèse de mes différents échanges avec des collègues qui ont, comme moi, passé une bonne partie de leur vie dans l’opérationnel des systèmes informatiques d’entreprises.
En faisant le tour de l’état de l’art dans l’élaboration des stratégies, j’ai parcouru des études et ouvrages très intéressants sur la stratégie d’entreprise, plus spécifiquement sur la stratégie du management des systèmes d’information, et également sur les concepts d’amélioration continue des performances. Le livre « Enterprise Architecture As Strategy » se fonde sur un nombre impressionnant d’études de cas et d’enquêtes sur plus d’une décennie. J’ai trouvé de nombreux points de convergence sur les problématiques, un peu moins sur les causes et encore moins sur les préconisations. Cela est certainement dû à mon « handicap » d’être trop imprégné par l’écosystème opérationnel. C’est une bonne base pour renforcer mes idées ou les challenger en restant sur le postulat de capitalisation des idées pour faire avancer. Je vais donc solliciter quelques auteurs ou concepts tout au long de ce livre.
C’est ce concept d’amélioration continue que développe le « Lean Six Sigma » qui est la rencontre de deux méthodes d’amélioration continue, qui est destiné à accroître la performance de l’entreprise. Le Lean Manufacturing repose sur l’élimination de tout ce qui est superflu ou facteur générateur de déchets dans la production. Alors que le Six Sigma repose sur l’élimination des variations sur les produits qui peuvent notamment augmenter les taux de défectuosité.
Le Lean Manufacturing ou Lean Production, est un concept développé à l’origine par « Toyota Motor Company » sous le nom de Toyota Production System ou TPS. Il est basé sur six grands principes que sont : la valeur, la chaîne de valeur, l’élimination du gaspillage, le flux, la traction et la perfection. Le principe sur lequel nous allons nous attarder dans notre argumentaire est surtout l’élimination du gaspillage, notamment sur sa déclinaison en surproduction, reprise et surtraitement. Sans être encore dans le vif du sujet, j’entrevois des points de convergence par rapport à notre sujet.
La Méthode Six Sigma a été développée en 1986 chez Motorola, mais elle devient populaire dans les années 1990 lorsque General Electric commence à l’appliquer, puis à l’améliorer. En termes techniques, cette méthode consiste à faire en sorte que les éléments d’un processus de production restent dans un intervalle 6 sigma (écart type) par rapport à la moyenne générale des éléments issus de ce processus. En maîtrisant la variabilité des processus, on réduit le risque que le produit (ou service) soit rejeté pour non-conformité par rapport aux différentes exigences. C’est donc produire juste dès la première fois en éliminant les coûts liés aux retouches, recyclage, mise au rebut, etc. D’une manière succincte, elle repose principalement sur les notions de client, processus et mesure.
La convergence des deux méthodes repose en partie dans la mise en place de systèmes de mesures performants afin de suivre les déviations liées aux déchets, les surcoûts, défauts, etc. J’ai entrevu à travers les littératures parcourues sur ces sujets, comme d’autres l’ont déjà théorisé, une possibilité de transposition de ces méthodologies dans la gestion quotidienne des Infrastructures Informatiques par l’utilisation d’éléments de gestion et de mesure qui ont atteint un niveau de maturation élevé dans le secteur manufacturier. Je ferai ainsi beaucoup référence aux règles issues de ces méthodes, toujours dans l’objectif de les contextualiser par rapport à mon expérience et dans le souci d’affiner mon analyse de ces concepts.
Il s’agira de voir les possibilités de renforcer la visibilité dans la gestion opérationnelle informatique par la fiabilisation d’indicateurs de mesures quantitatives, qui permettront de suivre les impacts positifs du cadre organisationnel de rupture, que je propose dans une perspective de rendre plus efficace la Direction Informatique dans sa globalité. Cela à travers principalement l’efficacité de la construction et l’administration de l’infrastructure informatique orientées sur les métiers de l’entreprise. Ce cadre organisationnel va poser un changement de paradigme dans la structuration des équipes, la transversalité des profils techniques, ainsi que dans la gouvernance technologique.



Contexte

L’élément contextuel sur lequel nous ne faisons pas assez attention dans l’écosystème informatique de l’entreprise, est l’impossibilité de développer des stratégies pérennes du fait de l’instabilité des équipes dirigeantes des Directions Informatiques. Cet état de fait à un impact négatif sur les activités de construction d’abord, mais aussi sur notre capacité à développer des solutions sur les problèmes structurels des organisations informatiques.
À ce jour, le principal levier utilisé par les directions des entreprises pour montrer leurs insatisfactions sur les activités informatiques, est de changer l’équipe dirigeante de la direction informatique et plus particulièrement son directeur (CIO). Mais le cycle est tellement accéléré (tous les 3 à 5 ans) que ça ne fait qu’accentuer l’instabilité, et on ne se pose pas assez la question : est-ce un problème de personnes ou organisationnel ? On a tellement vu de cycle passé qu’il est temps d’essayer d’autres solutions parce que le changement des personnes ne donne pas les résultats escomptés.
Pour revenir sur le cas pratique, évoqué en introduction, la mission récente dans cette PME spécialisée dans le commerce électronique. Une petite rétrospective sur les dix dernières années, des mouvements sur le poste de directeur de l’informatique, fait apparaître que quatre CIO ont occupé le poste, notamment le dernier, il y a juste quelques mois. Chaque changement de CIO s’accompagne évidemment d’une nouvelle stratégie et potentiellement une réorganisation des équipes. Cette fréquence de changement n’est soutenable pour aucune organisation fut elle informatique. Selon mon expérience, nous sommes plus dans la règle qu’un cas exceptionnel.
…