Ce white paper décrit les raisons qui expliqueraient pourquoi nombre de projets IT échouent si souvent

1. 1
White paper 1 : Gouvernance IT
Philippe Lastrayoli
Consultant Senior chez Mielabelo depuis 2010. Contrôleur de gestion de
formation, spécialiste des problématiques de Gouvernance et d’Alignement
des Systèmes d’Information, il rejoint Mielabelo après avoir évolué
durant de nombreuses années en France sur les thématiques du conseil
informatique. En parallèle des missions chez nos clients, il synthétise des
méthodes et référentiels d’alignement, d’analyse d’impact et d’arbitrage
pour proposer un framework transverse de mise en contrôle des évolutions
des organisations de support.
1. « Donne un poisson à un homme et il mangera un jour. Apprends-lui à
pêcher et il mangera toujours » ou l’importance de percevoir l’intérêt du projet
d’évolution
Dans la plupart des cas de volontés d’évolution, le sponsor d’un projet ICT oeuvre pour accroître
la valeur de l’organisation. Il peut alors décider de lancer un programme d’évolution. Dans ce
programme, il devra identifier précisément les principaux problèmes existants, et, ensuite, prioriser
leur résolution.
Cette excellente initiative risque pourtant d’être insuffisante pour garantir la réalisation des bénéfices
espérés ! Ce sera le cas, notamment, si les collaborateurs perçoivent cette initiative comme un ordre
venu «d’en haut», lancé sans réelle réflexion.
En effet, le succès d’un changement est étroitement lié à la perception de son intérêt par l’ensemble
des acteurs de l’organisation. Sans cette perception, la plupart des gens concernés par une évolution
de leur activité ne mettra rien en place. Et cela, le plus souvent parce que « changer c’est compliqué
et moi ça fait 10 ans que je bosse comme ça... je ne vois vraiment pas pourquoi je changerais »!
De plus, il est peu probable que les acteurs de l’entreprise soient davantage convaincus par cette
initiative en cours de déroulement du projet. En effet, si un dysfonctionnement peut sembler
relativement évident vu de l’extérieur, les acteurs n’en ont pas toujours conscience ou n’en perçoivent
pas toujours les effets négatifs.
Pour résumer, un projet de changement doit donc initialement « rencontrer son public ». Le public
doit être conscient de l’existence de douleurs et de leurs impacts négatifs dans le bon fonctionnement
de l’entreprise.
2. « Marcher dans le noir est la meilleure façon de se perdre » ou l’importance
de tout connaître du projet d’évolution
Un projet a également toutes les chances d’échouer si l’on démarre le projet sans savoir d’où l’on
part. Il est alors difficile de « tomber » par hasard sur les bonnes solutions d’amélioration. À terme,
5 raisons courantes de l’échec des projets
d’évolution des organisations informatiques
Les solutions à mettre en place pour assurer la viabilité et le succès des projets d’évolution
Par le passé, et même encore relativement récemment, un projet IT pouvait la plupart du temps avoir comme
justification : « On peut le faire ! » ou « Ça a l’air chouette, si on essayait ? » ou encore une ou plusieurs autres
raisons internes ayant comme caractéristique commune de ne pas nécessairement être très orientées client.
Cette période d’euphorie a pris fin et les « projects simplex inutilis » n’ont pas survécu à l’arrivée des politiques de
réduction des coûts. Toutefois, ce changement de paradigme n’implique pas forcément la disparition de certaines
pratiques impactant la réussite de programmes ou de projets...
Introduction

