Master m2 Miage

MASTER 2
-
Mention Informatique et Centre de Services informatiques
(CSI)
Scolarité 2-3è Cycles – UFR SFA Systèmes 14-16 rue Touzet Gaillard
Bd François Mitterrand 93400 ST OUEN
91025 EVRY Cédex
Spécialité - MIAGE -
« Méthodes Informatiques Appliquées à la Gestion d'Entreprise »
Problématiques du Maintien en Condition
Opérationnelle (MCO) d’Applications :

La gestion du MCO d’applications au sein d’un Service Informatique d’une Société
lorsqu’il est confié à une T.M.A.
Année :
Maître de stage Professionnel :
Auteur : Anne DENIBAUD Maître de stage Universitaire :

Problématique du Maintien en Condition Opérationnelle d’Applications (MCO)
Remerciements
Tout d’abord à Madame Estelle Dlouhy-Morel qui m’a intégrée dans son équipe sans faire
aucune différence quant à mon statut de stagiaire. Elle m’a accordée sa confiance et m’a permis
d’être autonome tout en sachant être disponible en cas de nécessité pour répondre à mes
interrogations.
Egalement à toutes les personnes du Pôle Clients pour leur accueil chaleureux, pour mon
intégration sans réserve, pour leur patience en regard de mes sollicitations et le tout sans compter
leur temps.
A tout le CSI et plus largement à la Direction des Systèmes d’Informations Client de GRTgaz,
notre MOA, pour lesquels j’étais une « gazière » comme une autre.
Mais aussi, à l’ensemble des enseignants de l’Université d’Evry que j’ai côtoyé lors du premier
semestre et qui ont satisfait mes attentes et contribué à l’intérêt de ce programme.
Et enfin, à toutes les personnes de mon entourage professionnel, familial et privé qui ont accepté
de me soutenir dans cette expérience, m’ont encouragée quand il le fallait et m’ont déchargée
d’une grande partie du quotidien.
Cette année et ce résultat sont les vôtres.
M2 Miage Anne Denibaud Page 2 / 73

Imprimé le
SOMMAIRE
BILAN ET SYNTHESE ............................................................................................................ 5
1. PRESENTATION DE L’ACTIVITE EN ENTREPRISE ...................................................... 5

1.1. L’entreprise d’accueil ........................................................................................................................... 5
1.2. Le Maître de stage professionnel ...................................................................................................... 6
1.3. Le résumé des travaux proposés ....................................................................................................... 6
1.4. Le résumé des travaux effectués ....................................................................................................... 7
2. PRESENTATION ET SYNTHESE DU SUJET DE MEMOIRE ...................................... 10

2.1. Le sujet et ses apports novateurs ................................................................................................... 10
2.2. La problématique du MCO déjà traitée ........................................................................................ 11
2.3. L’apport de l’étude ............................................................................................................................ 11
2.4. Ce qu’il faudrait faire de plus .......................................................................................................... 11
PRESENTATION DE L’ETUDE .......................................................................................... 12
1. INTRODUCTION ........................................................................................................... 12
2. LE MAINTIEN EN CONDITION OPERATIONNELLE ............................................... 14

2.1. Introduction ........................................................................................................................................ 14
2.2. Les définitions ..................................................................................................................................... 14
2.3. L’objectif du MCO .............................................................................................................................. 15
2.4. Conclusion ........................................................................................................................................... 16
3. L’ORGANISATION DE LA SOCIETE ET DE SON SI EN PARTICULIER................... 17

3.1. Introduction ........................................................................................................................................ 17
3.2. Les composantes d’un service IT .................................................................................................... 17
3.3. De la naissance du IT à aujourd’hui ............................................................................................... 17
3.4. Les grandes étapes du IT .................................................................................................................. 19
3.5. Les deux entités prépondérantes .................................................................................................. 23
3.6. L’évolution des IT dans l’ère de la maturité ................................................................................. 27
3.7. La maîtrise des coûts IT .................................................................................................................... 28
3.8. Conclusion ........................................................................................................................................... 28
4. LES CADRES THEORIQUES PERTINENTS ................................................................. 30

4.1. Introduction ........................................................................................................................................ 30
4.2. La méthodologie de gestion de projet ........................................................................................ 31

Imprimé le
4.3. Les cadres méthodologiques complémentaires ......................................................................... 43
4.4. Conclusion ........................................................................................................................................... 59
5. PREPARATION ET PASSAGE EN MCO ...................................................................... 60

5.1. Introduction ........................................................................................................................................ 60
5.2. Du projet au MCO .............................................................................................................................. 60
5.3. Les acteurs du MCO ........................................................................................................................... 62
5.4. L’organisation du MCO .................................................................................................................... 66
5.5. Les actions « incontournables » ...................................................................................................... 67
5.6. Conclusion ........................................................................................................................................... 68
6. CONCLUSION ............................................................................................................... 69
6.1. Récapitulatif des attentes de l’étude ............................................................................................. 69
6.2. Conclusion générale ......................................................................................................................... 69
6.3. Conclusion pour le PCL ..................................................................................................................... 70
ANNEXES ............................................................................................................................. 71
1. GLOSSAIRE .................................................................................................................... 71
2. WEBOLOGIE ................................................................................................................. 73
3. BIBLIOGRAPHIE ........................................................................................................... 73

Imprimé le
BILAN ET SYNTHESE
1. PRESENTATION DE L’ACTIVITE EN ENTREPRISE
1.1. L’entreprise d’accueil
GDF SUEZ Le groupe GDF SUEZ est un acteur majeur de l’énergie

en Europe. Il produit, achète, transporte, distribue et
Branches & Infratructures
commercialise du gaz naturel, de l’électricité et des
Centre Services Informatique (CSI) services associés à ses clients ; particuliers, entreprises et
14-16 rue Touzet Gaillard collectivités.
93400 ST OUEN
1.1.1. Le département CSI - Pôle clients– « Allocations - Bilans»
Le CSI est l’opérateur informatique des activités régulées de Gaz de France c’est à dire celles qui
concernent les infrastructures de transport, stockage, regazeification, et est organisé en 3 pôles.
 Le Pôle Système Industriel (PSI) gère les métiers d’exploitation et de maintenance des
installations et d’ingénierie,
 Le Pôle Clients (PCL) est en charge de la gestion des systèmes d’information liés à la
commercialisation des infrastructures qui outillent les processus de stockage,
d’acheminement, de conduite et de mesurage du gaz,
 Le Pôle Tertiaire est la structure qui porte les applications complémentaires aux
fonctionnements du CSI
Ci-dessous, l’organigramme correspondant :
ETAT MAJOR
Direction
Direction RH Direction Direction
Stratégie
…
SI Groupe Communication
GLOBAL GAZ ENERGIE INFRASTRUCTURES INTERNATIONAL SERVICES

& GNL FRANCE
Infras hors
DGI GRTgaz CSI GrDF France
Pôle Système Industriel Pôle Clients Pôle Tertiaire

Imprimé le
1.1.2. Description rapide des missions du pôle
Le Pôle Clients assure, dans le cadre de la gestion du système d’information, l’assistance à

Maîtrise d’ouvrage (AMOA), la conduite de projets, la maintenance et l’assistance utilisateurs
des applications métiers pour le compte de ses bénéficiaires (clients) qui sont :
 La filiale GRTgaz, responsable des activités liées aux réseaux de transport du gaz
(développement des réseaux, commercialisation des prestations de transports de gaz
destinées aux tiers, etc.),
 La Direction des Grandes Infrastructures (DGI) qui assure en France, l'exploitation, le
développement, la maintenance des stockages et terminaux méthaniers.
1.2. Le Maître de stage professionnel
Estelle DLOUHY-MOREL est Responsable du Domaine « Allocations - Bilans». Elle m’a

accueillie dans son équipe et suivie tout au long de mon stage.
1.3. Le résumé des travaux proposés
Ma mission au sein du PCL est de mettre en place pour le mois de juillet …., le dispositif de
Maintien en Condition Opérationnelle des applications VICTOR1, SINDI2 et SIMONE,
applications du domaine « Allocations - Bilans» qui sont au cœur du SI du pôle.
Cette mission est déclinée selon trois axes :
 Le premier axe consiste à étudier et à préparer la mise en place des contrats de Tierce
Maintenance Applicative (TMA) en tenant compte:
o Des dates et des budgets des contrats projets en cours qui traitent des lots de
conception, de développement, et du lot optionnel de Maintenance en Condition
Opérationnelle,
o Des renouvellements de contrats de TMA déjà planifiés au PCL.
 Le deuxième axe est de spécifier et de mettre en place les relations « Maîtrise
d’ouvrage (MOA) – Maîtrise d’œuvre (MOE) » et de proposer une offre de service
adéquate pour permettre à la MOA de piloter ses applications efficacement.
 Le troisième axe concerne l’identification et l’énumération des actions que devra
assurer la MOE. L’objectif est de fournir tous les éléments pour permettre de définir
l’organisation cible à mettre en place au sein du domaine.
1.3.1. Situation initiale
Pour mener à bien l’étude, je dispose de tous les documents relatifs au fonctionnement et à
l’organisation du CSI et du PCL en particulier. En complément, j’utilise les premiers processus
1 Validation des Index de Comptage et des Télétransmissions et Organisation des Restitutions

2 Système d’INformation DécisIonnel
Imprimé le
validés ou en cours de validation déclinés selon le référentiel « CobiT » dans le cadre de la

gouvernance du Système d’Information (SI) initialisée par la MOA de GRTgaz.
1.3.2. Planning prévisionnel des travaux
Action et dates clés
Le contrat de TMA Présentation des scénarii concernant la stratégie d’appel d’offre

04/..... Préconisation du scénario le plus en adéquation avec les
contraintes et les disponibilités du PCL.
Les relations MOA - 5 Ateliers programmés du 29 mai au 26 juin avec la MOA de
MOE GRTgaz pour mettre en place un mode de travail commun décliné
selon les principales procédures du processus ‘Gouvernance du SI’.
L’organisation MOE 5 Interviews d’agents dont les activités sont en relation avec le
MCO d’applications. Rédaction du document de synthèse pour
définir le plan d’actions associé à la mise en place d’une
organisation dédiée.
1.3.3. Le contexte des travaux
Au cours de cette prestation réalisée chez Gaz de France, j’ai bénéficié d’une totale autonomie
tant au niveau de l’organisation de mes activités que de la manière de les restituer.
1.4. Le résumé des travaux effectués
1.4.1. Missions principales

 Faire une analyse pertinente et factuelle des documents contractuels existants du
domaine « Allocations - Bilans» pour fournir une vision claire des actions à planifier
et assurer une transition de qualité entre les intégrateurs « Projet » et « TMA ».
 Etre force de proposition dans l’étude des procédures liées au passage en MCO
d’applications du domaine « Allocations - Bilans» en mettant en avant l’axe
opérationnel de l’activité. Définir les services qui pourront être proposés par le
domaine « Allocations - Bilans» à la MOA en fonction des besoins et de la capacité
« à faire ».
 Identifier, typer et organiser les actions qui doivent être menées au sein du domaine
« Allocations - Bilans» du PCL pour assurer le MCO des applications en relation
avec la MOA, puis proposer l’organisation adéquate du domaine.
1.4.2. Livrables
Le premier livrable est le résultat de l’analyse contractuelle des marchés existants. L’objectif est
de mettre en avant plusieurs scénarii possibles et d’identifier celui le plus en phase avec les
contraintes du PCL. Ainsi, le choix a été fait de lancer l’appel d’offre pour choisir le nouvel
intégrateur de TMA des applications du domaine « Allocations - Bilans» courant septembre .....
Imprimé le
Le deuxième livrable doit reprendre les éléments identifiés et les procédures à mettre en place
pour permettre à la MOE et à la MOA de communiquer efficacement et de disposer de moyens
clairement identifiés pour échanger.
Le troisième document reprendra, quant à lui, les actions à réaliser au sein du domaine pour
chacun des objectifs identifiés dans le cadre du MCO ainsi que les moyens à mettre en œuvre
pour y parvenir.
1.4.3. Reste à faire
S/O
1.4.4. Planning des travaux effectués
Action et dates clés
Le contrat de TMA Présentation des scénarii le 18/04 ; choix d’un scénario ;

appel d’offre à lancer entre juin et septembre .....
Préparation de l’appel d’offre avec la direction des
Achats de GDF à partir de juin .....
Les relations MOA - MOE 5 Ateliers réalisés du 29 mai au 12 juillet avec la MOA de
GRTgaz.
L’organisation MOE 5 Interviews d’agents dont les activités sont en relation
avec le MCO d’applications et la synthèse pour juin ....
1.4.5. Technologies utilisées
Les technologies utilisées sont basiques et concernent uniquement les outils de la bureautique.
1.4.6. Technologies enseignées dans le Master et utilisées dans l’activité
Ma mission, orientée organisation, communication, contractualisation, m’a permis de mettre en

avant directement les éléments de droit au programme du Master.
Même si les applications du domaine « Allocations - Bilans» du PCL utilisent des SGBD
(Système de Gestion de Base de Données) Oracle, le langage Java, des progiciels du marché, je
n’ai mis en œuvre aucune de ces technologies.
1.4.7. Moyens matériels mis à disposition
J’ai eu accès à un environnement de travail standard : bureau, poste de travail informatique,

imprimantes partagées, connexion aux applications, accès aux outils de travail collaboratifs (la
messagerie Notes, les bases de données « Lotus Notes ») ainsi qu’aux INTRANETS de Gaz de
France et à INTERNET.

Imprimé le
1.4.8. Eléments quantitatifs
J’ai prévu de fournir trois documents qui reprendront respectivement les analyses et synthèses
correspondantes, susceptibles d’être utilisées.

Imprimé le
2. PRESENTATION ET SYNTHESE DU SUJET DE MEMOIRE
2.1. Le sujet et ses apports novateurs
La problématique du Maintien en Condition Opérationnelle d’applications peut se formaliser par

les questions suivantes :
Que signifie « Maintien en Condition Opérationnelle d’une application » ?
Où se situe la phase de MCO d’une application dans le processus de gestion de projet ?
Comment situer le MCO dans le cadre des référentiels méthodologiques ? Quel serait le
mieux adapté ?
Quelles sont les instances d’entreprise, internes et externes, concernées par cette
problématique ?
Quels sont les processus à définir particulièrement? Que dire plus précisément de la
communication entre ces instances?
Quelles sont les actions à réaliser et par qui ?
Toutes les applications sont-elles concernées par cette problématique ?
L’organisation de l’entreprise et de son instance informatique en particulier est-elle
importante?
2.1.1. Eléments novateurs
La description des processus liés au passage d’applications en MCO n’est, à ma connaissance,

abordée dans son ensemble dans aucun des référentiels méthodologiques.
2.1.2. Motivations principales pour traiter ce sujet
J’ai pu constater que ce sujet devait mettre « en musique » plusieurs processus et plusieurs
entités internes ou externes à l’entreprise et que, pour ces deux raisons, une orchestration subtile
était nécessaire.
2.1.3. Importance du MCO dans l’informatique et chez GDF en particulier
Le service informatique de l’entreprise est devenu un centre de pilotage, et de ce fait, il lui est
devenu indispensable de maîtriser l’ensemble des processus mis en place ou à mettre en place et
de clairement les identifier notamment en termes d’acteurs, de rôles et de responsabilités.
Le CSI-PCL se doit de fournir un service de qualité à ses bénéficiaires. Son objectif est donc de
conserver la maîtrise des applications dont il a la charge en termes de niveau de réactivité, de
coûts et de qualité.
Lorsque les activités de MCO d’applications étaient assurées par les entités d’un service
informatique, ces 3 objectifs étaient déjà prépondérants. Maintenant qu’elles sont réalisées par
des entités externes, elles deviennent primordiales.

Imprimé le
En effet, comment les services informatiques pourraient-ils justifier de leur existence si le

pilotage de ces activités n’est pas garanti ?
Le CSI ne fait pas exception à la règle ; la mise en place de processus de MCO maîtrisés de ses
applications renforcera son apport vis à vis de ses bénéficiaires.
2.1.4. Relations entre le sujet du mémoire et les missions réalisées
Je vais m’appuyer sur les études réalisées au cours de mon stage. Elles sont en complète
correspondance avec le sujet du mémoire notamment en ce qui concerne la mise en place, d’une
part des relations entre la MOA et le CSI et d’autre part, de l’organisation correspondante du CSI
pour répondre aux sollicitations de sa MOA. Je vais également tenir compte de mes expériences
passées pour présenter l’historique des organisations des DSI (Direction des Systèmes
d’Information).
2.2. La problématique du MCO déjà traitée
Dans les ouvrages publiés, on parle de gestion de services, de plan de continuité d’activités du
système d’information ou encore de guide pour « faire certifier son SI ». Ces approches donnent
une image qualité. Ces ouvrages sont peu diserts s’agissant de MCO.
2.3. L’apport de l’étude
Cette étude s’appuie sur des actions attestées, analysées tout au long de ma mission et élargies à
un environnement standardisé.
La finalité est de comprendre les étapes à mettre en œuvre, d’instaurer des modes de
fonctionnement entre les différentes instances, de pouvoir s’appuyer sur cette analyse et de
l’utiliser comme fil conducteur pour mettre en condition de MCO n’importe quelle application.
Deux applications du domaine « Allocations - Bilans» du PCL seront concernées d’ici la fin du
premier semestre, une troisième intègrera le processus dès la fin de l’année. Ainsi, ce guide
pourra être éprouvé.
De plus, ce modèle devrait pouvoir servir dans tous services informatiques dont l’activité
principale est le pilotage de projets et d’applications dans un contexte méthodologique et
qualitatif.
2.4. Ce qu’il faudrait faire de plus
Dans une deuxième étape, il serait intéressant de proposer un outillage standard et des modèles
de documents pour :
 Recenser,
 Partager,
 Communiquer,
et ce quelle que soit l’étape en cours du processus de passage en MCO.

