Introduction

L'investissement dans une infrastructure informatique résulte d'un compromis entre coût, risque et innovation, le tout au service des affaires de l'entreprise. La bulle internet a montré qu'une réussite technique résultant d'un investissement dans des innovations coûteuses pouvait entraîner la chute pour des entreprises lorsque cela ne servait pas leurs affaires (en l'occurence pour les entreprises qui n'avaient pas su inventer un business model permettant d'exploiter ces investissements). Inversement, pour rester dans le même domaine, toutes les agences de voyage qui n'ont pas investi dans ce nouvel outil semblent condamnées à court terme.
Généralement, l'investissement dans une infrastructure nouvelle est moins visible et moins immédiatement impactante. Il n'en demeure pas moins qu'une entreprise peut traîner comme un boulet silencieux un système d'information qui agirait comme un frein et non comme un facilitateur.

Le processus de gestion de l'infrastructure" adresse directement quatre processus :

• Conception de l'infrastructure du SI
• Déploiement
• Production
• Support

Conception de l'infrastructure du SI

Analyser, synthétiser, conduire le changement

Planifier l'évolution de l'infrastructure du SI est une charge lourde (et périlleuse). Elle nécessite une vision globale et une très grande capacité d'analyse stratégique :

• Quels sont les objectifs et visions stratégiques des décideurs ?
• Quels sont les objectifs et visions stratégiques en terme de business plan ?
• Quels sont les objectifs et visions stratégiques de l'infrastructure actuelle du SI ?
• Quels sont les objectifs et visions stratégiques en terme de services informatiques offerts aux utilisateurs ?
• Quels sont les possibilités actuelles du sI (des points de vue techniques, organisationnels et des processus) ?

De cette analyse découleront entre autres un état des lieux, une mise en parallèle du schéma directeur de la DSI avec celui de l'entreprise, une vision claire permettant de manager les hommes mais également, permettant de faire comprendre l'importance de l'informatique pour l'entreprise (loin du simpliste "l'informatique coûte trop cher") voire d'initier de nouveaux marchés (cas de l'e-commerce - pour ceux qui ont vu juste !).

Un processus au coeur du métier du DSI

