5 SI …politique

En tant que chef adjoint du département SI, je découvrais donc que le SI n’est pas qu’une simple affaire technique mais aussi une affaire économique et politique.

Avoir des vues stratégiques, bien fondées, sur le développement du SI ne suffit pas ! Il faut en convaincre toutes les parties prenantes : la Direction de l’entreprise, certes, mais aussi ce qu’il est convenu d’appeler les « métiers » et en tout premier lieu, leurs responsables. Le développement du SI en entreprise n’a de sens que si l’entreprise y voit son intérêt, sur le plan économique, à l’évidence, mais aussi sur les plans organisation et politique interne.

Au premier abord, le plan économique paraît facile à aborder : après tout, comme pour tout projet, on peut chercher le BiKet (Business Case !) d’un projet informatique.

On calcule son coût de réalisation - l’investissement initial -, ses coûts récurrents une fois le projet réalisé, et on compare aux recettes attendues. Si le ROI est au rendez-vous (Return on Investment), on y va…

De fait, progressivement, nous avons été amenés à formaliser la façon des monter les BK selon les types de projets informatiques.

Deux types de projet informatiques ont été pris en compte : les projets applicatifs dits métiers, et les projets dits d’infrastructure.

Les services d’infrastructure sont en fait des services mutualisés pour les applications ; serveurs, stockages mutualisés, réseaux…
Je ne détaillerai pas la façon de calculer les coûts d’investissement et les coûts récurrents d’un projet. Même si ce n’est pas toujours simple, c’est en général connu.

Mais les recettes ? En théorie, ce n’est pas compliqué, et il ne manque pas de bons auteurs pour gloser sur le sujet. On peut représenter la chose sur le schéma comme ceci :.

Pour évaluer les recettes d’une application métier, on va d’abord prendre en compte les gains (éventuels) sur l’exploitation de l’application. Si, si ça arrive, car les vieux bouzins finissent par coûter très cher et leur remplacement peut faire gagner de l’argent.

Mais le poste principal de recette réside en générale dans ce qu’il est convenu d’appeler les « gains métier ». J’en reparlerai.

Pour tout ce qui sert de support mutualisé aux applications métier, c’est un peu pareil.

L’exploitation d’une nouvelle infrastructure en remplacement d’une ancienne peut être très rentable, du fait des progrès continus de l’informatique qui conduisent à des matériels et des services plus performants pour des coûts inférieurs. Là aussi, ce sont surtout les gains pour les services supportés qui vont en général être les plus importants : les coûts récurrents des applications baissent. Mais il peut y avoir aussi des gains métier, plus difficiles à appréhender, du fait d’une meilleure disponibilité et d’une meilleure efficacité des applications.

Tout ça semble simple. C’est quand on commence à essayer de calculer tout ça que ça se complique.

D’abord, il y des applications qui sont difficiles à classer, et à vrai dire elles sont un peu intermédiaires entre les deux types précédents. Ce sont les applications qui sont transverses à l’entreprise, qui servent souvent aux applications, mais qui sont aussi tournées vers l’utilisateur dit final. Exemples : la messagerie d’entreprise, le poste de travail (quelle qu’en soit la forme : PC, tablette, smartphone), les RSE (réseaux sociaux d’entreprise). Et là, commencent les problèmes : si les gains d’exploitation pour une renouvellement d’application sont évaluables, c’est un acte de foi que d’évaluer les gains de productivité pour l’entreprise d’un RSE, ou d’une amélioration des postes de travail. Quelques minutes par jour gagnées, même multiplié par le nombre de salariés, ne convainc généralement pas les financiers. La disponibilité de salariés équipés de postes mobiles, tablettes ou smartphones, idem en général. Quant au RSE, les gains de créativité ou nés d’un travail plus transverse …

Mais en fait les gains métier, ne sont pas si faciles à évaluer non plus. Et le ROI sujet à caution. D’abord, il convient de rappeler ce qui devrait être une évidence : il n’y a pas de projet informatique métier. Il y a des projets métier avec une composante informatique et obligatoirement une composante métier : en général les processus métier sont impactés, et il y a des coûts de transition à prendre en compte. Insertion métier est un mot faible à cet égard (formations, reclassements, réorganisations…).