Imprimé le
PRESENTATION DE L’ETUDE
1. INTRODUCTION
Aujourd’hui, les IT (Technologies de l’Information) sont au cœur de notre vie de tous les jours,
et plus encore de celui de l’entreprise. Elles permettent de répondre aux principes fondamentaux
de l’économie à savoir : exercer un métier, avoir des clients et disposer de ressources.
Et même si ce principe est inchangé depuis l’Antiquité, l’utilisation des IT, comme moyen pour
y parvenir, a fait évoluer le mode de fonctionnement de ces entreprises. Ainsi, un des points
essentiel et incontournable reste leur maîtrise. Par « Technologie », il faut comprendre ensemble
de techniques modernes complexes. Ainsi, l’interprétation de « maîtriser les IT » peut se faire
selon les trois propositions suivantes : soit posséder un savoir-faire IT, soit l’acquérir, soit piloter
des prestations spécialisées adéquates.
Mais revenons dans le monde de l’informatique d’une entreprise. Une des instances de cette
entreprise doit donc être spécialisée dans le métier qui consiste à maîtriser les IT. Ses clients sont
les autres entités de l’entreprise et elle utilise des ressources matérielles et humaines qui peuvent
être elles-mêmes des instances internes ou externes. Et c’est ici que tout se complique.
En effet, au début de l’ère informatique, ces instances étaient composées d’ingénieurs nommés
par les dirigeants de l’entreprise parce qu’ils étaient intéressés par les nouvelles technologies. Ils
ont ensuite été regroupés dans un service spécifique (on parlait alors de Service Informatique) et
ont commencé à automatiser efficacement un nombre significatif de tâches3.
Rapidement, les fonctions à automatiser ont augmenté de façon exponentielle, se sont
complexifiées et ont nécessité la mise en place d’organisations spécifiques puis ensuite de
méthodologies. C’est également au cours de cette période que les instances clientes ont été de
plus en plus exigeantes quant aux technologies de pointes utilisées, ce qui n’a pas été sans
conséquence sur la gestion financière, au sens rentabilité, de ces Services Informatiques.
Au fils des expériences acquises dans différentes sociétés et en confrontant mes expériences, j’ai
pu m’apercevoir que cette situation était somme toute banale et que chaque société, ayant une
structure informatique propre, aura à un moment ou à un autre le dilemme suivant à traiter :
privilégier soit l’offre de la meilleure qualité de service (le mieuxdisant) soit la rentabilité
financière (le moins-disant).
La littérature a abondamment traité des méthodes de gestion et de conduite de nouveaux projets
informatiques que ces méthodes soient généralistes4, ou orientées selon des domaines particuliers
3
IT Gouvernance- F.Georgel –page 14-«dans les années 60,…., les chefs d’entreprise comprennent alors que
l’informatique leur permet de remplacer efficacement le crayon et la règle à calcul .. »
4
PMBOK « Corpus des connaissances en management de projet » de PMI (Project Management Institute)
traduction française de la 3ème édition.
Imprimé le
comme le Décisionnel5, ou encore le WEB6. Il est intéressant de relever que la méthodologie à

suivre diffère, selon le domaine d’orientation, de la démarche projet en général. Par contre peu
d’ouvrages ont abordé une vision de maintenance opérationnelle ; ce dernier point étant sûrement
moins noble que le premier mais tout aussi difficile et délicat, si ce n’est plus. En fait, la
maintenance opérationnelle a été abordée dans le cycle de vie projet comme une étape de
transition dont nous ferons une analyse détaillée dans un des chapitres à venir.
Est-ce pour autant que le sujet n’est pas problématique ? Est-il donc si facile d’assurer à ses
instances métiers la garantie que leurs outils IT ne les trahiront pas une fois qu’ils ne feront plus
l’objet d’une attention aussi particulière qu’en phase projet ? Comment d’ailleurs être certain que
les nouvelles ressources seront toutes aussi performantes ?
Pour tenter de répondre à ces questions, nous allons donc nous fixer comme objectifs :
 De définir les activités couvertes par le MCO et à quel moment il est opportun de le
préparer,
 D’étudier les instances tant internes qu’externes à l’entreprise et l’évolution de cette
dernière et de son SI,
 D’identifier les bonnes pratiques existantes dans le cadre du passage et du suivi de
MCO d’applications, et à contrario les risques s’il n’y en a pas,
 De proposer un ensemble de recommandations utiles pour mener à bien le passage
d’un projet en une application à maintenir en condition opérationnelle.
En gardant comme fil conducteur la mise en œuvre des moyens nécessaires et suffisants pour
assurer le MCO des outils IT de l’entreprise nous allons donc :
 Donner un sens à l’acronyme « MCO » et identifier les compléments apportés par
rapport à la notion de « maintenance » communément utilisée,
 Tracer et décrire l’évolution de l’organisation des instances informatiques de
l’entreprise en s’attardant sur les problèmes induits et ce qu’il a fallu mettre en œuvre
pour y remédier,
 Ensuite analyser les différentes méthodologies tant en terme de gestion de projets que
de référentiels disponibles, le tout en s’attardant sur les motivations qui sont à
l’origine de leur naissance,
 Et enfin, s’attacher à mettre en phase les organisations actuelles et les méthodologies
afin de rendre opérationnel et pragmatique le MCO de ces applications.
5
« Le data Warehouse, Guide de conduite de projet » De Ralph Kimball, Laura Reeves, Margy Ross et Warrren
Thornthwaite - Eyrolles, Mars 2005
6
Conduite de projet Web - Avec 3 études de cas De Stéphane Bordage, David Thévenon, Franklin Brousse et
Laurence Dupaquier - Eyrolles Mai ....
Imprimé le
2. LE MAINTIEN EN CONDITION OPERATIONNELLE

2.1. Introduction
Dans ce chapitre, nous allons nous attacher à définir les activités couvertes par la phase de
Maintien en Condition Opérationnelle (MCO) versus celles de « Maintenance » plus
communément utilisée jusqu’au milieu des années 2000 dans les organisations IT et surtout,
largement explicitée dans tous les ouvrages ou référentiels.
L’objectif est de déterminer les similitudes ou éventuellement si l’une des activités est incluse
dans l’autre.
2.2. Les définitions
2.2.1. Le MCO
Le MCO est un ensemble d’actions à préparer en amont de toute mise en application

opérationnelle de matériel logiciel ou technique quel qu’il soit. Mais de quelles natures les
actions sont-elles induites ?
2.2.1.a) Le MCO hors IT
Communément la notion de MCO est utilisée pour la maintenance :

 Des navires de la Marine Nationale,
 Des avions,
 Des radars,
 …
Dans ce cadre, l’objectif du MCO est d’anticiper l’immobilisation de ces matériels pour garantir
un fonctionnement optimum en cours de mission. Les interventions concernent aussi bien des
changements de pièces essentielles dont l’usure est avérée ou de pièces endommagées sur
lesquelles il faut intervenir rapidement. Une maintenance mal programmée peut avoir des
conséquences dramatiques pour la sécurité des Hommes. Le maître mot est bien ici
« anticipation » car les conditions à mettre en œuvre pour assurer la maintenance technique d’un
navire ou d’un avion ne sont pas non plus sans conséquences financières. Deux exemples pour
illustrer ces propos : un bateau, pour certaines interventions doit être en cale sèche, de même un
avion doit, bien évidemment, avoir atterri.
2.2.1.b) Le MCO et les produits IT
L’analogie des applications IT complexes et leur caractère primordial pour l’entreprise, font que
les instances informatique ont également adopté ce mode de fonctionnement pour gérer le MCO
de leur IT. En fait, l’arrêt de l’exploitation est assimilé à l’immobilisation des matériels. La
maintenance des infrastructures, la prise en compte de nouvelles versions sont quant à elles
assimilées à des changements de pièces essentielles.

Imprimé le
L’anticipation, la planification de toutes ces actions sont, dans certain cas, toutes aussi
importantes pour la société que la maintenance de la flotte nationale.
Ainsi, par « Maintien en condition opérationnelle » il faut entendre « conserver l’application en
bon état de fonctionnement » par rapport au service attendu par ses utilisateurs.
2.2.2. La Maintenance
Le dictionnaire donne la définition suivante du mot « maintenance » :

 « fait de conserver un matériel technique ou industriel en état de fonctionner »,
 « ensemble d’opérations d'entretien d'un équipement ».
2.2.3. MCO & Maintenance
Nous pouvons donc établir que, d’un point de vue sémantique, « Maintenance » et « MCO »
sont des synonymes. Par contre, l’expression « MCO » sous entend « anticiper les actions de
maintenance autres que correctives»; elles sont donc à fortiori incluses dans le MCO.
L’évolution de « Maintenance » en « MCO » est apparue lorsque le socle du nombre
d’applications à maintenir a commencé à augmenter de façon significative. Les DSI, après l’ère
du développement, ont du faire face à la maintenance d’applications souvent développées dans
des technologies très hétérogènes et ont décidé de mettre en place un processus en
correspondance avec les difficultés de chaque situation.
Ces difficultés viennent essentiellement du volume et du cycle de vie des applications à
maintenir, du type de maintenance à réaliser et des compétences technologiques à contrôler.
Ainsi, le processus MCO va permettre de décrire précisément les actes qui sont pris en charge.
De même, il va être possible de fournir des outils aussi bien pour typer le niveau de difficulté de
l’intervention que pour préciser le délai de cette intervention, mesurer les écarts et donc produire
un niveau de service. Les SSII (Sociétés de Services en Ingénierie Informatique) ont su d’ailleurs
adapter leurs offres de services aux besoins de leurs clients et ont du être à l’origine de
l’adaptation du terme « Maintenance » en « Maintien en Condition opérationnelle » des SI. En
effet, leur force se situe dans l’hétérogénéité des compétences de leur personnel et des moyens
qu’elles mobilisent pour trouver ces compétences le cas échéant. Rappelons que leur cœur de
métier est la maîtrise des IT.
2.3. L’objectif du MCO
Les objectifs du MCO sont de maintenir efficacement les applications pour qu’elles fournissent
le service attendu par les clients, de préparer et de faire évoluer les applications pour préparer
l’avenir, le tout en maîtrisant les coûts, la réactivité et la qualité d’exécution et du résultat.
Les activités prioritaires couvertes pour le MCO sont de natures différentes.
Elles concernent les actions dont l’objectif est de fiabiliser l’application et d’améliorer les
performances. Ce volet inclut en général les modifications nécessaires pour assurer les montées

Imprimé le
de version sur les composants du SI utilisés par l’application. On parle alors de maintenance
corrective et préventive.
Elles concernent aussi les évolutions fonctionnelles qui proviennent soit des demandes de la
maîtrise d’ouvrage soit des évolutions réglementaires. Ici, c’est plutôt de maintenance évolutive
et adaptative qu’il s’agit.
Elles concernent encore la gestion des moyens opérationnels avec lesquels et sur lesquels les
actions de MCO sont exécutées.
Elles concernent enfin l’assistance utilisateur, qui est, globalement une assistance à plusieurs
niveaux d’escalade de 0 (prise d’appel) à 3 (analyse technique à réaliser). Ici c’est le niveau 3 qui
est en général pris en charge.
Le niveau de satisfaction du client va permettre, quant à lui, de valoriser le MCO. Il se mesure en
tenant compte de points névralgiques comme :
 Une utilisation régulière de l’application sans anicroche,
 Une gestion des incidents rapide et efficace,
 Une communication anticipée en cas d’interruption prévisible de l’application,
 Une prise en compte efficace des demandes d’évolution,
 Des propositions d’évolutions préventives, adaptatives, judicieuses et pertinentes.
2.4. Conclusion
Si l’activité « traditionnelle » de maintenance de tout ou partie d’un SI peut être comparée à un
« carnet d’entretien » d’une voiture (planification prévisionnelle d’opérations d’entretien), le
MCO serait plutôt de l’ordre du « contrat d’entretien » du véhicule. La différence est que dès
l’achat du véhicule (dans notre cas l’application) son propriétaire (dans notre cas l’utilisateur
final) prévoit un investissement planifié et contractualisé pour son « Maintien en Condition
Opérationnelle ».
Cet investissement toujours difficile à concevoir ou à consentir en phase projet (c’est clairement
un surcoût qui grève le ROI7) a l’avantage d’éviter toute surprise ultérieure et d’impliquer tous
les acteurs en amont. Le MCO est donc une démarche consciente d’anticipation qui englobe la
maintenance.
7
Return Of Investment
Imprimé le
3. L’ORGANISATION DE LA SOCIETE ET DE SON SI EN PARTICULIER

3.1. Introduction
Dans ce chapitre, nous allons présenter les différentes évolutions qu’ont subies les Services IT et
les différents acteurs qui y ont contribués. L’objectif est de comprendre l’organisation actuelle,
les relations qui existent entre les acteurs qui contribuent à la création et à la maintenance d’un
ouvrage,8 comment, pourquoi cette situation est devenue inéluctable et quels ont été les impacts
des mutations successives.
Dans un premier temps nous allons analyser les différentes politiques de gestion appliquées au
sein de ces sociétés en regard de leurs instances informatique. Puis nous allons examiner les
transformations supportées par ces Services IT selon trois grandes périodes consécutives aux
différentes politiques de gestion successives : celle de l’implantation, celle du développement et
celle de la maturité.
Dans un deuxième temps, nous allons explorer chacune de ces périodes et essayer de comprendre
les faits qui nous ont amenés logiquement à la situation actuelle.
3.2. Les composantes d’un service IT
Un SI regroupe trois composants prépondérants :
 L’infrastructure est un ensemble d’installations et d’individus nécessaires au
fonctionnement de l’instance IT,
 Les applicatifs sont des processus industrialisés par des outils IT utilisés par la société,
 Les services, ici le terme « service » désigne toujours un service offert par une
organisation à ses clients. Un service est indissociable de son utilisation. Selon la
commission de Normalisation de l’AFNOR, un service est « une prestation
immatérielle composable, manifestée de manière prédéfinie, et une source de valeur
pour le consommateur et le fournisseur ». Ainsi, en pratique la notion de service
apparaît lorsque la gestion du SI passe de centre de coûts à centre de profits, avec un
équilibre entre « qu’est ce que j’ai à vendre ? » et « qu’est-ce que le client est prêt à
acheter ?9 ».
3.3. De la naissance du IT à aujourd’hui
Les activités IT ont démarré au début des années 60. Trois grandes étapes se détachent, chacune
d’entre elles ayant une durée d’environ vingt ans. Chaque période correspond à une approche
différente d’un point de vue économique. Elles se répartissent comme suit : l’ère de
l’implantation, l’ère du développement et l’ère de la maturité.
8
Dans la suite du document, « ouvrage », « produit », « application » sont des synonymes et représentent le résultat
d’un projet en exploitation.
9
ITIL et la gestion des services-page 6
Imprimé le
Selon l’ère considérée et les préoccupations du moment, la hiérarchie des composants IT est
différente :
Priorité et engagement budgétaires
1- Infrastructures 2 - Applicatifs 3 - Services
2 - Applicatifs 1- Infrastructures 2 - Applicatifs
3 - Services 3 - Services 1- Infrastructures
Ère de l’implantation Ère du développement Ère de la maturité

1960 1980 2000
Maturité
Evolution de l’approche des systèmes informatiques 10
Pour commencer, les années 60 à 80 correspondent à l’avènement de l’informatique avec une

