Master 2 - Mention Informatique Et Systèmes Spécialité - MIAGE - Méthodes Informatiques Appliquées À La Gestion D'entreprise

Scol ari t 2-3 Cycl es UFR SFA
Bd Franoi s Mi tterrand
91025 EVRY Cdex
MASTER 2
-
Mention Informatique
et
Systmes
Centre de Servi ces
i nformati ques (CSI )
14-16 rue Touzet Gai l l ard
93400 ST OUEN
Spcialit - MIAGE -
Mthodes Informatiques Appliques la Gestion d'Entreprise

ProbImutiques du Muintien en Condition
OprutionneIIe (MCO) d'AppIicutions :
La gestion du MCO dapplications au sein dun Service Informatique dune Socit
lorsquil est confi une T.M.A.

Auteur : Anne DENIBAUD
Anne :
Matre de stage Professionnel :
Matre de stage Universitaire :

Problmatique du Maintien en Condition Oprationnelle dApplications (MCO)

M2 Miage Anne Denibaud Page 2 / 73
Imprim le
Remerciements

Tout dabord Madame Estelle Dlouhy-Morel qui ma intgre dans son quipe sans faire
aucune diffrence quant mon statut de stagiaire. Elle ma accorde sa confiance et ma permis
dtre autonome tout en sachant tre disponible en cas de ncessit pour rpondre mes
interrogations.
Egalement toutes les personnes du Ple Clients pour leur accueil chaleureux, pour mon
intgration sans rserve, 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 Systmes dInformations Client de GRTgaz,
notre MOA, pour lesquels jtais une gazire comme une autre.
Mais aussi, lensemble des enseignants de lUniversit dEvry que jai ctoy lors du premier
semestre et qui ont satisfait mes attentes et contribu lintrt de ce programme.
Et enfin, toutes les personnes de mon entourage professionnel, familial et priv qui ont accept
de me soutenir dans cette exprience, mont encourage quand il le fallait et mont dcharge
dune grande partie du quotidien.
Cette anne et ce rsultat sont les vtres.


Imprim le
SOMMAIRE
BlLAN ET SYNT BlLAN ET SYNT BlLAN ET SYNT BlLAN ET SYNTHESE HESE HESE HESE ............................................................................................................5
1. PRESENTATlON DE L'ACTlVlTE EN ENTREPRlSE......................................................5
1.1. L'entreprise d'accueil ........................................................................................................................5
1.2. Le Matre de stage professionnel....................................................................................................
1.3. Le resume des travaux proposes ....................................................................................................
1.4. Le resume des travaux effectues ....................................................................................................7
2. PRESENTATlON ET SYNTHESE DU SUJET DE MEMOlRE...................................... 1U
2.1. Le sujet et ses apports novateurs ................................................................................................ 1U
2.2. La problematique du MCO dej traitee...................................................................................... 11
2.3. L'apport de l'etude ......................................................................................................................... 11
2.4. Ce qu'il faudrait faire de plus........................................................................................................ 11
PRESENTATlON DE L'ET PRESENTATlON DE L'ET PRESENTATlON DE L'ET PRESENTATlON DE L'ETUDE UDE UDE UDE.......................................................................................... 12
1. lNTRODUCTlON........................................................................................................... 12
2. LE MAlNTlEN EN CONDlTlON OPERATlONNELLE ............................................... 14
2.1. lntroduction..................................................................................................................................... 14
2.2. Les definitions ................................................................................................................................. 14
2.3. L'objectif du MCO........................................................................................................................... 15
2.4. Conclusion ....................................................................................................................................... 1
3. L'ORGANlSATlON DE LA SOClETE ET DE SON Sl EN PARTlCULlER................... 17
3.1. lntroduction..................................................................................................................................... 17
3.2. Les composantes d'un service lT.................................................................................................. 17
3.3. De la naissance du lT aujourd'hui ............................................................................................ 17
3.4. Les grandes etapes du lT............................................................................................................... 19
3.5. Les deux entites preponderantes................................................................................................ 23
3.. L'evolution des lT dans l're de la maturite............................................................................... 27
3.7. La matrise des cots lT.................................................................................................................. 28
3.8. Conclusion ....................................................................................................................................... 28
4. LES CADRES THEORlOUES PERTlNENTS................................................................. 3U
4.1. lntroduction..................................................................................................................................... 3U
4.2. La methodologie de gestion de projet ...................................................................................... 31

Imprim le
4.3. Les cadres methodologiques complementaires ....................................................................... 43
4.4. Conclusion ....................................................................................................................................... 59
5. PREPARATlON ET PASSAGE EN MCO...................................................................... U
5.1. lntroduction..................................................................................................................................... U
5.2. Du projet au MCO........................................................................................................................... U
5.3. Les acteurs du MCO........................................................................................................................ 2
5.4. L'organisation du MCO..................................................................................................................
5.5. Les actions incontournables ................................................................................................... 7
5.. Conclusion ....................................................................................................................................... 8
. CONCLUSlON ............................................................................................................... 9
.1. Recapitulatif des attentes de l'etude .......................................................................................... 9
.2. Conclusion generale ...................................................................................................................... 9
.3. Conclusion pour le PCL.................................................................................................................. 7U
ANNEXES ANNEXES ANNEXES ANNEXES ............................................................................................................................. 71
1. GLOSSAlRE.................................................................................................................... 71
2. WEBOLOGlE................................................................................................................. 73
3. BlBLlOGRAPHlE ........................................................................................................... 73


Imprim le
BlLAN ET SYNTHESE BlLAN ET SYNTHESE BlLAN ET SYNTHESE BlLAN ET SYNTHESE
1. PRESENTATlON DE L'ACTlVlTE EN ENTREPRlSE
1.1. L'entreprise d'accueil
GDF SUEZ
Branches & Infratructures
Centre Services Informatique (CSI)
14-16 rue Touzet Gaillard
93400 ST OUEN
Le groupe GDF SUEZ est un acteur majeur de lnergie
en Europe. Il produit, achte, transporte, distribue et
commercialise du gaz naturel, de llectricit et des
services associs ses clients ; particuliers, entreprises et
collectivits.
1.1.1. Le departement CSl - Ple clients- Allocations - Bilans
Le CSI est loprateur informatique des activits rgules de Gaz de France cest dire celles qui
concernent les infrastructures de transport, stockage, regazeification, et est organis en 3 ples.
Le Ple Systme Industriel (PSI) gre les mtiers dexploitation et de maintenance des
installations et dingnierie,
Le Ple Clients (PCL) est en charge de la gestion des systmes dinformation lis la
commercialisation des infrastructures qui outillent les processus de stockage,
dacheminement, de conduite et de mesurage du gaz,
Le Ple Tertiaire est la structure qui porte les applications complmentaires aux
fonctionnements du CSI
Ci-dessous, lorganigramme correspondant :
DGI
GRTgaz GrDF
Infras hors
France
CSI
Ple Systme Industriel Ple Tertiaire Ple Clients
INFRASTRUCTURES GLOBAL GAZ
& GNL
ENERGIE
FRANCE
INTERNATIONAL SERVICES
ETAT MAJOR

Direction RH Direction
SI Groupe
Direction
Communication
Direction
Stratgie
. .. .

Imprim le
1.1.2. Description rapide des missions du ple
Le Ple Clients assure, dans le cadre de la gestion du systme dinformation, lassistance
Matrise douvrage (AMOA), la conduite de projets, la maintenance et lassistance utilisateurs
des applications mtiers pour le compte de ses bnficiaires (clients) qui sont :
La filiale GRTgaz, responsable des activits lies aux rseaux de transport du gaz
(dveloppement des rseaux, commercialisation des prestations de transports de gaz
destines aux tiers, etc.),
La Direction des Grandes Infrastructures (DGI) qui assure en France, l'exploitation, le
dveloppement, la maintenance des stockages et terminaux mthaniers.
1.2. Le Matre de stage professionnel
Estelle DLOUHY-MOREL est Responsable du Domaine Allocations - Bilans. Elle ma
accueillie dans son quipe et suivie tout au long de mon stage.
1.3. Le resume des travaux proposes
Ma mission au sein du PCL est de mettre en place pour le mois de juillet ., le dispositif de
Maintien en Condition Oprationnelle des applications VICTOR
1
, SINDI
2
et SIMONE,
applications du domaine Allocations - Bilans qui sont au cur du SI du ple.
Cette mission est dcline selon trois axes :
Le premier axe consiste tudier et prparer 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 dveloppement, et du lot optionnel de Maintenance en Condition
Oprationnelle,
o Des renouvellements de contrats de TMA dj planifis au PCL.
Le deuxime axe est de spcifier et de mettre en place les relations Matrise
douvrage (MOA) Matrise duvre (MOE) et de proposer une offre de service
adquate pour permettre la MOA de piloter ses applications efficacement.
Le troisime axe concerne lidentification et lnumration des actions que devra
assurer la MOE. Lobjectif est de fournir tous les lments pour permettre de dfinir
lorganisation cible mettre en place au sein du domaine.
1.3.1. Situation initiale
Pour mener bien ltude, je dispose de tous les documents relatifs au fonctionnement et
lorganisation du CSI et du PCL en particulier. En complment, jutilise les premiers processus

1 Validation des Index de Comptage et des Tltransmissions et Organisation des Restitutions
2 Systme dINformation DcisIonnel

Imprim le
valids ou en cours de validation dclins selon le rfrentiel CobiT dans le cadre de la
gouvernance du Systme dInformation (SI) initialise par la MOA de GRTgaz.
1.3.2. Planning previsionnel des travaux
Action et dates cls
Le contrat de TMA Prsentation des scnarii concernant la stratgie dappel doffre
04/..... Prconisation du scnario le plus en adquation avec les
contraintes et les disponibilits du PCL.
Les relations MOA -
MOE
5 Ateliers programms du 29 mai au 26 juin avec la MOA de
GRTgaz pour mettre en place un mode de travail commun dclin
selon les principales procdures du processus Gouvernance du SI.
Lorganisation MOE 5 Interviews dagents dont les activits sont en relation avec le
MCO dapplications. Rdaction du document de synthse pour
dfinir le plan dactions associ la mise en place dune
organisation ddie.
1.3.3. Le contexte des travaux
Au cours de cette prestation ralise chez Gaz de France, jai bnfici dune totale autonomie
tant au niveau de lorganisation de mes activits que de la manire de les restituer.
1.4. Le resume des travaux effectues
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 intgrateurs Projet et TMA .
Etre force de proposition dans ltude des procdures lies au passage en MCO
dapplications du domaine Allocations - Bilans en mettant en avant laxe
oprationnel de lactivit. Dfinir les services qui pourront tre proposs 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 menes au sein du domaine
Allocations - Bilans du PCL pour assurer le MCO des applications en relation
avec la MOA, puis proposer lorganisation adquate du domaine.
1.4.2. Livrables
Le premier livrable est le rsultat de lanalyse contractuelle des marchs existants. Lobjectif est
de mettre en avant plusieurs scnarii possibles et didentifier celui le plus en phase avec les
contraintes du PCL. Ainsi, le choix a t fait de lancer lappel doffre pour choisir le nouvel
intgrateur de TMA des applications du domaine Allocations - Bilans courant septembre .....

Imprim le
Le deuxime livrable doit reprendre les lments identifis et les procdures mettre en place
pour permettre la MOE et la MOA de communiquer efficacement et de disposer de moyens
clairement identifis pour changer.
Le troisime document reprendra, quant lui, les actions raliser au sein du domaine pour
chacun des objectifs identifis 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 effectues

Action et dates cls
Le contrat de TMA Prsentation des scnarii le 18/04 ; choix dun scnario ;
appel doffre lancer entre juin et septembre .....
Prparation de lappel doffre avec la direction des
Achats de GDF partir de juin .....
Les relations MOA - MOE 5 Ateliers raliss du 29 mai au 12 juillet avec la MOA de
GRTgaz.
Lorganisation MOE 5 Interviews dagents dont les activits sont en relation
avec le MCO dapplications et la synthse pour juin ....
1.4.5. Technologies utilisees
Les technologies utilises sont basiques et concernent uniquement les outils de la bureautique.
1.4.. Technologies enseignees dans le Master et utilisees dans l'activite
Ma mission, oriente organisation, communication, contractualisation, ma permis de mettre en
avant directement les lments de droit au programme du Master.
Mme si les applications du domaine Allocations - Bilans du PCL utilisent des SGBD
(Systme de Gestion de Base de Donnes) Oracle, le langage Java, des progiciels du march, je
nai mis en uvre aucune de ces technologies.
1.4.7. Moyens materiels mis disposition
Jai eu accs un environnement de travail standard : bureau, poste de travail informatique,
imprimantes partages, connexion aux applications, accs aux outils de travail collaboratifs (la
messagerie Notes, les bases de donnes Lotus Notes ) ainsi quaux INTRANETS de Gaz de
France et INTERNET.

Imprim le
1.4.8. Elements quantitatifs
Jai prvu de fournir trois documents qui reprendront respectivement les analyses et synthses
correspondantes, susceptibles dtre utilises.

Imprim le
2. PRESENTATlON ET SYNTHESE DU SUJET DE MEMOlRE
2.1. Le sujet et ses apports novateurs
La problmatique du Maintien en Condition Oprationnelle dapplications peut se formaliser par
les questions suivantes :
Que signifie Maintien en Condition Oprationnelle dune application ?
O se situe la phase de MCO dune application dans le processus de gestion de projet ?
Comment situer le MCO dans le cadre des rfrentiels mthodologiques ? Quel serait le
mieux adapt ?
Quelles sont les instances dentreprise, internes et externes, concernes par cette
problmatique ?
Quels sont les processus dfinir particulirement? Que dire plus prcisment de la
communication entre ces instances?
Quelles sont les actions raliser et par qui ?
Toutes les applications sont-elles concernes par cette problmatique ?
Lorganisation de lentreprise et de son instance informatique en particulier est-elle
importante?
2.1.1. Elements novateurs
La description des processus lis au passage dapplications en MCO nest, ma connaissance,
aborde dans son ensemble dans aucun des rfrentiels mthodologiques.
2.1.2. Motivations principales pour traiter ce sujet
Jai pu constater que ce sujet devait mettre en musique plusieurs processus et plusieurs
entits internes ou externes lentreprise et que, pour ces deux raisons, une orchestration subtile
tait ncessaire.
2.1.3. lmportance du MCO dans l'informatique et chez GDF en particulier
Le service informatique de lentreprise est devenu un centre de pilotage, et de ce fait, il lui est
devenu indispensable de matriser lensemble des processus mis en place ou mettre en place et
de clairement les identifier notamment en termes dacteurs, de rles et de responsabilits.
Le CSI-PCL se doit de fournir un service de qualit ses bnficiaires. Son objectif est donc de
conserver la matrise des applications dont il a la charge en termes de niveau de ractivit, de
cots et de qualit.
Lorsque les activits de MCO dapplications taient assures par les entits dun service
informatique, ces 3 objectifs taient dj prpondrants. Maintenant quelles sont ralises par
des entits externes, elles deviennent primordiales.

Imprim le
En effet, comment les services informatiques pourraient-ils justifier de leur existence si le
pilotage de ces activits nest pas garanti ?
Le CSI ne fait pas exception la rgle ; la mise en place de processus de MCO matriss de ses
applications renforcera son apport vis vis de ses bnficiaires.
2.1.4. Relations entre le sujet du memoire et les missions realisees
Je vais mappuyer sur les tudes ralises au cours de mon stage. Elles sont en complte
correspondance avec le sujet du mmoire notamment en ce qui concerne la mise en place, dune
part des relations entre la MOA et le CSI et dautre part, de lorganisation correspondante du CSI
pour rpondre aux sollicitations de sa MOA. Je vais galement tenir compte de mes expriences
passes pour prsenter lhistorique des organisations des DSI (Direction des Systmes
dInformation).
2.2. La problematique du MCO dej traitee
Dans les ouvrages publis, on parle de gestion de services, de plan de continuit dactivits du
systme dinformation ou encore de guide pour faire certifier son SI . Ces approches donnent
une image qualit. Ces ouvrages sont peu diserts sagissant de MCO.
2.3. L'apport de l'etude
Cette tude sappuie sur des actions attestes, analyses tout au long de ma mission et largies
un environnement standardis.
La finalit est de comprendre les tapes mettre en uvre, dinstaurer des modes de
fonctionnement entre les diffrentes instances, de pouvoir sappuyer sur cette analyse et de
lutiliser comme fil conducteur pour mettre en condition de MCO nimporte quelle application.
Deux applications du domaine Allocations - Bilans du PCL seront concernes dici la fin du
premier semestre, une troisime intgrera le processus ds la fin de lanne. Ainsi, ce guide
pourra tre prouv.
De plus, ce modle devrait pouvoir servir dans tous services informatiques dont lactivit
principale est le pilotage de projets et dapplications dans un contexte mthodologique et
qualitatif.
2.4. Ce qu'il faudrait faire de plus
Dans une deuxime tape, il serait intressant de proposer un outillage standard et des modles
de documents pour :
Recenser,
Partager,
Communiquer,
et ce quelle que soit ltape en cours du processus de passage en MCO.