Et pour un projet métier identifié, il n’y a pas qu’une solution informatique : avec différents curseurs comme le degré d’automatisation, la facilité d’utilisation…

Le BiKet ne peut être que global au niveau du projet métier et les différentes alternatives se doivent d’être étudiées dans ce contexte global.

Cela signifie aussi que la maîtrise d’ouvrage d’un projet informatique métier ne peut être que subordonnée à la maîtrise d’ouvrage du projet métier : le projet informatique est un lot, qui peut très important, du projet métier. Faute d’avoir compris cela, combien de luttes intestines à l’entreprise ont lieu entre « l’informatique » et « le métier ».

Encore faut-il que le « métier », souvent très éloigné de la sphère informatique soit structurée pour décider et conduire ces projets à composante informatique.

Une des choses dont je suis fier, lors de mon passage à RTE, a été l’institution de programmes métiers, présidés par des décideurs du métier ; les commanditaires. Ces programmes géraient les projets, mais suivaient aussi l’ensemble des dépenses induites par l’utilisation de l’informatique. Ils avaient dont en principe tous les éléments pour optimiser les dépenses informatiques au sein du budget global métier.

Tout irait pour le mieux si cette logique n’était pas régulièrement battue en brèche par les financiers. Dans un contexte économique tendu, ceux-ci n’acceptent pas en général la hausse continue des dépenses informatiques … pourtant quasi inéluctables, du fait de la substitution croissante de la puissance informatique au travail surtout tertiaire. A production équivalente, la part du travail baisse dans le produit final, ce qui ne se voit que sur la durée et à condition de raisonner à production équivalente.

Nos financiers, donc, souvent court-termistes, imposent des contraintes budgétaires sur l’informatique prise dans son ensemble. Croissance zéro, voire baisse importante.

De fait, les coûts unitaires de l’informatique baissent régulièrement (5 à 10%) ce qui permet des développement informatiques même avec une croissance zéro des budgets.

Malheureusement, la pression est souvent beaucoup plus forte, à tels que l’on assiste à des paradoxes : le métier a le budget pour faire le projet métier, mais la contrainte sur les dépenses SI fait qu’il est impossible de le mener ! Souvent d’ailleurs le métier se débrouille pour que des dépenses SI ne soient pas comptabilisées en SI. De ce point de vue le développement (inéluctable)  du BAAS (ni Syrien, ni Irakien : Business As A Service) est une aubaine car il masque les dépenses informatiques sous-jacentes qui sont réalisées par le fournisseur du service.

Mais ça j’en reparlerai certainement dans la suite de ma chronique.

4 Le SI ? ! ?

Après une longue interruption due en particulier à la découverte d’activités futiles mais chronophages, et en plein mois d’août, je reprends le cours de mon blog.

Souvenez-vous : j’avais parcouru du Nord au Sud et d’Est en Ouest le continent informatique. J’y avais pratiqué l’activité de chercheur en maths appliquées et en informatique, de concepteur d’applications scientifiques, de réalisateur de logiciels, jusqu’à la mise en production. J’avais été aussi administrateur et gestionnaire de réseaux de stations Unix et de PC.

Côté savoirs et expériences, j’étais parti des froides contrées de l’informatique théorique, de la complexité des algorithmes, de l’IA, pour me frotter à la recherche opérationnelle. Non sans avoir développé de solides bases en langages et compilation, en Systèmes Informatiques.

De là j’avais fait des incursions poussées sur le temps réel, le contrôle-commande, les protocoles réseaux. Dans le même temps j’avais exploré la jungle des méthodes de modélisation et la fabuleuse contrée de l’Orienté Objets (méthodes, langages, BD). Le passage d’un schéma « entités-relations » à un schéma relationnel n’avais plus de secrets pour moi, mais la façon de mettre ça à la sauce « objets » restait un peu floue.