approche fondée sur l’accroissement de la productivité. Les dirigeants des grandes entreprises y
sont très sensibles et il faudrait être aveugle pour ne pas anticiper les bénéfices qu’il va être
possible d’obtenir grâce à l’informatisation : moins d’individus pour plus de productivité.
Les deux étapes suivantes sont celles de la finance et puisque toutes les sociétés se sont lancées
dans l’informatique, l’objectif n’est plus d’automatiser les processus à n’importe quel prix mais
bien de rentabiliser les coûts de fonctionnement de ces processus. L’informatique devient un
outil de productivité parmi les autres et n’est plus soumis à des traitements de faveur. Donc
comme tous les processus, celui lié à l’Infrastructure voit son budget se réduire en faveur de
celui lié aux Services à fournir. Pour rappel, ces coûts sont devenus prohibitifs suite à des
demandes de plus en plus complexes d’utilisateurs, voir des dirigeants de l’entreprise.
Pendant la deuxième période, le composant « Applicatif » est apparu clairement comme
prioritaire pour les sociétés parce qu’il y avait beaucoup de processus à automatiser. En phase de
maturité, ce composant se positionne à nouveau au second plan derrière cette fois-ci les
« Services ». En effet, les instances dirigeantes d’une société s’attachent prioritairement à une
qualité de service irréprochable; étant acquis que les applicatifs et l’infrastructure ne posent plus
de problèmes : les technologies sont éprouvées et les logiciels doivent l’être aussi.
10
IT Gouvernance- F.Georgel –page 46
Imprimé le
3.4. Les grandes étapes du IT
3.4.1. L’ère de l’implantation
L’ère de l’implantation correspond donc à l’âge d’or de l’informatique. En effet, c’est à cette
époque que certains ingénieurs de l’entreprise sont désignés par les dirigeants pour mettre en
place les infrastructures informatiques. Rappelons que leur objectif est d’automatiser les activités
qui s’y prêtent pour augmenter la productivité.
Ainsi naît le service informatique, instance dans un premier temps, complètement intégrée à
l’entreprise. Ses missions sont de mettre en place un ensemble d'éléments structuraux
interconnectés qui fournissent le cadre pour supporter la totalité de l’environnement de
développements applicatifs. Ces ingénieurs au début, se suffisent à eux-mêmes et s’organisent
autour de spécialités : infrastructures (système, exploitation, production, etc.), applicatifs
(analyse, développement), services (gère les incidents).
3.4.1. L’ère du développement
3.4.1.a) L’organisation
De Service Informatique, cette instance évolue rapidement vers une Direction informatique,
d’abord DI (Direction informatique) pour devenir ensuite DSI (Direction des Systèmes
d’Information) où l’on gère en plus des techniques informatiques, le système d’information de
l’entreprise. Au cours de cette période, les «Etudes et Développement » sont très consommateurs
de personnes. La maintenance des applications est bien souvent réalisée par les équipes projet.
Ainsi, les actions correctives sont prioritaires devant les actions projet, par contre la maintenance
évolutive est planifiée selon le bon vouloir des programmeurs.
Pour appuyer ces propos, faisons un premier zoom sur la S.E.I.T.A.11, qui au début des années 80
disposait d’un Service Informatique d’une soixantaine de personnes, déjà très organisé avec des
processus techniques bien implantés. Elle disposait d’un service « Etudes et Développement » en
charge de la réalisation de projets qui représentait environ la moitié des effectifs affectés, les
autres services ayant la responsabilité de l’exploitation proprement dite des applications. En fait
le nombre de personnes dédiées à la maintenance était en adéquation avec le nombre de chaînes
applicatives à savoir environ quatre (l’approvisionnement, la fabrication, la facturation des
débitants de tabacs, et la paye). Les évolutions correctives (techniques ou fonctionnelles) étaient
assurées respectivement par chaque responsable de la maintenance.
En deuxième exemple, regardons le Service Informatique des Messageries du Livres12, composé
d’une quinzaine de personnes réparties comme suit : un expert « Système », une personne et
11
Société d’exploitation industrielle des tabacs et des Allumettes –devenu Altadis après la fusion en 1999 de la
SEITA et Tabacalera et qui a été racheté en 01/.... par TABACCO.
12
MDL, (devenu INTERFORUM en 1993) est la société de distribution du Groupes de la Cité qui regroupe les
Editions R.Lafont, Julliard, Presses de la Cité, Larousse, Bordas pour les principaux
Imprimé le
demi dédiée à la maintenance des applications et neuf personnes impliquées directement sur le
projet de refonte du système existant. Cette configuration montre bien l’importance donnée aux
projets par rapport au suivi de l’exploitation quotidienne des applications. Une deuxième
interprétation est d’avancer le fait que l’absence de dysfonctionnement implique qu’il n’est pas
utile de prévoir plus de ressources ; pourquoi alors vouloir changer ces applications ? Une
troisième hypothèse est également à envisager. En effet, l’ère du développement signifie qu’il y
a beaucoup de nouveaux projets à réaliser d’où l’importance des « équipes projet » en opposition
avec les équipes de maintenance qui n’avaient que très peu d’applications à maintenir.
Pour finir, regardons une troisième entreprise, la holding, REXEL13, dont la DSI a eu pour
objectif, début des années 1990, de piloter la réalisation d’un système commercial commun à
toutes ses sociétés. Dans cette DSI, cohabitaient trois entités, le pôle « Etudes et
Développement » classique, le pôle « Technique » et le pôle « Pilotage fonctionnel » ce dernier
ayant pour rôle de synthétiser les bonnes pratiques et les spécificités de chaque société. Là
encore, le pôle « maintenance des applications » n’existe pas. Cette maintenance est laissée à la
charge de chaque société régionale avec l’objectif de ne réaliser que les actions correctives. Fin
des années 90, il a quand même été nécessaire de s’assurer que le passage à l’an 2000 ne poserait
pas de problèmes…
3.4.1.b) Une nouvelle complexité
Dans le même temps, le nombre de nouvelles technologies a explosé, et leur maîtrise a nécessité
des compétences et des moyens de plus en plus spécialisés. La DSI est devenue une entreprise
dans l’entreprise. Elle est aux commandes d’une infrastructure de plus en plus complexe et
nécessite un nombre croissant de compétences donc de collaborateurs.
Dans la continuité de cette démarche, les coûts d’une DSI n’ont cessé de croître que ce soit tant
du niveau ressources humaines (si l’on tient compte de la diversité des nouveaux métiers), que
du niveau des matériels si l’on considère les nouvelles technologies. Cette instance devient alors
le centre de toutes les critiques en regard des bénéfices engloutis par ses divers systèmes.
3.4.1.c) L’expansion des SSII
Même si les SSII ont fait leur apparition au milieu de l’ère de l’implantation, elles ont vraiment
pris leur ampleur au cours de l’ère de développement (CapGemini a été fondée en 67 mais s’est
fortement implantée à partir des années 9014).
Ces sociétés de prestations informatique répondent aux principes fondamentaux de l’économie à
savoir : exercer un métier (maîtriser les IT), avoir des clients (les autres entreprises) et disposer
13
Holding, distributeur de matériel électrique composé d’une dizaine de sociétés telle qu’ADELEC (en région
parisienne), ISNARD (en région grenobloise), LIENARD (région centre), FACEN (région Nord) pour les
principales
14
Histoire de CapGemini : http://www.fr.capgemini.com/about/histoire/
Imprimé le
de ressources humaines qui correspondent à leur cœur de métier (des experts en IT). Concernant
les ressources matérielles, en général, elles utilisent celles de leurs clients.
Ainsi les sociétés de prestations se déclinent en trois grandes catégories avec lesquelles les DSI
doivent composer.
Complexe techno-informatique
SSII Editeurs Constructeurs

Applicatifs métiers
Equipements
Applicatifs IT
Conseil et
services
Directions des services

Directions opérationnelles
informatiques
Entreprise
Relation du complexe techno-informatique avec l’entreprise15
Ces SSII se sont introduites au niveau des directions opérationnelles de l’entreprise, en tant que
société de conseil et de services informatiques et vont profiter de leur situation pour renforcer le
sentiment que l’informatique soit une activité à part, complexe et coûteuse.
Au vu de ce nouveau contexte, beaucoup d’entreprises ont décidé de se recentrer elles aussi sur
leur de cœur de métier et par la même de sous traiter la gestion de leur IT à ces SSII. La
migration des experts IT de l’entreprise vers les SSII ne s’est pas réalisée de façon si radicale. Il
a fallu plusieurs étapes, étalées sur plusieurs années selon la société et qui n’ont pas débuté au
même moment. En général, cette mutation s’est déroulée dans la douleur. On parle alors
d’externalisation dans le sens confier une tâche, un service, à une entreprise extérieure.
Pour autant, gérer leur SI, ne veut pas dire le conduire et c’est pourquoi toutes les instances des
DSI n’ont pas été externalisées. Il reste les pilotes projet qui, en plus de leurs connaissances
informatiques, ont pour mission de comprendre le métier de leur entreprise, de communiquer
avec les services qui l’exercent pour leur fournir les meilleurs outils.
15
IT Gouvernance- F.Georgel –page 48
Imprimé le
3.4.2. L’ère de la maturité
Le Service Informatique de l’entreprise est donc devenu un centre de pilotage, et de ce fait, il est
devenu indispensable de maîtriser l’ensemble des processus mis en place ou à mettre en place et
de clairement les identifier notamment en termes d’acteurs, de rôles et de responsabilités.
Le fait que l’outil informatique soit perçu comme un moyen d’optimiser l’activité de l’entreprise,
implique qu’il soit gouverné au niveau des instances managériales de l’entreprise.
Nous aborderons ce point précisément dans le chapitre « Les cadres théoriques pertinents » qui
reprend notamment les principaux référentiels publiés par les organismes de normalisation.
La DSI doit conserver la maîtrise des applications dont elle a la charge en termes de niveau de
réactivité, de coûts et de qualité, rendre compte de son activité et de ses dépenses à son instance
de gouvernance et fournir des indicateurs pour lui permettre de suivre l’adéquation entre les
coûts et les activités réalisées. Le socle des applications en exploitation est significatif, il
nécessite la mise en place d’une structure organisée de MCO qui doit gérer l’exploitation
quotidienne, mais aussi les évolutions court, moyen et long terme, à réaliser.
Le système d’information doit se stabiliser. Ne sont réécrits, repensés que les processus qui en
valent la peine, qui auront une forte valeur ajoutée en terme financier. Avoir une bonne idée,
n’est plus suffisant, il faut prouver qu’elle est rentable en calculant un retour sur investissement,
le fameux ROI, fait qui nous est régulièrement rappelé. Attention, même s’il est moins onéreux
d’adapter une application en exploitation, le coût n’est quand même pas neutre. Il est souvent
plus difficile d’estimer le coût de maintenance d’une application que le coût d’un projet. Les
questions à se poser concernent le plus souvent la taille de l’équipe à mettre en place. Combien
de personnes faut-il prévoir pour assurer une maintenance efficace et sans risque ? Et oui, voilà
encore un mot qui fâche : « Risque ». Modifier une application qui est utilisée par un certain
nombre de personnes et qui doit fournir un résultat périodique, n’est sûrement pas sans risque.
Ce dernier est à mesurer et à anticiper, et là encore la SSII va pouvoir tirer son épingle du jeu.
Elle va proposer des prestations de Tierce Maintenance Applicative (TMA) pour libérer les DSI
de ce problème. Il est en effet plus aisé pour une SSII d’adapter sa taille en fonction des contrats
qu’elle va signer : de développement, de MCO.
Regardons, comme dernier exemple, la société Carrefour au milieu des années 2000.
L’organisation suivante a été mise en place :
 Une « Direction des Centres de Compétences et des Systèmes Métiers »,

 Une « Direction Projets (DP)»,
 Une «Direction de l’Architecture, Urbanisme et Développements technologiques»,
 Une « Direction des Services Opérationnels (DSO)».
La «Direction Développement et Maintenance Applicative (DDMA) » a disparu à cette période.
En effet, pour réduire les coûts de fonctionnement du service, les activités (et les personnes) de

Imprimé le
la DDMA ont été cédées à une SSII. Le lien entre la société et la SSII s’est fait au travers de la
DSO. C’est également à cette époque qu’une Direction projet a vu le jour, étant entendu que les
projets sont réalisés également par des SSII. Au final, la maintenance est assurée par une TMA.
L’objectif a bien été de pouvoir budgétiser précisément la charge financière du MCO de son parc
applicatif de la même façon que les projets sont soumis à des appels d’offres.
Donc, lorsque les activités de maintenance étaient assurées par les entités du Service
Informatique, le triptyque coût, réactivité, qualité était déjà prépondérant. Maintenant qu’elles
sont réalisées par des entités externes, elles deviennent primordiales.
En effet, comment les Services Informatique pourraient-ils justifier leur existence si le pilotage
de ces activités n’est pas garanti ?
La mise en place des processus maîtrisés de MCO de ses applications, doit garantir sa pérennité
vis à vis de ses instances clientes.
L’accent est donc mis sur la maîtrise des processus de MCO. En effet, la gestion des projets a été
au centre des préoccupations pendant l’ère du développement et a donc déjà été soumise à la
mise en place de processus maintenant éprouvés.
3.5. Les deux entités prépondérantes
La MOE (Maîtrise d’œuvre) et la MOA (Maîtrise d’Ouvrage), entités très présentes dans le
monde du bâtiment, se sont imposées au cours des années 90, au milieu de l’ère du
développement. Elles se sont partagées les rôles dans le cadre de la maîtrise des systèmes
d’information.
Plusieurs études ont été menées que ce soit par l’AFAI16, ou par des consultants expérimentés17.
3.5.1. La « maîtrise d’ouvrage »
3.5.1.a) Définition de la MOA
Le « maître d’ouvrage » est l’entité porteuse du besoin (entreprise, direction, service) cliente de
l’informatique qui sera le propriétaire de l’ouvrage. Par abus de langage, on appelle « maîtres
d’ouvrage » les personnes physiques qui, dans cette entité cliente, ont compétence pour définir le
système d’information que le Service Informatique construit, maintient et exploit. En fait, il
définit l’objectif du projet, son calendrier et il fixe l’enveloppe budgétaire. Le résultat attendu du
projet est la réalisation d‘un produit, appelé l’ouvrage.
16
Etude AFAI (Association Française de l'Audit et du Conseil Informatiques) « Maîtrise d’ouvrage » de projet de
système d’information
17
http://www.volle.com/travaux/moa_du_si.htm
Imprimé le
3.5.1.b) Rôles de la MOA
Le rôle du « maître d’ouvrage » est de spécifier les besoins, de prendre les décisions essentielles,
et en particulier celles nécessaires à la définition du budget du système d'information. Il maîtrise
donc l’idée de base du projet (ou de ses évolutions), et représente à ce titre les utilisateurs finaux
à qui l’ouvrage est destiné. Il doit également réceptionner l’application, s’assurer que son
fonctionnement est en rapport avec les besoins exprimés et que tout est prêt pour une
exploitation optimale de l’application. Par contre, il n’a pas forcément les compétences
techniques liées à sa réalisation.
Selon l’importance de l’entité cliente, les responsabilités de la MOA peuvent être partagées.
Ainsi, le MOA-D « maître d’ouvrage délégué » remplit une fonction d’expertise par délégation
du directeur de l'entité, le MOA-S « maître d’ouvrage stratégique », qu'il assiste dans la
préparation des décisions relatives au SI. Le maître d'ouvrage délégué a une mission de
coordination entre des MOA-O « maîtres d’ouvrage opérationnels » responsables chacun d'un
des domaines du métier. Chacune des MOA-O dialogue avec son homologue, ou une personne
déléguée, du MOE « maître d’œuvre ».
3.5.1.c) L’apport de la MOA
Avant 1990 l’informatique avait déjà pour clients les « métiers » de l’entreprise, mais les
spécifications fonctionnelles étaient souvent définies par les informaticiens eux-mêmes à partir
d’expressions de besoin sommaires dont la description tenait quelque fois sur un post’it. Avec
l’évolution et l’enrichissement du rôle de l’informatique, les spécifications fonctionnelles sont
devenues l’expression formelle complète du métier lui-même ; elles ne peuvent donc être
établies que par des personnes qui travaillent dans le métier tout en étant capables de définir un
SI et d’aider les dirigeants à tirer parti des potentialités de l’informatique.
Ainsi s’est construite dans l’entreprise une compétence nouvelle, la maîtrise d’ouvrage du SI.
Elle est souvent un débouché pour les informaticiens qui aiment à travailler au plus près des
métiers.
3.5.1.d) Les SSII et la MOA
De fait, les dirigeants des entités clientes nomment des responsables à la tête de la MOA qui ont
un profil métier. Ils connaissent très bien les besoins des utilisateurs pour avoir été l’un d’entre
eux quelques années mais n’ont pas forcément la formation ni les outils qui leurs permettent de
gérer un projet informatique.
Ainsi, lorsque le maître d’ouvrage ne possède pas l’expérience métier nécessaire au pilotage du
projet, ou tout simplement quand il a besoin de renforcer ponctuellement ses équipes, il peut
faire appel à une assistance (AMOA). Cette AMOA est chargée de faire l’interface entre la MOE
et la MOA.

Imprimé le
Ici encore, les SSII se sont infiltrées au niveau des entités décisionnaires. Des services
d'assistance à maîtrise d'ouvrage sont commercialisés par certaines SSII et fournissent aux
entreprises les compétences nécessaires qu'elles ne possèdent pas.
Les relations sont rythmées par divers comités périodiques dont le nom varie selon les sociétés.
Cependant leurs objectifs sont identiques à savoir :
 Un comité stratégique des systèmes d'information qui réunit les MOA-S et les MOA-
D pour prendre les décisions essentielles, et en particulier pour définir le budget du
système d'information,
 Une coordination des maîtrises d'ouvrage qui assure l'animation des MOA-D en
termes de méthode, de veille, et qui s’assure de la qualité des relations avec
l'informatique.
3.5.2. La « maîtrise d’œuvre »
3.5.2.a) Définition de la MOE
Le maître d'œuvre (ou maîtrise d'œuvre, notée MOE) est l'entité retenue par le maître d'ouvrage
pour réaliser l'ouvrage, dans les conditions de délais, de qualité et de coût fixés par ce dernier
conformément à un contrat.
3.5.2.b) Rôles de la MOE
Le rôle du « maître d’œuvre » est d’organiser la réalisation. Il coordonne la réalisation, contrôle

les résultats et met tout en œuvre pour une exploitation optimale. Les connaissances du MOE
sont très vastes et à ce titre reposent bien sur une entité et non une personne. La maîtrise d'œuvre
est donc responsable des choix techniques inhérents à la réalisation de l'ouvrage conformément
aux exigences de la maîtrise d'ouvrage. Le maître d'œuvre a ainsi la responsabilité dans le cadre
de sa mission de désigner une personne physique chargée du bon déroulement du projet (on parle
généralement de maîtrise du projet), il s'agit du chef de projet.
Force est de constater qu’on aborde ce sujet d’un point de vue projet mais qu’en est-il du MCO ?
3.5.2.c) Les SSII et la MOE
Là encore, les chefs de projet MOE peuvent également encadrer et, ou coordonner des
interventions de fournisseurs extérieurs (ici les SSII peuvent être à nouveau présentes). En effet,
pour la réalisation de certaines tâches du projet, lorsqu'il ne possède pas en interne les ressources
nécessaires, le maître d'œuvre peut faire appel à une ou plusieurs entreprises externes, on parle
alors de sous-traitance (et chaque entreprise est appelée sous-traitant ou prestataire). Chaque
sous-traitant réalise un sous-ensemble du projet directement avec le maître d'œuvre mais n'a
aucune responsabilité directe avec la maîtrise d'ouvrage, même si celle-ci a un " droit de regard "
sur sa façon de travailler.

Imprimé le
3.5.3. Distinction des rôles entre MOA et MOE