Imprim le
PRESENTATlON DE L'ET PRESENTATlON DE L'ET PRESENTATlON DE L'ET PRESENTATlON DE L'ETUDE UDE UDE UDE
1. lNTRODUCTlON
Aujourdhui, les IT (Technologies de lInformation) sont au cur de notre vie de tous les jours,
et plus encore de celui de lentreprise. Elles permettent de rpondre aux principes fondamentaux
de lconomie savoir : exercer un mtier, avoir des clients et disposer de ressources.
Et mme si ce principe est inchang depuis lAntiquit, lutilisation 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 matrise. Par Technologie , il faut comprendre ensemble
de techniques modernes complexes. Ainsi, linterprtation de matriser les IT peut se faire
selon les trois propositions suivantes : soit possder un savoir-faire IT, soit lacqurir, soit piloter
des prestations spcialises adquates.
Mais revenons dans le monde de linformatique dune entreprise. Une des instances de cette
entreprise doit donc tre spcialise dans le mtier qui consiste matriser les IT. Ses clients sont
les autres entits de lentreprise et elle utilise des ressources matrielles et humaines qui peuvent
tre elles-mmes des instances internes ou externes. Et cest ici que tout se complique.
En effet, au dbut de lre informatique, ces instances taient composes dingnieurs nomms
par les dirigeants de lentreprise parce quils taient intresss par les nouvelles technologies. Ils
ont ensuite t regroups dans un service spcifique (on parlait alors de Service Informatique) et
ont commenc automatiser efficacement un nombre significatif de tches
3
.
Rapidement, les fonctions automatiser ont augment de faon exponentielle, se sont
complexifies et ont ncessit la mise en place dorganisations spcifiques puis ensuite de
mthodologies. Cest galement au cours de cette priode que les instances clientes ont t de
plus en plus exigeantes quant aux technologies de pointes utilises, ce qui na pas t sans
consquence sur la gestion financire, au sens rentabilit, de ces Services Informatiques.
Au fils des expriences acquises dans diffrentes socits et en confrontant mes expriences, jai
pu mapercevoir que cette situation tait somme toute banale et que chaque socit, ayant une
structure informatique propre, aura un moment ou un autre le dilemme suivant traiter :
privilgier soit loffre de la meilleure qualit de service (le mieuxdisant) soit la rentabilit
financire (le moins-disant).
La littrature a abondamment trait des mthodes de gestion et de conduite de nouveaux projets
informatiques que ces mthodes soient gnralistes
4
, ou orientes selon des domaines particuliers

3
IT Gouvernance- F.Georgel page 14-dans les annes 60,., les chefs dentreprise comprennent alors que
linformatique leur permet de remplacer efficacement le crayon et la rgle calcul ..
4
PMBOK Corpus des connaissances en management de projet de PMI (Project Management Institute)
traduction franaise de la 3me dition.

Imprim le
comme le Dcisionnel
5
, ou encore le WEB
6
. Il est intressant de relever que la mthodologie
suivre diffre, selon le domaine dorientation, de la dmarche projet en gnral. Par contre peu
douvrages ont abord une vision de maintenance oprationnelle ; ce dernier point tant srement
moins noble que le premier mais tout aussi difficile et dlicat, si ce nest plus. En fait, la
maintenance oprationnelle a t aborde dans le cycle de vie projet comme une tape de
transition dont nous ferons une analyse dtaille dans un des chapitres venir.
Est-ce pour autant que le sujet nest pas problmatique ? Est-il donc si facile dassurer ses
instances mtiers la garantie que leurs outils IT ne les trahiront pas une fois quils ne feront plus
lobjet dune attention aussi particulire quen phase projet ? Comment dailleurs tre certain que
les nouvelles ressources seront toutes aussi performantes ?
Pour tenter de rpondre ces questions, nous allons donc nous fixer comme objectifs :
De dfinir les activits couvertes par le MCO et quel moment il est opportun de le
prparer,
Dtudier les instances tant internes quexternes lentreprise et lvolution de cette
dernire et de son SI,
Didentifier les bonnes pratiques existantes dans le cadre du passage et du suivi de
MCO dapplications, et contrario les risques sil ny en a pas,
De proposer un ensemble de recommandations utiles pour mener bien le passage
dun projet en une application maintenir en condition oprationnelle.
En gardant comme fil conducteur la mise en uvre des moyens ncessaires et suffisants pour
assurer le MCO des outils IT de lentreprise nous allons donc :
Donner un sens lacronyme MCO et identifier les complments apports par
rapport la notion de maintenance communment utilise,
Tracer et dcrire lvolution de lorganisation des instances informatiques de
lentreprise en sattardant sur les problmes induits et ce quil a fallu mettre en uvre
pour y remdier,
Ensuite analyser les diffrentes mthodologies tant en terme de gestion de projets que
de rfrentiels disponibles, le tout en sattardant sur les motivations qui sont
lorigine de leur naissance,
Et enfin, sattacher mettre en phase les organisations actuelles et les mthodologies
afin de rendre oprationnel 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 Stphane Bordage, David Thvenon, Franklin Brousse et
Laurence Dupaquier - Eyrolles Mai ....

Imprim le
2. LE MAlNTlEN EN CONDlTlON OPERATlONNELLE
2.1. lntroduction
Dans ce chapitre, nous allons nous attacher dfinir les activits couvertes par la phase de
Maintien en Condition Oprationnelle (MCO) versus celles de Maintenance plus
communment utilise jusquau milieu des annes 2000 dans les organisations IT et surtout,
largement explicite dans tous les ouvrages ou rfrentiels.
Lobjectif est de dterminer les similitudes ou ventuellement si lune des activits est incluse
dans lautre.
2.2. Les definitions
2.2.1. Le MCO
Le MCO est un ensemble dactions prparer en amont de toute mise en application
oprationnelle de matriel logiciel ou technique quel quil soit. Mais de quelles natures les
actions sont-elles induites ?
....`., | \C |. |
Communment la notion de MCO est utilise pour la maintenance :
Des navires de la Marine Nationale,
Des avions,
Des radars,

Dans ce cadre, lobjectif du MCO est danticiper limmobilisation de ces matriels pour garantir
un fonctionnement optimum en cours de mission. Les interventions concernent aussi bien des
changements de pices essentielles dont lusure est avre ou de pices endommages sur
lesquelles il faut intervenir rapidement. Une maintenance mal programme peut avoir des
consquences dramatiques pour la scurit des Hommes. Le matre mot est bien ici
anticipation car les conditions mettre en uvre pour assurer la maintenance technique dun
navire ou dun avion ne sont pas non plus sans consquences financires. Deux exemples pour
illustrer ces propos : un bateau, pour certaines interventions doit tre en cale sche, de mme un
avion doit, bien videmment, avoir atterri.
....`.|, | \C | ,. |
Lanalogie des applications IT complexes et leur caractre primordial pour lentreprise, font que
les instances informatique ont galement adopt ce mode de fonctionnement pour grer le MCO
de leur IT. En fait, larrt de lexploitation est assimil limmobilisation des matriels. La
maintenance des infrastructures, la prise en compte de nouvelles versions sont quant elles
assimiles des changements de pices essentielles.

Imprim le
Lanticipation, la planification de toutes ces actions sont, dans certain cas, toutes aussi
importantes pour la socit que la maintenance de la flotte nationale.
Ainsi, par Maintien en condition oprationnelle il faut entendre conserver lapplication en
bon tat de fonctionnement par rapport au service attendu par ses utilisateurs.
2.2.2. La Maintenance
Le dictionnaire donne la dfinition suivante du mot maintenance :
fait de conserver un matriel technique ou industriel en tat de fonctionner ,
ensemble doprations d'entretien d'un quipement .
2.2.3. MCO & Maintenance
Nous pouvons donc tablir que, dun point de vue smantique, Maintenance et MCO
sont des synonymes. Par contre, lexpression MCO sous entend anticiper les actions de
maintenance autres que correctives; elles sont donc fortiori incluses dans le MCO.
Lvolution de Maintenance en MCO est apparue lorsque le socle du nombre
dapplications maintenir a commenc augmenter de faon significative. Les DSI, aprs lre
du dveloppement, ont du faire face la maintenance dapplications souvent dveloppes dans
des technologies trs htrognes et ont dcid de mettre en place un processus en
correspondance avec les difficults de chaque situation.
Ces difficults viennent essentiellement du volume et du cycle de vie des applications
maintenir, du type de maintenance raliser et des comptences technologiques contrler.
Ainsi, le processus MCO va permettre de dcrire prcisment les actes qui sont pris en charge.
De mme, il va tre possible de fournir des outils aussi bien pour typer le niveau de difficult de
lintervention que pour prciser le dlai de cette intervention, mesurer les carts et donc produire
un niveau de service. Les SSII (Socits de Services en Ingnierie Informatique) ont su dailleurs
adapter leurs offres de services aux besoins de leurs clients et ont du tre lorigine de
ladaptation du terme Maintenance en Maintien en Condition oprationnelle des SI. En
effet, leur force se situe dans lhtrognit des comptences de leur personnel et des moyens
quelles mobilisent pour trouver ces comptences le cas chant. Rappelons que leur cur de
mtier est la matrise des IT.
2.3. L'objectif du MCO
Les objectifs du MCO sont de maintenir efficacement les applications pour quelles fournissent
le service attendu par les clients, de prparer et de faire voluer les applications pour prparer
lavenir, le tout en matrisant les cots, la ractivit et la qualit dexcution et du rsultat.
Les activits prioritaires couvertes pour le MCO sont de natures diffrentes.
Elles concernent les actions dont lobjectif est de fiabiliser lapplication et damliorer les
performances. Ce volet inclut en gnral les modifications ncessaires pour assurer les montes

Imprim le
de version sur les composants du SI utiliss par lapplication. On parle alors de maintenance
corrective et prventive.
Elles concernent aussi les volutions fonctionnelles qui proviennent soit des demandes de la
matrise douvrage soit des volutions rglementaires. Ici, cest plutt de maintenance volutive
et adaptative quil sagit.
Elles concernent encore la gestion des moyens oprationnels avec lesquels et sur lesquels les
actions de MCO sont excutes.
Elles concernent enfin lassistance utilisateur, qui est, globalement une assistance plusieurs
niveaux descalade de 0 (prise dappel) 3 (analyse technique raliser). Ici cest le niveau 3 qui
est en gnral 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 nvralgiques comme :
Une utilisation rgulire de lapplication sans anicroche,
Une gestion des incidents rapide et efficace,
Une communication anticipe en cas dinterruption prvisible de lapplication,
Une prise en compte efficace des demandes dvolution,
Des propositions dvolutions prventives, adaptatives, judicieuses et pertinentes.
2.4. Conclusion
Si lactivit traditionnelle de maintenance de tout ou partie dun SI peut tre compare un
carnet dentretien dune voiture (planification prvisionnelle doprations dentretien), le
MCO serait plutt de lordre du contrat dentretien du vhicule. La diffrence est que ds
lachat du vhicule (dans notre cas lapplication) son propritaire (dans notre cas lutilisateur
final) prvoit un investissement planifi et contractualis pour son Maintien en Condition
Oprationnelle .
Cet investissement toujours difficile concevoir ou consentir en phase projet (cest clairement
un surcot qui grve le ROI
7
) a lavantage dviter toute surprise ultrieure et dimpliquer tous
les acteurs en amont. Le MCO est donc une dmarche consciente danticipation qui englobe la
maintenance.

7
Return Of Investment

Imprim le
3. L'ORGANlSATlON DE LA SOClETE ET DE SON Sl EN PARTlCULlER
3.1. lntroduction
Dans ce chapitre, nous allons prsenter les diffrentes volutions quont subies les Services IT et
les diffrents acteurs qui y ont contribus. Lobjectif est de comprendre lorganisation actuelle,
les relations qui existent entre les acteurs qui contribuent la cration et la maintenance dun
ouvrage,
8
comment, pourquoi cette situation est devenue inluctable et quels ont t les impacts
des mutations successives.
Dans un premier temps nous allons analyser les diffrentes politiques de gestion appliques au
sein de ces socits en regard de leurs instances informatique. Puis nous allons examiner les
transformations supportes par ces Services IT selon trois grandes priodes conscutives aux
diffrentes politiques de gestion successives : celle de limplantation, celle du dveloppement et
celle de la maturit.
Dans un deuxime temps, nous allons explorer chacune de ces priodes et essayer de comprendre
les faits qui nous ont amens logiquement la situation actuelle.
3.2. Les composantes d'un service lT
Un SI regroupe trois composants prpondrants :
Linfrastructure est un ensemble dinstallations et dindividus ncessaires au
fonctionnement de linstance IT,
Les applicatifs sont des processus industrialiss par des outils IT utiliss par la socit,
Les services, ici le terme service dsigne toujours un service offert par une
organisation ses clients. Un service est indissociable de son utilisation. Selon la
commission de Normalisation de lAFNOR, un service est une prestation
immatrielle composable, manifeste de manire prdfinie, et une source de valeur
pour le consommateur et le fournisseur . Ainsi, en pratique la notion de service
apparat lorsque la gestion du SI passe de centre de cots centre de profits, avec un
quilibre entre quest ce que jai vendre ? et quest-ce que le client est prt
acheter ?
9
.
3.3. De la naissance du lT aujourd'hui
Les activits IT ont dmarr au dbut des annes 60. Trois grandes tapes se dtachent, chacune
dentre elles ayant une dure denviron vingt ans. Chaque priode correspond une approche
diffrente dun point de vue conomique. Elles se rpartissent comme suit : lre de
limplantation, lre du dveloppement et lre de la maturit.

8
Dans la suite du document, ouvrage , produit , application sont des synonymes et reprsentent le rsultat
dun projet en exploitation.
9
ITIL et la gestion des services-page 6

Imprim le
Selon lre considre et les proccupations du moment, la hirarchie des composants IT est
diffrente :

Evolution de lapproche des systmes informatiques
10

Pour commencer, les annes 60 80 correspondent lavnement de linformatique avec une
approche fonde sur laccroissement de la productivit. Les dirigeants des grandes entreprises y
sont trs sensibles et il faudrait tre aveugle pour ne pas anticiper les bnfices quil va tre
possible dobtenir grce linformatisation : moins dindividus pour plus de productivit.
Les deux tapes suivantes sont celles de la finance et puisque toutes les socits se sont lances
dans linformatique, lobjectif nest plus dautomatiser les processus nimporte quel prix mais
bien de rentabiliser les cots de fonctionnement de ces processus. Linformatique devient un
outil de productivit parmi les autres et nest plus soumis des traitements de faveur. Donc
comme tous les processus, celui li lInfrastructure voit son budget se rduire en faveur de
celui li aux Services fournir. Pour rappel, ces cots sont devenus prohibitifs suite des
demandes de plus en plus complexes dutilisateurs, voir des dirigeants de lentreprise.
Pendant la deuxime priode, le composant Applicatif est apparu clairement comme
prioritaire pour les socits parce quil y avait beaucoup de processus automatiser. En phase de
maturit, ce composant se positionne nouveau au second plan derrire cette fois-ci les
Services . En effet, les instances dirigeantes dune socit sattachent prioritairement une
qualit de service irrprochable; tant acquis que les applicatifs et linfrastructure ne posent plus
de problmes : les technologies sont prouves et les logiciels doivent ltre aussi.

10
IT Gouvernance- F.Georgel page 46