L'ICT infrastructure management est un volume ITIL nettement orienté vers la définition des processus d'entreprise et le management des hommes. On y insiste sur l'importance du recours aux audits, campagnes de benchmarking, compréhension de la façon de fonctionner des organisations, de la culture d'entreprise, de la planification, de la qualité des services rendus, des compétences internes, des impacts technologiques, géographiques et environnementaux, de l'environnement industriel ou du marché.
ITIL fait référence à des méthodes d'analyse communes telle le SWOT : Strengths (points forts de l'entreprise), Weaknesses (faiblesses connues), Opportunities (toute modification de l'environnement peut être un élément favorable), Threats (une modification ou une tendance peuvent également être une menace).

L'analyse doit permettre de :

• Permettre de préciser la vision globale
• Permettre de définir les objectifs clés
• Permettre de définir une stratégie
• Permettre d'en déduire un plan de mise en oeuvre (projets)
• Permettre de contrôler l'avancée de ce plan

Ce processus est au coeur du métier du DSI et en illustre toute la complexité. Exercer une telle responsabilité implique de maîtriser les métiers de base de l'entreprise tout en maîtrisant ceux de l'informatique, d'avoir une vision globale sur son marché ainsi qu'une vision de celui de l'informatique, de réussir à communiquer aussi efficacement avec les directions de l'entreprise qu'avec ses techniciens. Il en résulte généralement une grande hésitation lorsqu'il s'agit de recruter un nouveau DSI : sera-t-il un homme de l'art capable de comprendre l'entreprise ou un homme de l'informatique capable de se faire comprendre de ses équipes ? Assurément un homme d'expérience et de terrain, loin d'un gestionnaire "standard".

On remarquera qu'en terme de communication, le schéma précédent induit deux niveaux de complexité :

• horizontalement, la communication se fait entre un acteur "métier" de l'entreprise et un informaticien et tous deux ont de fortes chances d'utiliser des jargons différents
• verticalement, la communication se fait entre des managers et des acteurs techniques, et cette fois la difficulté se situe au niveau de la vision du périmètre d'action : objectifs de l'équipe ou personnel pour les acteurs techniques, objectifs plus globaux pour les managers.

Le DSI a tout intérêt à se donner les moyens de maîtriser sa communication !

On peut regretter ici qu'ITIL en reste un peu au plan des généralités (Cf.§ suivant) et n'aide en particulier pas le lecteur (ou plus particulièrement, le DSI), à comprendre comment se fait le lien entre des éléments généraux et stratégiques (business, processus, organisation) et des éléments opérationnels (normalisation, mesure de la qualité, choix technologiques et outillage, management des équipes et des projets). Or, on constate trop souvent que ce point d'inflexion est très souvent un lieu de grande solitude pour le directeur des systèmes d'information...

Mise en oeuvre de la conception de l'infrastructure du SI

ITIL propose une liste de bonnes qualités de l'infrastructure (technique) :

• simple à utiliser
• modulaire
• extensible
• flexible
• sécurisée
• tolérante aux pannes
• facile à restaurer
• simple pour diagnostiquer son état et à dépanner si besoin

ITIL insiste également sur un point : il faut au préalable établir clairement ce dont le business de l'entreprise a besoin (SOR ou Statement Of Requirements). Quels sont les objectifs généraux des services que l'on veut rendre à l'entreprise ?
Ce point, bien "qu'évident" est très souvent oublié lors de projets de grandes ampleurs. Il n'est hélas pas rare de rencontrer des infrastructures de sauvegarde coûteuses ne permettant pas de produire un type de sauvegarde/restauration spécifique (mais essentiel), ou des dispositifs dits "à tolérance de panne et continuité de service" (type cluster) qui génèrent plus d'interruptions de service la première année de fonctionnement qu'il n'y en aura statistiquement jamais pendant toute la vie d'une machine ! Les grands projets de supervision sont également de bons candidats à de telles aberrations lorsque l'objectif initial est oublié (et les exemples que je cite ici ne concernent qu'un périmètre technique a priori totalement maîtrisé par les informaticiens !).

ITIL insiste peu sur les normes et standards et c'est regretable. Bien que rebutant généralement les lecteurs, les N∓mp;S sont un moyen essentiel d'encadrer l'évolution du système d'information et de le lier à l'organisation et aux processus. Les normes sont la loi de l'entreprise (expressions de la vision stratégique) et les standards les décrêts d'application de cette loi (comment le décliner dans la réalité).
Ils ont également l'avantage de donner un cadre au contrôle de la qualité et sont partie intégrante de la culture et de la mémoire de l'entreprise.

En terme d'outils de conduite générale des changements, ITIL renvoie à des choses connues comme Balanced Scorecard (BSC) de Kaplan and Norton, le Management par les Objectifs (MBO), le SWOT déjà cité, Total Cost of Ownership (TCO). En fait, les outils disponibles sont encore plus nombreux (ROI, NPV, TEI, ...), l'important étant de les maîtriser et de les utiliser à bon escient (pour ne prendre qu'un seul exemple, le calcul d'un TCO varie dans des proportions énormes en fonction des paramètres retenus ou pas et en l'occurence ne vous disent pas si le service est rendu ou pas...).
En terme d'outil pour la gestion de projet, ITIL cherche à promouvoir PRINCE2®.

Déploiement de l'infrastructure

J'ai décidément du mal à être pleinement d'accord avec ITIL lorsqu'il s'agit de gestion des changements. Certes une modification d'architecture peut difficilement s'appuyer sur la gestion "habituelle" du SI (puisqu'on en change), mais je ne vois aucune raison de ne pas la faire entrer dans un processus de gestion des changements général (qui, à mon sens, inclut plus de choses que ne le fait ITIL). Je suis d'accord avec ITIL sur les sous-processus nécessaires, mais pas sur leur regroupement en processus (ce qui n'induit qu'une différence de point de vue, pas de mise en oeuvre, sauf pour la dernière phase avant le déploiement en production).
En particulier, je pense que le processus de gestion des changements doit inclure une étape d'intégration de production, car c'est là que l'ensemble programmes + machines sera transformé en un service, et que ce service à rendre étant de la responsabilité de la production, il doit être intégré par la production ; ITIL reste à une vision développeur (malgré ses efforts pour mettre en avant le service).

Dans le modèle que je propose (et que l'on rencontre très souvent), il y a deux déploiements. Un premier d'un environnement développeur (très largement ouvert aux modifications) vers un environnement contrôlé par la production (i.e. modifiable sous contrôle). Le second passe de cet environnement de pré-production vers la production (ou on ne rejoue que ce qui a été validé en pré-production). La recette utilisateur se fait soit en environnement de développement, soit en environnement de pré-production (plus souhaitable).

Production du service de l'infrastructure

Un nouveau point de divergence avec ITIL : était-il indispensable de distinguer la production des services informatiques utilisateurs et la production des services nécessaires à l'infrastructure. Après tout, la production peut parfaitement être son propre client et appliquer les mêmes méthodes. Son contrat de service (SLA) sera simplement la résultante des exigences maximales de tous les SLA contractés par ailleurs.

Support du service de l'infrastructure

Même remarque qu'au paragraphe précédent : était-il indispensable de distinguer le support aux services informatiques utilisateurs et le support aux services nécessaires à l'infrastructure ? Je pense que non.