La distinction entre maître d'ouvrage et maître d'œuvre est essentielle dans le déroulement du
projet, car elle permet de distinguer les responsabilités des deux entités. Il convient ainsi de
s'assurer que la définition des besoins reste sous l'entière responsabilité de la maîtrise d'ouvrage.
En effet, il arrive dans certains cas que la maîtrise d'ouvrage délègue à la maîtrise d'œuvre des
choix d'ordre fonctionnel sous prétexte d'une insuffisance de connaissances techniques (de façon
concrète le service informatique d'une organisation prend la main et pilote le projet dès la phase
d'expression des besoins). Or seul le maître d'ouvrage est en mesure de connaître le besoin de ses
utilisateurs. Une mauvaise connaissance des rôles des deux entités risque ainsi de conduire à des
conflits dans lesquels chacun rejette la faute sur l'autre.
D'autre part, s'il est vrai que le maître d'œuvre doit prendre en compte les exigences initiales du
maître d'ouvrage, il n'est, par contre, pas habilité à ajouter de nouvelles fonctionnalités au cours
du projet même si cela lui semble opportun. Le maître d'œuvre est cependant chargé des choix
techniques pour peu que ceux-ci répondent fonctionnellement aux exigences de la maîtrise
d'ouvrage.
Enfin il arrive qu'une maîtrise d'ouvrage estime qu'un produit existant soit susceptible de
répondre à ses besoins, l'achète, puis se retourne vers la maîtrise d'œuvre (le service informatique
par exemple) pour effectuer des adaptations du produit.
La distinction entre maîtrise d'œuvre et maîtrise d'ouvrage est encore plus difficile lorsque les
deux entités font partie de la même structure d'entreprise. Dans de pareils cas, il est d'autant plus
essentiel de bien définir contractuellement les rôles respectifs des deux entités.
3.5.4. Communication entre MOA et MOE
Pour le bon déroulement du projet, il est nécessaire de définir clairement les rôles de chaque
entité et d'identifier respectivement un représentant au sein de la maîtrise d'ouvrage et de la
maîtrise d'œuvre. Un groupe projet associant tous les acteurs de la MOA et de la MOE doivent se
réunir lorsque cela est nécessaire pour résoudre les conflits liés aux exigences de la maîtrise
d'ouvrage ou à la coordination du projet.
Enfin, il est essentiel d'établir un plan de formation permettant à la maîtrise d'œuvre et à la
maîtrise d'ouvrage d'avoir un langage commun et de s'entendre sur une méthode de conduite de
projet, de conduite d'entretiens ou de réunions, etc. 18
3.5.5. Relations MOA-MOE : deux vues complémentaires
18
Une formation de ce type a été mise en place en .... par la DSI générale de Gaz de France pour favoriser ce
dialogue
Imprimé le
Les relations MOA-MOE vue par Michel Volle Les relations MOA-MOE 19
Certains disent que la distinction entre maîtrise d’ouvrage et maîtrise d’œuvre est « franco-
française ». Elle existe pourtant dans les pays anglo-saxons même si le vocabulaire y est
différent. Aux États-Unis les maîtres d’ouvrage délégués sont nommés « business
technologists » : c’est une spécialité à laquelle forment les universités.
3.6. L’évolution des IT dans l’ère de la maturité
L’organisation de l’entreprise a dû évoluer pour faire une place à la maîtrise d’ouvrage, le rôle de
l’informatique a dû changer. Cela ne pouvait pas être facile. Il y a eu bien naturellement au début
des incompréhensions et des polémiques. Puis les choses ont évolué. Dans la plupart des grandes
entreprises, il n’est plus nécessaire aujourd’hui de se battre pour faire admettre la nécessité de la
maîtrise d’ouvrage et l’époque des polémiques avec l’informatique est révolue. Il est désormais
admis que le SI dépend de deux professions qui doivent coopérer : le maître d’ouvrage définit les
fonctionnalités du SI et surveille sa bonne utilisation ; l’informaticien est maître d’œuvre des
solutions techniques, architectures et plates formes.
Certes, il est délicat d’organiser une telle bipolarité mais il en existe d’autres dans
l’entreprise (que l’on pense aux relations entre « commerciaux » et « producteurs »). Le secret du
succès réside dans le respect mutuel entre les deux spécialités, respect qui n’interdira pas la
vigueur dans la négociation.
La première priorité est donc de renforcer la qualité de la maîtrise d’ouvrage : le risque d’échec -
ou de surcoût - est élevé si celle-ci ne sait pas définir ses priorités pour rechercher la sobriété, ou
encore si elle tente de régler des problèmes politiques à travers le SI.
La demande des utilisateurs doit être classée selon un ordre de priorité et il faut la soumettre à
une sélection sévère. Un SI sobre est intelligent et évolutif.
19
Document intitulé « Maîtrise d’ouvrage / Maîtrise d’œuvre » issu de Comment ça marche
(www.commentcamarche.net) disponible sous la licence Creative Commons
Imprimé le
Par ailleurs l’informatique passe par une phase de diversification en spécialités « pointues »
analogue à celle qu’a connue la médecine voici quelques décennies. Aucune entreprise ne peut
rentabiliser en interne toutes les compétences nécessaires à son SI, qu’il s’agisse du
développement, de l’architecture, de l’Internet ou de la sécurité. Chaque direction informatique
doit donc définir les spécialités que l’entreprise maîtrisera en interne et celles qu’elle devra
demander à des prestataires extérieurs. En outre il faudra qu’elle soit devant ces prestataires un
client compétent et non un simple gestionnaire de contrats.
3.7. La maîtrise des coûts IT
Comme le SI équipe tous les métiers de l’entreprise, il est normal que celle-ci lui consacre un
certain effort. Mais des progrès restent à faire pour maîtriser les dépenses. Dans certains cas les
entités dirigeantes sont bousculées par des phénomènes de mode au détriment des maturations
nécessaires (après avoir longtemps freiné l’utilisation de l’Internet, elles se sont au début 2000
ruées vers l’e-business).
Le coût du SI comporte non seulement les dépenses informatiques, mais aussi celles de la
maîtrise d’ouvrage qui sont moins bien connues : temps interne et assistance consacrés aux
recueils d’expertise, spécifications, validations, recettes ; au déploiement, à l’organisation, la
formation des utilisateurs, l’animation, l’administration des processus etc. Si l’attention se
focalise sur les projets, épisodes héroïques, on examine de moins près les coûts de maintenance
et d’exploitation qu’ils induiront ; le coût de détention de l’application.
L’entreprise doit connaître le coût de son SI pour décider en connaissance de cause. A partir de
cette connaissance lucide, elle pourra appliquer des règles simples : réaliser par palier, sous une
stricte contrainte de budget et de délai, cela aide à obtenir un SI sobre. Il faut aussi savoir tirer
parti des nouvelles technologies : on aurait tort de dépenser des millions d’Euros de travaux sur
système classique qui ne coûtent que quelques dizaines de milliers d’Euros avec l’Intranet.
Enfin, s’il est difficile d’évaluer la rentabilité du SI, c’est parce qu’il est devenu impossible
d’imaginer une entreprise sans SI : elle disparaîtrait ! Le SI, même s’il a un coût, est rentable. Par
contre, rien n’empêche de chercher toutes nouvelles idées de fonctionnement ou d’organisations
qui permettraient d’augmenter sa rentabilité.
3.8. Conclusion
L’analyse de la société (entreprise) et de son Service Informatique en particulier, au vu des
mutations dont il a été l’objet (passage de l’ère de l’implantation à celui de la maturité), et des
acteurs (internes ou externes) qui interviennent dans la construction d’un ouvrage ou du MCO
d’une application, avait pour dessein de mettre en avant la nécessité de faire partager le pilotage
entre deux entités la MOA et la MOE et le rôle non négligeable des SSII.
Par ailleurs, il est apparu clairement que la diversité des IT implantées dans tous les services de
l’entreprise, impose la coopération entre MOA, MOE et SSII, comme une solution

Imprimé le
incontournable. L’objectif est donc bien de gérer au mieux les projets ou les produits livrés
(MCO d’applications) et de laisser prendre la responsabilité inhérente à chacune des instances.
Par contre, la définition de l’organisation de l’entreprise et des acteurs associés n’est pas
suffisante. En effet, il est important d’analyser également le cadre méthodologique dans lequel
ces acteurs vont évoluer et quels seront les outils ou référentiels sur lesquels ils pourront
s’appuyer.

Imprimé le
4. LES CADRES THEORIQUES PERTINENTS
4.1. Introduction
Nous venons de poser le cadre du problème induit par la réalisation d’un projet, la réception de
l’ouvrage (application) correspondant et son suivi en MCO dans un contexte où l’entreprise doit
mettre en place des moyens pour que l’ensemble des acteurs de l’entreprise (MOA-MOE)
contribue efficacement au fonctionnement de son IT.
La démarche que nous allons suivre, dans ce chapitre, consiste à :
 Répertorier dans les cadres théoriques pertinents, les méthodes, pratiques et outils de
référence susceptibles d’apporter des éléments de réponse à notre problématique,
 Identifier, parmi ces cadres, les bonnes pratiques qui seraient transposables au suivi et
à l’évolution de nos applications,
 Proposer une démarche de mise en œuvre indépendante de l’organisation de
l’entreprise.
La finalité de cette étape serait de disposer d’une liste de préconisations à suivre et d’une « check
list » d’actions à réaliser et utilisable par la personne qui aurait la charge d’assurer le passage en
MCO d’une application.
L’objectif est donc de regarder les différents cadres théoriques et de s’assurer que toutes les
étapes nécessaires à garantir le MCO d’un ouvrage, de sa réception à son exploitation, peuvent
être couvertes.
Ces référentiels doivent permettre, à la MOA de piloter ses applications, mais aussi à la MOE de
préparer la gestion des applications lorsqu’elles seront en exploitation.
Bien évidemment, avant de répondre au problème de MCO, une application est passée par toutes
les étapes projets. Et si le fait de mener un projet dans les règles de l’art suffisait à ce que
l’application soit ensuite facilement évolutive ou suffisait à garantir une utilisation sans risque, il
n’y aurait aucune action à mener. Mais ce monde est, bien entendu utopique ; rares en effet sont
les applications qui ne subissent aucun incident et qui ne subiront aucun changement qu’il soit
d’ordre technique ou fonctionnel.
Nous allons donc analyser rétrospectivement les études méthodologiques qui font référence dans
le domaine et identifier celles qui pourraient être utilisées dans le cadre d’une démarche de
MCO.
Ainsi, les méthodes qui traitent notamment de l’assurance qualité, de la gestion des problèmes,
du changement, des coûts, des risques, des approvisionnements, du management des équipes,
(tout autant de processus qui concourent à la bonne gouvernance du SI et donc à la mise en place
de MCO dans des conditions optimales), sont à étudier avec attention.

Imprimé le
L’objectif ici, n’est pas de décliner toutes les étapes de la gestion de projet, ni tous les processus
liés à la gouvernance du SI mais au moins tous ceux qui y participent activement et de mesurer
leur complémentarité, de comprendre leur positionnement dans le cadre de fonctionnement de
l’entreprise et d’appréhender leur approche en matière de MCO. En d’autres termes, nous faire
une idée de ce qui est induit par l’activité de MCO d’applications naissantes et de l’aborder
sereinement en commençant par analyser les processus de gestion de projet, puis en continuant
par les référentiels complémentaires tels que CobiT, CMMi, ITIL pour les principaux.
4.2. La méthodologie de gestion de projet

Les premières réflexions sur la gestion de projet datent de l’après Seconde Guerre Mondiale.
Elles avaient pour motivation de garantir la maîtrise et la coordination des travaux de grands
projets mobilisant plusieurs corps de métiers. Ces premières ébauches ont été largement
complétées et améliorées depuis.
L’émergence de l’informatique dans l’entreprise vers la fin de l’ère de l’implantation et au début
de celle du développement, a conduit différentes associations professionnelles et organismes de
normalisation à enrichir et cadrer le sujet pour l’appliquer aux projets SI.
En matière de SI, la « gestion de projet » est un sujet traité depuis de nombreuses années. C’est
un domaine arrivé à maturité, son utilité n’est plus à démontrer, son exercice est majoritairement
bien maîtrisé et surtout clairement décrit.
Sans détailler tous les aspects liés à la gestion de projet, abordons son champ d’application, sa
couverture et tentons d’y saisir les éventuelles références à la maintenance ou tout du moins
toutes celles qui faciliteraient l’exploitabilité des applications, ou qui pourraient être utilisés dans
le cadre d’une transition vers le MCO.
4.2.1. Principes de base
En matière de gestion de projet, les auteurs de l’ouvrage « Management de projet IT » [WEKA,

2003] résument bien l’état des lieux, ce qui est communément admis par la profession : « Le plus
beau projet du monde, mal organisé et mal piloté, ne peut que donner des résultats décevants.
Sans un dispositif de gestion de projet efficace, il est difficile de garantir le succès d’une
opération de ce type ».
Un exemple de dispositif de gestion de projet efficace est celui proposé par le PMI (Project
Management Institute) à travers le guide du PMBOK (Project Management Body Of Knowledge
pour Corpus des connaissances en management de projet).
Ce dispositif est un standard reconnu par l’ANSI (American National Standards Institute,
pendant américain de l’AFNOR, Association Française de NORmalisation auprès de l’ISO,
Organisation Internationale de Normalisation) qui décrit les connaissances requises à l’exercice
de la gestion de projet. Le guide PMBOK comporte trois parties.

Imprimé le
4.2.2. Les trois parties de PMBOK
La partie I définit le contexte en posant le « Cadre du management de projet ». On y trouve la

définition de termes clés et une description de l’environnement dans lequel se déroule un projet :
la connaissance du champ d’application, des normes et réglementations ou la compréhension de
l’environnement du projet.
Cette partie peut tout à fait être reprise dans le cadre du MCO d’application. En effet, l’équipe en
charge de MCO doit également connaître l’environnement dans lequel évolue son application.
D’ailleurs, certains des éléments peuvent être repris de la phase projet.
La partie II s’attache à décrire les cinq groupes de processus de management d’un projet :
Démarrage
Planification
Surveillance
Exécution
et maîtrise
Clôture
Les cinq groupes du processus de management de projet
Un groupe de processus est un ensemble de processus élémentaires reliés entre eux par leurs
données d’entrée et de sortie. Chaque groupe de processus est spécialisé, ainsi, celui de :
 « Démarrage » définit et autorise le projet ou une phase du projet s’il est de grande
taille.
 « Planification » affine les objectifs et planifie le déroulement des actions nécessaires
à leur atteinte.
 « Exécution » intègre l’ensemble des ressources pour une bonne exécution du plan de
management du projet.
 « Surveillance et maîtrise », telle une vigie, est le dispositif qui cherche à éviter tout
écart et, le cas échéant, à en permettre la correction pour maintenir l’atteinte des
objectifs du projet.
 « Clôture » conclut le projet (ou une de ses phases) par formalisation de l’acceptation
du (ou des) livrables(s).
Dans l'ensemble des groupes de processus et de leurs processus, les données de sortie des
processus sont en relation entre elles, et ont un impact sur les autres groupes de processus.

Imprimé le
Ce principe d’interactions a pour effet que chaque groupe de processus n’est pas indépendant des
autres. Leur bonne exécution se traduit par un chevauchement :
Interactions des groupes de processus dans un projet selon le PMBOK
Ici encore, lorsque l’équipe en charge du MCO doit gérer une évolution, elle peut tout à fait
suivre ces processus. Elle s’inscrit comme une phase projet d’un gros projet.
La partie III décrit l’ensemble des processus élémentaires des groupes de processus et les
organise à travers neuf domaines de connaissances :

Imprimé le
Vue d’ensemble des domaines de connaissance d’après le PMBOK
Pour être en phase avec l’approche la plus récente des associations professionnelles, il faut
préciser que la gestion de projet relève, avec la conduite de projet, de la fonction de management
de projet. Cette dualité conduite/gestion est motivée par la séparation de rôles dès lors que les
activités respectives pouvaient éventuellement être jouées par des personnes ou des entreprises
différentes. Elle a été proposée comme vocabulaire normalisé par l’AFITEP (Association
Francophone de Management de Projet) et l’AFNOR20 (Association Française de
NORmalisation) ».
Il n’est pas rare que les rôles soient attribués à des personnes différentes. La conduite de projet
est une activité assurée par une personne dont le rôle est de donner les orientations, prendre les
20
http://www.afitep.fr et http://www.afnor.org
Imprimé le
décisions propres au bon fonctionnement de la structure de projet. C’est en général un directeur

de projet ; on dit qu’il assure le pilotage.
Les caractéristiques de la gestion de projet sont plutôt de faire vivre le projet, de collecter et de
préparer les informations nécessaires à la prise de décision. Elle est assurée par le chef de projet.
Cette fonction se retrouve aussi sous les appellations « responsable de projet », « gestionnaire de
projet » selon les différentes classifications des emplois dans les entreprises.
Les deux fonctions peuvent être confondues et assurées par une seule et même personne21. C’est
souvent le cas pour les petits projets SI ou lors de la gestion des évolutions sur une application.
Il n’est pas rare, non plus, qu’il existe deux chefs de projet, un qui appartient à la MOA et un
deuxième qui appartient à la MOE. Cette bicéphalie revêt l’avantage d’une meilleure cohésion
entre MOA et MOE, fluidifie la circulation de l’information entre les deux structures, et sécurise
la MOA dans sa vision de l’avancement du projet. Ce constat est bien en phase avec le résultat
de l’analyse des entités MOA-MOE du chapitre précédent.
La liste des activités principales, des domaines de connaissances du PMBOK, met en avant que
mener un projet SI ne nécessite pas uniquement des compétences informatiques. Les rubriques
« ressources humaines » ou « communications » en sont un exemple. La nécessaire
compréhension, que doit avoir un responsable de projet, de l’environnement du projet en est une
autre.
De plus, dans le cas de séparation des entités, la définition des rôles et des responsabilités est
primordiale.
Ainsi, l’adaptation au MCO de cette partie est la suivante :
1. La phase de transition avec les processus élémentaires suivants :
 Management des coûts du projet
 Management des approvisionnements du projet
 Management de la qualité du projet
2. La phase de gestion des changements avec les processus suivants :
 Management des ressources humaines du projet
 Management des risques du projet
 Managements des communications du projet
Regardons plus précisément chaque processus élémentaire.
21
Au Pôle Clients du CSI, ces deux fonctions sont assurées par le POA (Pilote Opérationnel Applications)
Imprimé le
4.2.2.a) La phase de gestion des changements
Vue d'ensemble du management des coûts du projet
Chacune des activités du « Management des coûts de projet » peut être adaptée au MCO de
façon plus ou moins approfondie. De base, « l’estimation des coûts » reprend les éléments liés
aux évolutions potentielles de l’application faite selon des outils et techniques d’estimation par
analogie.
De même l’activité de « Budgétisation » est celle qui permet d’estimer le budget nécessaire aux
travaux d’évolutions en tenant compte d’éléments tels que des coûts de références.
Ces deux premiers points permettent d’estimer une enveloppe de maintenance évolutive utile
lorsqu’il faudra élaborer le cahier des charges nécessaire à notre besoin de mise en place d’une
TMA (Tierce Maintenance Applicative).
Le dernier point, la «Maîtrise des coûts » permet, en phase de MCO de mesurer le coût de
réalisation de la maintenance par rapport au coût budgétisé.