Bref, je me prenais pour l’honnête homme informaticien du vingtième siècle.
Par ailleurs j’avais l’impression de commencer à tourner en rond à la Direction des Études et Recherches, de n’avoir guère de nouveaux terrains à défricher.

Aussi, dès que l’opportunité s’en présente, je rejoins le germe du SI, à la Mission Système d’Information du GRTE (Gestionnaire du Réseau de Transport d’Électricité).  André Merlin y constituait le futur RTE, contre vents et marées. C’était une période un peu héroïque, avec une espèce de guerre des tranchées entre la Direction Production Transport et le futur RTE.

Et c’est là que je découvre le SI, que naïvement je prenais au début pour une déclinaison plus « mode » de SI que Systèmes Informatiques.

Bon, j’avais bien en tête une définition à la Wikipédia : « Un système d'information (SI) est un ensemble organisé de ressources qui permet de collecter, stocker, traiter et diffuser de l'information. Il s'agit d'un système socio-technique composé de 2 sous-systèmes, l'un social et l'autre technique. Le sous-système social est composé de la structure organisationnelle et des personnes liées au SI. Le sous-système technique est composé des technologies (hardware, software et équipements de télécommunication) et des processus concernés par le SI ». Mais cela reste un peu abstrait.

Toutefois, un point important me semble manquer dans la définition ci-dessus : la vue Information. Les flux de données support de l’information de l’entreprise, les référentiels et les stockages d’information, l’analyse précise de la transformation des informations dans les divers processus de l’entreprise. Bref, au-delà de la tuyauterie, et des réservoirs, qu’est-ce qui circule et se transforme dedans. Autrement dit tout l’enjeu des couches hautes de l’urbanisme et des méthodes associées, y compris l’aspect analyse des processus.

À la DER je n’avais guère eu l’occasion de me frotter au « SI ».

• La DER est plus côté scientifique et technique, très peu côté gestion. Or j’ai l’impression que le paradigme SI est plutôt né côté gestion.Certes, javais un peu fricoté avec la gestion. En particulier, membre pendant plusieurs années du bureau du collège GID de l’AFCET (Gestion, Informatisation, Décision), j’y avais côtoyé les illustres pères de MERISE. J’étais donc assez au fait des méthodologies d’analyse des informations. Mais ce n’était pas encore la vision « urbanisme » ou « architecture d’entreprise ».
• Malgré le côté « chercheurs », les activités de la DER sont plutôt de la maîtrise d’œuvre, ou de l’appui à maîtrise d’ouvrage, mais non réellement de la maîtrise d’ouvrage : c’est le « business » qui décide de son SI et qui est « propriétaire » des informations qui y circulent.

A la mission Système d’Information, je plongeais donc dans une vision Maîtrise d’Ouvrage, au côté des acteurs clefs du business, qui se développait vers les activités de marché de l’énergie électrique. Et il fallait se préoccuper aussi bien des contenus informationnels que des contenants à créer, presque « from scratch ».

Le RTE se développant à côté d’EDF, pour ne pas dire contre, c’est aussi tous les aspects politiques et organisationnels du SI auxquels je me trouvais mêlé, en tant que chef adjoint du nouveau Département SI. Mais … la suite au prochain numéro.

Les cent fleurs !

Après une année en tant qu’officier travaux au cinquième Génie à Versailles, il était temps de chercher un emploi.

Je tombe sur une annonce de la Direction des Études et Recherches d’EDF pour un poste d’ingénieur en planification des réseaux. En plein mois d’août je postule. Je suis reçu illico par Jean Bergougnoux, alors Chef de Service Adjoint au Service Études De Réseaux, puis par André Merlin alors responsable d’une des divisions du département Méthodes d’Optimisation. Ma spécialisation en Recherche Opérationnelle et en Informatique, plus ma thèse en IA, a dû leur taper dans l’œil.

En tant qu’ingénieur chercheur, je me mets à ravauder et à développer des logiciels d’optimisation de réseaux électriques, pour la planification ou l’exploitation.