2. 2
cela empêche aussi de mesurer la réalité de l’amélioration ; il est difficile de prouver que les efforts
ont porté leurs fruits. Et le risque est fort de piétiner les éléments qui fonctionnaient bien à la base et
d’envoyer ad patres les bénéfices qui y étaient associés...
Une variation peut aussi consister à ne pas tenir compte de ce qui a déjà été fait lors des précédents
(voire énièmes) audits ou projets d’amélioration, et en particulier de ce qui avait été identifié comme
problèmes ou axes d’amélioration.
Les effets peuvent alors être nocifs pour deux types de raisons :
• Le manque de mesure sur l’atteinte des objectifs et le pilotage des actions,
• Le fait que ce genre de fonctionnement génère énormément de frustration et de lassitude
chez l’ensemble des parties prenantes, aussi bien pour les équipes IT que pour les utilisateurs
finaux. Une sensation répétée de « déjà vu » mettra à terre la plus énergique et enthousiaste des
équipes!
Pour pallier ces problèmes, il est donc indispensable d’avoir une idée précise et détaillée de la situation
de départ en termes de maturité, de souffrances, mais aussi de bonnes pratiques et bénéfices
existants. Tous ces éléments serviront de base référentielle pour le suivi des résultats du programme
d’évolution.
3. « Allez, un autre projet glissé dans la pile ! » ou l’importance de l’engagement
du management dans le projet d’évolution
Initier un projet de changement d’organisation génère habituellement une réaction paradoxale. Cela
peut devenir assez facilement dans l’esprit des acteurs concernés « un truc si j’ai un peu de temps
après mon vrai travail, parce que mon responsable me l’a demandé ». Ce phénomène peut d’ailleurs
aussi se retrouver dans l’esprit des décisionnaires, voire du responsable du projet.
Il existe plusieurs causes à cela:
• Les projets techniques semblent généralement plus concrets pour les utilisateurs. Ils sont
également plus simples à mettre en œuvre ou à intégrer dans le plan de charge des projets à
venir. Les équipes savent généralement ce qu’elles doivent faire dans ce genre de cas.
• Dans un projet de changement, les acteurs deviennent le « sujet », ce qui change radicalement
leur perception du projet! Cette remise en question est souvent génératrice de perturbation, car
elle touche aux capacités et aux compétences des personnes.
• Les projets de changement n’ont parfois pas assez, voire pas du tout, de charges ou budget
spécifiques prévisionnels.
Les projets de changement nécessitent donc une attention et un engagement spécifique de la part du
management. C’est lui qui doit aider l’ensemble des personnes impliquées à intégrer et s’approprier
la nouvelle culture et les nouvelles pratiques. Pour se faire, une allocation de temps et de budget
correspondante est indispensable.
Par ailleurs, faire évoluer une organisation a fatalement des impacts temporaires sur l’activité courante:
baisse momentanée de productivité liée au rodage des pratiques, besoins d’embaucher, d’être formé,
etc. Cet état de fait doit être compris et accepté de tous, y compris des clients de l’organisation, par
le biais :
• d’une analyse préalable des impacts sur les autres projets à mener,
• d’une priorisation et arbitrage de la part de l’ensemble des parties prenantes.
4. « Dessiner une maison ne permet pas d’habiter dedans» ou l’importance
d’aller au-delà d’une simple planification du projet d’évolution
Une autre façon de s’égarer, très souvent liée à la précédente, consiste à établir les plans de la nouvelle
organisation... et à s’arrêter là. Malheureusement, rédiger l’intégralité des nouveaux processus et
s’arrêter à cela ne produira aucune implémentation surnaturelle des activités.
Là encore, trouver ce qui ne va pas et dessiner ce qui changerait la donne est une activité nécessaire
et potentiellement complexe. Mais ce n’est bien qu’une étape, et à proprement parler, rien de concret
n’a été édifié : « les plans de la maison sont là, reste à la construire ». Beaucoup d’initiatives de
changement d’organisation s’arrêtent à ce moment-là, ou perdent en partie de leur « engagement »

