Les composantes du processus de gestion des applications

Introduction ITIL fait une nette différence entre la gestion du service et la gestion d'une application. Le second inclut le déploiement, la production courante, le support et l'optimisation alors que le premier considère le cycle complet de l'application (phase de développement comprise et production du service). Il faut noter l'importance de ceci : la pratique courante constatée est de considérer que la phase études / développements est la phase "noble" voire la seule qui compte et qu'une fois cette étape passée, il ne "reste plus qu'à livrer" un paquet à la production qui s'en débrouillera. On n'insistera jamais assez auprès des chefs de projet sur le fait que ce qui est demandé n'est ni un programme ni une machine, mais un service rendu par un ensemble de composants informatiques et humains. La différence n'est pas que philosophique.

Cycle ITIL de gestion des applications :

Gestion de la valeur du métier de l'entreprise

Depuis son origine, l'informatique d'entreprise a une tendance marquée à considérer qu'elle ne travaille que pour elle-même. Il n'est pas naturel à un informaticien de penser son activité en tant que "bailleur de logement", "banquier", "assureur", ... L'informaticien se voit principalement comme un technicien ayant une appartenance à une chapelle très limitée. Cette myopie prononcée est généralement source d'incompréhension car le technicien fier de son art n'arrive pas à comprendre les choix de son management et encore moins à le relier à un choix stratégique d'entreprise.
ITIL insiste sur la nécessité de réconcilier l'informaticien et son entreprise : "It is not technology itself that supplies returns to a business, but how technology is employed to meet business requirements."
J'ajouterais que j'ai pu remarquer que ce phénomène de "fascination technologique" touche souvent les maîtrises d'ouvrage elles-même. En effet, alors qu'elles partent d'objectifs métiers (mieux gérer les relations avec leurs clients, augmenter le secteur géographique de leurs activités, ...) elles en arrivent trop souvent à la question du meilleur logiciel, du langage de programmation "à la pointe",... jusqu'au jour où le meilleur logiciel et le meilleur langage n'arrivant pas à rendre le service métier qui était à la base de leur démarche, elle s'y intéresse à nouveau, mais trop tard hélas pour la performance de leur business.
La dérive technologique est un mal contagieux...

Les relations entre vue stratégique de l'entreprise, schéma directeur de la DSI, organisation de la DSI et technologie de cette même DSI vont déterminer le rôle stratégique de l'informatique pour l'entreprise : suiveur (voire frein au développement), centre de profit, et dans le meilleur des cas, initiateur ou créateur d'affaires.
La période e-business des années 2000-2001 a bien illustré ces aspects : un écart immense s'est créé entre les sociétés qui ont su inventer un commerce qui n'hésistait pas (google, amazone, voyagistes, ...), ceux qui ont investi pour de pures raisons d'image (et qui ont du arrêter l'expérience), et ceux qui se sont accrochés tant bien que mal à une vague de fond tout en ne sachant pas bien faire la différence entre la nouveauté technologique (sans intérêt en elle-même) et une nouvelle réalité économique. Les échecs et les succès de cette période montre l'importance fondamentale du rôle de directeur des systèmes d'informations dans une entreprise.

Une stratégie DSI en accord avec les objectifs commerciaux de l'entreprise et son organisation