Imprimé le
Vue d'ensemble du management des approvisionnements du projet

Imprimé le
L’ensemble de ces activités, comme précédemment, est à décliner lors de la phase de transition.
L’objectif est de préparer, de planifier et de lancer les appels d’offres de recherche de TMA. En
effet, avant toute commande d’approvisionnement, il est impératif de lancer un appel d’offre
pour choisir le meilleur prestataire selon des critères définis préalablement. Cette action est
longue et assez laborieuse et doit être anticipée.
Management de la qualité du projet
Que l’on soit en phase projet ou en phase MCO, l’activité de « Management de la qualité » est
aussi importante. Elle se traduit par la mise en place d’un plan qualité produit, par l’identification
d’indicateurs de mesure de la qualité du MCO, et par la mise en place de moyens de contrôle
constitués de bilans d’activité, de retour d’expérience ; autant d’outils qui permettront
d’identifier par exemple les actions préventives.
Imprimé le
4.2.2.b) La phase de gestion des changements
Management des ressources humaines du projet

Imprimé le
L’activité de « Management des ressources humaines du projet » se focalise sur l’équipe projet et
ce, même en mode MCO.
Management des risques du projet
Toutes les rubriques du management des risques sont aussi à appliquer dans le cadre des
développements induits par des changements. Il est donc tout à fait envisageable d’utiliser les
mécaniques de ce processus dans le cadre de MCO. En effet, les risques liés à une interruption de
service ou à une régression de fonctionnement sont à anticiper, d’autant plus lorsque
l’application est en exploitation.

Imprimé le
Management des communications projet
Enfin, l’activité de « Management des communications du projet » souligne que « les processus
mis en œuvre apportent les liens indispensables entre les gens et les informations nécessaires à
une communication réussie ». Cette communication est évidemment aussi importante en phase
de MCO.

Imprimé le
Ainsi, le management des relations interpersonnelles comprend les éléments suivants :

 Une communication efficace, à savoir la maîtrise de l'échange d'informations,
 L'influence sur l'organisation, en quelque sorte la capacité de « faire faire les choses
»,
 L'aptitude à diriger, en sachant développer une vision et une stratégie, et motiver les
personnes pour réaliser cette vision,
 La motivation, afin de stimuler l'énergie nécessaire pour atteindre de hauts niveaux
de performance et surmonter les obstacles au changement,
 La négociation et la gestion des conflits, en sachant conférer avec d'autres personnes
pour s'entendre ou parvenir à un accord,
 La résolution des problèmes, qui comprend la définition du problème,
l'identification et l'analyse d'alternatives, et la prise de décision.
4.2.3. Conclusion sur l’application de la gestion de projet au MCO
La démarche du PMBOK peut être utilisée dans le cadre du passage d’un projet en application et
notamment pour réaliser les opérations telles que la gestion des approvisionnements (lancer un
appel d’offre de TMA pour assurer le MCO), la gestion du management d’équipe (pour mettre
en place l’équipe adéquate), la gestion des coûts (pour définir le coût prévisionnel de la TMA et
maîtriser les dépenses), la gestion des risques (pour maîtriser un maximum de risques liés aux
changements subis par l’application), la gestion globale du projet (pour piloter les évolutions de
l’application), la gestion qualité du projet (pour s’assurer de l’efficacité du MCO) et pour finir la
gestion de la communication.
Ainsi le MCO d’applications peut, comme les projets, être divisé en composants plus faciles à
gérer. Les sous projets sont souvent donnés en sous-traitance à une entreprise externe ou à un
autre service fonctionnel de l'entreprise réalisatrice. On peut citer les exemples suivants :
 Les sous-projets basés sur le processus du projet, tels qu'une phase spécifique du cycle
de vie du projet,
 Les sous-projets qui sont fonction d'exigences de compétences des ressources
humaines, voire la Tierce Maintenance Applicative en terme de SI,
 Les sous-projets impliquant une technologie spécialisée, tels que les tests automatisés
de programmes informatiques dans un projet de développement de logiciel, Tierce
Recette Applicative (TRA).
Le lien entre le projet et le produit est représenté par les 2 schémas suivants :

Imprimé le
Relations entre le cycle de vie du produit et celui du projet
Le détail du cycle de vie du projet
La description initiale du contenu et les ressources que l'organisation est disposée à investir sont
de nouveau affinées lors du processus de démarrage. Le chef de projet est alors sélectionné s'il
n'est pas déjà affecté. Les hypothèses et les contraintes initiales vont aussi être documentées à
nouveau. Le cycle de vie du projet est une phase répétitive de la vie du produit et est géré en
MCO.
4.3. Les cadres méthodologiques complémentaires

Comme nous l’évoquions en début de chapitre, au-delà de la gestion de projet « pure », il existe
des concepts connexes et complémentaires qui renforcent un dispositif déjà bien fourni.
Intéressons nous maintenant à la façon dont ils soutiennent la gestion de projet et s’ils
s’appliquent au MCO en matière de gestion des SI.

Imprimé le
Bien souvent dans les entreprises ces démarches, complémentaires à la gestion de projet
proprement dite, sont mises en œuvre et assurées par des structures de supports aux projets.
Les intervenants sont spécialisés et maîtrisent les sujets (qualité, risques, sécurité, contrôles,
changement, …) qui définissent en quelque sorte le cadre de fonctionnement au sein duquel il
faut s’inscrire.
Le concept de gouvernance s’applique au niveau de l’entreprise dans sa globalité mais aussi au
niveau du seul système d’information. Elle permet de répondre aux nouveaux enjeux de la
politique de management des ressources IT.
C’est ce que l’on appelle « Gouvernance des SI » qui peut se définir comme : « une conséquence
du mécanisme de Gouvernance d’Entreprise visant à réduire les risques opérationnels engendrés
par les technologies de l’information à travers des processus d’audit et de contrôle, destinés à
garantir l’intégrité, la complétude et la traçabilité des informations »22 .
La mise en œuvre de ces « bonnes pratiques » est basée sur les outils méthodologiques qui
couvrent les différents sous-systèmes de l’entreprise.
En ne citant que certains de ces cadres, de ces outils, le schéma que nous nous proposerions de
construire serait :
AMELIORER
Apports méthodologiques
CMMi
CONTROLER
DOCUMENTER
CobiT ITIL
MODELISER
ORIENTER DECIDER CONSTRUIRE DEPLOYER OPERER

Activités SI
Contribution des outils méthodologiques de référence
Ce schéma n’est pas exhaustif. Il existe d’autres outils méthodologiques23 qui ne seront pas
évoqués ici.
Nous allons juste appréhender de manière synthétique l’apport complémentaire de CobiT, CMMi
et ITIL en regard des activités SI, et du MCO en particulier.
22
« IT Gouvernance » de F Georgel – page 24
23
« IT Gouvernance » de F Georgel
Imprimé le
4.3.1. CobiT
CobiT pour Control Objectives for Information and Technology est un cadre méthodologique qui
propose « un ensemble de moyens très puissants pour gérer les niveaux de contrôle devant être
exercés sur les ressources IT afin que ces dernières soutiennent efficacement la réalisation des
objectifs de l’entreprise »24 .
4.3.1.a) Origine
Ce cadre méthodologique a été développé, mis au point et maintenu par l’ISACA (Information
Systems Audit and Control Association). L’ISACA est une association internationale implantée
aux Etats-Unis qui effectue des travaux de recherche et des études dans le domaine de l’analyse
et des méthodes de contrôle des SI.
Il existe une version française de CobiT. Elle est réalisée par l’AFAI (Association Française de
l’Audit et du conseil Informatiques). L’AFAI, créé en 1982, est le chapitre français de l’ISACA
et le représentant de l’ITGI (Information Technology Governance Institute), centre de recherches
de l’ISACA. La dernière version de Cobit a été présentée aux Etats-Unis en décembre 2005 ;
c’est la « version 4 ».
4.3.1.b) Périmètre d’application
L’objectif de la gouvernance est de comprendre et de gérer les risques liés aux IT.
Les points clés, mis en avant par l’AFAI, pour mettre en œuvre CobiT dans une entreprise sont
que :
 L’entreprise ait une stratégie claire qui fixe les objectifs à atteindre,
 Les directions métiers traduisent et enrichissent ces objectifs en fonction de leur type
de contribution (les objectifs du marketing ne sont pas les mêmes que ceux de la
logistique),
 Les objectifs métiers soient traduits en objectifs SI,
 Ce « plan de bataille » fasse l’objet d’un suivi et d’un contrôle qui assurent le maintien
du bon cap (identifier et éviter les dérives voire apporter les corrections nécessaires si
la dérive est amorcée).
CobiT ne s’adresse donc pas seulement à la DSI mais aussi aux directions métiers et aux
directions générales. Son positionnement se situe au niveau de la gouvernance ; gouvernance
d’entreprise comme gouvernance des SI.
Si cela peut paraître évident, rien ne sert d’espérer mettre en œuvre CobiT et d’en tirer quelque
bénéfice s’il n’y a pas de stratégie.
24
« IT Gouvernance » de F Georgel – chapitre 15
Imprimé le
Bien évidemment toutes ces opérations, tous ces programmes ou projets de transformation du SI
doivent faire l’objet d’une gestion de priorités et être suivis dans leur mise en œuvre.
La feuille de route que propose CobiT est un ensemble de préconisations qui s’articulent autour
de quatre thèmes principaux :
 PO pour Planifier et Organiser : domaine de la stratégie de l’entreprise,
 AI pour Acquérir et Implémenter : domaine de la stratégie du système d’information,
 DS pour Délivrer et Supporter : domaine opérationnel de fourniture des services aux
utilisateurs,
 SE pour Surveiller et Evaluer : domaine du contrôle et de l’évaluation de la
performance et de la qualité.
Chaque thème, ou domaine, regroupe les processus clés qui lui sont propres. Le nombre de
processus total est de trente quatre.
La figure qui suit montre ce principe de décomposition25 :
25
document traduit de l’AFAI
Imprimé le
Cadre de référence général de CobiT (source AFAI)
Le schéma traduit aussi l’importance qu’est la compréhension de l’utilité et de la contribution

que doit avoir, et a, le SI de l’entreprise dans sa contribution à la stratégie globale.
CobiT aide les dirigeants à évaluer les risques et à contrôler les investissements dans un
environnement informatique souvent imprévisible. Il permet ainsi de vérifier que la gouvernance
des systèmes d’information est cohérente avec celle de l’entreprise, on parle alors d’alignement
stratégique.
Au-delà des processus, CobiT détaille chacun d’eux en activités. Il y en a au total deux cent vingt
que nous n’aborderons pas ici.
L’objectif ici est de mettre en place des processus qui permettent à chacun des acteurs
(MOA/MOE) de maîtriser ses actions et plus précisément à la MOA de piloter son SI (d’avoir les
Imprimé le
cadres pertinents pour piloter ses ouvrages) et à la MOE de pouvoir s’appuyer sur sa MOA pour
toutes activités à la périphérie de son domaine de compétences et de responsabilités : « Chacun
ses responsabilités pour avancer sereinement et efficacement ».
4.3.1.c) CoBiT et le MCO
Même si tous les processus peuvent potentiellement être adaptés, certains d’entre eux sont à
mettre en avant plus précisément dans le cadre du MCO d’applications.
Ce sont par exemple, « surveiller et évaluer la performance SI », « S’assurer de la conformité
réglementaire » « Mettre en place une gouvernance SI », « Gérer la qualité », « Evaluer et gérer
les risques », « Gérer les changements», « Gérer les problèmes », « Acquérir les applications et
en assurer la maintenance », « Installer et valider les solutions et les modifier », « Faciliter le
fonctionnement et l’utilisation », « Définir les processus, l’organisation et les relations de
travail » pour les principaux.
Une attention particulière est à apporter cependant aux processus « Gérer les changements »,
« Gérer les problèmes », qui précise un objectif général et les objectifs de contrôle détaillés.
L’objectif général est ici la maîtrise des changements apportés sur l’environnement de
production pour en garantir la stabilité. Les objectifs de contrôle détaillés mettent en avant :
 L’importance de procédures formelles de gestion des changements de leur
standardisation,
 La nécessité de prioriser les changements en fonction de leur importance et
d’impliquer le demandeur par son autorisation formelle,
 L’existence d’une procédure particulière pour mettre en œuvre les modifications
d’urgence,
 La contrainte de documentation pour communiquer à toutes les parties prenantes sur
l’état d’avancement du changement et acter de son achèvement.
Un des instruments que fourni le guide de management est un tableau RGCI (Responsable,
Garant, Consulté et/ou Informé) qui identifie le niveau de responsabilité pour chaque fonction
par activité.
Le dernier instrument donné pour chaque processus, est la liste des indicateurs de mesure qui
permettent d’évaluer la performance de l’exercice et d’en assurer le contrôle.
La dernière rubrique concerne le modèle de maturité. C’est une échelle à cinq niveaux qui
permet d’évaluer le degré de maîtrise du processus : de « inexistante » à « optimisée ». Cette
évaluation de la maturité au niveau de chaque processus permet, par consolidation, une
évaluation au niveau de chaque domaine puis à celui de l’entreprise. Le niveau de maturité
donne une indication de la qualité de l’alignement du système d’information à la stratégie de
l’entreprise.

Imprimé le
Un autre point important est la mise en place et la maintenance opérationnelle d’une structure de
coordination, de communication et de liaison optimale entre la fonction informatique et divers
autres professionnels à l’intérieur et à l’extérieur de cette fonction, comme le conseil
d’administration, la direction générale, les unités opérationnelles, certains utilisateurs, les
fournisseurs, les responsables de la sécurité, les responsables de la gestion des risques, le groupe
responsable de la conformité dans l’entreprise, les responsables chargés des prestations externes
(externalisation et sous-traitance). Ce point peut être complémentaire au processus de gestion de
projets de « Management des communications ».
Pour conclure ce focus sur CobiT, si nous ne devions retenir qu’une préconisation, ce serait celle
donnée, sous forme d’avertissement, par l’ITGI au début de son guide : « l’utilisation de CobiT
ne garantit pas de produire de façon certaine un résultat positif ».
L’idée qui veut que la qualité d’un outil soit fonction, plus de l’usage qui en est fait que de sa
façon d’être respectée !
Ce point n’est pas anodin ; il est valable pour tous les référentiels. En effet une méthode pose les
bonnes questions ; elle ne donne pas les bonnes réponses.
En conclusion de CobiT, nous dirions qu’il s’agit d’un outil :
 Plutôt de préoccupation stratégique, orienté audit qui atteste de l’importance que revêt
le SI pour l’entreprise,
 Et que d’un point de vue MCO, il donne une marche à suivre pour maîtriser au
maximum les changements et les incidents (de même qu’en gestion de projet, le fait
d’appliquer une méthodologie ne garantit pas un MCO de qualité)
4.3.2. CMMi
CMMi, pour Capability Maturity Model Integration (Modèle de Maturité de Capacités Intégré),
traite de l’ingénierie du logiciel, des systèmes, du développement intégré de produit ou de
processus, et de la gestion des fournisseurs.
Bien que spécifique à l’ingénierie des systèmes et du logiciel, il s’agit d’un modèle de maturité
qui est généralisable à d’autres activités comme le développement de matériel, l’assistance
client, les acquisitions, etc.
Il concerne tous les processus liés aux affaires et aux projets, du développement jusqu’à la
préparation de la production en série. Il s’intéresse aux processus de support du management afin
de s’assurer que les processus métiers disposent bien des moyens et ressources nécessaires.
4.3.2.a) Origine
Le modèle CMMi a été développé à la fin de la dernière décennie quatre vingt par le SEI
(Software Engineering Institute ou Institut de l’Ingénierie Logiciel) à la demande du département
américain de la défense (le DoD). Le DoD jugeait nécessaire de pouvoir évaluer ses fournisseurs

Imprimé le
informatiques en regard des bonnes pratiques relatives au « génie logiciel » (i.e. l'ensemble des
activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser
la production d’un logiciel et son suivi).
Les thèmes, les domaines particuliers des modèles de départ abordent par exemple :
 La maturité des développements logiciels (en fait le premier modèle),
 La maîtrise des processus d’ingénierie,
 La capacité d’acquisition de logiciels (faire le bon achat),
 L’évaluation des fournisseurs de logiciels,
 …
La dernière version de CMMi est la version 1.2.
En première analyse nous pouvons dire que l’approche CMMi est de nature périphérique au
thème de la gestion de projets SI. Elle propose à l’entreprise une démarche qui lui confère le
niveau de maturité nécessaire à la meilleure façon de mettre en œuvre ses projets SI.
En d’autres termes, CMMi permet de mesurer si une organisation, une entreprise, dispose des
compétences requises pour délimiter ses projets, s’assure de leurs bonnes spécifications
(périphérie de l’amont du projet), et du bon usage des produits délivrés (périphérie de l’aval au
projet).
La démarche est basée sur un système d’évaluation des bonnes pratiques nécessaires : comment
gagner en maturité en matière de développement logiciel (qualité, fonctionnalité, coût et délai).
Une particularité du CMMi est qu’il possède deux niveaux de représentation26
Représentation par niveau Représentation continue
(niveau de maturité) (profil d’aptitude)
 Cinq niveaux de maturité  Six niveaux d’aptitude par domaine de