3. 3
et l’attention spécifique qui va avec.
Pourtant c’est le moment de mettre « les mains dans le cambouis »! Dans ce contexte de changement
humain, les «maçons » ne peuvent être uniquement externes, même si un consultant Mielabelo tient
le rôle de chef de chantier et d’architecte. Il est indispensable d’expérimenter les nouvelles pratiques,
de se les approprier à l’aide d’une conduite de changement appropriée et d’une méthodologie
d’accompagnement.
5. « Prier un messie providentiel ne comblera pas vos vœux » ou l’importance
de trouver une méthode cohérente et efficace pour le projet d’évolution
Une dernière approche problématique consiste à chercher une méthode d’implémentation du
changement « sur l’étagère ». Ce serait, par exemple, une méthode rédigée en latin dans un vieux
grimoire secret, et qui solutionnerait l’ensemble des problèmes au moment même où elle a été acquise.
Ou à la rigueur, celle qui consisterait à prendre quelques consultants, les faire travailler à la place des
équipes internes, changer le nom d’un ou deux processus et « hop c’est plié ! ».
Ce type d’erreur d’appréciation a beaucoup à voir avec la précédente évoquée au point 4. Il est
d’ailleurs fréquent de les voir en action simultanément. En effet, les deux répondent à un même
souhait illusoire : ne pas générer de perturbations dans la « vie courante » de l’activité informatique.
Et elles fonctionnent sur la même dynamique : il suffirait de penser une théorie pour bénéficier de ses
effets! Dans l’espoir de la « méthode miracle », il ne faudrait plus faire un effort d’implémentation ni
penser son organisation par rapport à ses propres besoins.
Soyons clair, les méthodes, référentiels et autres bonnes pratiques sont évidemment très utiles, voire
nécessaires, pour construire son organisation dans les règles de l’art. Aussi nécessaires que les
principes de construction peuvent l’être pour construire une maison qui ne s’effondrera pas au premier
coup de vent! Mais aucune méthode ne dira s’il faut 1 ou 3 chambres, seul le client connait ses besoins,
et la méthode ne construira certainement pas la maison. De plus, dans l’entreprise, les composants de
la maison sont ici essentiellement des gens formés qui suivent des règles communes pour fonctionner
tous ensemble. Il serait donc difficile de la faire construire uniquement par des ouvriers extérieurs.
Une fois de plus, les acteurs devront donc s’approprier les bonnes pratiques, même si celles-ci ont en
très grande partie été inspirées par une méthode externe complète. Par exemple, la méthode COBIT
5 sur laquelle Mielabelo a constitué son approche complète d’accompagnement stratégique, en tant
que fil conducteur garantissant la cohésion de toute démarche d’évolution.
Des exemples concrets : quelques expériences rencontrées…
• Percevoir l’intérêt du projet d’évolution
Un projet d’évolution de la gestion de la maintenance pour une société de transport a connu des
difficultés à se mettre en place parce que les opérateurs spécialisés n’étaient pas prêts au changement
et n’en voyaient pas l’intérêt.
Ils étaient attachés en particulier à leur « bon vieux système » de 20 ans d’âge et ressentaient le
nouvel outil et les nouveaux modes de fonctionnement comme une réelle source de souffrance et de
perturbation.
En l’absence d’anticipation de ce point par une intégration préalable des acteurs dans la définition du
nouveau système, l’intégration de ce dernier a nécessité au final une longue période de négociation
pour les convaincre de l’employer. Et ce, dans une version adaptée «moins efficiente mais acceptable»
de la façon de fonctionner. Le tout a généré un important retard dans la mise en œuvre du projet et
dans la délivrance d’une partie uniquement des bénéfices attendus.
• Tout connaître d’un projet d’évolution et obtenir l’engagement du
management dans ce projet
Une compagnie d’assurance avait généré plusieurs projets afin de régler les manques mis en lumière
par plusieurs audits successifs, afin de se conformer aux règles de l’autorité de régulation.
Les projets ne bénéficiaient pas des éléments suivants :
• une cartographie précise entre les causes, les initiatives et les bénéfices attendus,
• une politique de suivi des avancées pendant le projet et surtout avant et après chaque projet.