Imprim le
3.4. Les grandes etapes du lT
3.4.1. L're de l'implantation
Lre de limplantation correspond donc lge dor de linformatique. En effet, cest cette
poque que certains ingnieurs de lentreprise sont dsigns par les dirigeants pour mettre en
place les infrastructures informatiques. Rappelons que leur objectif est dautomatiser les activits
qui sy prtent pour augmenter la productivit.
Ainsi nat le service informatique, instance dans un premier temps, compltement intgre
lentreprise. Ses missions sont de mettre en place un ensemble d'lments structuraux
interconnects qui fournissent le cadre pour supporter la totalit de lenvironnement de
dveloppements applicatifs. Ces ingnieurs au dbut, se suffisent eux-mmes et sorganisent
autour de spcialits : infrastructures (systme, exploitation, production, etc.), applicatifs
(analyse, dveloppement), services (gre les incidents).
3.4.1. L're du developpement
.-.`., |.
De Service Informatique, cette instance volue rapidement vers une Direction informatique,
dabord DI (Direction informatique) pour devenir ensuite DSI (Direction des Systmes
dInformation) o lon gre en plus des techniques informatiques, le systme dinformation de
lentreprise. Au cours de cette priode, les Etudes et Dveloppement sont trs consommateurs
de personnes. La maintenance des applications est bien souvent ralise par les quipes projet.
Ainsi, les actions correctives sont prioritaires devant les actions projet, par contre la maintenance
volutive est planifie selon le bon vouloir des programmeurs.
Pour appuyer ces propos, faisons un premier zoom sur la S.E.I.T.A.
11
, qui au dbut des annes 80
disposait dun Service Informatique dune soixantaine de personnes, dj trs organis avec des
processus techniques bien implants. Elle disposait dun service Etudes et Dveloppement en
charge de la ralisation de projets qui reprsentait environ la moiti des effectifs affects, les
autres services ayant la responsabilit de lexploitation proprement dite des applications. En fait
le nombre de personnes ddies la maintenance tait en adquation avec le nombre de chanes
applicatives savoir environ quatre (lapprovisionnement, la fabrication, la facturation des
dbitants de tabacs, et la paye). Les volutions correctives (techniques ou fonctionnelles) taient
assures respectivement par chaque responsable de la maintenance.
En deuxime exemple, regardons le Service Informatique des Messageries du Livres
12
, compos
dune quinzaine de personnes rparties comme suit : un expert Systme , une personne et

11
Socit dexploitation industrielle des tabacs et des Allumettes devenu Altadis aprs 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 socit 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 ddie la maintenance des applications et neuf personnes impliques directement sur le
projet de refonte du systme existant. Cette configuration montre bien limportance donne aux
projets par rapport au suivi de lexploitation quotidienne des applications. Une deuxime
interprtation est davancer le fait que labsence de dysfonctionnement implique quil nest pas
utile de prvoir plus de ressources ; pourquoi alors vouloir changer ces applications ? Une
troisime hypothse est galement envisager. En effet, lre du dveloppement signifie quil y
a beaucoup de nouveaux projets raliser do limportance des quipes projet en opposition
avec les quipes de maintenance qui navaient que trs peu dapplications maintenir.
Pour finir, regardons une troisime entreprise, la holding, REXEL
13
, dont la DSI a eu pour
objectif, dbut des annes 1990, de piloter la ralisation dun systme commercial commun
toutes ses socits. Dans cette DSI, cohabitaient trois entits, le ple Etudes et
Dveloppement classique, le ple Technique et le ple Pilotage fonctionnel ce dernier
ayant pour rle de synthtiser les bonnes pratiques et les spcificits de chaque socit. L
encore, le ple maintenance des applications nexiste pas. Cette maintenance est laisse la
charge de chaque socit rgionale avec lobjectif de ne raliser que les actions correctives. Fin
des annes 90, il a quand mme t ncessaire de sassurer que le passage lan 2000 ne poserait
pas de problmes
.-.`.|, ' || ,|
Dans le mme temps, le nombre de nouvelles technologies a explos, et leur matrise a ncessit
des comptences et des moyens de plus en plus spcialiss. La DSI est devenue une entreprise
dans lentreprise. Elle est aux commandes dune infrastructure de plus en plus complexe et
ncessite un nombre croissant de comptences donc de collaborateurs.
Dans la continuit de cette dmarche, les cots dune DSI nont cess de crotre que ce soit tant
du niveau ressources humaines (si lon tient compte de la diversit des nouveaux mtiers), que
du niveau des matriels si lon considre les nouvelles technologies. Cette instance devient alors
le centre de toutes les critiques en regard des bnfices engloutis par ses divers systmes.
.-.`., |, ..||
Mme si les SSII ont fait leur apparition au milieu de lre de limplantation, elles ont vraiment
pris leur ampleur au cours de lre de dveloppement (CapGemini a t fonde en 67 mais sest
fortement implante partir des annes 90
14
).
Ces socits de prestations informatique rpondent aux principes fondamentaux de lconomie
savoir : exercer un mtier (matriser les IT), avoir des clients (les autres entreprises) et disposer

13
Holding, distributeur de matriel lectrique compos dune dizaine de socits telle quADELEC (en rgion
parisienne), ISNARD (en rgion grenobloise), LIENARD (rgion centre), FACEN (rgion Nord) pour les
principales
14
Histoire de CapGemini : http://www.fr.capgemini.com/about/histoire/

Imprim le
de ressources humaines qui correspondent leur cur de mtier (des experts en IT). Concernant
les ressources matrielles, en gnral, elles utilisent celles de leurs clients.
Ainsi les socits de prestations se dclinent en trois grandes catgories avec lesquelles les DSI
doivent composer.
C
o
n
s
e
i
l

e
t

s
e
r
v
i
c
e
s
Complexe techno-informatique
Editeurs Constructeurs SS
Entreprise
Directions oprationnelles
Directions des services
informatiques
A
p
p
l
i
c
a
t
i
f
s

m
t
i
e
r
s
A
p
p
l
i
c
a
t
i
f
s

T
E
q
u
i
p
e
m
e
n
t
s

Relation du complexe techno-informatique avec lentreprise
15

Ces SSII se sont introduites au niveau des directions oprationnelles de lentreprise, en tant que
socit de conseil et de services informatiques et vont profiter de leur situation pour renforcer le
sentiment que linformatique soit une activit part, complexe et coteuse.
Au vu de ce nouveau contexte, beaucoup dentreprises ont dcid de se recentrer elles aussi sur
leur de cur de mtier et par la mme de sous traiter la gestion de leur IT ces SSII. La
migration des experts IT de lentreprise vers les SSII ne sest pas ralise de faon si radicale. Il
a fallu plusieurs tapes, tales sur plusieurs annes selon la socit et qui nont pas dbut au
mme moment. En gnral, cette mutation sest droule dans la douleur. On parle alors
dexternalisation dans le sens confier une tche, un service, une entreprise extrieure.
Pour autant, grer leur SI, ne veut pas dire le conduire et cest pourquoi toutes les instances des
DSI nont pas t externalises. Il reste les pilotes projet qui, en plus de leurs connaissances
informatiques, ont pour mission de comprendre le mtier de leur entreprise, de communiquer
avec les services qui lexercent pour leur fournir les meilleurs outils.

15
IT Gouvernance- F.Georgel page 48

Imprim le
3.4.2. L're de la maturite
Le Service Informatique de lentreprise est donc devenu un centre de pilotage, et de ce fait, il est
devenu indispensable de matriser lensemble des processus mis en place ou mettre en place et
de clairement les identifier notamment en termes dacteurs, de rles et de responsabilits.
Le fait que loutil informatique soit peru comme un moyen doptimiser lactivit de lentreprise,
implique quil soit gouvern au niveau des instances managriales de lentreprise.
Nous aborderons ce point prcisment dans le chapitre Les cadres thoriques pertinents qui
reprend notamment les principaux rfrentiels publis par les organismes de normalisation.
La DSI doit conserver la matrise des applications dont elle a la charge en termes de niveau de
ractivit, de cots et de qualit, rendre compte de son activit et de ses dpenses son instance
de gouvernance et fournir des indicateurs pour lui permettre de suivre ladquation entre les
cots et les activits ralises. Le socle des applications en exploitation est significatif, il
ncessite la mise en place dune structure organise de MCO qui doit grer lexploitation
quotidienne, mais aussi les volutions court, moyen et long terme, raliser.
Le systme dinformation doit se stabiliser. Ne sont rcrits, repenss que les processus qui en
valent la peine, qui auront une forte valeur ajoute en terme financier. Avoir une bonne ide,
nest plus suffisant, il faut prouver quelle est rentable en calculant un retour sur investissement,
le fameux ROI, fait qui nous est rgulirement rappel. Attention, mme sil est moins onreux
dadapter une application en exploitation, le cot nest quand mme pas neutre. Il est souvent
plus difficile destimer le cot de maintenance dune application que le cot dun projet. Les
questions se poser concernent le plus souvent la taille de lquipe mettre en place. Combien
de personnes faut-il prvoir pour assurer une maintenance efficace et sans risque ? Et oui, voil
encore un mot qui fche : Risque . Modifier une application qui est utilise par un certain
nombre de personnes et qui doit fournir un rsultat priodique, nest srement 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 librer les DSI
de ce problme. Il est en effet plus ais pour une SSII dadapter sa taille en fonction des contrats
quelle va signer : de dveloppement, de MCO.
Regardons, comme dernier exemple, la socit Carrefour au milieu des annes 2000.
Lorganisation suivante a t mise en place :

Une Direction des Centres de Comptences et des Systmes Mtiers ,
Une Direction Projets (DP),
Une Direction de lArchitecture, Urbanisme et Dveloppements technologiques,
Une Direction des Services Oprationnels (DSO).
La Direction Dveloppement et Maintenance Applicative (DDMA) a disparu cette priode.
En effet, pour rduire les cots de fonctionnement du service, les activits (et les personnes) de

Imprim le
la DDMA ont t cdes une SSII. Le lien entre la socit et la SSII sest fait au travers de la
DSO. Cest galement cette poque quune Direction projet a vu le jour, tant entendu que les
projets sont raliss galement par des SSII. Au final, la maintenance est assure par une TMA.
Lobjectif a bien t de pouvoir budgtiser prcisment la charge financire du MCO de son parc
applicatif de la mme faon que les projets sont soumis des appels doffres.
Donc, lorsque les activits de maintenance taient assures par les entits du Service
Informatique, le triptyque cot, ractivit, qualit tait dj prpondrant. Maintenant quelles
sont ralises par des entits externes, elles deviennent primordiales.
En effet, comment les Services Informatique pourraient-ils justifier leur existence si le pilotage
de ces activits nest pas garanti ?
La mise en place des processus matriss de MCO de ses applications, doit garantir sa prennit
vis vis de ses instances clientes.
Laccent est donc mis sur la matrise des processus de MCO. En effet, la gestion des projets a t
au centre des proccupations pendant lre du dveloppement et a donc dj t soumise la
mise en place de processus maintenant prouvs.
3.5. Les deux entites preponderantes
La MOE (Matrise duvre) et la MOA (Matrise dOuvrage), entits trs prsentes dans le
monde du btiment, se sont imposes au cours des annes 90, au milieu de lre du
dveloppement. Elles se sont partages les rles dans le cadre de la matrise des systmes
dinformation.
Plusieurs tudes ont t menes que ce soit par lAFAI
16
, ou par des consultants expriments
17
.

3.5.1. La matrise d'ouvrage
..`., !| | \C/
Le matre douvrage est lentit porteuse du besoin (entreprise, direction, service) cliente de
linformatique qui sera le propritaire de louvrage. Par abus de langage, on appelle matres
douvrage les personnes physiques qui, dans cette entit cliente, ont comptence pour dfinir le
systme dinformation que le Service Informatique construit, maintient et exploit. En fait, il
dfinit lobjectif du projet, son calendrier et il fixe lenveloppe budgtaire. Le rsultat attendu du
projet est la ralisation dun produit, appel louvrage.