processus
 Un comportement organisationnel
vraiment différent à chaque niveau  Un algorithme qui donne la maturité
organisationnelle
 Un ensemble de domaines de processus
à chaque niveau  Sélection des domaines de processus
selon ses besoins et priorité
 Une façon simple d’exprimer un but à
atteindre
=> priorité à la vision organisationnelle => priorité à la vision processus
26
Guide des certifications SI –p 33
Imprimé le
Le SEI précise ces différences en indiquant que

 La démarche par étapes envisage une évaluation globale de l’organisation dont on
mesure le niveau de maturité,
 La démarche continue propose de mesurer des niveaux de capacité par grande
catégorie de processus (gestion de processus, gestion de projet, ingénierie et support).
Pour mieux se représenter ces différences, nous pourrions dire que pour la démarche par étapes,
l’entreprise doit progresser globalement du niveau de maturité le plus bas vers le plus élevé. Pour
la seconde, démarche continue, il peut exister un décalage de niveau de capacité entre les
catégories de processus (la capacité de l’entreprise peut être plus avancée dans l’une par rapport
aux autres) qui ne remet pas en cause l’ensemble.
Le nombre de niveaux varie selon la démarche considérée :
Niveau Niveaux de maturité de Niveaux de capacité de
la démarche par étapes la démarche continue
0 N/A Incomplet
1 Initial Pratiqué
2 Reproductible Reproductible
3 Défini Défini
4 Maîtrisé Maîtrisé
5 Optimisé Optimisé
Niveaux de maturité CMMi selon la démarche
CMMi couvre un ensemble de vingt-deux domaines d’application. Chaque domaine considéré

fait l’objet d’une description :
 De son but,
 De sa couverture,
 Des autres domaines auxquels il est lié.
La gestion de la planification, la gestion des risques, la gestion des achats, la gestion
développement et, la gestion du changement, sont des exemples de domaine.
Chaque domaine d’application est détaillé par les objectifs visés, par les pratiques à mettre en
œuvre et les produits résultants.
Ainsi, un objectif visé peut être d’ordre général ou spécifique. S’il est d’ordre spécifique, il ne
s’applique qu’à lui même, par contre s’il est d’ordre général, il sera commun à plusieurs
domaines. Par exemple, le « lancement de la réalisation », la « Capacité de réaliser », la
« Conduite de mise en œuvre », etc. sont des objectifs communs à presque tous les domaines
La capacité, à atteindre à l’aide des domaines de connaissance, est évaluée par niveaux. Les cinq
niveaux de maturité de la démarche par étapes qualifient la maîtrise de la gestion de projet pour
une organisation :
Imprimé le
Niveau 1 caractérise une organisation plutôt habituée à subir les dépassements (délai,
« initial » coût), la non-qualité des produits livrés. Les situations de crises se répètent et
les succès restent exceptionnels. De ce fait, aucun domaine d’application
n’est associé à ce niveau ; il n’implique pas de pré-requis.
Niveau 2 désigne une organisation capable de gérer les exigences, planifier et répartir
« reproductible » la charge de travail, assurer la qualité des produits.
Niveau 3 est celui d’une organisation qui sait capitaliser sur ses expériences. Les
« défini » processus de gestion existent, sont mis en œuvre, maîtrisés et assurent une
bonne cohérence des différents intervenants. C’est à ce niveau qu’une
organisation dispose d’une méthode standard de gestion de projets.
Niveau 4 confère à l’organisation un caractère plus efficient qu’efficace. Les

« maîtrisé » indicateurs qui permettent différentes mesures existent et sont utilisés.
Niveau 5 est celui où la seule maîtrise des processus de gestion ne suffit plus.
« optimisé » L’organisation cherche l’amélioration continue de ses processus, de ses
méthodes et se met en situation de pouvoir anticiper.
La totalité des vingt deux domaines d’application n’est pas considérée à chaque niveau de
maturité ; on ne progresse pas sur la totalité en fonction du niveau atteint.
A chaque niveau de maturité correspondent des domaines d’application particuliers que
l’organisation doit maîtriser pour l’atteindre.
C’est au niveau cinq de maturité que l’ensemble des vingt deux domaines est couvert. Les
niveaux deux et trois sont ceux auxquels correspondent le plus de domaines d’application.

Imprimé le
Maîtrise du changement
5 : En optimisation
Amélioration continue
Performance
Mesure/Prévision
4 : Géré quantitativement
Processus prévisible
Standardisation
3 : Défini
Processus standardisé
Structuration
2 : Géré
Risque
Processus organisé
1 : Initial
Processus non défini
Les cinq niveaux de maturité de CMMi
Au-delà du premier niveau, qui peut être vu comme un ensemble de « mauvaises pratiques »,
chaque niveau est un palier de mise en œuvre des bonnes pratiques des domaines d’application
requis.
Le niveau deux considère ce qui se passe du point de vue de la réalisation des projets SI. Le
niveau trois élargit le champ vers l’amont et l’aval de la réalisation.
Les deux derniers niveaux portent sur la maîtrise et l’amélioration continue de l’ensemble (nous
pourrions dire que mettre en œuvre CMMi c’est procéder par expansion).
4.3.2.c) CMMi et le MCO
De part le processus de gestion de configuration, le CMMi est bien adapté à la gestion des
évolutions aussi bien fonctionnelles que techniques.
La considération faite du MCO par le CMMi porte sur l’aspect infrastructure informatique ;
l’environnement de production. En effet, cet aspect sera traité par la capacité de la TMA à gérer
les changements et à répondre rapidement aux incidents de fonctionnement dans le cadre du
MCO.
En synthèse de cet aperçu de CMMi, nous pourrions dire que c’est un référentiel qui considère
les moyens de réaliser correctement les projets informatiques sans être une méthode de conduite
de projet ; il se positionne donc plutôt au niveau des études informatiques, ou de la TMA lorsque
ses études sont externalisées.
4.3.3. ITIL
ITIL pour Information Technology Infrastructure Library est un ensemble de bonnes pratiques
présentées sous forme de livres. Plus précisément, il s’agit d’un recueil de « conseils et
recommandations qui s’appuient sur la pratique et la maîtrise du système d’information,

Imprimé le
orientés vers le client pour tendre vers l’excellence opérationnelle par le déploiement de
processus » [Lettre d’information ITIL]27. On parle généralement de bibliothèque ITIL.
4.3.3.a) Origine
Ce référentiel de bonnes pratiques est édité par l’OGC (Office of Government Commerce),
Office public Britannique du Commerce et, contrairement à d’autres, relève du domaine de
l’OSL (Open Source Library). Cela signifie que l’OGC n’en est pas le seul auteur ; des groupes
de travail issus d’autres structures contribuent à ITIL et contrôlent les termes et conditions de
distribution de leurs créations28.
ITIL a été initié au début des années 1980 par le gouvernement britannique afin d’améliorer le
service rendu par les différents services informatiques de l’état. C’est un dispositif élaboré et
enrichi par des praticiens alors que d’autres le sont plutôt par des utilisateurs (il faut comprendre
des « personnes qui n’ont qu’une vision théorique »).
Depuis sa création, la bibliothèque a vu le nombre de livres se réduire. Il est, dans sa version
deux, au nombre de sept. Les deux livres les plus significatifs, d’ITIL, sont le :
 Fourniture des services qui traite des thèmes de « Gestion des contrats de service »,
« Gestion transversale des problématiques communes à tous les contrats de service »
et « Gestion financière »,
 Support des services qui aborde les thèmes de « Prise d’appels », « Résolution des
dysfonctionnements », « Gestion des évolutions », « Application des contrats de
service », « gestion des incidents ».
La version trois d’ITIL a été présentée en mai 2007. Le nombre de livres diminue encore :
ITIL version 2 ITIL version 3 (mai 2007)
Perspective de l’entreprise Stratégie des services
Fourniture de services Conception des services
Gestion de la sécurité Mise en production des services
Planification et mise en œuvre de la Exploitation des services
gestion de services
Gestion des applications Evaluation continuelle des services
Support des services
Gestion des infrastructures informatique
Livres ITIL - version 2 vs version 3
27
La lettre d’information (ou newsletter) ITIL est rédigée par Christian NAWROCKI et publiée sur internet à
l’adresse http://www.newsitweb.info
28
La distinction entre « Open source » et logiciel libre est clairement précisé par F GEORGEL dans son ouvrage
« IT Gouvernance », chapitre 16.
Imprimé le
L’objectif d’ITIL est de fournir aux DSI les outils leur permettant d’améliorer la qualité des
services rendus à leurs clients (les directions métiers). Ce n’est pas incompatible avec le principe
de contribution aux objectifs de stratégie de l’entreprise. Elles ont, de plus, été largement
éprouvées dans le monde industriel.
Il y a fort à parier que les techniques de maintenance des outils d’une ligne de production, qui
doit être opérationnelle vingt quatre heures sur vingt quatre, soient applicables à des matériels de
centres de calculs (on utilise aussi l’anglicisme Data Center) et surtout tout aussi efficaces. Ce
parallèle industriel permet de souligner un des intérêts de la démarche ITIL : donner à
l’entreprise une capacité de mise en ordre de marche et de mobilisation de ses moyens (dont font
partie les infrastructures du SI) lorsqu’elle doit mener la « bataille » de mise en œuvre de sa
stratégie.
Les objectifs d’ITIL y contribuent en :
 Alignant les services informatiques aux besoins actuels et futurs de l’entreprise et de
ses clients (pas qu’au sens utilisateurs internes),
 Améliorant la qualité et réduisant les coûts des services fournis par l’infrastructure,
 Augmentant le taux de disponibilité et la productivité des ressources,
 Réduisant les coûts de fourniture des services à long terme,
 Proposant une démarche évolutive basée sur les processus au sens dispositif de
transformation.
En d’autres termes ITIL vise, pour les entreprises qui l’adoptent, à améliorer la qualité globale de
la production informatique et la rendre perceptible par les utilisateurs.
4.3.3.c) Les bénéfices de la démarche ITIL
Etant donné que la démarche ITIL propose un référentiel des meilleures pratiques, les plus
values de sa mise en œuvre, généralement constatées sont la :
 Satisfaction des utilisateurs (personnel et clients),
 Clarification des rôles,
 Amélioration de la communication inter-services,
 Mise sous contrôle des processus avec des indicateurs pertinents et mesurables,
permettant d'identifier les leviers pour réaliser des économies,
 Meilleure compétitivité,
 Sécurité accrue (disponibilité, fiabilité, intégrité),
 Capitalisation des données de l'entreprise,
 Optimisation de l'utilisation des ressources,
 Outil de parangonnage (benchmarking) et outil de positionnement vis-à-vis de la
concurrence.

Imprimé le
4.3.3.d) ITIL et le MCO
En terme de MCO, le livre « Supports des Services » vise à répondre aux problèmes de gestion
opérationnelle (traiter les erreurs connues) et à assurer le maintien du bon alignement de la
production des services (rendus) avec l’exigence de services (attendus) des directions
utilisatrices.
Les changements apportés au niveau de l’infrastructure globale (matériels, logiciels, réseaux,
contrats de services et documentation qui en découlent) sont clairement identifiés comme une
des principales causes d’arrêt non planifié au niveau des infrastructures. ITIL détaille donc les
moyens de répondre de la meilleure façon aux problèmes rencontrés (c’est un lien avec le
processus de gestion des incidents29) mais aussi de se prévaloir de conséquences indésirables
causées par l’application de changements.
La gestion des changements induite par le MCO est :
 L’enregistrement et le filtrage des demandes : cette première fonction a pour objet la
traçabilité des demandes de changements. Elles peuvent être acceptées ou rejetées
mais doivent toujours être enregistrées ; c’est la notion de RFC (Request For Change
ou Demande de changement).
 La gestion des priorités : fonction dont l’objet principal est d’assurer une planification
des changements à apporter en regard de leur impact sur l’architecture et surtout de
leur urgence.
 La gestion des catégories : la catégorisation des demandes de changement permet leur
classement à partir de l’estimation de l’effort à consentir pour les mettre en œuvre.
 La planification : comme pour toute activité bien menée, un planning de gestion des
changements donne une vision globale des interventions à mener. La planification
facilite aussi l’analyse d’impacts en cas d’intervention urgente à mener.
 Le développement, les tests et l’implémentation : comme pour les développements
applicatifs, la mise en œuvre d’un changement technique ne se fait pas sans un
minimum de précautions, de garantie. L’objet de cette fonction clé est d’attester de la
bonne maîtrise du changement (au sens procédures de mise en œuvre comme au sens
de son effet) sur un environnement le plus proche possible de celui de production. La
disponibilité d’un environnement représentatif de celui de production relève plus
souvent d’un vœu pieux que d’une réalité avérée. Les coûts d’acquisition et de
détention d’un environnement de « pré-production » ont souvent du mal à trouver une
justification aux yeux de ceux qui tiennent les cordons de la bourse …
Ces fonctions clés relèvent d’une approche plutôt orientée « technique ». Même si ITIL est
clairement positionné du point de vue production (i.e. le sous-système opérant), le référentiel ne
29
Décrit dans « ITIL la gestion des services » -p 161-164
Imprimé le
néglige pas l’aspect de la relation avec les objectifs des directions métiers. Il le fait à travers trois
autres fonctions clé :
 L’analyse d’impact : cette fonction a pour objet de comprendre les effets de bord que
pourrait avoir une demande de changement du point de vue des directions métiers
mais aussi des autres engagements inhérents à la continuité du service offert. Un
exemple pourrait être la mise à niveau, la « montée de version », d’un système de
gestion de base de données. Si une telle évolution n’est pas sans risque, vis à vis de la
mise en production programmée d’une nouvelle application, il sera
vraisemblablement opportun de la différer.
 L’approbation : le principe de cette fonction clé est d’appréhender, en plus de la partie
technique, les aspects coût et portée fonctionnelle de la demande de changement. Ces
compléments d’analyse contribuent à la qualification de la demande ; l’approuver ou
pas.
 Le comité de gestion des changements30 : au même titre qu’un projet, les changements
font l’objet d’une gestion digne de ce nom. C’est pourquoi il existe, en la matière, une
instance de type comité (comme il y a un comité de gestion de projet) composé de
membres permanents, ou non, qui procède aux arbitrages nécessaires : le CAB
(Change Advisory Board). Une autre de ses fonctions, qui rejoint en cela les
approches précédemment abordées de CobiT et CMMi, est l’analyse « a posteriori ».
C’est ce qui permet d’identifier et de comprendre les causes d’échecs et donc
d’améliorer le processus lui-même.
4.3.4. Synthèse des référentiels analysés
L’aperçu que nous venons de faire de ces trois référentiels « de base » permet de se faire une
idée assez précise de leurs complémentarités et de leurs relations à la gestion de projet.
L’organisation informatique doit disposer des bonnes méthodes et des bons outils pour rassurer
ses clients et accroître sa performance.
Rappelons que CobiT couvre l’ensemble des activités du IT, c’est un outil de gouvernance
remarquable, cependant sa mise en œuvre est semée d’embûches.
CMMi est une méthode d’organisation pour le développement et la maintenance d’applications
afin de fournir un code de qualité et la documentation associée.
Et ITIL est un référentiel de meilleures pratiques dans la gestion des services.
La norme ISO 9000, non décrite précisément ici, est cependant le socle sur lequel s’appuient les
autres référentiels. Elle est issue de l’industrie et est un standard en terme de gestion de la qualité
dans le cadre des « Exigences qualité du client », « Exigences de mise à jour et d’applications »,
« d’Augmentation de la satisfaction client » et « d’Amélioration continue des performances »
30
Ce comité de gestion du changement est présent chez Gaz de France sous le Comité de pilotage Opérationnel
Imprimé le
La figure ci-dessous représente une approche symbolisée par une maison des référentiels :
La maison des référentiels31
CobiT, CMMi, ITL constituent les briques essentielles du pilotage des Systèmes d’Information
et de leurs directions, en alignement avec la stratégie d’entreprise. Rappelons qu’il existe
d’autres référentiels, non étudiés ici.
Ils définissent les meilleures pratiques dans leurs domaines de compétences respectives. Ces
référentiels ne sont pas « étanches » les uns vis-à-vis des autres. Il existe des passerelles, des
points communs comme peut l’être le concept de niveau de maturité de CMMi abordé par CobiT
et ITIL.
Pour une entreprise mettre en pratique l’un, ou plusieurs de ces référentiels est une action à
prévoir sur du long terme.
Ainsi, un état des lieux des entreprises utilisant des méthodologies, indique les résultats
suivants32 sachant que certaines d’entres elles en utilisent plusieurs:
 56% utilisent méthodes internes,
 24% ISO 9 001,
 16% PMI,
 8% ITIL,
 4% Autre,
 2% CMM,
 13% aucune méthode.
31
ITIL et la Gestion des Services –T.Chamfrault & C. Durand –p 280
32
Ces résultats sont issus d’une enquête menée par IDC en 2004 auprès des DSI de 170 entreprises et
administrations françaises
Imprimé le
4.4. Conclusion
Ces référentiels permettent d’aborder le MCO d’applications de manière homogène avec une
même préoccupation : éviter et/ou maîtriser les perturbations potentielles de ce qui doit
préférablement rester le plus stable possible (l’application, les architectures applicatives ou les
infrastructures du SI). Ils ont également pour but de simplifier, rationaliser, mutualiser les
infrastructures et les coûts induits.
Dans le cadre du MCO, il est donc possible de se référer à tout ou partie de ces référentiels,
étant entendu que leur mise en œuvre n’est pas un gage de qualité mais bien une aide pour
arriver à un résultat.
De fait, CobiT sera utilisé par la MOA pour gouverner son système d’information, ITIL par la
MOE pour assurer la meilleure « gestion de service » et le CMMi par la SSII pour maintenir le
produit dans des conditions opérationnelles optimales.
Les processus de chacun de ces référentiels sont à utiliser en fonction des attentes des instances
de Gouvernance du SI et avec un objectif « opérationnel ». Rien ne sert de décrire des processus
qui ne seront pas utilisés parce que trop complexes à suivre au quotidien.