Je réalise en particulier un logiciel, Corali, bourré d’heuristiques complexes, avec en particulier un interpréteur d’interpréteur des paramètres d’heuristique. Toujours plus féru d’informatique, j’y instille certains paradigmes de la programmation « robuste » : vérification d’invariants, de pré et post conditions, zones de contrôle, « blocs de recouvrement » (mauvaise traduction de « recovery blocks »). 

Il faut dire que je n’avais que Fortran sous la main, dont je poussais le compilateur dans ses derniers retranchements. Une des caractéristiques désagréables de l’implémentation de ce langage sur IBM 360 était l’aisance avec laquelle on pouvait générer des écrasements mémoire des données et même des instructions. 

Devenu débuggeur hors pair, je tombais sur au moins sur deux erreurs du compilateur. Cela m’a couté quelques jours et nuits de recherche, penché sur les dumps et le code assembleur généré par le compilateur.

Au bout du compte le programme était d’une fiabilité hors pair et fut utilisé pendant une dizaine d’années. Quasiment sans maintenance du cœur ! Et pour une mauvaise raison ! J’avais fait quelque chose de si compliqué qu’il était pratiquement impossible de le maintenir… Cela me servit de leçon ; « keep it as simple as possible » ; on écrit un programme pour une machine, mais il ne faut pas oublier ceux qui viendront derrière.

Pour me racheter, je créais à la DER, le GOM (Groupe Outils et Méthodes), une sous-commission de la commission interservices Génie Logiciel. C’était la grande époque des premiers projets d’AGL (ateliers de génie logiciel), ce qui m’a permis de rencontrer plein de monde hors d’EDF. La quasi-totalité de ces ateliers sont morts en bas âge, à peu près en même temps que le « plan calcul ».

Après d’aussi bons débuts, on me confia la responsabilité, au sein du Service Études De Réseaux, du petit groupe AISE : Algorithmes, Informatique et Systèmes Experts.

Il faut dire, qu’au milieu des années 80, la DER découvrait enfin « l’Intelligence artificielle ». S’ensuivit une période frénétique : une dizaine d’équipes réalisait une centaine de systèmes experts ou d’intelligence artificielle. Une équipe reconstruisait un moteur d’inférence pour des raisons bonnes ou moins bonnes (il y en avait déjà un tas sur le marché).

Des méthodologies sophistiquées étaient utilisées pour essayer de capturer l’expertise des experts, de créer des ontologies… las ! Les cent fleurs fanèrent assez vite car l’expertise que l’on figeait dans les systèmes était toujours trop limitée. On était très loin de Watson… et de sa capacité à « analyser » des millions de pages.

À ma connaissance, seuls deux systèmes, initiés dans mon équipe au début des années 90, ont survécu… puis ont enfin été utilisés, au bout d’une vingtaine d’années dans un système d’aide à la conduite des réseaux moyenne tension, accolé à un système de conduite lui aussi issu des travaux de mon équipe. Finalement, tout arrive ! Mais j’étais déjà ailleurs.

À noter en parallèle : à peu près contemporaine de la vague des AGL, des « SE », la programmation « objets » ; ce qui avait été moi l’occasion de créer un nouveau groupe, le GLOO, qui outre les langages cultivait également les Méthodes Orientées Objets, les BDOO… 

C’était aussi l’époque où apparaissaient les stations de travail : mon équipe mis sur pied un des tout premiers réseaux de station de travail à la DER. Très vite cela fit tâche d’huile. On était en plein down sizing : pour un coût 10 à 20 fois moindres on arrivait mieux, plus efficacement, et plus agréablement pour l’utilisateur, que ce que l’on faisait sur les IBM360 de la DER.

Après tout cela, quelques années en tant que consultant senior auprès la direction du Service Études de Réseaux, à auditer projets et architectures informatiques. Puis encore quelques années à diriger le groupe qui réalisait pour la Direction de la Distribution le « Poste de Contrôle Commande Numérique ». L’occasion pour moi de découvrir le monde foisonnant des réseaux de communication informatiques et temps-réel, avec leurs empilements de protocoles.

La prochaine fois, un nouveau monde : « le SI » !