Il y a bien des façons de faire échouer un projet et les informaticiens semblent s'être fait une spécialité de les redécouvrir toutes... Que se soit par optimisme, fascination technologique, désintérêt pour la stratégie des directions générales ou tout simplement orgueil, on rencontre encore beaucoup trop de système d'information qui se noient dans les problèmes qu'ils s'auto-génère au détriment des services qu'ils sont censés rendre. ITIL insiste sur la nécessité d'aligner la technologie et l'organisation de la DSI avec les besoins et capacités réels liés aux affaires de l'entreprise. Ceci est vrai aussi bien en phase de conception que plus tard en phase de production ou de maintenance.
Il faut également noter que ce n'est pas parce que l'on propose la meilleure informatique du monde que l'on est en mesure de rendre le meilleur service informatique à sa société : s'il est rejeté par les utilisateurs, un système informatique ne sert à rien. Le management du changement doit prendre une place importante dans la mise en place des actions stratégiques du DSI. ITIL conseille d'établir clairement le niveau de risque de la réalisation d'un projet (un "risco-mètre"). Il s'agit entre autres d'établir le fossé qui existe entre les besoins du business et la capacité de réponse de la DSI.
Comprendre et mesurer quel est le risque permet de gérer ce risque (et j'ajouterai : de le budgetiser !).

ITIL propose une classification des organisations liées aux risques qu'elles induisent (avec des compléments personnels) :

Niveau de maturité	Caractéristiques	Problèmes induits
Artisanal (somme d'individus)	Travail basé sur les capacités d'individus communiquant peu ou pas	Planification de projet et management très aléatoires
Cellules artisanales (petit groupe autour d'un "artisan leader")	Travail basé sur les capacités de petites équipes repliées sur elles-même	Pas de standard d'entreprise, pas de métrologie échangée avec "l'extérieur"
Organisation définie dans une vision "purement informatique"	Travail basé sur des équipes au périmètre clairement établi	Les équipes comprennent mal leur travail en tant que partie prenant d'un processus d'entreprise, l'analyse des dysfonctionnements "organisationnels" est difficile
Organisation avec un management DSI	Responsabilisation des équipes en tant que partie prenante d'un processus d'entreprise	Gestion difficile des changements, en particulier technologiques
Organisation DSI optimisée	Vision sur le long terme avec adaptation constante des processus de la DSI avec ceux de l'entreprise	Automatisation (ou plus clairement, les hommes risquent de se sentir dépossédés de leur travail - qu'ils soient informaticiens ou utilisateurs).

NB : Il est bien nécessaire de comprendre que la recherche du niveau de maturité le plus élevé n'est pas dans l'absolu la meilleure chose à faire. Si la structure même des affaires de l'entreprise nécessite de faire travailler des individus très qualifiés mais isolés (des "artistes"), forcer le passage à une organisation avec un management DSI par exemple serait une erreur, ou dans la terminologie ITIL, on mesurerait un très grand risque d'inadéquation entre l'alignement de l'organisation de l'informatique et les besoins du business de l'entreprise.

Pour un processus donné, ITIL propose de mesurer l'écart entre besoin estimé et maturité actuelle à travers un diagramme radar prenant en compte - la qualité d'exécution au sein du processus, - son niveau d'intégration, - sa capacité métrologique, - son niveau d'outillage, - son niveau méthodologique, - son niveau d'organisation, - le niveau de compétence des équipes - et le niveau atteint en terme d'objectifs du processus. Reste cependant à définir objectivement tous ces niveaux et à y plaquer une métrologie (NB : si le niveau de métrologie est nulle, le reste n'est pas mesurable...).

Stratégie DSI pour la fourniture des nouveaux services

Une fois les objectifs clarifiés pour la DSI et l'analyse interne sur sa capacité de les atteindre, il faut mettre en oeuvre les changements destinés à supprimer les manques. ITIL liste plusieurs stratégies possibles (avec des compléments personnels) :

Stratégies	Avantages	Inconvénients
Insourcing (on accueille une équipe d'une société extérieure)	Contrôle, liberté de choix, acquisition rapide du savoir-faire, mise en place rapide	Coût élevé (si les compétences sont rares), problèmes légaux (délit de marchandage), fusion avec la culture d'entreprise
Outsourcing (une société extérieure gère chez elle vos besoins)	Economie d'échelle, pas de gestion de compétences jugées non stratégiques, on ne se préoccupe plus des problèmes "d'intendance"	Perte de contrôle, coût de désengagement, gestion plus complexe des risques, implique un plus grand contrôle des processus d'entreprise, problème posterieur du support
Co-sourcing (mélange in/out)	Y-a-t-il vraiment des avantages ?	Complexité du management en général, qui a la propriété intellectuelle de quoi ?, problème posterieur du support
Partenariat	Temps de réponse, gestion des coûts d'entrée sur un marché, compétitivité, partage d'expertise, partage des risques	Complexité des projets, qui a la propriété intellectuelle de quoi ?, problèmes de culture d'entreprise, problème d'intégration des organisation, problème d'intégration des moyens techniques, requiert un haut niveau de confiance
Fusion / Acquisition (ou création ex nihilo)	Contrôle, réponse rapide au marché, compétitivité maîtrisée	Coût très élevé, problème de culture d'entreprise

Conclusion

Les rédacteurs ITIL semblent très attachés à la philosophie de management de W. Deming (planifier, faire, vérifier, (ré)agir puis recommencer le cycle). Implicitement, en adoptant cette approche, on adopte un management DSI top/down basé sur une vision stratégique et un contrôle qualité omniprésent, sans laisser beaucoup de place à l'initiative individuelle. C'est d'autant plus regretable que la population des informaticiens est généralement qualifiée, dynamique et motivée. Tout en conservant la vision stratégique du DSI et le contrôle qualité, il me semble qu'une approche axée sur un "management kaizen" me semble plus adaptée aux DSI françaises.

Pour ce qui est du choix stratégique liée à la fourniture de nouveaux services informatiques, il est primordial que le DSI ait une vision exacte de ce qui est vraiment vital pour le business de l'entreprise (pas ce qui semble l'être...). Une façon simple pour commencer à établir la liste des priorités est de se demander, équipe par équipe, ce qui se passerait en cas d'absence totale pendant un jour, une semaine ou un mois. Une équipe entraînant une cessation d'activité de l'entreprise pour cause d'absence pendant un jour est vitale, pendant une semaine demande des relations réactives et de confiance, pendant un mois peut être laissé au hasard du marché. Je ne peux que déconseiller l'idée d'abandonner un contrôle totale sur une équipe ayant une activité vitale.