Imprimé le
5. PREPARATION ET PASSAGE EN MCO

5.1. Introduction
Dans les chapitres précédents, nous avons défini ce qu’est le MCO, décrit l’évolution de
l’organisation des instances IT de l’entreprise en mettant en avant les différentes composants
internes et externes. Nous avons également analysé les différentes méthodologies qui existent, de
la gestion de projet aux référentiels complémentaires liés à la « Gouvernance des SI » en rapport
avec le MCO.
Dans ce chapitre, nous allons décrire les actions à réaliser lorsque le projet devient une
application à gérer en MCO, détailler les activités principales à mener en MCO et les acteurs qui
les portent avec le niveau de responsabilité associé.
5.2. Du projet au MCO
Le découpage en phase du projet, du lancement à la mise en production, va permettre d’avoir une
visibilité suffisante pour déterminer la période probable de passage en MCO. Une des tâches à
déclencher lors de la clôture du contrat du processus « Management des approvisionnements du
projet » du PMBOK est donc de prévoir le lancement du contrat suivant. On peut donc dire que
la tâche « Planifier la clôture du contrat de réalisation » implique obligatoirement le lancement
de la mise en œuvre d’un nouveau contrat. Ainsi, il est nécessaire de mettre en oeuvre les étapes
d’une procédure achat dont l’issu est la production et la signature d’un contrat.
5.2.1. Les procédures d’achat
Quelque soit le type de contrat, de réalisation ou de TMA pour ce qui nous intéresse, les
entreprises sont soumises à cinq grands principes d’achats qui sont les suivants :
 Une mise en concurrence systématique de plusieurs fournisseurs,
 Une non-discrimination,
 Une transparence de la consultation,
 Une traçabilité des différents documents, intervenant,
 Une Ethique.
Pour répondre à ces principes, la procédure d’achat va se dérouler comme suit :
 L’appel d’Offre. Un appel d’offre décrit les caractéristiques de la prestation attendue
(de l’achat), les conditions de la consultation, c’est à dire les délais et les éléments de
réponses attendus qu’ils soient techniques ou financiers. En général, le formalisme du
cadre des réponses est également fourni. Les critères qui permettront de qualifier les
réponses les une par rapport aux autres sont définis simultanément et sont regroupés
sous forme de grille d’analyse,
 Le dépouillement. Les réponses de chaque fournisseur sont ensuite analysées
(dépouillées), les grilles sont remplies et sont prêtes à être comparées. En général, les
fournisseurs dont la note à l’écrit atteint un seuil défini à l’avance sont convoqués à
Imprimé le
une soutenance orale. La même mécanique est appliquée pour qualifier ces
soutenances orales.
 Le choix. Le fournisseur choisi est celui qui a la meilleure notation moyenne, écrite et
orale cumulées.
La procédure d’achat peut donc se concrétiser par l’achat de la prestation demandée formalisée
par un contrat.
5.2.2. Les contrats
Ainsi, un contrat est, en général, composé d’un lot ferme (avec la description des réalisations
impératives du contrat) et un ou plusieurs lots optionnels qui ont pour objet de prévoir à l’avance
les actions complémentaires éventuelles. Comme il n’est pas toujours aisé d’anticiper ces
actions trois ou quatre années à l’avance, le caractère optionnel de ces lots permet de prendre la
décision de les souscrire ou non une fois l’étape de réalisation terminée.
Dans le cadre plus précis d’un contrat de réalisation, il est possible de prévoir la rédaction d’un
lot optionnel de MCO avec pour cible de préparer la ou les premières années de vie du produit.
Pour qu’il soit utilisable, la description des activités, des responsabilités et des devoirs respectifs
de chaque instance doivent être détaillées. En général, ce n’est pas le cas puisque l’accent est mis
sur la phase de réalisation au détriment bien naturel du MCO. Dans ce contexte, le lot de MCO
est à prendre comme un moyen de prolonger l’extension de garantie due par l’intégrateur et
permettre à la DSI de la société de mettre en place l’équipe adaptée au maintien en condition
opérationnelle du produit, d’assurer les périodes de recouvrement nécessaire au transfert de
compétences et éventuellement de mettre en place les organisations pour fédérer les services.
L’appel d’offre pour assurer la TMA peut être lancé plus sereinement que s’il avait fallu le
paralléliser avec la phase de mise en production du projet.
En effet, le lancement d’un produit est toujours une phase suffisamment délicate pour quelle soit
menée indépendamment de toutes contraintes externes au projet.
5.2.3. La phase de transition
Dans tous les cas, cette phase permet d’assurer la transition entre la fin du projet et le début du
cycle de vie du produit. Il est bien sûr nécessaire de prévoir un contrat de maintien en condition
opérationnelle spécifique où tous les aspects de maintenance (acteurs, actions, délais, moyens,
contraintes, sanctions) seront décrits en détail.
Dans le cas où le maintien en condition opérationnelle serait sous traité, le contrat à établir avec
le prestataire est un contrat de TMA.
Le passage en « MCO » signe donc théoriquement la fin du mode projet. Ceci se traduit très
concrètement par une démobilisation des équipes MOE, surtout lorsqu’elles s’appuient sur des

Imprimé le
contrats de réalisation au forfait33. La reconduction de l’équipe « intégrateur » via la

contractualisation du lot optionnel de MCO peut permettre une démobilisation plus en douceur
de cette équipe.
Toutefois, c’est bien à cette période qu’il faut s’interroger sur la manière dont cette phase devra
se dérouler (qui va assurer la gestion de services), préparer l’organisation adaptée à mettre en
place (interne et externe à la MOE du SI de l’entreprise), considérer les organisations existantes
et éventuellement y adhérer. En tout état de cause, la préparation du MCO du produit est à
construire.
Dans le cas où il serait nécessaire de faire appel à un ou plusieurs prestataires pour assurer les
actions d’assistance à maîtrise d’œuvre, d’expertise, d’assistance utilisateurs, de recette de
versions, d’expert technique en développement de logiciel et de gestion de l’exploitation
quotidienne, il faudra préparer et lancer un ou plusieurs appels d’offre pour choisir celui qui
assumera les différents services. Pour la partie de « MCO » proprement dite, l’appel d’offre à
mener sera destiné à des SSII et devra tenir compte de tous les éléments détaillés dans le
chapitre concernant les « objectifs du MCO ».
5.3. Les acteurs du MCO
La phase de MCO va mobiliser également des acteurs MOA et MOE avec des profils souvent
différents de la période « projet ».
5.3.1. Acteurs MOA
Comme indiqué dans les chapitres précédents, le « maître d’ouvrage » est l’entité porteuse du
besoin (entreprise, direction, service). Cette responsabilité ne change pas pour la phase de
gestion et de suivi de l’application.
La MOA est en général représentée à deux niveaux distincts :
 Le niveau des utilisateurs regroupés autour d’un comité de suivi de l’application (ou
d’un club utilisateurs, un bon moyen de créer une entraide efficace) ; l’objectif ici est
de partager sur le caractère utilisable du produit : quels en seraient les axes
d’amélioration, ce qui est plus de l’ordre de l’anomalie de fonctionnement que de
l’évolution…
 Le niveau de décision de la MOA qui statut sur le bien fondé d’évolutions majeures en
terme de nécessité et de ROI. Ce deuxième niveau aura la charge de gérer le
portefeuille des demandes d’évolution en terme de recevabilité et de priorité. En
d’autres termes, elle aura la responsabilité de définir le contenu d’une nouvelle
version d’un produit, sa date de livraison en tenant compte des contraintes techniques
de mises à disposition et d’utilisation quotidienne.
33
Un contrat au forfait est un contrat « avec engagement de résultat » le produit est le livrable principal. En cas de
désaccord sur la qualité de ce livrable, la « charge de la preuve » s’il y a eu manquement, est à fournir par le
prestataire
Imprimé le
La MOA est donc le contact privilégié des utilisateurs finaux. A ce titre, elle sera aussi
l’interface entre la MOE et les utilisateurs lors de la recette d’une nouvelle version de
l’application.
5.3.2. Acteurs MOE
Pour la MOE, la grande différence entre la gestion de projet et le MCO réside dans le nombre de
personnes mobilisées et la manière dont les activités sont réparties.
Le pilotage des travaux confiés à la DSI pour le MCO d’un système informatique est assuré par
le chef de produit. Il est en général accompagné d’une équipe et s’appuie sur des contrats
externes.
Les éléments suivants sont le résultat d’une réflexion consolidée à partir de plusieurs modes
d’organisations existantes où les responsabilités hiérarchiques et fonctionnelles cohabitent et
n’impactent ni les rôles ni les responsabilités individuels.
5.3.2.a) Un Chef de produit34 de la DSI
Il est responsable des applications dont il a la charge. Il définit le calendrier des évolutions du
système.
A ce titre, son domaine d’activité est le suivant :
 Il pilote les appels d’offre liés à des renouvellements de contrats ou à de nouveaux
contrats de prestation,
 Il gère les contrats et les budgets des prestations externes,
 Il pilote la prestation de TMA et valide les lotissements (versions),
 Il gère le respect des livraisons planifiées pour chaque version,
 Il valide les devis et gère les commandes d’approvisionnement,
 Il est garant vis à vis de la MOA de toutes les actions liées à la gestion des
changements, des incidents, des indisponibilités,
 Il pilote et arbitre les activités du gestionnaire opérationnel, du ou des experts
fonctionnels,
 Il assure le reporting de l’activité de l’équipe vis à vis du responsable de domaine.
Certaines de ces activités peuvent être réalisées par délégation. La taille humaine de l’équipe
dépendra de l’importance de la ou des applications à maintenir.
34
Au CSI de Gaz De France, c’est le POA : Pilote Opérationnel d’Application
Imprimé le
5.3.2.b) Le Responsable Opérationnel 35
Il a la responsabilité du fonctionnement quotidien de l’application. Il assure et rend compte du

service rendu.
Si on se réfère au livre sur le « Support des Services » d’ITIL, l’objectif est bien de répondre
aux problèmes de gestion opérationnelle (traiter les erreurs connues) et d’assurer la production
des services rendus en tenant compte de l’exigence des services attendus par les entités métiers
utilisatrices ; A ce titre,
 Il prend en charge l’analyse des sollicitations36 utilisateurs reçues et enregistrées par
l’Assistance Utilisateur (AU). Il est le contact privilégié de la cellule AU de la DSI,
 Il est responsable du résultat des analyses faites en cas d’incident d’exploitation.
L’analyse des causes et des conséquences doit permettre de rétablir rapidement la
situation. La traçabilité des actions doit être menée pour capitaliser en cas de récidive.
Des actions de maintenance corrective pérennes doivent être planifiées auprès de la
TMA pour éviter que l’incident ne se reproduise,
 Il s’assure que les travaux concernant les corrections de base de production sont
coordonnés entre les différents intervenants,
 Il synthétise les sollicitations et communique sur leur avancement à la MOA,
 Il assure la communication (reporting) en rendant compte de la nature (sollicitations,
incidents, etc.) et de leur nombre respectif vis-à-vis du Responsable d’application
mais aussi de la MOA. L’un des objectifs ici est de diminuer le nombre d’appels en
identifiant leur origine : de nouvelles formations peuvent être à planifier, une
attention particulière lors de la mise en production de nouvelles versions de
l’application sont à initier, (actions préventives, etc.).
5.3.2.c) L’expert fonctionnel
Il a la responsabilité des demandes d’évolution des applications dont il gère le portefeuille de

réalisation.
Il réceptionne les demandes d’évolution de la MOA ; ces demandes sont fournies sous forme de
« cahier des charges » ou d’expression de besoin ».
La MOA attend en retour une « étude de faisabilité » avec les impacts fonctionnels, techniques et
organisationnels s’il y en a, un coût financier prévisionnel et une charge de réalisation.
L’ensemble de ces informations est indispensable pour statuer sur la priorité des évolutions en
fonction d’un budget et d’impératif de disponibilité.
35
Selon le cas, il peut être appelé « Responsable de la Performance » ou « Gestionnaire Opérationnel »
36
Une sollicitation est une demande d’aide à l’utilisation, une interrogation face à un dysfonctionnement de
l’application, etc.
Imprimé le
Ces demandes relèvent du processus « Gestion des changements » de CobiT qui permet de
décrire en commun accord, les rôles, les responsabilités et les livrables à répartir entre la MOA et
la MOE. En phase de MCO, le rôle de l’expert fonctionnel devient majeur.
A ce titre,
 Il synthétise l’ensemble des demandes d’évolution et propose des versions cohérentes,
 Il rédige les études de faisabilité associées aux cahiers des charges et sollicite la TMA
pour les charges et les coûts prévisionnels de réalisation. Il met en avant d’éventuelle
connexion et/ou interférence avec d’autres applications et mutualise les analyses le
cas échéant,
 Il anime les ateliers métiers en fonction des demandes d’évolution en cours,
 Il rédige les spécifications générales destinées à la TMA pour prise en compte de
l’évolution et valide en retour les spécifications détaillées correspondantes rédigées
par la TMA,
 Il organise les recettes des versions et coordonne les activités liées aux livraisons
correspondantes avec le sous traitant en charge de l’intégration et de la recette à qui il
fournit le cahier de recette associé,
 Il rend compte de l’avancement des travaux de recette,
 Il analyse
o La qualité des livraisons en intégration/recette avec des indicateurs liés aux
nombres d’anomalies (bloquantes, majeures, mineures ou de confort) détectées
par livraison,
o la qualité des recettes avec des indicateurs qui comptabilisent les anomalies
détectées après la mise en production,
 Il est responsable de la qualité de la version livrée aux utilisateurs finaux pour recette,
 Il organise les recettes métiers,
 Il assure également le reporting concernant l’avancement sur les demandes
d’évolution en cours et sur l’avancement de réalisation des versions.
5.3.2.d) Les autres acteurs MOE externes
Les autres acteurs de la MOE sont liés à la TMA, à l’AU et à la recette.

Leurs périmètres d’activités ont été définis lors de la signature du contrat de TMA d’une part et
de services pour l’AU et la recette.
Le responsable d’application est à même de qualifier leur prestation respective à l’aide
notamment des différents reporting fournis par son équipe.
Ici, l’aspect contractuel est mis en avant. La prestation fournie doit correspondre à la prestation
décrite dans les contrats.

Imprimé le
5.4. L’organisation du MCO

La phase de MCO comme celle de projet vit au rythme des instances de pilotage et de
coordination.
En effet, un des impacts de la formation d’équipe hétérogène de MCO (instance cliente, instance
AMOA, instance AMOE et instance MOE) est qu’il nécessite la mise en place d’instances de
pilotage et de coordination. Au cours de ces réunions, tous les points importants sont abordés,
débattus le cas échéants, statués et tracés.
5.4.1. Reconduction des méthodes appliquées dans les projets
La méthode de gestion de projet, comme indiqué dans les chapitres précédents, doit pouvoir être
appliquée également à la phase MCO lorsqu’il s’agit de gestion du changement. Ces
changements doivent être maîtrisés et répartis dans des versions. Ce constat est consécutif au fait
qu’il est primordial d’atténuer les points faibles de la gestion projet, points accentués dans le
cadre du MCO.
En effet, en termes de méthodes, on touche aux limites de validité de celles employées sur les
projets. Ces faiblesses sont, lorsqu’elles existent, liées à l’absence de véritable structure projet :
 L’évaluation des charges à l’issue de la spécification : il est bien rare que l’on travaille
autrement qu’à « dire d’expert » pour évaluer les charges. La mise en route d’un
processus d’achat au forfait est trop lourde et finalement c’est le client qui s’engage,
rarement le prestataire,
 Les tests : trop longtemps les parents pauvres des projets, restent le maillon faible tant
il est difficile de constituer et de maintenir un jeu de tests qui serait automatiquement
passé à chaque mise en service avec production automatique des écarts et des
anomalies. Ce point est en cours d’étude37 notamment par la mise au point de contrat
précis de recette passé avec des sous-traitants. Même si l’aspect contractuel doit
préciser les attentes réelles de la société et spécifier des indicateurs mesurables et
mesurés. La mise en place de structures et d’outils de tests automatisés reste un point
fort à ne pas négliger.
 L’intégration : la mise en production est souvent lourde et compliquée, elle exige des
ressources mobilisées en mode projet mais pas toujours disponibles en maintenance.
Cet aspect doit également être spécifié précisément avec le sous-traitant et être
contractualisé pour que ce dernier puisse mettre en place les actions nécessaires.
 La validation par les utilisateurs : elle se fait bien souvent en situation d’utilisation
réelle, faute de temps et d’environnement ad hoc. Ce point là est plus difficile à
résoudre. En effet, il est également possible de contractualiser ces éléments avec la
MOA, mais pour un utilisateur métier, il est toujours délicat de se dispenser de
37
Au PCL, et plus particulièrement à la cellule Recette de la TRA, des essais de suivi qualitatifs de tests sont en
cours notamment sur l’application VICTOR.
Imprimé le
l’activité quotidienne. Sur ce point, l’application des processus CobiT de

« Gouvernance du SI » et notamment de la procédure « Acquisition des applications »
peut être une solution. En tout cas, c’est à la MOA de régler ce problème vis-à-vis des
métiers. Il reste à la charge de la MOE de planifier les dates de recette et de ne pas
les respecter.
Un des leviers pour diminuer ces faiblesses est de faire attention à ne pas multiplier le nombre de
versions sur une année. En effet, la multiplication des versions dégrade considérablement le
processus aval de la mise en production en relation avec les utilisateurs.
Cet inconvénient combiné à la difficulté de trouver des «fenêtres» de changement dans des
plannings de production souvent surchargés conduisent également à militer pour regrouper les
modifications dans une même version. Un nombre de quatre versions par an semble raisonnable
ce qui permet d’avoir un volume de changement conséquent quasiment assimilable à un projet et
qui justifie la mise en place d’une structure adaptée et l’application de la méthode projet.
5.4.2. Les procédures supplémentaires à prévoir
Ces procédures concernent les points sensibles du MCO d’une application et ont été abordés
précédemment, elles concernent :
 La gestion du portefeuille des évolutions qui met en avant la relation « MOA-MOE-