4. 4
Du fait de cette absence au cours des différents projets du programme d’évolution global de l’IT, la
direction informatique a connu des difficultés à se concentrer sur les éléments les plus importants et à
savoir ce qu’il restait à faire. Elle a consommé plus de ressources que nécessaires et a dû faire face à
une démotivation progressive des équipes et des utilisateurs. La société a également eu des difficultés
à démontrer la réalité de l’amélioration et de la couverture des règles à l’autorité de régulation.
• Aller au-delà de la simple planification du projet d’évolution et trouver une
méthode cohérente et efficace pour ce projet
Une société de services a décidé de modifier certains processus et activités afin d’améliorer la
satisfaction des clients internes.
Une équipe undercover a été constituée, et a commencé à creuser « son propre sillon ». Afin d’aider
l’équipe et de gagner du temps, il a été décidé de faire appel à de l’aide extérieure. Les consultants
choisis ont eu comme consigne de fournir un package complet incluant à la fois une forme d’organisation
standard « aux avantages prouvés », et des jours d’intervention pour résoudre les petites différences
et l’appliquer au contexte client.
Au final, le projet a donc produit un ensemble complet de nouveaux processus avec les activités,
les rôles et responsabilités, le tout absolument conforme à ITIL. L’ensemble n’avait aussi et surtout
que peu de rapport avec les points spécifiques de souffrances, ne correspondait pas à la capacité de
l’organisation existante à évoluer et à fonctionner, et restait globalement méconnu par les principaux
acteurs et parties prenantes qui allaient avoir à vivre avec.
La mise en œuvre effective de l’organisation dessinée resta « relativement partielle » (pléonasme).

5. 5
Conclusion
On concevrait difficilement de développer une application ou une évolution de celle-ci sans se
préoccuper de savoir :
• Ce que les utilisateurs en attendent précisément en termes de bénéfices,
• Quelles sont les fonctionnalités déjà couvertes,
• Si les utilisateurs ont besoin ou adhérent à l’intérêt d’une nouvelle application.
Non plus, en oubliant d’y affecter des ressources et un budget, ou encore en achetant tout fait une
application sans envisager de l’adapter à ses propres besoins.
Pourtant, les initiatives d’amélioration sont souvent traitées de manière moins rigoureuse qu’un
projet de mise en œuvre ou d’amélioration d’une application. Cela tient en grande partie au fait que
le sujet même des travaux d’une part, et l’organisation et les personnes qui doivent les mener à
bien d’autre part, sont confondus. Cette proximité fait que les enjeux et leurs relations sont souvent
mal compris et que l’approche pour les résoudre n’est alors pas structurée.
Pour pallier ces difficultés, Mielabelo préconise une approche intégrée associant:
• Un référentiel de gestion de l’alignement, depuis les attentes des différentes parties
prenantes jusqu’au suivi des bénéfices via les indicateurs d’activité,
• Une méthode d’analyse des causes et de recherche des axes d’amélioration,
• Une méthode de mise en œuvre (Lean) des évolutions d’activité retenue.
Le tout permettant :
• De communiquer sur les enjeux et le pourquoi de l’évolution, en insistant sur les souffrances
à fonctionner de la manière existante, les causes de cette souffrance et les axes d’amélioration
potentiels,
• D’établir immédiatement un référentiel sur l’état des lieux et la capacité à évoluer afin de
prendre des décisions à la fois cohérentes théoriquement et tenables en pratique,
• De piloter et avancer les travaux en ne perdant pas de vue les objectifs et exigences initiales
sur la base d’un budget et d’une charge de travail prévus,
• De ne pas s’arrêter en chemin en ayant dessiné l’organisation idéale sans savoir comment
la mettre en œuvre concrètement,
• D’adapter concrètement les initiatives d’amélioration aux enjeux spécifiques de l’entreprise
prise dans ses contraintes et son environnement propres (attentes et objectifs d’une part,
capacité réelle à les déployer d’autre part).