16
Etude AFAI (Association Franaise de l'Audit et du Conseil Informatiques) Matrise douvrage de projet de
systme dinformation
17
http://www.volle.com/travaux/moa_du_si.htm

Imprim le
..`.|, || | \C/
Le rle du matre douvrage est de spcifier les besoins, de prendre les dcisions essentielles,
et en particulier celles ncessaires la dfinition du budget du systme d'information. Il matrise
donc lide de base du projet (ou de ses volutions), et reprsente ce titre les utilisateurs finaux
qui louvrage est destin. Il doit galement rceptionner lapplication, sassurer que son
fonctionnement est en rapport avec les besoins exprims et que tout est prt pour une
exploitation optimale de lapplication. Par contre, il na pas forcment les comptences
techniques lies sa ralisation.
Selon limportance de lentit cliente, les responsabilits de la MOA peuvent tre partages.
Ainsi, le MOA-D matre douvrage dlgu remplit une fonction dexpertise par dlgation
du directeur de l'entit, le MOA-S matre douvrage stratgique , qu'il assiste dans la
prparation des dcisions relatives au SI. Le matre d'ouvrage dlgu a une mission de
coordination entre des MOA-O matres douvrage oprationnels responsables chacun d'un
des domaines du mtier. Chacune des MOA-O dialogue avec son homologue, ou une personne
dlgue, du MOE matre duvre .
..`., |,,. | \C/
Avant 1990 linformatique avait dj pour clients les mtiers de lentreprise, mais les
spcifications fonctionnelles taient souvent dfinies par les informaticiens eux-mmes partir
dexpressions de besoin sommaires dont la description tenait quelque fois sur un postit. Avec
lvolution et lenrichissement du rle de linformatique, les spcifications fonctionnelles sont
devenues lexpression formelle complte du mtier lui-mme ; elles ne peuvent donc tre
tablies que par des personnes qui travaillent dans le mtier tout en tant capables de dfinir un
SI et daider les dirigeants tirer parti des potentialits de linformatique.
Ainsi sest construite dans lentreprise une comptence nouvelle, la matrise douvrage du SI.
Elle est souvent un dbouch pour les informaticiens qui aiment travailler au plus prs des
mtiers.
..`., | ..|| | \C/
De fait, les dirigeants des entits clientes nomment des responsables la tte de la MOA qui ont
un profil mtier. Ils connaissent trs bien les besoins des utilisateurs pour avoir t lun dentre
eux quelques annes mais nont pas forcment la formation ni les outils qui leurs permettent de
grer un projet informatique.
Ainsi, lorsque le matre douvrage ne possde pas lexprience mtier ncessaire 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 charge de faire linterface entre la MOE
et la MOA.

Imprim le
Ici encore, les SSII se sont infiltres au niveau des entits dcisionnaires. Des services
d'assistance matrise d'ouvrage sont commercialiss par certaines SSII et fournissent aux
entreprises les comptences ncessaires qu'elles ne possdent pas.
Les relations sont rythmes par divers comits priodiques dont le nom varie selon les socits.
Cependant leurs objectifs sont identiques savoir :
Un comit stratgique des systmes d'information qui runit les MOA-S et les MOA-
D pour prendre les dcisions essentielles, et en particulier pour dfinir le budget du
systme d'information,
Une coordination des matrises d'ouvrage qui assure l'animation des MOA-D en
termes de mthode, de veille, et qui sassure de la qualit des relations avec
l'informatique.
3.5.2. La matrise d'ouvre
...., !| | \C!
Le matre d'uvre (ou matrise d'uvre, note MOE) est l'entit retenue par le matre d'ouvrage
pour raliser l'ouvrage, dans les conditions de dlais, de qualit et de cot fixs par ce dernier
conformment un contrat.
....|, || | \C!
Le rle du matre duvre est dorganiser la ralisation. Il coordonne la ralisation, contrle
les rsultats et met tout en uvre pour une exploitation optimale. Les connaissances du MOE
sont trs vastes et ce titre reposent bien sur une entit et non une personne. La matrise d'uvre
est donc responsable des choix techniques inhrents la ralisation de l'ouvrage conformment
aux exigences de la matrise d'ouvrage. Le matre d'uvre a ainsi la responsabilit dans le cadre
de sa mission de dsigner une personne physique charge du bon droulement du projet (on parle
gnralement de matrise du projet), il s'agit du chef de projet.
Force est de constater quon aborde ce sujet dun point de vue projet mais quen est-il du MCO ?
...., | ..|| | \C!
L encore, les chefs de projet MOE peuvent galement encadrer et, ou coordonner des
interventions de fournisseurs extrieurs (ici les SSII peuvent tre nouveau prsentes). En effet,
pour la ralisation de certaines tches du projet, lorsqu'il ne possde pas en interne les ressources
ncessaires, le matre d'uvre peut faire appel une ou plusieurs entreprises externes, on parle
alors de sous-traitance (et chaque entreprise est appele sous-traitant ou prestataire). Chaque
sous-traitant ralise un sous-ensemble du projet directement avec le matre d'uvre mais n'a
aucune responsabilit directe avec la matrise d'ouvrage, mme si celle-ci a un " droit de regard "
sur sa faon de travailler.

Imprim le
3.5.3. Distinction des rles entre MOA et MOE
La distinction entre matre d'ouvrage et matre d'uvre est essentielle dans le droulement du
projet, car elle permet de distinguer les responsabilits des deux entits. Il convient ainsi de
s'assurer que la dfinition des besoins reste sous l'entire responsabilit de la matrise d'ouvrage.
En effet, il arrive dans certains cas que la matrise d'ouvrage dlgue la matrise d'uvre des
choix d'ordre fonctionnel sous prtexte d'une insuffisance de connaissances techniques (de faon
concrte le service informatique d'une organisation prend la main et pilote le projet ds la phase
d'expression des besoins). Or seul le matre d'ouvrage est en mesure de connatre le besoin de ses
utilisateurs. Une mauvaise connaissance des rles des deux entits risque ainsi de conduire des
conflits dans lesquels chacun rejette la faute sur l'autre.
D'autre part, s'il est vrai que le matre d'uvre doit prendre en compte les exigences initiales du
matre d'ouvrage, il n'est, par contre, pas habilit ajouter de nouvelles fonctionnalits au cours
du projet mme si cela lui semble opportun. Le matre d'uvre est cependant charg des choix
techniques pour peu que ceux-ci rpondent fonctionnellement aux exigences de la matrise
d'ouvrage.
Enfin il arrive qu'une matrise d'ouvrage estime qu'un produit existant soit susceptible de
rpondre ses besoins, l'achte, puis se retourne vers la matrise d'uvre (le service informatique
par exemple) pour effectuer des adaptations du produit.
La distinction entre matrise d'uvre et matrise d'ouvrage est encore plus difficile lorsque les
deux entits font partie de la mme structure d'entreprise. Dans de pareils cas, il est d'autant plus
essentiel de bien dfinir contractuellement les rles respectifs des deux entits.
3.5.4. Communication entre MOA et MOE
Pour le bon droulement du projet, il est ncessaire de dfinir clairement les rles de chaque
entit et d'identifier respectivement un reprsentant au sein de la matrise d'ouvrage et de la
matrise d'uvre. Un groupe projet associant tous les acteurs de la MOA et de la MOE doivent se
runir lorsque cela est ncessaire pour rsoudre les conflits lis aux exigences de la matrise
d'ouvrage ou la coordination du projet.
Enfin, il est essentiel d'tablir un plan de formation permettant la matrise d'uvre et la
matrise d'ouvrage d'avoir un langage commun et de s'entendre sur une mthode de conduite de
projet, de conduite d'entretiens ou de runions, etc.
18

3.5.5. Relations MOA-MOE : deux vues complementaires

18
Une formation de ce type a t mise en place en .... par la DSI gnrale 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 matrise douvrage et matrise duvre est franco-
franaise . Elle existe pourtant dans les pays anglo-saxons mme si le vocabulaire y est
diffrent. Aux tats-Unis les matres douvrage dlgus sont nomms business
technologists : cest une spcialit laquelle forment les universits.
3.. L'evolution des lT dans l're de la maturite
Lorganisation de lentreprise a d voluer pour faire une place la matrise douvrage, le rle de
linformatique a d changer. Cela ne pouvait pas tre facile. Il y a eu bien naturellement au dbut
des incomprhensions et des polmiques. Puis les choses ont volu. Dans la plupart des grandes
entreprises, il nest plus ncessaire aujourdhui de se battre pour faire admettre la ncessit de la
matrise douvrage et lpoque des polmiques avec linformatique est rvolue. Il est dsormais
admis que le SI dpend de deux professions qui doivent cooprer : le matre douvrage dfinit les
fonctionnalits du SI et surveille sa bonne utilisation ; linformaticien est matre duvre des
solutions techniques, architectures et plates formes.
Certes, il est dlicat dorganiser une telle bipolarit mais il en existe dautres dans
lentreprise (que lon pense aux relations entre commerciaux et producteurs ). Le secret du
succs rside dans le respect mutuel entre les deux spcialits, respect qui ninterdira pas la
vigueur dans la ngociation.
La premire priorit est donc de renforcer la qualit de la matrise douvrage : le risque dchec -
ou de surcot - est lev si celle-ci ne sait pas dfinir ses priorits pour rechercher la sobrit, ou
encore si elle tente de rgler des problmes politiques travers le SI.
La demande des utilisateurs doit tre classe selon un ordre de priorit et il faut la soumettre
une slection svre. Un SI sobre est intelligent et volutif.

19
Document intitul Matrise douvrage / Matrise duvre issu de Comment a marche
(www.commentcamarche.net) disponible sous la licence Creative Commons

Imprim le
Par ailleurs linformatique passe par une phase de diversification en spcialits pointues
analogue celle qua connue la mdecine voici quelques dcennies. Aucune entreprise ne peut
rentabiliser en interne toutes les comptences ncessaires son SI, quil sagisse du
dveloppement, de larchitecture, de lInternet ou de la scurit. Chaque direction informatique
doit donc dfinir les spcialits que lentreprise matrisera en interne et celles quelle devra
demander des prestataires extrieurs. En outre il faudra quelle soit devant ces prestataires un
client comptent et non un simple gestionnaire de contrats.
3.7. La matrise des cots lT
Comme le SI quipe tous les mtiers de lentreprise, il est normal que celle-ci lui consacre un
certain effort. Mais des progrs restent faire pour matriser les dpenses. Dans certains cas les
entits dirigeantes sont bouscules par des phnomnes de mode au dtriment des maturations
ncessaires (aprs avoir longtemps frein lutilisation de lInternet, elles se sont au dbut 2000
rues vers le-business).
Le cot du SI comporte non seulement les dpenses informatiques, mais aussi celles de la
matrise douvrage qui sont moins bien connues : temps interne et assistance consacrs aux
recueils dexpertise, spcifications, validations, recettes ; au dploiement, lorganisation, la
formation des utilisateurs, lanimation, ladministration des processus etc. Si lattention se
focalise sur les projets, pisodes hroques, on examine de moins prs les cots de maintenance
et dexploitation quils induiront ; le cot de dtention de lapplication.
Lentreprise doit connatre le cot de son SI pour dcider en connaissance de cause. A partir de
cette connaissance lucide, elle pourra appliquer des rgles simples : raliser par palier, sous une
stricte contrainte de budget et de dlai, cela aide obtenir un SI sobre. Il faut aussi savoir tirer
parti des nouvelles technologies : on aurait tort de dpenser des millions dEuros de travaux sur
systme classique qui ne cotent que quelques dizaines de milliers dEuros avec lIntranet.
Enfin, sil est difficile dvaluer la rentabilit du SI, cest parce quil est devenu impossible
dimaginer une entreprise sans SI : elle disparatrait ! Le SI, mme sil a un cot, est rentable. Par
contre, rien nempche de chercher toutes nouvelles ides de fonctionnement ou dorganisations
qui permettraient daugmenter sa rentabilit.
3.8. Conclusion
Lanalyse de la socit (entreprise) et de son Service Informatique en particulier, au vu des
mutations dont il a t lobjet (passage de lre de limplantation celui de la maturit), et des
acteurs (internes ou externes) qui interviennent dans la construction dun ouvrage ou du MCO
dune application, avait pour dessein de mettre en avant la ncessit de faire partager le pilotage
entre deux entits la MOA et la MOE et le rle non ngligeable des SSII.
Par ailleurs, il est apparu clairement que la diversit des IT implantes dans tous les services de
lentreprise, impose la coopration entre MOA, MOE et SSII, comme une solution

Imprim le
incontournable. Lobjectif est donc bien de grer au mieux les projets ou les produits livrs
(MCO dapplications) et de laisser prendre la responsabilit inhrente chacune des instances.
Par contre, la dfinition de lorganisation de lentreprise et des acteurs associs nest pas
suffisante. En effet, il est important danalyser galement le cadre mthodologique dans lequel
ces acteurs vont voluer et quels seront les outils ou rfrentiels sur lesquels ils pourront
sappuyer.

Imprim le
4. LES CADRES THEORlOUES PERTlNENTS
4.1. lntroduction
Nous venons de poser le cadre du problme induit par la ralisation dun projet, la rception de
louvrage (application) correspondant et son suivi en MCO dans un contexte o lentreprise doit
mettre en place des moyens pour que lensemble des acteurs de lentreprise (MOA-MOE)
contribue efficacement au fonctionnement de son IT.
La dmarche que nous allons suivre, dans ce chapitre, consiste :
Rpertorier dans les cadres thoriques pertinents, les mthodes, pratiques et outils de
rfrence susceptibles dapporter des lments de rponse notre problmatique,
Identifier, parmi ces cadres, les bonnes pratiques qui seraient transposables au suivi et
lvolution de nos applications,
Proposer une dmarche de mise en uvre indpendante de lorganisation de
lentreprise.
La finalit de cette tape serait de disposer dune liste de prconisations suivre et dune check
list dactions raliser et utilisable par la personne qui aurait la charge dassurer le passage en
MCO dune application.
Lobjectif est donc de regarder les diffrents cadres thoriques et de sassurer que toutes les
tapes ncessaires garantir le MCO dun ouvrage, de sa rception son exploitation, peuvent
tre couvertes.
Ces rfrentiels doivent permettre, la MOA de piloter ses applications, mais aussi la MOE de
prparer la gestion des applications lorsquelles seront en exploitation.
Bien videmment, avant de rpondre au problme de MCO, une application est passe par toutes
les tapes projets. Et si le fait de mener un projet dans les rgles de lart suffisait ce que
lapplication soit ensuite facilement volutive ou suffisait garantir une utilisation sans risque, il
ny 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 quil soit
dordre technique ou fonctionnel.
Nous allons donc analyser rtrospectivement les tudes mthodologiques qui font rfrence dans
le domaine et identifier celles qui pourraient tre utilises dans le cadre dune dmarche de
MCO.
Ainsi, les mthodes qui traitent notamment de lassurance qualit, de la gestion des problmes,
du changement, des cots, 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
Lobjectif ici, nest pas de dcliner toutes les tapes de la gestion de projet, ni tous les processus
lis la gouvernance du SI mais au moins tous ceux qui y participent activement et de mesurer
leur complmentarit, de comprendre leur positionnement dans le cadre de fonctionnement de
lentreprise et dapprhender leur approche en matire de MCO. En dautres termes, nous faire
une ide de ce qui est induit par lactivit de MCO dapplications naissantes et de laborder
sereinement en commenant par analyser les processus de gestion de projet, puis en continuant
par les rfrentiels complmentaires tels que CobiT, CMMi, ITIL pour les principaux.
4.2. La methodologie de gestion de projet
Les premires rflexions sur la gestion de projet datent de laprs Seconde Guerre Mondiale.
Elles avaient pour motivation de garantir la matrise et la coordination des travaux de grands
projets mobilisant plusieurs corps de mtiers. Ces premires bauches ont t largement
compltes et amliores depuis.
Lmergence de linformatique dans lentreprise vers la fin de lre de limplantation et au dbut
de celle du dveloppement, a conduit diffrentes associations professionnelles et organismes de
normalisation enrichir et cadrer le sujet pour lappliquer aux projets SI.
En matire de SI, la gestion de projet est un sujet trait depuis de nombreuses annes. Cest
un domaine arriv maturit, son utilit nest plus dmontrer, son exercice est majoritairement
bien matris et surtout clairement dcrit.
Sans dtailler tous les aspects lis la gestion de projet, abordons son champ dapplication, sa
couverture et tentons dy saisir les ventuelles rfrences la maintenance ou tout du moins
toutes celles qui faciliteraient lexploitabilit des applications, ou qui pourraient tre utiliss dans
le cadre dune transition vers le MCO.
4.2.1. Principes de base
En matire de gestion de projet, les auteurs de louvrage Management de projet IT [WEKA,
2003] rsument bien ltat des lieux, ce qui est communment admis par la profession : Le plus
beau projet du monde, mal organis et mal pilot, ne peut que donner des rsultats dcevants.
Sans un dispositif de gestion de projet efficace, il est difficile de garantir le succs dune
opration 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 lANSI (American National Standards Institute,
pendant amricain de lAFNOR, Association Franaise de NORmalisation auprs de lISO,
Organisation Internationale de Normalisation) qui dcrit les connaissances requises lexercice
de la gestion de projet. Le guide PMBOK comporte trois parties.

Imprim le
4.2.2. Les trois parties de PMBOK
La partie I dfinit le contexte en posant le Cadre du management de projet . On y trouve la
dfinition de termes cls et une description de lenvironnement dans lequel se droule un projet :
la connaissance du champ dapplication, des normes et rglementations ou la comprhension de
lenvironnement du projet.
Cette partie peut tout fait tre reprise dans le cadre du MCO dapplication. En effet, lquipe en
charge de MCO doit galement connatre lenvironnement dans lequel volue son application.
Dailleurs, certains des lments peuvent tre repris de la phase projet.
La partie II sattache dcrire les cinq groupes de processus de management dun projet :
Dmarrage
Planification
Excution
Surveillance
et matrise
Clture
Dmarrage
Planification
Excution
Surveillance
et matrise
Clture

Les cinq groupes du processus de management de projet
Un groupe de processus est un ensemble de processus lmentaires relis entre eux par leurs
donnes dentre et de sortie. Chaque groupe de processus est spcialis, ainsi, celui de :
Dmarrage dfinit et autorise le projet ou une phase du projet sil est de grande
taille.
Planification affine les objectifs et planifie le droulement des actions ncessaires
leur atteinte.
Excution intgre lensemble des ressources pour une bonne excution du plan de
management du projet.
Surveillance et matrise , telle une vigie, est le dispositif qui cherche viter tout
cart et, le cas chant, en permettre la correction pour maintenir latteinte des
objectifs du projet.
Clture conclut le projet (ou une de ses phases) par formalisation de lacceptation
du (ou des) livrables(s).
Dans l'ensemble des groupes de processus et de leurs processus, les donnes de sortie des
processus sont en relation entre elles, et ont un impact sur les autres groupes de processus.

Imprim le
Ce principe dinteractions a pour effet que chaque groupe de processus nest pas indpendant des
autres. Leur bonne excution se traduit par un chevauchement :

Interactions des groupes de processus dans un projet selon le PMBOK
Ici encore, lorsque lquipe en charge du MCO doit grer une volution, elle peut tout fait
suivre ces processus. Elle sinscrit comme une phase projet dun gros projet.
La partie III dcrit lensemble des processus lmentaires des groupes de processus et les
organise travers neuf domaines de connaissances :


Imprim le

Vue densemble des domaines de connaissance daprs le PMBOK
Pour tre en phase avec lapproche la plus rcente des associations professionnelles, il faut
prciser que la gestion de projet relve, avec la conduite de projet, de la fonction de management
de projet. Cette dualit conduite/gestion est motive par la sparation de rles ds lors que les
activits respectives pouvaient ventuellement tre joues par des personnes ou des entreprises
diffrentes. Elle a t propose comme vocabulaire normalis par lAFITEP (Association
Francophone de Management de Projet) et lAFNOR
20
(Association Franaise de
NORmalisation) .
Il nest pas rare que les rles soient attribus des personnes diffrentes. La conduite de projet
est une activit assure par une personne dont le rle est de donner les orientations, prendre les

20
http://www.afitep.fr et http://www.afnor.org

Imprim le
dcisions propres au bon fonctionnement de la structure de projet. Cest en gnral un directeur
de projet ; on dit quil assure le pilotage.
Les caractristiques de la gestion de projet sont plutt de faire vivre le projet, de collecter et de
prparer les informations ncessaires la prise de dcision. Elle est assure par le chef de projet.
Cette fonction se retrouve aussi sous les appellations responsable de projet , gestionnaire de
projet selon les diffrentes classifications des emplois dans les entreprises.
Les deux fonctions peuvent tre confondues et assures par une seule et mme personne
21
. Cest
souvent le cas pour les petits projets SI ou lors de la gestion des volutions sur une application.
Il nest pas rare, non plus, quil existe deux chefs de projet, un qui appartient la MOA et un
deuxime qui appartient la MOE. Cette bicphalie revt lavantage dune meilleure cohsion
entre MOA et MOE, fluidifie la circulation de linformation entre les deux structures, et scurise
la MOA dans sa vision de lavancement du projet. Ce constat est bien en phase avec le rsultat
de lanalyse des entits MOA-MOE du chapitre prcdent.
La liste des activits principales, des domaines de connaissances du PMBOK, met en avant que
mener un projet SI ne ncessite pas uniquement des comptences informatiques. Les rubriques
ressources humaines ou communications en sont un exemple. La ncessaire
comprhension, que doit avoir un responsable de projet, de lenvironnement du projet en est une
autre.
De plus, dans le cas de sparation des entits, la dfinition des rles et des responsabilits est
primordiale.
Ainsi, ladaptation au MCO de cette partie est la suivante :
1. La phase de transition avec les processus lmentaires suivants :
Management des cots 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 prcisment chaque processus lmentaire.

21
Au Ple Clients du CSI, ces deux fonctions sont assures par le POA (Pilote Oprationnel Applications)

Imprim le
-....., | ,| |

Vue d'ensemble du management des cots du projet
Chacune des activits du Management des cots de projet peut tre adapte au MCO de
faon plus ou moins approfondie. De base, lestimation des cots reprend les lments lis
aux volutions potentielles de lapplication faite selon des outils et techniques destimation par
analogie.
De mme lactivit de Budgtisation est celle qui permet destimer le budget ncessaire aux
travaux dvolutions en tenant compte dlments tels que des cots de rfrences.
Ces deux premiers points permettent destimer une enveloppe de maintenance volutive utile
lorsquil faudra laborer le cahier des charges ncessaire notre besoin de mise en place dune
TMA (Tierce Maintenance Applicative).
Le dernier point, la Matrise des cots permet, en phase de MCO de mesurer le cot de
ralisation de la maintenance par rapport au cot budgtis.


Imprim le

Vue d'ensemble du management des approvisionnements du projet

Imprim le
Lensemble de ces activits, comme prcdemment, est dcliner lors de la phase de transition.
Lobjectif est de prparer, de planifier et de lancer les appels doffres de recherche de TMA. En
effet, avant toute commande dapprovisionnement, il est impratif de lancer un appel doffre
pour choisir le meilleur prestataire selon des critres dfinis pralablement. Cette action est
longue et assez laborieuse et doit tre anticipe.

Management de la qualit du projet
Que lon soit en phase projet ou en phase MCO, lactivit de Management de la qualit est
aussi importante. Elle se traduit par la mise en place dun plan qualit produit, par lidentification
dindicateurs de mesure de la qualit du MCO, et par la mise en place de moyens de contrle
constitus de bilans dactivit, de retour dexprience ; autant doutils qui permettront
didentifier par exemple les actions prventives.

Imprim le
-.....|, | ,| |

Management des ressources humaines du projet

Imprim le
Lactivit de Management des ressources humaines du projet se focalise sur lquipe projet et
ce, mme en mode MCO.

Management des risques du projet
Toutes les rubriques du management des risques sont aussi appliquer dans le cadre des
dveloppements induits par des changements. Il est donc tout fait envisageable dutiliser les
mcaniques de ce processus dans le cadre de MCO. En effet, les risques lis une interruption de
service ou une rgression de fonctionnement sont anticiper, dautant plus lorsque
lapplication est en exploitation.

Imprim le

Management des communications projet
Enfin, lactivit de Management des communications du projet souligne que les processus
mis en uvre apportent les liens indispensables entre les gens et les informations ncessaires
une communication russie . Cette communication est videmment aussi importante en phase
de MCO.


Imprim le
Ainsi, le management des relations interpersonnelles comprend les lments suivants :
Une communication efficace, savoir la matrise 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 dvelopper une vision et une stratgie, et motiver les
personnes pour raliser cette vision,
La motivation, afin de stimuler l'nergie ncessaire pour atteindre de hauts niveaux
de performance et surmonter les obstacles au changement,
La ngociation et la gestion des conflits, en sachant confrer avec d'autres personnes
pour s'entendre ou parvenir un accord,
La rsolution des problmes, qui comprend la dfinition du problme,
l'identification et l'analyse d'alternatives, et la prise de dcision.
4.2.3. Conclusion sur l'application de la gestion de projet au MCO
La dmarche du PMBOK peut tre utilise dans le cadre du passage dun projet en application et
notamment pour raliser les oprations telles que la gestion des approvisionnements (lancer un
appel doffre de TMA pour assurer le MCO), la gestion du management dquipe (pour mettre
en place lquipe adquate), la gestion des cots (pour dfinir le cot prvisionnel de la TMA et
matriser les dpenses), la gestion des risques (pour matriser un maximum de risques lis aux
changements subis par lapplication), la gestion globale du projet (pour piloter les volutions de
lapplication), la gestion qualit du projet (pour sassurer de lefficacit du MCO) et pour finir la
gestion de la communication.
Ainsi le MCO dapplications peut, comme les projets, tre divis en composants plus faciles
grer. Les sous projets sont souvent donns en sous-traitance une entreprise externe ou un
autre service fonctionnel de l'entreprise ralisatrice. On peut citer les exemples suivants :
Les sous-projets bass sur le processus du projet, tels qu'une phase spcifique du cycle
de vie du projet,
Les sous-projets qui sont fonction d'exigences de comptences des ressources
humaines, voire la Tierce Maintenance Applicative en terme de SI,
Les sous-projets impliquant une technologie spcialise, tels que les tests automatiss
de programmes informatiques dans un projet de dveloppement de logiciel, Tierce
Recette Applicative (TRA).
Le lien entre le projet et le produit est reprsent par les 2 schmas suivants :

Imprim le

Relations entre le cycle de vie du produit et celui du projet

Le dtail du cycle de vie du projet
La description initiale du contenu et les ressources que l'organisation est dispose investir sont
de nouveau affines lors du processus de dmarrage. Le chef de projet est alors slectionn s'il
n'est pas dj affect. Les hypothses et les contraintes initiales vont aussi tre documentes
nouveau. Le cycle de vie du projet est une phase rptitive de la vie du produit et est gr en
MCO.
4.3. Les cadres methodologiques complementaires
Comme nous lvoquions en dbut de chapitre, au-del de la gestion de projet pure , il existe
des concepts connexes et complmentaires qui renforcent un dispositif dj bien fourni.
Intressons nous maintenant la faon dont ils soutiennent la gestion de projet et sils
sappliquent au MCO en matire de gestion des SI.

Imprim le
Bien souvent dans les entreprises ces dmarches, complmentaires la gestion de projet
proprement dite, sont mises en uvre et assures par des structures de supports aux projets.
Les intervenants sont spcialiss et matrisent les sujets (qualit, risques, scurit, contrles,
changement, ) qui dfinissent en quelque sorte le cadre de fonctionnement au sein duquel il
faut sinscrire.
Le concept de gouvernance sapplique au niveau de lentreprise dans sa globalit mais aussi au
niveau du seul systme dinformation. Elle permet de rpondre aux nouveaux enjeux de la
politique de management des ressources IT.
Cest ce que lon appelle Gouvernance des SI qui peut se dfinir comme : une consquence
du mcanisme de Gouvernance dEntreprise visant rduire les risques oprationnels engendrs
par les technologies de linformation travers des processus daudit et de contrle, destins
garantir lintgrit, la compltude et la traabilit des informations
22
.
La mise en uvre de ces bonnes pratiques est base sur les outils mthodologiques qui
couvrent les diffrents sous-systmes de lentreprise.
En ne citant que certains de ces cadres, de ces outils, le schma que nous nous proposerions de
construire serait :
ORIENTER DECIDER CONSTRUIRE DEPLOYER OPERER
AMELIORER
CONTROLER
DOCUMENTER
MODELISER
CobiT ITIL
CMMi
Activits SI
A
p
p
o
r
t
s

m
t
h
o
d
o
l
o
g
i
q
u
e
s
ORIENTER DECIDER CONSTRUIRE DEPLOYER OPERER
AMELIORER
CONTROLER
DOCUMENTER
MODELISER
CobiT ITIL
CMMi
Activits SI
A
p
p
o
r
t
s

m
t
h
o
d
o
l
o
g
i
q
u
e
s

Contribution des outils mthodologiques de rfrence
Ce schma nest pas exhaustif. Il existe dautres outils mthodologiques
23
qui ne seront pas
voqus ici.
Nous allons juste apprhender de manire synthtique lapport complmentaire de CobiT, CMMi
et ITIL en regard des activits 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 mthodologique qui
propose un ensemble de moyens trs puissants pour grer les niveaux de contrle devant tre
exercs sur les ressources IT afin que ces dernires soutiennent efficacement la ralisation des
objectifs de lentreprise
24
.
-..`., C.
Ce cadre mthodologique a t dvelopp, mis au point et maintenu par lISACA (Information
Systems Audit and Control Association). LISACA est une association internationale implante
aux Etats-Unis qui effectue des travaux de recherche et des tudes dans le domaine de lanalyse
et des mthodes de contrle des SI.
Il existe une version franaise de CobiT. Elle est ralise par lAFAI (Association Franaise de
lAudit et du conseil Informatiques). LAFAI, cr en 1982, est le chapitre franais de lISACA
et le reprsentant de lITGI (Information Technology Governance Institute), centre de recherches
de lISACA. La dernire version de Cobit a t prsente aux Etats-Unis en dcembre 2005 ;
cest la version 4 .
-..`.|, |.. ,,|
Lobjectif de la gouvernance est de comprendre et de grer les risques lis aux IT.
Les points cls, mis en avant par lAFAI, pour mettre en uvre CobiT dans une entreprise sont
que :
Lentreprise ait une stratgie claire qui fixe les objectifs atteindre,
Les directions mtiers traduisent et enrichissent ces objectifs en fonction de leur type
de contribution (les objectifs du marketing ne sont pas les mmes que ceux de la
logistique),
Les objectifs mtiers soient traduits en objectifs SI,
Ce plan de bataille fasse lobjet dun suivi et dun contrle qui assurent le maintien
du bon cap (identifier et viter les drives voire apporter les corrections ncessaires si
la drive est amorce).
CobiT ne sadresse donc pas seulement la DSI mais aussi aux directions mtiers et aux
directions gnrales. Son positionnement se situe au niveau de la gouvernance ; gouvernance
dentreprise comme gouvernance des SI.
Si cela peut paratre vident, rien ne sert desprer mettre en uvre CobiT et den tirer quelque
bnfice sil ny a pas de stratgie.

24
IT Gouvernance de F Georgel chapitre 15

Imprim le
Bien videmment toutes ces oprations, tous ces programmes ou projets de transformation du SI
doivent faire lobjet dune gestion de priorits et tre suivis dans leur mise en uvre.
La feuille de route que propose CobiT est un ensemble de prconisations qui sarticulent autour
de quatre thmes principaux :
PO pour Planifier et Organiser : domaine de la stratgie de lentreprise,
AI pour Acqurir et Implmenter : domaine de la stratgie du systme dinformation,
DS pour Dlivrer et Supporter : domaine oprationnel de fourniture des services aux
utilisateurs,
SE pour Surveiller et Evaluer : domaine du contrle et de lvaluation de la
performance et de la qualit.
Chaque thme, ou domaine, regroupe les processus cls qui lui sont propres. Le nombre de
processus total est de trente quatre.
La figure qui suit montre ce principe de dcomposition
25
:

25
document traduit de lAFAI

Imprim le

Applications
Informations
Infrastructures
Personnes
DS1 Dfinir et grer les niveaux de service
DS3 Grer la performance et la capacit
DS5 Assurer la scurit des systmes
DS7 Instruire et former les utilisateurs
DS9 Grer la configuration
DS11 Grer les donnes
DS13 Grer lexploitation
DS2 Grer les services tiers
DS4 Assurer un service continu
DS6 Identifier et imputer les cots
DS8 Grer le service dassistance client et les incidents
DS10 Grer les problmes
DS12 Grer lenvironnement physique
AI 1 Trouver des solutions informatiques
AI 3 Acqurir une infrastructure technique et en assurer la maintenance
AI 7 Installer et valider les solutions et les modifications
AI 4 Faciliter le fonctionnement et lutilisation
AI 6 Grer les changements
AI 2 Acqurir des applications et en assurer la maintenance
AI 5 Acqurir des ressources informatiques
PO1 Dfinir un plan informatique stratgique
PO2 Dfinir larchitecture de linformation
PO3 Dterminer lorientation technologique
PO4 Dfinir les processus, lorganisation et les relations de travail
PO5 Grer lesinvestissements informatiques
PO6 Faire connatre les buts et les orientations du management
PO7 Grer les ressources humaines de linformatique
PO9 valuer et grer les risques
PO10 Grer les projets
PO8 Grer la qualit
SE2 Surveiller et valuer le contrle interne
SE3 Sassurer de la conformit rglementaire
SE4 Mettre en place la gouvernance des SI
SE1 Surveiller et valuer la performance des SI
SURVEILLER ET
EVALUER
PLANIFIER ET
ORGANISER
DELIVRER ET
SUPPORTER
ACQUERIR ET
IMPLEMENTER
RESSOURCES
Efficience
Intgrit
Disponibilit
Conformit
Fiabilit
Confidentialit
Efficacit
COBIT
OBJECTIFS METIER
OBJECTIFS DE GOUVERNANCE
INFORMATION
Applications
Informations
Infrastructures
Personnes
Applications
Informations
Infrastructures
Personnes
Applications
Informations
Infrastructures
Personnes
Applications
Informations
Infrastructures
Personnes
PO8 Grer la qualit
PO8 Grer la qualit
SURVEILLER ET
EVALUER
PLANIFIER ET
ORGANISER
PLANIFIER ET
ORGANISER
DELIVRER ET
SUPPORTER
ACQUERIR ET
IMPLEMENTER
RESSOURCES
Efficience
Intgrit
Disponibilit
Conformit
Fiabilit
Confidentialit
Efficacit
Efficience
Efficience
Intgrit
Intgrit
Disponibilit
Disponibilit
Conformit
Conformit
Fiabilit
Fiabilit
Confidentialit
Confidentialit
Efficacit
Efficacit
COBIT COBIT
OBJECTIFS METIER
OBJECTIFS DE GOUVERNANCE
INFORMATION INFORMATION

Cadre de rfrence gnral de CobiT (source AFAI)
Le schma traduit aussi limportance quest la comprhension de lutilit et de la contribution
que doit avoir, et a, le SI de lentreprise dans sa contribution la stratgie globale.
CobiT aide les dirigeants valuer les risques et contrler les investissements dans un
environnement informatique souvent imprvisible. Il permet ainsi de vrifier que la gouvernance
des systmes dinformation est cohrente avec celle de lentreprise, on parle alors dalignement
stratgique.
Au-del des processus, CobiT dtaille chacun deux en activits. Il y en a au total deux cent vingt
que nous naborderons pas ici.
Lobjectif ici est de mettre en place des processus qui permettent chacun des acteurs
(MOA/MOE) de matriser ses actions et plus prcisment la MOA de piloter son SI (davoir les

Imprim le
cadres pertinents pour piloter ses ouvrages) et la MOE de pouvoir sappuyer sur sa MOA pour
toutes activits la priphrie de son domaine de comptences et de responsabilits : Chacun
ses responsabilits pour avancer sereinement et efficacement .
-..`., ! | \C
Mme si tous les processus peuvent potentiellement tre adapts, certains dentre eux sont
mettre en avant plus prcisment dans le cadre du MCO dapplications.
Ce sont par exemple, surveiller et valuer la performance SI , Sassurer de la conformit
rglementaire Mettre en place une gouvernance SI , Grer la qualit , Evaluer et grer
les risques , Grer les changements, Grer les problmes , Acqurir les applications et
en assurer la maintenance , Installer et valider les solutions et les modifier , Faciliter le
fonctionnement et lutilisation , Dfinir les processus, lorganisation et les relations de
travail pour les principaux.
Une attention particulire est apporter cependant aux processus Grer les changements ,
Grer les problmes , qui prcise un objectif gnral et les objectifs de contrle dtaills.
Lobjectif gnral est ici la matrise des changements apports sur lenvironnement de
production pour en garantir la stabilit. Les objectifs de contrle dtaills mettent en avant :
Limportance de procdures formelles de gestion des changements de leur
standardisation,
La ncessit de prioriser les changements en fonction de leur importance et
dimpliquer le demandeur par son autorisation formelle,
Lexistence dune procdure particulire pour mettre en uvre les modifications
durgence,
La contrainte de documentation pour communiquer toutes les parties prenantes sur
ltat davancement du changement et acter de son achvement.
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 dvaluer la performance de lexercice et den assurer le contrle.
La dernire rubrique concerne le modle de maturit. Cest une chelle cinq niveaux qui
permet dvaluer le degr de matrise du processus : de inexistante optimise . Cette
valuation de la maturit au niveau de chaque processus permet, par consolidation, une
valuation au niveau de chaque domaine puis celui de lentreprise. Le niveau de maturit
donne une indication de la qualit de lalignement du systme dinformation la stratgie de
lentreprise.

Imprim le
Un autre point important est la mise en place et la maintenance oprationnelle dune structure de
coordination, de communication et de liaison optimale entre la fonction informatique et divers
autres professionnels lintrieur et lextrieur de cette fonction, comme le conseil
dadministration, la direction gnrale, les units oprationnelles, certains utilisateurs, les
fournisseurs, les responsables de la scurit, les responsables de la gestion des risques, le groupe
responsable de la conformit dans lentreprise, les responsables chargs des prestations externes
(externalisation et sous-traitance). Ce point peut tre complmentaire au processus de gestion de
projets de Management des communications .
Pour conclure ce focus sur CobiT, si nous ne devions retenir quune prconisation, ce serait celle
donne, sous forme davertissement, par lITGI au dbut de son guide : lutilisation de CobiT
ne garantit pas de produire de faon certaine un rsultat positif .
Lide qui veut que la qualit dun outil soit fonction, plus de lusage qui en est fait que de sa
faon dtre respecte !
Ce point nest pas anodin ; il est valable pour tous les rfrentiels. En effet une mthode pose les
bonnes questions ; elle ne donne pas les bonnes rponses.
En conclusion de CobiT, nous dirions quil sagit dun outil :
Plutt de proccupation stratgique, orient audit qui atteste de limportance que revt
le SI pour lentreprise,
Et que dun point de vue MCO, il donne une marche suivre pour matriser au
maximum les changements et les incidents (de mme quen gestion de projet, le fait
dappliquer une mthodologie ne garantit pas un MCO de qualit)
4.3.2. CMMi
CMMi, pour Capability Maturity Model Integration (Modle de Maturit de Capacits Intgr),
traite de lingnierie du logiciel, des systmes, du dveloppement intgr de produit ou de
processus, et de la gestion des fournisseurs.
Bien que spcifique lingnierie des systmes et du logiciel, il sagit dun modle de maturit
qui est gnralisable dautres activits comme le dveloppement de matriel, lassistance
client, les acquisitions, etc.
Il concerne tous les processus lis aux affaires et aux projets, du dveloppement jusqu la
prparation de la production en srie. Il sintresse aux processus de support du management afin
de sassurer que les processus mtiers disposent bien des moyens et ressources ncessaires.
-...., C.
Le modle CMMi a t dvelopp la fin de la dernire dcennie quatre vingt par le SEI
(Software Engineering Institute ou Institut de lIngnierie Logiciel) la demande du dpartement
amricain de la dfense (le DoD). Le DoD jugeait ncessaire de pouvoir valuer ses fournisseurs

Imprim le
informatiques en regard des bonnes pratiques relatives au gnie logiciel (i.e. l'ensemble des
activits de conception et de mise en uvre des produits et des procdures tendant rationaliser
la production dun logiciel et son suivi).
Les thmes, les domaines particuliers des modles de dpart abordent par exemple :
La maturit des dveloppements logiciels (en fait le premier modle),
La matrise des processus dingnierie,
La capacit dacquisition de logiciels (faire le bon achat),
Lvaluation des fournisseurs de logiciels,

La dernire version de CMMi est la version 1.2.
-....|, |.. ,,|
En premire analyse nous pouvons dire que lapproche CMMi est de nature priphrique au
thme de la gestion de projets SI. Elle propose lentreprise une dmarche qui lui confre le
niveau de maturit ncessaire la meilleure faon de mettre en uvre ses projets SI.
En dautres termes, CMMi permet de mesurer si une organisation, une entreprise, dispose des
comptences requises pour dlimiter ses projets, sassure de leurs bonnes spcifications
(priphrie de lamont du projet), et du bon usage des produits dlivrs (priphrie de laval au
projet).
La dmarche est base sur un systme dvaluation des bonnes pratiques ncessaires : comment
gagner en maturit en matire de dveloppement logiciel (qualit, fonctionnalit, cot et dlai).
Une particularit du CMMi est quil possde deux niveaux de reprsentation
26

Reprsentation par niveau
(niveau de maturit)
Reprsentation continue
(profil daptitude)
Cinq niveaux de maturit
Un comportement organisationnel
vraiment diffrent chaque niveau
Un ensemble de domaines de processus
chaque niveau
Une faon simple dexprimer un but
atteindre
=> priorit la vision organisationnelle
Six niveaux daptitude par domaine de
processus
Un algorithme qui donne la maturit
organisationnelle
Slection des domaines de processus
selon ses besoins et priorit

=> priorit la vision processus

26
Guide des certifications SI p 33

Imprim le
Le SEI prcise ces diffrences en indiquant que
La dmarche par tapes envisage une valuation globale de lorganisation dont on
mesure le niveau de maturit,
La dmarche continue propose de mesurer des niveaux de capacit par grande
catgorie de processus (gestion de processus, gestion de projet, ingnierie et support).
Pour mieux se reprsenter ces diffrences, nous pourrions dire que pour la dmarche par tapes,
lentreprise doit progresser globalement du niveau de maturit le plus bas vers le plus lev. Pour
la seconde, dmarche continue, il peut exister un dcalage de niveau de capacit entre les
catgories de processus (la capacit de lentreprise peut tre plus avance dans lune par rapport
aux autres) qui ne remet pas en cause lensemble.
Le nombre de niveaux varie selon la dmarche considre :
Niveau Niveaux de maturit de
la dmarche par tapes
Niveaux de capacit de
la dmarche continue
0 N/A Incomplet
1 Initial Pratiqu
2 Reproductible Reproductible
3 Dfini Dfini
4 Matris Matris
5 Optimis Optimis
Niveaux de maturit CMMi selon la dmarche
CMMi couvre un ensemble de vingt-deux domaines dapplication. Chaque domaine considr
fait lobjet dune 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
dveloppement et, la gestion du changement, sont des exemples de domaine.
Chaque domaine dapplication est dtaill par les objectifs viss, par les pratiques mettre en
uvre et les produits rsultants.
Ainsi, un objectif vis peut tre dordre gnral ou spcifique. Sil est dordre spcifique, il ne
sapplique qu lui mme, par contre sil est dordre gnral, il sera commun plusieurs
domaines. Par exemple, le lancement de la ralisation , la Capacit de raliser , la
Conduite de mise en uvre , etc. sont des objectifs communs presque tous les domaines
La capacit, atteindre laide des domaines de connaissance, est value par niveaux. Les cinq
niveaux de maturit de la dmarche par tapes qualifient la matrise de la gestion de projet pour
une organisation :

Imprim le

Niveau 1
initial
caractrise une organisation plutt habitue subir les dpassements (dlai,
cot), la non-qualit des produits livrs. Les situations de crises se rptent et
les succs restent exceptionnels. De ce fait, aucun domaine dapplication
nest associ ce niveau ; il nimplique pas de pr-requis.

Niveau 2
reproductible
dsigne une organisation capable de grer les exigences, planifier et rpartir
la charge de travail, assurer la qualit des produits.

Niveau 3
dfini
est celui dune organisation qui sait capitaliser sur ses expriences. Les
processus de gestion existent, sont mis en uvre, matriss et assurent une
bonne cohrence des diffrents intervenants. Cest ce niveau quune
organisation dispose dune mthode standard de gestion de projets.

Niveau 4
matris
confre lorganisation un caractre plus efficient quefficace. Les
indicateurs qui permettent diffrentes mesures existent et sont utiliss.

Niveau 5
optimis
est celui o la seule matrise des processus de gestion ne suffit plus.
Lorganisation cherche lamlioration continue de ses processus, de ses
mthodes et se met en situation de pouvoir anticiper.
La totalit des vingt deux domaines dapplication nest pas considre chaque niveau de
maturit ; on ne progresse pas sur la totalit en fonction du niveau atteint.
A chaque niveau de maturit correspondent des domaines dapplication particuliers que
lorganisation doit matriser pour latteindre.
Cest au niveau cinq de maturit que lensemble des vingt deux domaines est couvert. Les
niveaux deux et trois sont ceux auxquels correspondent le plus de domaines dapplication.

Imprim le
1 : Initial
Processus non dfini
2 : Gr
Processus organis
3 : Dfini
Processus standardis
4 : Gr quantitativement
Processus prvisible
5 : En optimisation
Amlioration continue
Structuration
Standardisation
Mesure/Prvision
Matrise du changement
R
i
s
q
u
e
P
e
r
f
o
r
m
a
n
c
e
1 : Initial
Processus non dfini
2 : Gr
Processus organis
3 : Dfini
Processus standardis
4 : Gr quantitativement
Processus prvisible
5 : En optimisation
Amlioration continue
Structuration
Standardisation
Mesure/Prvision
Matrise du changement
R
i
s
q
u
e
P
e
r
f
o
r
m
a
n
c
e

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 dapplication
requis.
Le niveau deux considre ce qui se passe du point de vue de la ralisation des projets SI. Le
niveau trois largit le champ vers lamont et laval de la ralisation.
Les deux derniers niveaux portent sur la matrise et lamlioration continue de lensemble (nous
pourrions dire que mettre en uvre CMMi cest procder par expansion).
-...., \\ | \C
De part le processus de gestion de configuration, le CMMi est bien adapt la gestion des
volutions aussi bien fonctionnelles que techniques.
La considration faite du MCO par le CMMi porte sur laspect infrastructure informatique ;
lenvironnement de production. En effet, cet aspect sera trait par la capacit de la TMA grer
les changements et rpondre rapidement aux incidents de fonctionnement dans le cadre du
MCO.
En synthse de cet aperu de CMMi, nous pourrions dire que cest un rfrentiel qui considre
les moyens de raliser correctement les projets informatiques sans tre une mthode de conduite
de projet ; il se positionne donc plutt au niveau des tudes informatiques, ou de la TMA lorsque
ses tudes sont externalises.
4.3.3. lTlL
ITIL pour Information Technology Infrastructure Library est un ensemble de bonnes pratiques
prsentes sous forme de livres. Plus prcisment, il sagit dun recueil de conseils et
recommandations qui sappuient sur la pratique et la matrise du systme dinformation,

Imprim le
orients vers le client pour tendre vers lexcellence oprationnelle par le dploiement de
processus [Lettre dinformation ITIL]
27
. On parle gnralement de bibliothque ITIL.
-..., C.
Ce rfrentiel de bonnes pratiques est dit par lOGC (Office of Government Commerce),
Office public Britannique du Commerce et, contrairement dautres, relve du domaine de
lOSL (Open Source Library). Cela signifie que lOGC nen est pas le seul auteur ; des groupes
de travail issus dautres structures contribuent ITIL et contrlent les termes et conditions de
distribution de leurs crations
28
.
ITIL a t initi au dbut des annes 1980 par le gouvernement britannique afin damliorer le
service rendu par les diffrents services informatiques de ltat. Cest un dispositif labor et
enrichi par des praticiens alors que dautres le sont plutt par des utilisateurs (il faut comprendre
des personnes qui nont quune vision thorique ).
Depuis sa cration, la bibliothque a vu le nombre de livres se rduire. Il est, dans sa version
deux, au nombre de sept. Les deux livres les plus significatifs, dITIL, sont le :
Fourniture des services qui traite des thmes de Gestion des contrats de service ,
Gestion transversale des problmatiques communes tous les contrats de service
et Gestion financire ,
Support des services qui aborde les thmes de Prise dappels , Rsolution des
dysfonctionnements , Gestion des volutions , Application des contrats de
service , gestion des incidents .
La version trois dITIL a t prsente en mai 2007. Le nombre de livres diminue encore :
ITIL version 2 ITIL version 3 (mai 2007)
Perspective de lentreprise Stratgie des services
Fourniture de services Conception des services
Gestion de la scurit Mise en production des services
Planification et mise en uvre de la
gestion de services
Exploitation des 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 dinformation (ou newsletter) ITIL est rdige par Christian NAWROCKI et publie sur internet
ladresse http://www.newsitweb.info
28
La distinction entre Open source et logiciel libre est clairement prcis par F GEORGEL dans son ouvrage
IT Gouvernance , chapitre 16.

Imprim le
-...|, |.. ,,|
Lobjectif dITIL est de fournir aux DSI les outils leur permettant damliorer la qualit des
services rendus leurs clients (les directions mtiers). Ce nest pas incompatible avec le principe
de contribution aux objectifs de stratgie de lentreprise. Elles ont, de plus, t largement
prouves dans le monde industriel.
Il y a fort parier que les techniques de maintenance des outils dune ligne de production, qui
doit tre oprationnelle vingt quatre heures sur vingt quatre, soient applicables des matriels de
centres de calculs (on utilise aussi langlicisme Data Center) et surtout tout aussi efficaces. Ce
parallle industriel permet de souligner un des intrts de la dmarche ITIL : donner
lentreprise une capacit de mise en ordre de marche et de mobilisation de ses moyens (dont font
partie les infrastructures du SI) lorsquelle doit mener la bataille de mise en uvre de sa
stratgie.
Les objectifs dITIL y contribuent en :
Alignant les services informatiques aux besoins actuels et futurs de lentreprise et de
ses clients (pas quau sens utilisateurs internes),
Amliorant la qualit et rduisant les cots des services fournis par linfrastructure,
Augmentant le taux de disponibilit et la productivit des ressources,
Rduisant les cots de fourniture des services long terme,
Proposant une dmarche volutive base sur les processus au sens dispositif de
transformation.
En dautres termes ITIL vise, pour les entreprises qui ladoptent, amliorer la qualit globale de
la production informatique et la rendre perceptible par les utilisateurs.
-..., | || | .| |||
Etant donn que la dmarche ITIL propose un rfrentiel des meilleures pratiques, les plus
values de sa mise en uvre, gnralement constates sont la :
Satisfaction des utilisateurs (personnel et clients),
Clarification des rles,
Amlioration de la communication inter-services,
Mise sous contrle des processus avec des indicateurs pertinents et mesurables,
permettant d'identifier les leviers pour raliser des conomies,
Meilleure comptitivit,
Scurit accrue (disponibilit, fiabilit, intgrit),
Capitalisation des donnes de l'entreprise,
Optimisation de l'utilisation des ressources,
Outil de parangonnage (benchmarking) et outil de positionnement vis--vis de la
concurrence.

Imprim le
-..., ||| | \C
En terme de MCO, le livre Supports des Services vise rpondre aux problmes de gestion
oprationnelle (traiter les erreurs connues) et assurer le maintien du bon alignement de la
production des services (rendus) avec lexigence de services (attendus) des directions
utilisatrices.
Les changements apports au niveau de linfrastructure globale (matriels, logiciels, rseaux,
contrats de services et documentation qui en dcoulent) sont clairement identifis comme une
des principales causes darrt non planifi au niveau des infrastructures. ITIL dtaille donc les
moyens de rpondre de la meilleure faon aux problmes rencontrs (cest un lien avec le
processus de gestion des incidents
29
) mais aussi de se prvaloir de consquences indsirables
causes par lapplication de changements.
La gestion des changements induite par le MCO est :
Lenregistrement et le filtrage des demandes : cette premire fonction a pour objet la
traabilit des demandes de changements. Elles peuvent tre acceptes ou rejetes
mais doivent toujours tre enregistres ; cest la notion de RFC (Request For Change
ou Demande de changement).
La gestion des priorits : fonction dont lobjet principal est dassurer une planification
des changements apporter en regard de leur impact sur larchitecture et surtout de
leur urgence.
La gestion des catgories : la catgorisation des demandes de changement permet leur
classement partir de lestimation de leffort consentir pour les mettre en uvre.
La planification : comme pour toute activit bien mene, un planning de gestion des
changements donne une vision globale des interventions mener. La planification
facilite aussi lanalyse dimpacts en cas dintervention urgente mener.
Le dveloppement, les tests et limplmentation : comme pour les dveloppements
applicatifs, la mise en uvre dun changement technique ne se fait pas sans un
minimum de prcautions, de garantie. Lobjet de cette fonction cl est dattester de la
bonne matrise du changement (au sens procdures de mise en uvre comme au sens
de son effet) sur un environnement le plus proche possible de celui de production. La
disponibilit dun environnement reprsentatif de celui de production relve plus
souvent dun vu pieux que dune ralit avre. Les cots dacquisition et de
dtention dun environnement de pr-production ont souvent du mal trouver une
justification aux yeux de ceux qui tiennent les cordons de la bourse
Ces fonctions cls relvent dune approche plutt oriente technique . Mme si ITIL est
clairement positionn du point de vue production (i.e. le sous-systme oprant), le rfrentiel ne

29
Dcrit dans ITIL la gestion des services -p 161-164

Imprim le
nglige pas laspect de la relation avec les objectifs des directions mtiers. Il le fait travers trois
autres fonctions cl :
Lanalyse dimpact : cette fonction a pour objet de comprendre les effets de bord que
pourrait avoir une demande de changement du point de vue des directions mtiers
mais aussi des autres engagements inhrents la continuit du service offert. Un
exemple pourrait tre la mise niveau, la monte de version , dun systme de
gestion de base de donnes. Si une telle volution nest pas sans risque, vis vis de la
mise en production programme dune nouvelle application, il sera
vraisemblablement opportun de la diffrer.
Lapprobation : le principe de cette fonction cl est dapprhender, en plus de la partie
technique, les aspects cot et porte fonctionnelle de la demande de changement. Ces
complments danalyse contribuent la qualification de la demande ; lapprouver ou
pas.
Le comit de gestion des changements
30
: au mme titre quun projet, les changements
font lobjet dune gestion digne de ce nom. Cest pourquoi il existe, en la matire, une
instance de type comit (comme il y a un comit de gestion de projet) compos de
membres permanents, ou non, qui procde aux arbitrages ncessaires : le CAB
(Change Advisory Board). Une autre de ses fonctions, qui rejoint en cela les
approches prcdemment abordes de CobiT et CMMi, est lanalyse a posteriori .
Cest ce qui permet didentifier et de comprendre les causes dchecs et donc
damliorer le processus lui-mme.
4.3.4. Synthse des referentiels analyses
Laperu que nous venons de faire de ces trois rfrentiels de base permet de se faire une
ide assez prcise de leurs complmentarits et de leurs relations la gestion de projet.
Lorganisation informatique doit disposer des bonnes mthodes et des bons outils pour rassurer
ses clients et accrotre sa performance.
Rappelons que CobiT couvre lensemble des activits du IT, cest un outil de gouvernance
remarquable, cependant sa mise en uvre est seme dembches.
CMMi est une mthode dorganisation pour le dveloppement et la maintenance dapplications
afin de fournir un code de qualit et la documentation associe.
Et ITIL est un rfrentiel de meilleures pratiques dans la gestion des services.
La norme ISO 9000, non dcrite prcisment ici, est cependant le socle sur lequel sappuient les
autres rfrentiels. Elle est issue de lindustrie et est un standard en terme de gestion de la qualit
dans le cadre des Exigences qualit du client , Exigences de mise jour et dapplications ,
dAugmentation de la satisfaction client et dAmlioration continue des performances

30
Ce comit de gestion du changement est prsent chez Gaz de France sous le Comit de pilotage Oprationnel

Imprim le
La figure ci-dessous reprsente une approche symbolise par une maison des rfrentiels :

La maison des rfrentiels
31

CobiT, CMMi, ITL constituent les briques essentielles du pilotage des Systmes dInformation
et de leurs directions, en alignement avec la stratgie dentreprise. Rappelons quil existe
dautres rfrentiels, non tudis ici.
Ils dfinissent les meilleures pratiques dans leurs domaines de comptences respectives. Ces
rfrentiels ne sont pas tanches les uns vis--vis des autres. Il existe des passerelles, des
points communs comme peut ltre le concept de niveau de maturit de CMMi abord par CobiT
et ITIL.
Pour une entreprise mettre en pratique lun, ou plusieurs de ces rfrentiels est une action
prvoir sur du long terme.
Ainsi, un tat des lieux des entreprises utilisant des mthodologies, indique les rsultats
suivants
32
sachant que certaines dentres elles en utilisent plusieurs:
56% utilisent mthodes internes,
24% ISO 9 001,
16% PMI,
8% ITIL,
4% Autre,
2% CMM,
13% aucune mthode.

31
ITIL et la Gestion des Services T.Chamfrault & C. Durand p 280
32
Ces rsultats sont issus dune enqute mene par IDC en 2004 auprs des DSI de 170 entreprises et
administrations franaises

Imprim le
4.4. Conclusion
Ces rfrentiels permettent daborder le MCO dapplications de manire homogne avec une
mme proccupation : viter et/ou matriser les perturbations potentielles de ce qui doit
prfrablement rester le plus stable possible (lapplication, les architectures applicatives ou les
infrastructures du SI). Ils ont galement pour but de simplifier, rationaliser, mutualiser les
infrastructures et les cots induits.
Dans le cadre du MCO, il est donc possible de se rfrer tout ou partie de ces rfrentiels,
tant entendu que leur mise en uvre nest pas un gage de qualit mais bien une aide pour
arriver un rsultat.
De fait, CobiT sera utilis par la MOA pour gouverner son systme dinformation, ITIL par la
MOE pour assurer la meilleure gestion de service et le CMMi par la SSII pour maintenir le
produit dans des conditions oprationnelles optimales.
Les processus de chacun de ces rfrentiels sont utiliser en fonction des attentes des instances
de Gouvernance du SI et avec un objectif oprationnel . Rien ne sert de dcrire des processus
qui ne seront pas utiliss parce que trop complexes suivre au quotidien.

Imprim le
5. PREPARATlON ET PASSAGE EN MCO
5.1. lntroduction
Dans les chapitres prcdents, nous avons dfini ce quest le MCO, dcrit lvolution de
lorganisation des instances IT de lentreprise en mettant en avant les diffrentes composants
internes et externes. Nous avons galement analys les diffrentes mthodologies qui existent, de
la gestion de projet aux rfrentiels complmentaires lis la Gouvernance des SI en rapport
avec le MCO.
Dans ce chapitre, nous allons dcrire les actions raliser lorsque le projet devient une
application grer en MCO, dtailler les activits principales mener en MCO et les acteurs qui
les portent avec le niveau de responsabilit associ.
5.2. Du projet au MCO
Le dcoupage en phase du projet, du lancement la mise en production, va permettre davoir une
visibilit suffisante pour dterminer la priode probable de passage en MCO. Une des tches
dclencher lors de la clture du contrat du processus Management des approvisionnements du
projet du PMBOK est donc de prvoir le lancement du contrat suivant. On peut donc dire que
la tche Planifier la clture du contrat de ralisation implique obligatoirement le lancement
de la mise en uvre dun nouveau contrat. Ainsi, il est ncessaire de mettre en oeuvre les tapes
dune procdure achat dont lissu est la production et la signature dun contrat.
5.2.1. Les procedures d'achat
Quelque soit le type de contrat, de ralisation ou de TMA pour ce qui nous intresse, les
entreprises sont soumises cinq grands principes dachats qui sont les suivants :
Une mise en concurrence systmatique de plusieurs fournisseurs,
Une non-discrimination,
Une transparence de la consultation,
Une traabilit des diffrents documents, intervenant,
Une Ethique.
Pour rpondre ces principes, la procdure dachat va se drouler comme suit :
Lappel dOffre. Un appel doffre dcrit les caractristiques de la prestation attendue
(de lachat), les conditions de la consultation, cest dire les dlais et les lments de
rponses attendus quils soient techniques ou financiers. En gnral, le formalisme du
cadre des rponses est galement fourni. Les critres qui permettront de qualifier les
rponses les une par rapport aux autres sont dfinis simultanment et sont regroups
sous forme de grille danalyse,
Le dpouillement. Les rponses de chaque fournisseur sont ensuite analyses
(dpouilles), les grilles sont remplies et sont prtes tre compares. En gnral, les
fournisseurs dont la note lcrit atteint un seuil dfini lavance sont convoqus

Imprim le
une soutenance orale. La mme mcanique est applique pour qualifier ces
soutenances orales.
Le choix. Le fournisseur choisi est celui qui a la meilleure notation moyenne, crite et
orale cumules.
La procdure dachat peut donc se concrtiser par lachat de la prestation demande formalise
par un contrat.
5.2.2. Les contrats
Ainsi, un contrat est, en gnral, compos dun lot ferme (avec la description des ralisations
impratives du contrat) et un ou plusieurs lots optionnels qui ont pour objet de prvoir lavance
les actions complmentaires ventuelles. Comme il nest pas toujours ais danticiper ces
actions trois ou quatre annes lavance, le caractre optionnel de ces lots permet de prendre la
dcision de les souscrire ou non une fois ltape de ralisation termine.
Dans le cadre plus prcis dun contrat de ralisation, il est possible de prvoir la rdaction dun
lot optionnel de MCO avec pour cible de prparer la ou les premires annes de vie du produit.
Pour quil soit utilisable, la description des activits, des responsabilits et des devoirs respectifs
de chaque instance doivent tre dtailles. En gnral, ce nest pas le cas puisque laccent est mis
sur la phase de ralisation au dtriment bien naturel du MCO. Dans ce contexte, le lot de MCO
est prendre comme un moyen de prolonger lextension de garantie due par lintgrateur et
permettre la DSI de la socit de mettre en place lquipe adapte au maintien en condition
oprationnelle du produit, dassurer les priodes de recouvrement ncessaire au transfert de
comptences et ventuellement de mettre en place les organisations pour fdrer les services.
Lappel doffre pour assurer la TMA peut tre lanc plus sereinement que sil avait fallu le
parallliser avec la phase de mise en production du projet.
En effet, le lancement dun produit est toujours une phase suffisamment dlicate pour quelle soit
mene indpendamment de toutes contraintes externes au projet.
5.2.3. La phase de transition
Dans tous les cas, cette phase permet dassurer la transition entre la fin du projet et le dbut du
cycle de vie du produit. Il est bien sr ncessaire de prvoir un contrat de maintien en condition
oprationnelle spcifique o tous les aspects de maintenance (acteurs, actions, dlais, moyens,
contraintes, sanctions) seront dcrits en dtail.
Dans le cas o le maintien en condition oprationnelle serait sous trait, le contrat tablir avec
le prestataire est un contrat de TMA.
Le passage en MCO signe donc thoriquement la fin du mode projet. Ceci se traduit trs
concrtement par une dmobilisation des quipes MOE, surtout lorsquelles sappuient sur des

Imprim le
contrats de ralisation au forfait
33
. La reconduction de lquipe intgrateur via la
contractualisation du lot optionnel de MCO peut permettre une dmobilisation plus en douceur
de cette quipe.
Toutefois, cest bien cette priode quil faut sinterroger sur la manire dont cette phase devra
se drouler (qui va assurer la gestion de services), prparer lorganisation adapte mettre en
place (interne et externe la MOE du SI de lentreprise), considrer les organisations existantes
et ventuellement y adhrer. En tout tat de cause, la prparation du MCO du produit est
construire.
Dans le cas o il serait ncessaire de faire appel un ou plusieurs prestataires pour assurer les
actions dassistance matrise duvre, dexpertise, dassistance utilisateurs, de recette de
versions, dexpert technique en dveloppement de logiciel et de gestion de lexploitation
quotidienne, il faudra prparer et lancer un ou plusieurs appels doffre pour choisir celui qui
assumera les diffrents services. Pour la partie de MCO proprement dite, lappel doffre
mener sera destin des SSII et devra tenir compte de tous les lments dtaills 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
diffrents de la priode projet .
5.3.1. Acteurs MOA
Comme indiqu dans les chapitres prcdents, le matre douvrage est lentit porteuse du
besoin (entreprise, direction, service). Cette responsabilit ne change pas pour la phase de
gestion et de suivi de lapplication.
La MOA est en gnral reprsente deux niveaux distincts :
Le niveau des utilisateurs regroups autour dun comit de suivi de lapplication (ou
dun club utilisateurs, un bon moyen de crer une entraide efficace) ; lobjectif ici est
de partager sur le caractre utilisable du produit : quels en seraient les axes
damlioration, ce qui est plus de lordre de lanomalie de fonctionnement que de
lvolution
Le niveau de dcision de la MOA qui statut sur le bien fond dvolutions majeures en
terme de ncessit et de ROI. Ce deuxime niveau aura la charge de grer le
portefeuille des demandes dvolution en terme de recevabilit et de priorit. En
dautres termes, elle aura la responsabilit de dfinir le contenu dune nouvelle
version dun produit, sa date de livraison en tenant compte des contraintes techniques
de mises disposition et dutilisation quotidienne.

33
Un contrat au forfait est un contrat avec engagement de rsultat le produit est le livrable principal. En cas de
dsaccord sur la qualit de ce livrable, la charge de la preuve sil y a eu manquement, est fournir par le
prestataire

Imprim le
La MOA est donc le contact privilgi des utilisateurs finaux. A ce titre, elle sera aussi
linterface entre la MOE et les utilisateurs lors de la recette dune nouvelle version de
lapplication.
5.3.2. Acteurs MOE
Pour la MOE, la grande diffrence entre la gestion de projet et le MCO rside dans le nombre de
personnes mobilises et la manire dont les activits sont rparties.
Le pilotage des travaux confis la DSI pour le MCO dun systme informatique est assur par
le chef de produit. Il est en gnral accompagn dune quipe et sappuie sur des contrats
externes.
Les lments suivants sont le rsultat dune rflexion consolide partir de plusieurs modes
dorganisations existantes o les responsabilits hirarchiques et fonctionnelles cohabitent et
nimpactent ni les rles ni les responsabilits individuels.
...., ' || ,.
-
| !.|
Il est responsable des applications dont il a la charge. Il dfinit le calendrier des volutions du
systme.
A ce titre, son domaine dactivit est le suivant :
Il pilote les appels doffre lis des renouvellements de contrats ou de nouveaux
contrats de prestation,
Il gre les contrats et les budgets des prestations externes,
Il pilote la prestation de TMA et valide les lotissements (versions),
Il gre le respect des livraisons planifies pour chaque version,
Il valide les devis et gre les commandes dapprovisionnement,
Il est garant vis vis de la MOA de toutes les actions lies la gestion des
changements, des incidents, des indisponibilits,
Il pilote et arbitre les activits du gestionnaire oprationnel, du ou des experts
fonctionnels,
Il assure le reporting de lactivit de lquipe vis vis du responsable de domaine.
Certaines de ces activits peuvent tre ralises par dlgation. La taille humaine de lquipe
dpendra de limportance de la ou des applications maintenir.

34
Au CSI de Gaz De France, cest le POA : Pilote Oprationnel dApplication

Imprim le
....|, | |,|| C,.|

Il a la responsabilit du fonctionnement quotidien de lapplication. Il assure et rend compte du
service rendu.
Si on se rfre au livre sur le Support des Services dITIL, lobjectif est bien de rpondre
aux problmes de gestion oprationnelle (traiter les erreurs connues) et dassurer la production
des services rendus en tenant compte de lexigence des services attendus par les entits mtiers
utilisatrices ; A ce titre,
Il prend en charge lanalyse des sollicitations
36
utilisateurs reues et enregistres par
lAssistance Utilisateur (AU). Il est le contact privilgi de la cellule AU de la DSI,
Il est responsable du rsultat des analyses faites en cas dincident dexploitation.
Lanalyse des causes et des consquences doit permettre de rtablir rapidement la
situation. La traabilit des actions doit tre mene pour capitaliser en cas de rcidive.
Des actions de maintenance corrective prennes doivent tre planifies auprs de la
TMA pour viter que lincident ne se reproduise,
Il sassure que les travaux concernant les corrections de base de production sont
coordonns entre les diffrents intervenants,
Il synthtise 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 dapplication
mais aussi de la MOA. Lun des objectifs ici est de diminuer le nombre dappels en
identifiant leur origine : de nouvelles formations peuvent tre planifier, une
attention particulire lors de la mise en production de nouvelles versions de
lapplication sont initier, (actions prventives, etc.).
...., |,. ||
Il a la responsabilit des demandes dvolution des applications dont il gre le portefeuille de
ralisation.
Il rceptionne les demandes dvolution de la MOA ; ces demandes sont fournies sous forme de
cahier des charges ou dexpression de besoin .
La MOA attend en retour une tude de faisabilit avec les impacts fonctionnels, techniques et
organisationnels sil y en a, un cot financier prvisionnel et une charge de ralisation.
Lensemble de ces informations est indispensable pour statuer sur la priorit des volutions en
fonction dun budget et dimpratif de disponibilit.

35
Selon le cas, il peut tre appel Responsable de la Performance ou Gestionnaire Oprationnel
36
Une sollicitation est une demande daide lutilisation, une interrogation face un dysfonctionnement de
lapplication, etc.

Imprim le
Ces demandes relvent du processus Gestion des changements de CobiT qui permet de
dcrire en commun accord, les rles, les responsabilits et les livrables rpartir entre la MOA et
la MOE. En phase de MCO, le rle de lexpert fonctionnel devient majeur.
A ce titre,
Il synthtise lensemble des demandes dvolution et propose des versions cohrentes,
Il rdige les tudes de faisabilit associes aux cahiers des charges et sollicite la TMA
pour les charges et les cots prvisionnels de ralisation. Il met en avant dventuelle
connexion et/ou interfrence avec dautres applications et mutualise les analyses le
cas chant,
Il anime les ateliers mtiers en fonction des demandes dvolution en cours,
Il rdige les spcifications gnrales destines la TMA pour prise en compte de
lvolution et valide en retour les spcifications dtailles correspondantes rdiges
par la TMA,
Il organise les recettes des versions et coordonne les activits lies aux livraisons
correspondantes avec le sous traitant en charge de lintgration et de la recette qui il
fournit le cahier de recette associ,
Il rend compte de lavancement des travaux de recette,
Il analyse
o La qualit des livraisons en intgration/recette avec des indicateurs lis aux
nombres danomalies (bloquantes, majeures, mineures ou de confort) dtectes
par livraison,
o la qualit des recettes avec des indicateurs qui comptabilisent les anomalies
dtectes aprs la mise en production,
Il est responsable de la qualit de la version livre aux utilisateurs finaux pour recette,
Il organise les recettes mtiers,
Il assure galement le reporting concernant lavancement sur les demandes
dvolution en cours et sur lavancement de ralisation des versions.
...., | . . \C! .
Les autres acteurs de la MOE sont lis la TMA, lAU et la recette.
Leurs primtres dactivits ont t dfinis lors de la signature du contrat de TMA dune part et
de services pour lAU et la recette.
Le responsable dapplication est mme de qualifier leur prestation respective laide
notamment des diffrents reporting fournis par son quipe.
Ici, laspect contractuel est mis en avant. La prestation fournie doit correspondre la prestation
dcrite 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 dquipe htrogne de MCO (instance cliente, instance
AMOA, instance AMOE et instance MOE) est quil ncessite la mise en place dinstances de
pilotage et de coordination. Au cours de ces runions, tous les points importants sont abords,
dbattus le cas chants, status et tracs.
5.4.1. Reconduction des methodes appliquees dans les projets
La mthode de gestion de projet, comme indiqu dans les chapitres prcdents, doit pouvoir tre
applique galement la phase MCO lorsquil sagit de gestion du changement. Ces
changements doivent tre matriss et rpartis dans des versions. Ce constat est conscutif au fait
quil est primordial dattnuer les points faibles de la gestion projet, points accentus dans le
cadre du MCO.
En effet, en termes de mthodes, on touche aux limites de validit de celles employes sur les
projets. Ces faiblesses sont, lorsquelles existent, lies labsence de vritable structure projet :
Lvaluation des charges lissue de la spcification : il est bien rare que lon travaille
autrement qu dire dexpert pour valuer les charges. La mise en route dun
processus dachat au forfait est trop lourde et finalement cest le client qui sengage,
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 dtude
37
notamment par la mise au point de contrat
prcis de recette pass avec des sous-traitants. Mme si laspect contractuel doit
prciser les attentes relles de la socit et spcifier des indicateurs mesurables et
mesurs. La mise en place de structures et doutils de tests automatiss reste un point
fort ne pas ngliger.
Lintgration : la mise en production est souvent lourde et complique, elle exige des
ressources mobilises en mode projet mais pas toujours disponibles en maintenance.
Cet aspect doit galement tre spcifi prcisment avec le sous-traitant et tre
contractualis pour que ce dernier puisse mettre en place les actions ncessaires.
La validation par les utilisateurs : elle se fait bien souvent en situation dutilisation
relle, faute de temps et denvironnement ad hoc. Ce point l est plus difficile
rsoudre. En effet, il est galement possible de contractualiser ces lments avec la
MOA, mais pour un utilisateur mtier, il est toujours dlicat de se dispenser de

37
Au PCL, et plus particulirement la cellule Recette de la TRA, des essais de suivi qualitatifs de tests sont en
cours notamment sur lapplication VICTOR.

Imprim le
lactivit quotidienne. Sur ce point, lapplication des processus CobiT de
Gouvernance du SI et notamment de la procdure Acquisition des applications
peut tre une solution. En tout cas, cest la MOA de rgler ce problme vis--vis des
mtiers. 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 anne. En effet, la multiplication des versions dgrade considrablement le
processus aval de la mise en production en relation avec les utilisateurs.
Cet inconvnient combin la difficult de trouver des fentres de changement dans des
plannings de production souvent surchargs conduisent galement militer pour regrouper les
modifications dans une mme version. Un nombre de quatre versions par an semble raisonnable
ce qui permet davoir un volume de changement consquent quasiment assimilable un projet et
qui justifie la mise en place dune structure adapte et lapplication de la mthode projet.
5.4.2. Les procedures supplementaires prevoir
Ces procdures concernent les points sensibles du MCO dune application et ont t abords
prcdemment, 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 accs aux applications,
o Signaler des anomalies,
o Demander des traitements particuliers (type extraction de donnes),
La gestion des incidents qui met en avant la relation MOA-AU-MOE-TMA ,
La gestion des configurations : cette gestion est en gnrale aborde dun point de vue
centre de dveloppement ; cependant la DSI doit galement pouvoir grer ses
configurations et grer les interactions entre les diffrents produits maintenir en
condition oprationnelle.
5.5. Les actions incontournables
Les actions suivantes sont ou ont t menes avant la fin du contrat initial de ralisation, lot
optionnel inclus de MCO ventuellement :
1. Etablir un contrat de TMA : tout doit tre dfini prcisment, lidal pour une DSI est de
possder des contrats de TMA type qui prcise les niveaux de services attendus et les
indicateurs pour les mesurer (dlai de correction dune anomalie bloquante, majeure,
mineure ; nombre danomalies dtect suite la livraison dune nouvelle version, etc.),

Imprim le
2. Etablir un contrat de TRA (Tierce Recette Applicative) : dfinir les activits de cette
cellule (rdaction des scnarii de test de non rgression, de versions, les mettre jour) ;
dfinir un dlai pour raliser la recette de la version (au prorata du nombre de jours de
ralisation de la version par exemple), dfinir des indicateurs de qualit de la recette en
suivant les anomalies de production, etc.,
3. Etablir un contrat dassistance utilisateur (AU) : cest le centre de service, le point
nvralgique de la relation client, ses activits sont orientes clients, il doit tout mettre en
uvre pour informer au plus vite de sa capacit ou non rpondre une demande. Le
contrat doit galement prciser le niveau dassistance apport par lAU aux clients. Les
indicateurs vont mesurer les dlais entre la prise dappel et la rponse apporte au client,
etc.,
4. Mettre en place un mode de gestion collaboratif avec la MOA et prciser au minimum le
mode de communication pour :
a. La gestion des changements,
b. La gestion des incidents,
c. Lacquisition des applications,
5. Mettre en place un mode dchange avec les diffrentes instances dexploitation.
5.. Conclusion
Passer dun projet un produit exploitable et assurer son maintien en condition oprationnelle
est une tche seme dembches.
La MOA devra mettre en place les lments induits par le processus de Gouvernance du SI et
notamment grer 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 linterface principale
entre la DSI et les utilisateurs, tre le garant du respect des engagements de services,
mettre les moyens pour piloter les vnements (incidents, demandes), fournir une
interface avec les processus de production, proposer une plate-forme daccueil de
services destine aux utilisateurs, etc.,
Anticiper la recherche dune TMA quelques mois avant la fin de garantie ou la fin du
lot de MCO souscrit ventuellement avec le contrat de ralisation. De plus, il est
impratif de rflchir et mettre en place une quipe charge du MCO du produit
concern.

Imprim le
. CONCLUSlON
.1. Recapitulatif des attentes de l'etude
Lobjectif de cette tude consistait mettre en avant les difficults portes par la gestion en
MCO dune application, didentifier, de dfinir et de mettre en uvre lensemble des tapes et
des actions de la dernire phase du projet la premire phase de maintien en condition
oprationnelle du produit associ.
Pour ce faire, nous avons dans les prcdents chapitres :
Donn un sens lacronyme MCO en terme de contenu dactivit raliser et de
but atteindre,
Trac et dcrit lvolution de lorganisation des instances informatiques de lentreprise
et situ la priode dans laquelle ces instances voluent actuellement en mettant
laccent sur les axes et les actions stratgiques,
Mis en avant le fait que beaucoup dentreprises 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 mthodologies tant en terme de gestion de projets que de rfrentiels mis
disposition par diffrents types dorganismes de normalisation ou dinstances
gouvernementales,
Identifi galement, que le cycle de vie du projet est une phase rptitive de la vie du
produit gre en MCO
Identifi, parmi les rfrentiels complmentaires ceux qui taient les plus utiliss en
tenant compte des objectifs cibls, ce qui a eu pour effet dassocier CobiT la MOA
pour la Gouvernance de son SI , ITIL aux instances informatiques Interne des
socits notamment pour la gestion des services et CMMi la production industrielle
de logiciel,
Mis en avant lutilit pour les entreprises dutiliser les mthodologies adaptes
chaque situation selon quelle est IT ou Mtier .
.2. Conclusion generale
Au vu du rsultat de ces analyses, il est avr que la matrise du processus de maintien en
condition oprationnelle dun produit est une phase primordiale pour lentreprise, comme la t
au cours des annes 80, limplantation dune mthodologie de projet. Limpact est visible au
niveau global de lentreprise, des instances mtier linstance informatique. En effet, pour les
utilisateurs, un processus sous contrle, propage un sentiment de scurit quant la fiabilit des
outils IT mis disposition. Les relations, entre les diffrents acteurs et les actions menes au
sein des socits se sont clarifies, dcloisonnes et formalises.
Attention, toutes ces mthodologies doivent tre adaptes aux spcificits de chaque socit et
non linverse. En effet, ce sont avant tout des moyens qui permettent de mieux travailler

Imprim le
ensemble. Elles dcrivent 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 matriser toutes les phases du processus simultanment,
laccent est mettre sur celles qui induisent trop dinsatisfactions savoir la gestion des services
et plus prcisment, la Gestion des incidents et la Gestion des volutions .
.3. Conclusion pour le PCL
Cette tude couple la mission effectue au PCL a mis en vidence la ncessit dorganiser la
phase de transition entre le projet et le MCO du produit en termes :
Contractuel, cest dire sassurer que les activits de maintenance sont prvues et que
le relais entre le contrat de ralisation et de TMA est planifi. Ainsi, pour
lapplication VICTOR, une anne de MCO via le contrat de ralisation a t souscrit.
Pour que la TMA soit oprationnelle lissu de cette prolongation, le cahier des
charges, pice indispensable au lancement dun appel doffre, sera rdig en
septembre .... avec notamment lambition dtre suffisamment prcis et complet pour
pouvoir tre capitalis au niveau du domaine (gestion transversale des problmatiques
communes tous les contrats de service dITIL),
De communication entre la MOE et le PCL ; les processus lis la Gouvernance du
SI issus de CobiT et plus particulirement les procdures Acqurir des
applications et en assurer la maintenance , Grer les changements , Installer et
valider les solutions et les modifications , Grer les problmes ont t adaptes
la gestion du MCO de VICTOR et des applications futures maintenir du domaine.
Les comits de coordination dune part et de pilotage dautre part sont en place.
Dorganisation de lquipe de MCO ; sur ce point, les activits assumer sont
identifies et sont bien orientes vers la satisfaction des utilisateurs, la clarification
des rles, lamlioration de la communication. Laccent est mis sur la gestion des
changements et notamment sur lenregistrement et le filtrage des demandes qui doit
se faire en un point unique, sur la gestion des priorits avec lobjectif dorganiser et
de planifier les versions et sur la recette. Les indicateurs pour mesurer la performance
sont en cours de construction.

La Cellule Oprationnelle du PCL a, entre autre, en charge de dcliner et de contrler 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 dvolutions et de gestion des incidents, vont tre suivis et revus
priodiquement la cellule Oprationnelle selon les retours dexpriences.


Imprim le
ANNEXES ANNEXES ANNEXES ANNEXES
1. GLOSSAlRE
AFAI Association Franaise de lAudit et du conseil Informatiques
AFITEP Association Francophone de Management de Projet
AFNOR Association Franaise de NORmalisation
ANSI American National Standards Institute
AU Assistance Utilisateur
CAB Change Advisory Board
CIRAU Cellule Intgration Recette Assistance Utilisateur du CSI-PCL
CMMI Capability Maturity Model Integration. Mthode qui vise porter
lentreprise au niveau de comptence (ou maturit) qui lui permet de
raliser correctement ses projets. CMMI est plutt positionn sur la
maturit du dveloppement logiciel
COBIT Control Objectives for Information and related Technologies.
Rfrentiel mthodologique qui traite de la gouvernance.
CSI Centre de Services Informatiques
DGI Direction des grandes infrastructures de GDF SUEZ
DoD Dpartement amricain de la dfense
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 Systme dinformation
ITGI Information Technology Governance Institute
ITIL IT Infrastructure Library
MCO Maintien en Condition Oprationnelle
MOA Matrise douvrage
MOA-D MOA Dlgu Mission dexpertise par dlgation du directeur

Imprim le
MOA-O MOA Oprationnelle- responsable de chaque domaine mtier
MOA-S MOA Stratgique- Assiste le directeur pour les dcisions relatives au SI
MOE Matrise duvre
PCL Ple Clients, entit du CSI
PCS Pouvoir Calorique Suprieur exprim en kwh/m3
Est dtermin lentre (alimentation) par analyse chromatographique
des diffrents composants du gaz naturel (mthane, propane, butane,
etc.) dtermine la qualit du gaz
Il calcule la quantit dnergie que dgage un m3 de gaz normal en
brlant.
PMBOK Project Management Body Of Knowledge pour Corpus des
connaissances en management de projet
PMI Project Management Institute

PSI Ple Systme Industriel, entit du CSI
ROI Return Of Investment
SEI Software Engineering Institute ou Institut de lIngnierie Logiciel
SIMONE-GRT Application qui dtermine les PCS aux points de livraison du rseau par
le biais dun algorithme de reconstruction, et de permettre ainsi de
minimiser les cots dquipement et dexploitation lis aux
chromatographes supplmentaires installer, tout en respectant les
futures exigences rglementaires
SINDI Systme dINformation DcisIonnel
SSII Socits de Services en Ingnierie Informatique
SI Systme dInformation
TMA Tierce Maintenance Applicative
TRA Tierce Recette Applicative
VICTOR Validation des Index de Comptage et des Tltransmissions et
Organisations des Restitutions
Application qui gre les donnes de comptage et effectue tous les
traitements sur ces donnes. Sa principale fonction est dlaborer et de
mettre disposition des autres applications les mesures horaires et
journalires en nergie et en volume pour tous les points de comptage
(tl-transmis, relve mensuelle ou fictive)

Imprim le
2. WEBOLOGlE
http://interne.gaznet.gazdefrance.com Site intranet de GDF SUEZ
http://www.Itilfrance.com Le site Francophone sur ITIL
http://www.afitep.fr
Association Francophone de Management
de Projet
http://www.afnor.org/ Association Franaise de NORmalisation
http://www.g9plus.org/interface/CR_ITGov_5Juil
_2006.pdf
L IT Gouvernance et panorama qualit
versus ITIL, CMMI & Cobit :quel avantage
pour la DSI ?
http://www.volle.com/travaux/moa_du_si.htm Prospective de la matrise d'ouvrage
(cf. copyright : Michel Volle)

http://www.newsitweb.info La lettre dinformation (ou newsletter) ITIL
est rdige par Christian NAWROCKI et
publie sur internet ladresse
http://www.fr.capgemini.com/about/histoire/

Histoire de CapGemini
www.commentcamarche.net
Document intitul Matrise douvrage /
Matrise duvre issu de Comment a
marche
3. BlBLlOGRAPHlE
AFAI, COBIT Objectifs de contrle de lInformation et des technologies associes , 4
me

dition traduite en franais.
GEORGEL F, IT Gouvernance , Dunod 2006.
PMI, PMBOK Corpus des connaissances en management de projet , traduction franaise de la
3me 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 dactivit et systme dinformation , 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 systme d'information, par Fabien Cleuet, article Informatique
professionnelle n209,12/2002 (publication Diathse)

Master 2 - Mention Informatique Et Systèmes Spécialité - MIAGE - Méthodes Informatiques Appliquées À La Gestion D'entreprise

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Master 2 - Mention Informatique Et Systèmes Spécialité - MIAGE - Méthodes Informatiques Appliquées À La Gestion D'entreprise

Încărcat de

Drepturi de autor:

Formate disponibile

Scol ari t 2-3 Cycl es UFR SFA

Les relations MOA-MOE

S-ar putea să vă placă și