TMA-Recette-AU »,
 La gestion des sollicitations qui met en avant la relation « MOA-AU-MOE »
o Poser tout type de questions concernant le fonctionnement des applications,
o Demander les codes accès aux applications,
o Signaler des anomalies,
o Demander des traitements particuliers (type extraction de données),
 La gestion des incidents qui met en avant la relation « MOA-AU-MOE-TMA »,
 La gestion des configurations : cette gestion est en générale abordée d’un point de vue
centre de développement ; cependant la DSI doit également pouvoir gérer ses
configurations et gérer les interactions entre les différents produits à maintenir en
condition opérationnelle.
5.5. Les actions « incontournables »
Les actions suivantes sont ou ont été menées avant la fin du contrat initial de réalisation, lot
optionnel inclus de MCO éventuellement :
1. Etablir un contrat de TMA : tout doit être défini précisément, l’idéal pour une DSI est de
posséder des contrats de TMA « type » qui précise les niveaux de services attendus et les
indicateurs pour les mesurer (délai de correction d’une anomalie bloquante, majeure,
mineure ; nombre d’anomalies détecté suite à la livraison d’une nouvelle version, etc.),

Imprimé le
2. Etablir un contrat de TRA (Tierce Recette Applicative) : définir les activités de cette
cellule (rédaction des scénarii de test de non régression, de versions, les mettre à jour) ;
définir un délai pour réaliser la recette de la version (au prorata du nombre de jours de
réalisation de la version par exemple), définir des indicateurs de qualité de la recette en
suivant les anomalies de production, etc.,
3. Etablir un contrat d’assistance utilisateur (AU) : c’est le centre de service, le point
névralgique de la relation client, ses activités sont orientées clients, il doit tout mettre en
œuvre pour informer au plus vite de sa capacité ou non à répondre à une demande. Le
contrat doit également préciser le niveau d’assistance apporté par l’AU aux clients. Les
indicateurs vont mesurer les délais entre la prise d’appel et la réponse apportée au client,
etc.,
4. Mettre en place un mode de gestion collaboratif avec la MOA et préciser au minimum le
mode de communication pour :
a. La gestion des changements,
b. La gestion des incidents,
c. L’acquisition des applications,
5. Mettre en place un mode d’échange avec les différentes instances d’exploitation.
5.6. Conclusion
Passer d’un projet à un produit exploitable et assurer son maintien en condition opérationnelle
est une tâche semée d’embûches.
La MOA devra mettre en place les éléments induits par le processus de « Gouvernance du SI » et
notamment gérer efficacement le portefeuille des évolutions.
La MOE de la DSI, fournisseur interne, devra quant à elle
 Mettre en place les processus de « Centre de services » pour être l’interface principale
entre la DSI et les utilisateurs, être le garant du respect des engagements de services,
mettre les moyens pour piloter les événements (incidents, demandes), fournir une
interface avec les processus de production, proposer une plate-forme d’accueil de
services destinée aux utilisateurs, etc.,
 Anticiper la recherche d’une TMA quelques mois avant la fin de garantie ou la fin du
lot de MCO souscrit éventuellement avec le contrat de réalisation. De plus, il est
impératif de réfléchir et mettre en place une équipe chargée du MCO du produit
concerné.

Imprimé le
6. CONCLUSION
6.1. Récapitulatif des attentes de l’étude
L’objectif de cette étude consistait à mettre en avant les difficultés portées par la gestion en
MCO d’une application, d’identifier, de définir et de mettre en œuvre l’ensemble des étapes et
des actions de la dernière phase du projet à la première phase de maintien en condition
opérationnelle du produit associé.
Pour ce faire, nous avons dans les précédents chapitres :
 Donné un sens à l’acronyme « MCO » en terme de contenu d’activité à réaliser et de
but à atteindre,
 Tracé et décrit l’évolution de l’organisation des instances informatiques de l’entreprise
et situé la période dans laquelle ces instances évoluent actuellement en mettant
l’accent sur les axes et les actions stratégiques,
 Mis en avant le fait que beaucoup d’entreprises conservaient le pilotage de leurs
projets et de leurs applications mais avaient ou allaient externaliser leurs instances
techniques et utilisaient les services des SSII,
 Analysé les méthodologies tant en terme de gestion de projets que de référentiels mis
à disposition par différents types d’organismes de normalisation ou d’instances
gouvernementales,
 Identifié également, que le cycle de vie du projet est une phase répétitive de la vie du
produit gérée en MCO
 Identifié, parmi les référentiels complémentaires ceux qui étaient les plus utilisés en
tenant compte des objectifs ciblés, ce qui a eu pour effet d’associer CobiT à la MOA
pour la « Gouvernance de son SI », ITIL aux instances informatiques Interne des
sociétés notamment pour la gestion des services et CMMi à la production industrielle
de logiciel,
 Mis en avant l’utilité pour les entreprises d’utiliser les méthodologies adaptées à
chaque situation selon qu’elle est « IT » ou « Métier ».
6.2. Conclusion générale
Au vu du résultat de ces analyses, il est avéré que la maîtrise du processus de maintien en
condition opérationnelle d’un produit est une phase primordiale pour l’entreprise, comme l’a été
au cours des années 80, l’implantation d’une méthodologie de projet. L’impact est visible au
niveau global de l’entreprise, des instances métier à l’instance informatique. En effet, pour les
utilisateurs, un processus sous contrôle, propage un sentiment de sécurité quant à la fiabilité des
outils IT mis à disposition. Les relations, entre les différents acteurs et les actions menées au
sein des sociétés se sont clarifiées, décloisonnées et formalisées.
Attention, toutes ces méthodologies doivent être adaptées aux spécificités de chaque société et
non l’inverse. En effet, ce sont avant tout des moyens qui permettent de mieux travailler
Imprimé le
ensemble. Elles décrivent les bonnes pratiques à mettre en œuvre pour fiabiliser, industrialiser et
donc augmenter la rentabilité des IT. Cependant leur mise en œuvre ne garantit en rien un IT
performant. Rien ne sert de vouloir maîtriser toutes les phases du processus simultanément,
l’accent est à mettre sur celles qui induisent trop d’insatisfactions à savoir la gestion des services
et plus précisément, la « Gestion des incidents » et la « Gestion des évolutions ».
6.3. Conclusion pour le PCL
Cette étude couplée à la mission effectuée au PCL a mis en évidence la nécessité d’organiser la
phase de transition entre le projet et le MCO du produit en termes :
 Contractuel, c’est à dire s’assurer que les activités de maintenance sont prévues et que
le relais entre le contrat de réalisation et de TMA est planifié. Ainsi, pour
l’application VICTOR, une année de MCO via le contrat de réalisation a été souscrit.
Pour que la TMA soit opérationnelle à l’issu de cette prolongation, le cahier des
charges, pièce indispensable au lancement d’un appel d’offre, sera rédigé en
septembre .... avec notamment l’ambition d’être suffisamment précis et complet pour
pouvoir être capitalisé au niveau du domaine (gestion transversale des problématiques
communes à tous les contrats de service d’ITIL),
 De communication entre la MOE et le PCL ; les processus liés à la « Gouvernance du
SI » issus de CobiT et plus particulièrement les procédures « Acquérir des
applications et en assurer la maintenance », « Gérer les changements » , « Installer et
valider les solutions et les modifications », « Gérer les problèmes » ont été adaptées à
la gestion du MCO de VICTOR et des applications futures à maintenir du domaine.
Les comités de coordination d’une part et de pilotage d’autre part sont en place.
 D’organisation de l’équipe de MCO ; sur ce point, les activités à assumer sont
identifiées et sont bien orientées vers la satisfaction des utilisateurs, la clarification
des rôles, l’amélioration de la communication. L’accent est mis sur la gestion des
changements et notamment sur l’enregistrement et le filtrage des demandes qui doit
se faire en un point unique, sur la gestion des priorités avec l’objectif d’organiser et
de planifier les versions et sur la recette. Les indicateurs pour mesurer la performance
sont en cours de construction.
La Cellule Opérationnelle du PCL a, entre autre, en charge de décliner et de contrôler le respect

des principes du CSI. A ce titre, les processus mis en place entre la MOA et le PCL, ainsi que la
gestion et le suivi des demandes d’évolutions et de gestion des incidents, vont être suivis et revus
périodiquement à la cellule Opérationnelle selon les retours d’expériences.

Imprimé le
ANNEXES
1. GLOSSAIRE
AFAI Association Française de l’Audit et du conseil Informatiques
AFITEP Association Francophone de Management de Projet
AFNOR Association Française de NORmalisation
ANSI American National Standards Institute
AU Assistance Utilisateur
CAB Change Advisory Board
CIRAU Cellule Intégration Recette Assistance Utilisateur du CSI-PCL
CMMI Capability Maturity Model Integration. Méthode qui vise à porter

l’entreprise au niveau de compétence (ou maturité) qui lui permet de
réaliser correctement ses projets. CMMI est plutôt positionné sur la
maturité du développement logiciel
COBIT Control Objectives for Information and related Technologies.
Référentiel méthodologique qui traite de la gouvernance.
CSI Centre de Services Informatiques
DGI Direction des grandes infrastructures de GDF SUEZ
DoD Département américain de la défense
GRDF Distribution aux particuliers – Direction GDF SUEZ
GRTgaz Transport de gaz (grosses canalisations) – Filiale GDF SUEZ
ISACA Information Systems Audit and Control Association
IT Governance Gouvernance du Système d’information
ITGI Information Technology Governance Institute
ITIL IT Infrastructure Library
MCO Maintien en Condition Opérationnelle
MOA Maîtrise d’ouvrage
MOA-D MOA Délégué – Mission d’expertise par délégation du directeur

Imprimé le
MOA-O MOA Opérationnelle- responsable de chaque domaine métier
MOA-S MOA Stratégique- Assiste le directeur pour les décisions relatives au SI
MOE Maîtrise d’œuvre
PCL Pôle Clients, entité du CSI
PCS Pouvoir Calorique Supérieur exprimé en kwh/m3

Est déterminé à l’entrée (alimentation) par analyse chromatographique
des différents composants du gaz naturel (méthane, propane, butane,
etc.) détermine la qualité du gaz
Il calcule la quantité d’énergie que dégage un m3 de gaz normal en
brûlant.
PMBOK Project Management Body Of Knowledge pour Corpus des
connaissances en management de projet
PMI Project Management Institute
PSI Pôle Système Industriel, entité du CSI
ROI Return Of Investment
SEI Software Engineering Institute ou Institut de l’Ingénierie Logiciel
SIMONE-GRT Application qui détermine les PCS aux points de livraison du réseau par
le biais d’un algorithme de reconstruction, et de permettre ainsi de
minimiser les coûts d’équipement et d’exploitation liés aux
chromatographes supplémentaires à installer, tout en respectant les
futures exigences réglementaires
SINDI Système d’INformation DécisIonnel
SSII Sociétés de Services en Ingénierie Informatique
SI Système d’Information
TMA Tierce Maintenance Applicative
TRA Tierce Recette Applicative
VICTOR Validation des Index de Comptage et des Télétransmissions et

Organisations des Restitutions
Application qui gère les données de comptage et effectue tous les
traitements sur ces données. Sa principale fonction est d’élaborer et de
mettre à disposition des autres applications les mesures horaires et
journalières en énergie et en volume pour tous les points de comptage
(télé-transmis, à relève mensuelle ou fictive)

Imprimé le
2. WEBOLOGIE
http://interne.gaznet.gazdefrance.com Site intranet de GDF SUEZ
http://www.Itilfrance.com Le site Francophone sur ITIL

Association Francophone de Management
http://www.afitep.fr
de Projet
http://www.afnor.org/ Association Française de NORmalisation
http://www.g9plus.org/interface/CR_ITGov_5Juil L’ IT Gouvernance et panorama qualité

versus ITIL, CMMI & Cobit :quel avantage
_2006.pdf pour la DSI ?
http://www.volle.com/travaux/moa_du_si.htm Prospective de la maîtrise d'ouvrage

(cf. copyright : Michel Volle)
http://www.newsitweb.info La lettre d’information (ou newsletter) ITIL

est rédigée par Christian NAWROCKI et
publiée sur internet à l’adresse
http://www.fr.capgemini.com/about/histoire/ Histoire de CapGemini
www.commentcamarche.net Document intitulé « Maîtrise d’ouvrage /

Maîtrise d’œuvre » issu de Comment ça
marche
3. BIBLIOGRAPHIE
AFAI, COBIT « Objectifs de contrôle de l’Information et des technologies associées », 4ème

édition traduite en français.
GEORGEL F, « IT Gouvernance », Dunod 2006.
PMI, PMBOK « Corpus des connaissances en management de projet », traduction française de la
3ème édition.
SIDI J, OTTER M, HANAUD L, « Guide des certifications SI », Dunod 2006
CHAMFRAULT T, DURAND C, « ITIL et la gestion des services », Dunod 2006
BENNASAR M, « Plan de continuité d’activité et système d’information », Dunod 2006
ALCON D, BOUTEL J-S, CARBONEL M, CHASSEFEIRE M-A, CLEUET F, MESDON B,
MILOT D, SALZMAN C, “Management de projet I.T”, Weka 2003.
La maintenance du système d'information, par Fabien Cleuet, article Informatique

professionnelle n°209,12/2002 (publication Diathèse)

Imprimé le

Master m2 Miage

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Master m2 Miage

Загружено:

Авторское право:

Доступные форматы

MASTER 2

Bd François Mitterrand 93400 ST OUEN

91025 EVRY Cédex

« Méthodes Informatiques Appliquées à la Gestion d'Entreprise »

Problématiques du Maintien en Condition

Opérationnelle (MCO) d’Applications :

Maître de stage Professionnel :

Auteur : Anne DENIBAUD Maître de stage Universitaire :

M2 Miage Anne Denibaud Page 2 / 73

1. PRESENTATION DE L’ACTIVITE EN ENTREPRISE ...................................................... 5

1.2. Le Maître de stage professionnel ...................................................................................................... 6

1.3. Le résumé des travaux proposés ....................................................................................................... 6

1.4. Le résumé des travaux effectués ....................................................................................................... 7

2. PRESENTATION ET SYNTHESE DU SUJET DE MEMOIRE ...................................... 10

2.2. La problématique du MCO déjà traitée ........................................................................................ 11

2.3. L’apport de l’étude ............................................................................................................................ 11

2.4. Ce qu’il faudrait faire de plus .......................................................................................................... 11

PRESENTATION DE L’ETUDE .......................................................................................... 12

2. LE MAINTIEN EN CONDITION OPERATIONNELLE ............................................... 14

2.2. Les définitions ..................................................................................................................................... 14

2.3. L’objectif du MCO .............................................................................................................................. 15

2.4. Conclusion ........................................................................................................................................... 16

3. L’ORGANISATION DE LA SOCIETE ET DE SON SI EN PARTICULIER................... 17

3.2. Les composantes d’un service IT .................................................................................................... 17

3.3. De la naissance du IT à aujourd’hui ............................................................................................... 17

3.4. Les grandes étapes du IT .................................................................................................................. 19

3.5. Les deux entités prépondérantes .................................................................................................. 23

3.6. L’évolution des IT dans l’ère de la maturité ................................................................................. 27

3.7. La maîtrise des coûts IT .................................................................................................................... 28

3.8. Conclusion ........................................................................................................................................... 28

4. LES CADRES THEORIQUES PERTINENTS ................................................................. 30

4.2. La méthodologie de gestion de projet ........................................................................................ 31

4.3. Les cadres méthodologiques complémentaires ......................................................................... 43

4.4. Conclusion ........................................................................................................................................... 59

5. PREPARATION ET PASSAGE EN MCO ...................................................................... 60

5.2. Du projet au MCO .............................................................................................................................. 60

5.3. Les acteurs du MCO ........................................................................................................................... 62

5.4. L’organisation du MCO .................................................................................................................... 66

5.5. Les actions « incontournables » ...................................................................................................... 67

5.6. Conclusion ........................................................................................................................................... 68

6.2. Conclusion générale ......................................................................................................................... 69

6.3. Conclusion pour le PCL ..................................................................................................................... 70

M2 Miage Anne Denibaud Page 4 / 73

1. PRESENTATION DE L’ACTIVITE EN ENTREPRISE

1.1. L’entreprise d’accueil

GDF SUEZ Le groupe GDF SUEZ est un acteur majeur de l’énergie

GLOBAL GAZ ENERGIE INFRASTRUCTURES INTERNATIONAL SERVICES

Pôle Système Industriel Pôle Clients Pôle Tertiaire

M2 Miage Anne Denibaud Page 5 / 73

1.1.2. Description rapide des missions du pôle

Le Pôle Clients assure, dans le cadre de la gestion du système d’information, l’assistance à

Estelle DLOUHY-MOREL est Responsable du Domaine « Allocations - Bilans». Elle m’a

1.3.1. Situation initiale

1 Validation des Index de Comptage et des Télétransmissions et Organisation des Restitutions

validés ou en cours de validation déclinés selon le référentiel « CobiT » dans le cadre de la

1.3.2. Planning prévisionnel des travaux

Action et dates clés

Le contrat de TMA Présentation des scénarii concernant la stratégie d’appel d’offre

1.3.3. Le contexte des travaux

1.4.1. Missions principales

1.4.3. Reste à faire

1.4.4. Planning des travaux effectués

Action et dates clés

Le contrat de TMA Présentation des scénarii le 18/04 ; choix d’un scénario ;