M2

5/11/2018 M2 - slidepdf.com

http://slidepdf.com/reader/full/m25571fdb5497959916999bf72 1/73

Scolarité 2-3è Cycles – UFR SFA

Bd François Mitterrand

91025 EVRY Cédex

MASTER 2

-

Mention Informatiqueet

Systèmes

Centre de Services informatiques (CSI)

14-16 rue Touzet Gaillard

93400 ST OUEN

Spécialité - MIAGE -

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

(MCO)

La gestion du MCO d’applications au sein d’un Service Informatique d’une Société

lorsqu’il est confié à une T.M.A.

Auteur : Anne DENIBAUD

Année :

Maître de stage Professionnel :

M aître de stage Universitaire :



Problématique du Maintien en Condition Opérationnelle d’Applications (MCO)

M2 Miage Anne Denibaud / 73

Imprimé le

Remerciements

Tout d’abord à Madame Estelle Dlouhy-Morel qui m’a intégrée dans son équipe sans faireaucune différence quant à mon statut de stagiaire. Elle m’a accordée sa confiance et m’a permis

d’être autonome tout en sachant être disponible en cas de nécessité pour répondre à mes

interrogations.

Egalement à toutes les personnes du Pôle Clients pour leur accueil chaleureux, pour mon

intégration sans réserve, pour leur patience en regard de mes sollicitations et le tout sans compter

leur temps.

A tout le CSI et plus largement à la Direction des Systèmes d’Informations Client de GRTgaz,

notre MOA, pour lesquels j’étais une « gazière » comme une autre.

Mais aussi, à l’ensemble des enseignants de l’Université d’Evry que j’ai côtoyé lors du premier

semestre et qui ont satisfait mes attentes et contribué à l’intérêt de ce programme.

Et enfin, à toutes les personnes de mon entourage professionnel, familial et privé qui ont accepté

de me soutenir dans cette expérience, m’ont encouragée quand il le fallait et m’ont déchargée

d’une grande partie du quotidien.

Cette année et ce résultat sont les vôtres.





Imprimé le

SOMMAIRE

!

" #$%&'&!(

) *+*,-&&* (

. *+*,-''* /

" 001## 2

" 3&&, 2

"" &4!*+5#*36*

") &!*

". 5!''!

0000 "

0 "

" # .

" && .

"" *'& .

") &43'#

". &!& (

) 70 /

) && /

)" &+&, /

)) !63&8 /

). %* 9

) -**&* ")

)( *,&!&!:!+* "/

)/ +$&; "<

)< &!& "<

. =0 )2

. && )2

." +*8&&!&%%&&3 )





Imprimé le

.) +*8&&!&%5&+!*+ .)

.. &!& 9

7# (2

&& (2

" &3# (2

) # ("

. &%&# ((

&>&&4!? (/

( &!& (<

( 0 (9

( *!'!* (9

(" &!&%**! (9

() &!&&! /2

@ @ @ @ /

7 /

" A7 /)

) 7 /)





Imprimé le

!

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 l’énergieen Europe. Il produit, achète, transporte, distribue etcommercialise du gaz naturel, de l’électricité et desservices associés à ses clients ; particuliers, entreprises etcollectivités.

*+BC!!D>!!&&B!?

Le CSI est l’opérateur informatique des activités régulées de Gaz de France c’est à dire celles quiconcernent les infrastructures de transport, stockage, regazeification, et est organisé en 3 pôles.• Le Pôle Système Industriel (PSI) gère les métiers d’exploitation et de maintenance des

installations et d’ingénierie,

• Le Pôle Clients (PCL) est en charge de la gestion des systèmes d’information liés à la

commercialisation des infrastructures qui outillent les processus de stockage,

d’acheminement, de conduite et de mesurage du gaz,

• Le Pôle Tertiaire est la structure qui porte les applications complémentaires auxfonctionnements du CSI

Ci-dessous, l’organigramme correspondant :

!!"#$%#&'#

""""

"$# "("

")*$

+

,

-





Imprimé le

" &+&C!

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

Maîtrise d’ouvrage (AMOA), la conduite de projets, la maintenance et l’assistance utilisateurs

des applications métiers pour le compte de ses bénéficiaires (clients) qui sont :

• La filiale GRTgaz, responsable des activités liées aux réseaux de transport du gaz

(développement des réseaux, commercialisation des prestations de transports de gaz

destinées aux tiers, etc.),

• La Direction des Grandes Infrastructures (DGI) qui assure en France, l'exploitation, le

développement, la maintenance des stockages et terminaux méthaniers.

" #$%&'&!

Estelle DLOUHY-MOREL est Responsable du Domaine « Allocations - Bilans». Elle m’aaccueillie dans son équipe et suivie tout au long de mon stage.

) *+*,-&&*

Ma mission au sein du PCL est de mettre en place pour le mois de juillet …., le dispositif de

Maintien en Condition Opérationnelle des applications VICTOR1, SINDI2 et SIMONE,

applications du domaine « Allocations - Bilans» qui sont au cœur du SI du pôle.

Cette mission est déclinée selon trois axes :

• Le premier axe consiste à étudier et à préparer la mise en place des contrats de Tierce

Maintenance Applicative (TMA) en tenant compte:

o Des dates et des budgets des contrats projets en cours qui traitent des lots de

conception, de développement, et du lot optionnel de Maintenance en Condition

Opérationnelle,

o Des renouvellements de contrats de TMA déjà planifiés au PCL.

• Le deuxième axe est de spécifier et de mettre en place les relations « Maîtrise

d’ouvrage (MOA) – Maîtrise d’œuvre (MOE) » et de proposer une offre de service

adéquate pour permettre à la MOA de piloter ses applications efficacement.• Le troisième axe concerne l’identification et l’énumération des actions que devra

assurer la MOE. L’objectif est de fournir tous les éléments pour permettre de définir

l’organisation cible à mettre en place au sein du domaine.

) &!

Pour mener à bien l’étude, je dispose de tous les documents relatifs au fonctionnement et à

l’organisation du CSI et du PCL en particulier. En complément, j’utilise les premiers processus

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

2 Système d’INformation DécisIonnel





Imprimé le

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

gouvernance du Système d’Information (SI) initialisée par la MOA de GRTgaz.

)" !%*,&!,-

Action et dates clés

Le contrat de TMA Présentation des scénarii concernant la stratégie d’appel d’offre04/..... Préconisation du scénario le plus en adéquation avec lescontraintes et les disponibilités du PCL.

Les relations MOA -

MOE

5 Ateliers programmés du 29 mai au 26 juin avec la MOA de

GRTgaz pour mettre en place un mode de travail commun décliné

selon les principales procédures du processus ‘Gouvernance du SI’.

L’organisation MOE 5 Interviews d’agents dont les activités sont en relation avec leMCO d’applications. Rédaction du document de synthèse pourdéfinir le plan d’actions associé à la mise en place d’uneorganisation dédiée.

)) &-,-

Au cours de cette prestation réalisée chez Gaz de France, j’ai bénéficié d’une totale autonomie

tant au niveau de l’organisation de mes activités que de la manière de les restituer.

. *+*,-''*

. #&!

• Faire une analyse pertinente et factuelle des documents contractuels existants du

domaine « Allocations - Bilans» pour fournir une vision claire des actions à planifier

et assurer une transition de qualité entre les intégrateurs « Projet » et « TMA ».

• Etre force de proposition dans l’étude des procédures liées au passage en MCO

d’applications du domaine « Allocations - Bilans» en mettant en avant l’axe

opérationnel de l’activité. Définir les services qui pourront être proposés par le

domaine « Allocations - Bilans» à la MOA en fonction des besoins et de la capacité« à faire ».

• Identifier, typer et organiser les actions qui doivent être menées au sein du domaine

« Allocations - Bilans» du PCL pour assurer le MCO des applications en relation

avec la MOA, puis proposer l’organisation adéquate du domaine.

." ,4!

Le premier livrable est le résultat de l’analyse contractuelle des marchés existants. L’objectif est

de mettre en avant plusieurs scénarii possibles et d’identifier celui le plus en phase avec les

contraintes du PCL. Ainsi, le choix a été fait de lancer l’appel d’offre pour choisir le nouvel

intégrateur de TMA des applications du domaine « Allocations - Bilans» courant septembre .....





Imprimé le

Le deuxième livrable doit reprendre les éléments identifiés et les procédures à mettre en place

pour permettre à la MOE et à la MOA de communiquer efficacement et de disposer de moyens

clairement identifiés pour échanger.

Le troisième document reprendra, quant à lui, les actions à réaliser au sein du domaine pourchacun des objectifs identifiés dans le cadre du MCO ainsi que les moyens à mettre en œuvre

pour y parvenir.

.) 6'

S/O

.. !%,-''*

Action et dates clés

Le contrat de TMA Présentation des scénarii le 18/04 ; choix d’un scénario ;appel d’offre à lancer entre juin et septembre .....Préparation de l’appel d’offre avec la direction desAchats de GDF à partir de juin .....

Les relations MOA - MOE 5 Ateliers réalisés du 29 mai au 12 juillet avec la MOA de

GRTgaz.

L’organisation MOE 5 Interviews d’agents dont les activités sont en relationavec le MCO d’applications et la synthèse pour juin ....

. 8&!&%!*

Les technologies utilisées sont basiques et concernent uniquement les outils de la bureautique.

.( 8&!&%%*!#!*!,*

Ma mission, orientée organisation, communication, contractualisation, m’a permis de mettre en

avant directement les éléments de droit au programme du Master.

Même si les applications du domaine « Allocations - Bilans» du PCL utilisent des SGBD

(Système de Gestion de Base de Données) Oracle, le langage Java, des progiciels du marché, je

n’ai mis en œuvre aucune de ces technologies.

./ #&E+*!+6&&

J’ai eu accès à un environnement de travail standard : bureau, poste de travail informatique,

imprimantes partagées, connexion aux applications, accès aux outils de travail collaboratifs (la

messagerie Notes, les bases de données « Lotus Notes ») ainsi qu’aux INTRANETS de Gaz de

France et à INTERNET.





Imprimé le

.< !*+5'

J’ai prévu de fournir trois documents qui reprendront respectivement les analyses et synthèses

correspondantes, susceptibles d’être utilisées.





Imprimé le

" 001##

" 3&&,

La problématique du Maintien en Condition Opérationnelle d’applications peut se formaliser parles questions suivantes :

Que signifie « Maintien en Condition Opérationnelle d’une application » ?

Où se situe la phase de MCO d’une application dans le processus de gestion de projet ?

Comment situer le MCO dans le cadre des référentiels méthodologiques ? Quel serait le

mieux adapté ?

Quelles sont les instances d’entreprise, internes et externes, concernées par cette

problématique ?

Quels sont les processus à définir particulièrement? Que dire plus précisément de lacommunication entre ces instances?

Quelles sont les actions à réaliser et par qui ?

Toutes les applications sont-elles concernées par cette problématique ?

L’organisation de l’entreprise et de son instance informatique en particulier est-elle

importante?

" !*+&,

La description des processus liés au passage d’applications en MCO n’est, à ma connaissance,abordée dans son ensemble dans aucun des référentiels méthodologiques.

"" #&,&!&3

J’ai pu constater que ce sujet devait mettre « en musique » plusieurs processus et plusieurs

entités internes ou externes à l’entreprise et que, pour ces deux raisons, une orchestration subtile

était nécessaire.

") +&#!'&+58F7G!

Le service informatique de l’entreprise est devenu un centre de pilotage, et de ce fait, il lui est

devenu indispensable de maîtriser l’ensemble des processus mis en place ou à mettre en place et

de clairement les identifier notamment en termes d’acteurs, de rôles et de responsabilités.

Le CSI-PCL se doit de fournir un service de qualité à ses bénéficiaires. Son objectif est donc de

conserver la maîtrise des applications dont il a la charge en termes de niveau de réactivité, de

coûts et de qualité.

Lorsque les activités de MCO d’applications étaient assurées par les entités d’un service

informatique, ces 3 objectifs étaient déjà prépondérants. Maintenant qu’elles sont réalisées par

des entités externes, elles deviennent primordiales.





Imprimé le

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

pilotage de ces activités n’est pas garanti ?

Le CSI ne fait pas exception à la règle ; la mise en place de processus de MCO maîtrisés de ses

applications renforcera son apport vis à vis de ses bénéficiaires.

". !&!3+*+&!+&*!*

Je vais m’appuyer sur les études réalisées au cours de mon stage. Elles sont en complète

correspondance avec le sujet du mémoire notamment en ce qui concerne la mise en place, d’une

part des relations entre la MOA et le CSI et d’autre part, de l’organisation correspondante du CSI

pour répondre aux sollicitations de sa MOA. Je vais également tenir compte de mes expériences

passées pour présenter l’historique des organisations des DSI (Direction des Systèmes

d’Information).

"" &4!*+5#*36*

Dans les ouvrages publiés, on parle de gestion de services, de plan de continuité d’activités du

système d’information ou encore de guide pour « faire certifier son SI ». Ces approches donnent

une image qualité. Ces ouvrages sont peu diserts s’agissant de MCO.

") &!*

Cette étude s’appuie sur des actions attestées, analysées tout au long de ma mission et élargies à

un environnement standardisé.La finalité est de comprendre les étapes à mettre en œuvre, d’instaurer des modes de

fonctionnement entre les différentes instances, de pouvoir s’appuyer sur cette analyse et de

l’utiliser comme fil conducteur pour mettre en condition de MCO n’importe quelle application.

Deux applications du domaine « Allocations - Bilans» du PCL seront concernées d’ici la fin du

premier semestre, une troisième intègrera le processus dès la fin de l’année. Ainsi, ce guide

pourra être éprouvé.

De plus, ce modèle devrait pouvoir servir dans tous services informatiques dont l’activité

principale est le pilotage de projets et d’applications dans un contexte méthodologique etqualitatif.

". 5!''!

Dans une deuxième étape, il serait intéressant de proposer un outillage standard et des modèles

de documents pour :

• Recenser,

• Partager,

• Communiquer,

et ce quelle que soit l’étape en cours du processus de passage en MCO.





Imprimé le

0000

0

Aujourd’hui, les IT (Technologies de l’Information) sont au cœur de notre vie de tous les jours,

et plus encore de celui de l’entreprise. Elles permettent de répondre aux principes fondamentaux

de l’économie à savoir : exercer un métier, avoir des clients et disposer de ressources.

Et même si ce principe est inchangé depuis l’Antiquité, l’utilisation des IT, comme moyen pour

y parvenir, a fait évoluer le mode de fonctionnement de ces entreprises. Ainsi, un des points

essentiel et incontournable reste leur maîtrise. Par « Technologie », il faut comprendre ensemble

de techniques modernes complexes. Ainsi, l’interprétation de « maîtriser les IT » peut se faire

selon les trois propositions suivantes : soit posséder un savoir-faire IT, soit l’acquérir, soit piloterdes prestations spécialisées adéquates.

Mais revenons dans le monde de l’informatique d’une entreprise. Une des instances de cette

entreprise doit donc être spécialisée dans le métier qui consiste à maîtriser les IT. Ses clients sont

les autres entités de l’entreprise et elle utilise des ressources matérielles et humaines qui peuvent

être elles-mêmes des instances internes ou externes. Et c’est ici que tout se complique.

En effet, au début de l’ère informatique, ces instances étaient composées d’ingénieurs nommés

par les dirigeants de l’entreprise parce qu’ils étaient intéressés par les nouvelles technologies. Ils

ont ensuite été regroupés dans un service spécifique (on parlait alors de Service Informatique) et

ont commencé à automatiser efficacement un nombre significatif de tâches3.

Rapidement, les fonctions à automatiser ont augmenté de façon exponentielle, se sont

complexifiées et ont nécessité la mise en place d’organisations spécifiques puis ensuite de

méthodologies. C’est également au cours de cette période que les instances clientes ont été de

plus en plus exigeantes quant aux technologies de pointes utilisées, ce qui n’a pas été sans

conséquence sur la gestion financière, au sens rentabilité, de ces Services Informatiques.

Au fils des expériences acquises dans différentes sociétés et en confrontant mes expériences, j’ai

pu m’apercevoir que cette situation était somme toute banale et que chaque société, ayant une

structure informatique propre, aura à un moment ou à un autre le dilemme suivant à traiter :

privilégier soit l’offre de la meilleure qualité de service (le mieuxdisant) soit la rentabilité

financière (le moins-disant).

La littérature a abondamment traité des méthodes de gestion et de conduite de nouveaux projets

informatiques que ces méthodes soient généralistes4, ou orientées selon des domaines particuliers

3 IT Gouvernance- F.Georgel –page 14-«dans les années 60,…., les chefs d’entreprise comprennent alors que

l’informatique leur permet de remplacer efficacement le crayon et la règle à calcul .. »4 PMBOK « Corpus des connaissances en management de projet » de PMI (Project Management Institute)traduction française de la 3ème édition.





Imprimé le

comme le Décisionnel5, ou encore le WEB6. Il est intéressant de relever que la méthodologie à

suivre diffère, selon le domaine d’orientation, de la démarche projet en général. Par contre peu

d’ouvrages ont abordé une vision de maintenance opérationnelle ; ce dernier point étant sûrement

moins noble que le premier mais tout aussi difficile et délicat, si ce n’est plus. En fait, lamaintenance opérationnelle a été abordée dans le cycle de vie projet comme une étape de

transition dont nous ferons une analyse détaillée dans un des chapitres à venir. Est-ce pour autant que le sujet n’est pas problématique ? Est-il donc si facile d’assurer à ses

instances métiers la garantie que leurs outils IT ne les trahiront pas une fois qu’ils ne feront plus

l’objet d’une attention aussi particulière qu’en phase projet ? Comment d’ailleurs être certain que

les nouvelles ressources seront toutes aussi performantes ?

Pour tenter de répondre à ces questions, nous allons donc nous fixer comme objectifs :

• De définir les activités couvertes par le MCO et à quel moment il est opportun de lepréparer,

• D’étudier les instances tant internes qu’externes à l’entreprise et l’évolution de cette

dernière et de son SI,

• D’identifier les bonnes pratiques existantes dans le cadre du passage et du suivi de

MCO d’applications, et à contrario les risques s’il n’y en a pas,

• De proposer un ensemble de recommandations utiles pour mener à bien le passage

d’un projet en une application à maintenir en condition opérationnelle.

En gardant comme fil conducteur la mise en œuvre des moyens nécessaires et suffisants pourassurer le MCO des outils IT de l’entreprise nous allons donc :

• Donner un sens à l’acronyme « MCO » et identifier les compléments apportés par

rapport à la notion de « maintenance » communément utilisée,

• Tracer et décrire l’évolution de l’organisation des instances informatiques de

l’entreprise en s’attardant sur les problèmes induits et ce qu’il a fallu mettre en œuvre

pour y remédier,

• Ensuite analyser les différentes méthodologies tant en terme de gestion de projets que

de référentiels disponibles, le tout en s’attardant sur les motivations qui sont àl’origine de leur naissance,

• Et enfin, s’attacher à mettre en phase les organisations actuelles et les méthodologies

afin de rendre opérationnel et pragmatique le MCO de ces applications.

5 « Le data Warehouse, Guide de conduite de projet » De Ralph Kimball, Laura Reeves, Margy Ross et Warrren

Thornthwaite - Eyrolles, Mars 2005 6 Conduite de projet Web - Avec 3 études de cas De Stéphane Bordage, David Thévenon, Franklin Brousse etLaurence Dupaquier - Eyrolles Mai ....





Imprimé le

" #

" &&

Dans ce chapitre, nous allons nous attacher à définir les activités couvertes par la phase deMaintien en Condition Opérationnelle (MCO) versus celles de « Maintenance » plus

communément utilisée jusqu’au milieu des années 2000 dans les organisations IT et surtout,

largement explicitée dans tous les ouvrages ou référentiels.

L’objectif est de déterminer les similitudes ou éventuellement si l’une des activités est incluse

dans l’autre.

"" *'&

"" #

Le MCO est un ensemble d’actions à préparer en amont de toute mise en application

opérationnelle de matériel logiciel ou technique quel qu’il soit. Mais de quelles natures les

actions sont-elles induites ?

Communément la notion de MCO est utilisée pour la maintenance :

• Des navires de la Marine Nationale,

• Des avions,

• Des radars,

• …

Dans ce cadre, l’objectif du MCO est d’anticiper l’immobilisation de ces matériels pour garantir

un fonctionnement optimum en cours de mission. Les interventions concernent aussi bien des

changements de pièces essentielles dont l’usure est avérée ou de pièces endommagées sur

lesquelles il faut intervenir rapidement. Une maintenance mal programmée peut avoir des

conséquences dramatiques pour la sécurité des Hommes. Le maître mot est bien ici

« anticipation » car les conditions à mettre en œuvre pour assurer la maintenance technique d’un

navire ou d’un avion ne sont pas non plus sans conséquences financières. Deux exemples pourillustrer ces propos : un bateau, pour certaines interventions doit être en cale sèche, de même un

avion doit, bien évidemment, avoir atterri.

L’analogie des applications IT complexes et leur caractère primordial pour l’entreprise, font que

les instances informatique ont également adopté ce mode de fonctionnement pour gérer le MCO

de leur IT. En fait, l’arrêt de l’exploitation est assimilé à l’immobilisation des matériels. La

maintenance des infrastructures, la prise en compte de nouvelles versions sont quant à ellesassimilées à des changements de pièces essentielles.





Imprimé le

L’anticipation, la planification de toutes ces actions sont, dans certain cas, toutes aussi

importantes pour la société que la maintenance de la flotte nationale.

Ainsi, par « Maintien en condition opérationnelle » il faut entendre « conserver l’application en

bon état de fonctionnement » par rapport au service attendu par ses utilisateurs.

""" #

Le dictionnaire donne la définition suivante du mot « maintenance » :

• « fait de conserver un matériel technique ou industriel en état de fonctionner »,

• « ensemble d’opérations d'entretien d'un équipement ».

"") #H#

Nous pouvons donc établir que, d’un point de vue sémantique, « Maintenance » et « MCO »

sont des synonymes. Par contre, l’expression « MCO » sous entend « anticiper les actions de

maintenance autres que correctives»; elles sont donc à fortiori incluses dans le MCO.

L’évolution de « Maintenance » en « MCO » est apparue lorsque le socle du nombre

d’applications à maintenir a commencé à augmenter de façon significative. Les DSI, après l’ère

du développement, ont du faire face à la maintenance d’applications souvent développées dans

des technologies très hétérogènes et ont décidé de mettre en place un processus en

correspondance avec les difficultés de chaque situation.

Ces difficultés viennent essentiellement du volume et du cycle de vie des applications àmaintenir, du type de maintenance à réaliser et des compétences technologiques à contrôler.

Ainsi, le processus MCO va permettre de décrire précisément les actes qui sont pris en charge.

De même, il va être possible de fournir des outils aussi bien pour typer le niveau de difficulté de

l’intervention que pour préciser le délai de cette intervention, mesurer les écarts et donc produire

un niveau de service. Les SSII (Sociétés de Services en Ingénierie Informatique) ont su d’ailleurs

adapter leurs offres de services aux besoins de leurs clients et ont du être à l’origine de

l’adaptation du terme « Maintenance » en « Maintien en Condition opérationnelle » des SI. En

effet, leur force se situe dans l’hétérogénéité des compétences de leur personnel et des moyens

qu’elles mobilisent pour trouver ces compétences le cas échéant. Rappelons que leur cœur demétier est la maîtrise des IT.

") &43'#

Les objectifs du MCO sont de maintenir efficacement les applications pour qu’elles fournissent

le service attendu par les clients, de préparer et de faire évoluer les applications pour préparer

l’avenir, le tout en maîtrisant les coûts, la réactivité et la qualité d’exécution et du résultat.

Les activités prioritaires couvertes pour le MCO sont de natures différentes.

Elles concernent les actions dont l’objectif est de fiabiliser l’application et d’améliorer lesperformances. Ce volet inclut en général les modifications nécessaires pour assurer les montées





Imprimé le

de version sur les composants du SI utilisés par l’application. On parle alors de maintenance

corrective et préventive.

Elles concernent aussi les évolutions fonctionnelles qui proviennent soit des demandes de la

maîtrise d’ouvrage soit des évolutions réglementaires. Ici, c’est plutôt de maintenance évolutiveet adaptative qu’il s’agit.

Elles concernent encore la gestion des moyens opérationnels avec lesquels et sur lesquels les

actions de MCO sont exécutées.

Elles concernent enfin l’assistance utilisateur, qui est, globalement une assistance à plusieurs

niveaux d’escalade de 0 (prise d’appel) à 3 (analyse technique à réaliser). Ici c’est le niveau 3 qui

est en général pris en charge.

Le niveau de satisfaction du client va permettre, quant à lui, de valoriser le MCO. Il se mesure entenant compte de points névralgiques comme :

• Une utilisation régulière de l’application sans anicroche,

• Une gestion des incidents rapide et efficace,

• Une communication anticipée en cas d’interruption prévisible de l’application,

• Une prise en compte efficace des demandes d’évolution,

• Des propositions d’évolutions préventives, adaptatives, judicieuses et pertinentes.

". &!&

Si l’activité « traditionnelle » de maintenance de tout ou partie d’un SI peut être comparée à un« carnet d’entretien » d’une voiture (planification prévisionnelle d’opérations d’entretien), le

MCO serait plutôt de l’ordre du « contrat d’entretien » du véhicule. La différence est que dès

l’achat du véhicule (dans notre cas l’application) son propriétaire (dans notre cas l’utilisateur

final) prévoit un investissement planifié et contractualisé pour son « Maintien en Condition

Opérationnelle ».

Cet investissement toujours difficile à concevoir ou à consentir en phase projet (c’est clairement

un surcoût qui grève le ROI7) a l’avantage d’éviter toute surprise ultérieure et d’impliquer tous

les acteurs en amont. Le MCO est donc une démarche consciente d’anticipation qui englobe lamaintenance.

7 Return Of Investment





Imprimé le

) 70

) &&

Dans ce chapitre, nous allons présenter les différentes évolutions qu’ont subies les Services IT etles différents acteurs qui y ont contribués. L’objectif est de comprendre l’organisation actuelle,

les relations qui existent entre les acteurs qui contribuent à la création et à la maintenance d’un

ouvrage,8 comment, pourquoi cette situation est devenue inéluctable et quels ont été les impacts

des mutations successives.

Dans un premier temps nous allons analyser les différentes politiques de gestion appliquées au

sein de ces sociétés en regard de leurs instances informatique. Puis nous allons examiner les

transformations supportées par ces Services IT selon trois grandes périodes consécutives aux

différentes politiques de gestion successives : celle de l’implantation, celle du développement etcelle de la maturité.

Dans un deuxième temps, nous allons explorer chacune de ces périodes et essayer de comprendre

les faits qui nous ont amenés logiquement à la situation actuelle.

)" &+&,

Un SI regroupe trois composants prépondérants :

• L’infrastructure est un ensemble d’installations et d’individus nécessaires au

fonctionnement de l’instance IT,

• Les applicatifs sont des processus industrialisés par des outils IT utilisés par la société,

• Les services, ici le terme « service » désigne toujours un service offert par une

organisation à ses clients. Un service est indissociable de son utilisation. Selon la

commission de Normalisation de l’AFNOR, un service est « une prestation

immatérielle composable, manifestée de manière prédéfinie, et une source de valeur

pour le consommateur et le fournisseur ». Ainsi, en pratique la notion de service

apparaît lorsque la gestion du SI passe de centre de coûts à centre de profits, avec un

équilibre entre « qu’est ce que j’ai à vendre ? » et « qu’est-ce que le client est prêt à

acheter ?9 ».)) !63&8

Les activités IT ont démarré au début des années 60. Trois grandes étapes se détachent, chacune

d’entre elles ayant une durée d’environ vingt ans. Chaque période correspond à une approche

différente d’un point de vue économique. Elles se répartissent comme suit : l’ère de

l’implantation, l’ère du développement et l’ère de la maturité.

8 Dans la suite du document, « ouvrage », « produit », « application » sont des synonymes et représentent le résultatd’un projet en exploitation.9 ITIL et la gestion des services-page 6





Imprimé le

Selon l’ère considérée et les préoccupations du moment, la hiérarchie des composants IT est

différente :

Evolution de l’approche des systèmes informatiques10

Pour commencer, les années 60 à 80 correspondent à l’avènement de l’informatique avec une

approche fondée sur l’accroissement de la productivité. Les dirigeants des grandes entreprises y

sont très sensibles et il faudrait être aveugle pour ne pas anticiper les bénéfices qu’il va être

possible d’obtenir grâce à l’informatisation : moins d’individus pour plus de productivité.

Les deux étapes suivantes sont celles de la finance et puisque toutes les sociétés se sont lancées

dans l’informatique, l’objectif n’est plus d’automatiser les processus à n’importe quel prix mais

bien de rentabiliser les coûts de fonctionnement de ces processus. L’informatique devient un

outil de productivité parmi les autres et n’est plus soumis à des traitements de faveur. Donc

comme tous les processus, celui lié à l’Infrastructure voit son budget se réduire en faveur de

celui lié aux Services à fournir. Pour rappel, ces coûts sont devenus prohibitifs suite à des

demandes de plus en plus complexes d’utilisateurs, voir des dirigeants de l’entreprise.

Pendant la deuxième période, le composant « Applicatif » est apparu clairement comme

prioritaire pour les sociétés parce qu’il y avait beaucoup de processus à automatiser. En phase dematurité, ce composant se positionne à nouveau au second plan derrière cette fois-ci les

« Services ». En effet, les instances dirigeantes d’une société s’attachent prioritairement à une

qualité de service irréprochable; étant acquis que les applicatifs et l’infrastructure ne posent plus

de problèmes : les technologies sont éprouvées et les logiciels doivent l’être aussi.

10 IT Gouvernance- F.Georgel –page 46





Imprimé le

). %*

). :!+!&

L’ère de l’implantation correspond donc à l’âge d’or de l’informatique. En effet, c’est à cetteépoque que certains ingénieurs de l’entreprise sont désignés par les dirigeants pour mettre en

place les infrastructures informatiques. Rappelons que leur objectif est d’automatiser les activités

qui s’y prêtent pour augmenter la productivité.

Ainsi naît le service informatique, instance dans un premier temps, complètement intégrée à

l’entreprise. Ses missions sont de mettre en place un ensemble d'éléments structuraux

interconnectés qui fournissent le cadre pour supporter la totalité de l’environnement de

développements applicatifs. Ces ingénieurs au début, se suffisent à eux-mêmes et s’organisent

autour de spécialités : infrastructures (système, exploitation, production, etc.), applicatifs

(analyse, développement), services (gère les incidents).

). :*,!&+

De Service Informatique, cette instance évolue rapidement vers une Direction informatique,

d’abord DI (Direction informatique) pour devenir ensuite DSI (Direction des Systèmes

d’Information) où l’on gère en plus des techniques informatiques, le système d’information de

l’entreprise. Au cours de cette période, les «Etudes et Développement » sont très consommateursde personnes. La maintenance des applications est bien souvent réalisée par les équipes projet.

Ainsi, les actions correctives sont prioritaires devant les actions projet, par contre la maintenance

évolutive est planifiée selon le bon vouloir des programmeurs.

Pour appuyer ces propos, faisons un premier zoom sur la S.E.I.T.A.11, qui au début des années 80

disposait d’un Service Informatique d’une soixantaine de personnes, déjà très organisé avec des

processus techniques bien implantés. Elle disposait d’un service « Etudes et Développement » en

charge de la réalisation de projets qui représentait environ la moitié des effectifs affectés, les

autres services ayant la responsabilité de l’exploitation proprement dite des applications. En fait

le nombre de personnes dédiées à la maintenance était en adéquation avec le nombre de chaînes

applicatives à savoir environ quatre (l’approvisionnement, la fabrication, la facturation des

débitants de tabacs, et la paye). Les évolutions correctives (techniques ou fonctionnelles) étaient

assurées respectivement par chaque responsable de la maintenance.

En deuxième exemple, regardons le Service Informatique des Messageries du Livres12, composé

d’une quinzaine de personnes réparties comme suit : un expert « Système », une personne et

11 Société d’exploitation industrielle des tabacs et des Allumettes –devenu Altadis après la fusion en 1999 de la

SEITA et Tabacalera et qui a été racheté en 01/.... par TABACCO.12 MDL, (devenu INTERFORUM en 1993) est la société de distribution du Groupes de la Cité qui regroupe lesEditions R.Lafont, Julliard, Presses de la Cité, Larousse, Bordas pour les principaux





Imprimé le

demi dédiée à la maintenance des applications et neuf personnes impliquées directement sur le

projet de refonte du système existant. Cette configuration montre bien l’importance donnée aux

projets par rapport au suivi de l’exploitation quotidienne des applications. Une deuxième

interprétation est d’avancer le fait que l’absence de dysfonctionnement implique qu’il n’est pasutile de prévoir plus de ressources ; pourquoi alors vouloir changer ces applications ? Une

troisième hypothèse est également à envisager. En effet, l’ère du développement signifie qu’il y

a beaucoup de nouveaux projets à réaliser d’où l’importance des « équipes projet » en opposition

avec les équipes de maintenance qui n’avaient que très peu d’applications à maintenir.

Pour finir, regardons une troisième entreprise, la holding, REXEL13, dont la DSI a eu pour

objectif, début des années 1990, de piloter la réalisation d’un système commercial commun à

toutes ses sociétés. Dans cette DSI, cohabitaient trois entités, le pôle « Etudes et

Développement » classique, le pôle « Technique » et le pôle « Pilotage fonctionnel » ce dernierayant pour rôle de synthétiser les bonnes pratiques et les spécificités de chaque société. Là

encore, le pôle « maintenance des applications » n’existe pas. Cette maintenance est laissée à la

charge de chaque société régionale avec l’objectif de ne réaliser que les actions correctives. Fin

des années 90, il a quand même été nécessaire de s’assurer que le passage à l’an 2000 ne poserait

pas de problèmes…

!"#$

Dans le même temps, le nombre de nouvelles technologies a explosé, et leur maîtrise a nécessité

des compétences et des moyens de plus en plus spécialisés. La DSI est devenue une entreprisedans l’entreprise. Elle est aux commandes d’une infrastructure de plus en plus complexe et

nécessite un nombre croissant de compétences donc de collaborateurs.

Dans la continuité de cette démarche, les coûts d’une DSI n’ont cessé de croître que ce soit tant

du niveau ressources humaines (si l’on tient compte de la diversité des nouveaux métiers), que

du niveau des matériels si l’on considère les nouvelles technologies. Cette instance devient alors

le centre de toutes les critiques en regard des bénéfices engloutis par ses divers systèmes.

! #%%

Même si les SSII ont fait leur apparition au milieu de l’ère de l’implantation, elles ont vraiment

pris leur ampleur au cours de l’ère de développement (CapGemini a été fondée en 67 mais s’est

fortement implantée à partir des années 9014).

Ces sociétés de prestations informatique répondent aux principes fondamentaux de l’économie à

savoir : exercer un métier (maîtriser les IT), avoir des clients (les autres entreprises) et disposer

13 Holding, distributeur de matériel électrique composé d’une dizaine de sociétés telle qu’ADELEC (en région

parisienne), ISNARD (en région grenobloise), LIENARD (région centre), FACEN (région Nord) pour lesprincipales14 Histoire de CapGemini : http://www.fr.capgemini.com/about/histoire/





Imprimé le

de ressources humaines qui correspondent à leur cœur de métier (des experts en IT). Concernant

les ressources matérielles, en général, elles utilisent celles de leurs clients.

Ainsi les sociétés de prestations se déclinent en trois grandes catégories avec lesquelles les DSI

doivent composer.

Relation du complexe techno-informatique avec l’entreprise15

Ces SSII se sont introduites au niveau des directions opérationnelles de l’entreprise, en tant que

société de conseil et de services informatiques et vont profiter de leur situation pour renforcer le

sentiment que l’informatique soit une activité à part, complexe et coûteuse.

Au vu de ce nouveau contexte, beaucoup d’entreprises ont décidé de se recentrer elles aussi sur

leur de cœur de métier et par la même de sous traiter la gestion de leur IT à ces SSII. La

migration des experts IT de l’entreprise vers les SSII ne s’est pas réalisée de façon si radicale. Ila fallu plusieurs étapes, étalées sur plusieurs années selon la société et qui n’ont pas débuté au

même moment. En général, cette mutation s’est déroulée dans la douleur. On parle alors

d’externalisation dans le sens confier une tâche, un service, à une entreprise extérieure.

Pour autant, gérer leur SI, ne veut pas dire le conduire et c’est pourquoi toutes les instances des

DSI n’ont pas été externalisées. Il reste les pilotes projet qui, en plus de leurs connaissances

informatiques, ont pour mission de comprendre le métier de leur entreprise, de communiquer

avec les services qui l’exercent pour leur fournir les meilleurs outils.

15 IT Gouvernance- F.Georgel –page 48





Imprimé le

)." :!+*

Le Service Informatique de l’entreprise est donc devenu un centre de pilotage, et de ce fait, il est

devenu indispensable de maîtriser l’ensemble des processus mis en place ou à mettre en place et

de clairement les identifier notamment en termes d’acteurs, de rôles et de responsabilités.

Le fait que l’outil informatique soit perçu comme un moyen d’optimiser l’activité de l’entreprise,

implique qu’il soit gouverné au niveau des instances managériales de l’entreprise.

Nous aborderons ce point précisément dans le chapitre « Les cadres théoriques pertinents » qui

reprend notamment les principaux référentiels publiés par les organismes de normalisation.

La DSI doit conserver la maîtrise des applications dont elle a la charge en termes de niveau de

réactivité, de coûts et de qualité, rendre compte de son activité et de ses dépenses à son instance

de gouvernance et fournir des indicateurs pour lui permettre de suivre l’adéquation entre les

coûts et les activités réalisées. Le socle des applications en exploitation est significatif, il

nécessite la mise en place d’une structure organisée de MCO qui doit gérer l’exploitation

quotidienne, mais aussi les évolutions court, moyen et long terme, à réaliser.

Le système d’information doit se stabiliser. Ne sont réécrits, repensés que les processus qui en

valent la peine, qui auront une forte valeur ajoutée en terme financier. Avoir une bonne idée,

n’est plus suffisant, il faut prouver qu’elle est rentable en calculant un retour sur investissement,

le fameux ROI, fait qui nous est régulièrement rappelé. Attention, même s’il est moins onéreux

d’adapter une application en exploitation, le coût n’est quand même pas neutre. Il est souvent

plus difficile d’estimer le coût de maintenance d’une application que le coût d’un projet. Lesquestions à se poser concernent le plus souvent la taille de l’équipe à mettre en place. Combien

de personnes faut-il prévoir pour assurer une maintenance efficace et sans risque ? Et oui, voilà

encore un mot qui fâche : « Risque ». Modifier une application qui est utilisée par un certain

nombre de personnes et qui doit fournir un résultat périodique, n’est sûrement pas sans risque.

Ce dernier est à mesurer et à anticiper, et là encore la SSII va pouvoir tirer son épingle du jeu.

Elle va proposer des prestations de Tierce Maintenance Applicative (TMA) pour libérer les DSI

de ce problème. Il est en effet plus aisé pour une SSII d’adapter sa taille en fonction des contrats

qu’elle va signer : de développement, de MCO.Regardons, comme dernier exemple, la société Carrefour au milieu des années 2000.

L’organisation suivante a été mise en place :

• Une « Direction des Centres de Compétences et des Systèmes Métiers »,

• Une « Direction Projets (DP)»,

• Une «Direction de l’Architecture, Urbanisme et Développements technologiques»,

• Une « Direction des Services Opérationnels (DSO)».

La «Direction Développement et Maintenance Applicative (DDMA) » a disparu à cette période.En effet, pour réduire les coûts de fonctionnement du service, les activités (et les personnes) de





Imprimé le

la DDMA ont été cédées à une SSII. Le lien entre la société et la SSII s’est fait au travers de la

DSO. C’est également à cette époque qu’une Direction projet a vu le jour, étant entendu que les

projets sont réalisés également par des SSII. Au final, la maintenance est assurée par une TMA.

L’objectif a bien été de pouvoir budgétiser précisément la charge financière du MCO de son parcapplicatif de la même façon que les projets sont soumis à des appels d’offres.

Donc, lorsque les activités de maintenance étaient assurées par les entités du Service

Informatique, le triptyque coût, réactivité, qualité était déjà prépondérant. Maintenant qu’elles

sont réalisées par des entités externes, elles deviennent primordiales.

En effet, comment les Services Informatique pourraient-ils justifier leur existence si le pilotage

de ces activités n’est pas garanti ?

La mise en place des processus maîtrisés de MCO de ses applications, doit garantir sa pérennité

vis à vis de ses instances clientes.L’accent est donc mis sur la maîtrise des processus de MCO. En effet, la gestion des projets a été

au centre des préoccupations pendant l’ère du développement et a donc déjà été soumise à la

mise en place de processus maintenant éprouvés.

) -**&*

La MOE (Maîtrise d’œuvre) et la MOA (Maîtrise d’Ouvrage), entités très présentes dans le

monde du bâtiment, se sont imposées au cours des années 90, au milieu de l’ère du

développement. Elles se sont partagées les rôles dans le cadre de la maîtrise des systèmes

d’information.

Plusieurs études ont été menées que ce soit par l’AFAI16, ou par des consultants expérimentés17.

) >+$&,%?

& '$()

Le « maître d’ouvrage » est l’entité porteuse du besoin (entreprise, direction, service) cliente de

l’informatique qui sera le propriétaire de l’ouvrage. Par abus de langage, on appelle « maîtresd’ouvrage » les personnes physiques qui, dans cette entité cliente, ont compétence pour définir le

système d’information que le Service Informatique construit, maintient et exploit. En fait, il

définit l’objectif du projet, son calendrier et il fixe l’enveloppe budgétaire. Le résultat attendu du

projet est la réalisation d‘un produit, appelé l’ouvrage.

16 Etude AFAI (Association Française de l'Audit et du Conseil Informatiques) « Maîtrise d’ouvrage » de projet desystème d’information17 http://www.volle.com/travaux/moa_du_si.htm





Imprimé le

& *+)

Le rôle du « maître d’ouvrage » est de spécifier les besoins, de prendre les décisions essentielles,

et en particulier celles nécessaires à la définition du budget du système d'information. Il maîtrise

donc l’idée de base du projet (ou de ses évolutions), et représente à ce titre les utilisateurs finaux

à qui l’ouvrage est destiné. Il doit également réceptionner l’application, s’assurer que son

fonctionnement est en rapport avec les besoins exprimés et que tout est prêt pour une

exploitation optimale de l’application. Par contre, il n’a pas forcément les compétences

techniques liées à sa réalisation.

Selon l’importance de l’entité cliente, les responsabilités de la MOA peuvent être partagées.

Ainsi, le MOA-D « maître d’ouvrage délégué » remplit une fonction d’expertise par délégation

du directeur de l'entité, le MOA-S « maître d’ouvrage stratégique », qu'il assiste dans la

préparation des décisions relatives au SI. Le maître d'ouvrage délégué a une mission decoordination entre des MOA-O « maîtres d’ouvrage opérationnels » responsables chacun d'un

des domaines du métier. Chacune des MOA-O dialogue avec son homologue, ou une personne

déléguée, du MOE « maître d’œuvre ».

&! )

Avant 1990 l’informatique avait déjà pour clients les « métiers » de l’entreprise, mais les

spécifications fonctionnelles étaient souvent définies par les informaticiens eux-mêmes à partir

d’expressions de besoin sommaires dont la description tenait quelque fois sur un post’it. Avecl’évolution et l’enrichissement du rôle de l’informatique, les spécifications fonctionnelles sont

devenues l’expression formelle complète du métier lui-même ; elles ne peuvent donc être

établies que par des personnes qui travaillent dans le métier tout en étant capables de définir un

SI et d’aider les dirigeants à tirer parti des potentialités de l’informatique.

Ainsi s’est construite dans l’entreprise une compétence nouvelle, la maîtrise d’ouvrage du SI.

Elle est souvent un débouché pour les informaticiens qui aiment à travailler au plus près des

métiers.

& %%)

De fait, les dirigeants des entités clientes nomment des responsables à la tête de la MOA qui ont

un profil métier. Ils connaissent très bien les besoins des utilisateurs pour avoir été l’un d’entre

eux quelques années mais n’ont pas forcément la formation ni les outils qui leurs permettent de

gérer un projet informatique.

Ainsi, lorsque le maître d’ouvrage ne possède pas l’expérience métier nécessaire au pilotage du

projet, ou tout simplement quand il a besoin de renforcer ponctuellement ses équipes, il peut

faire appel à une assistance (AMOA). Cette AMOA est chargée de faire l’interface entre la MOE

et la MOA.





Imprimé le

Ici encore, les SSII se sont infiltrées au niveau des entités décisionnaires. Des services

d'assistance à maîtrise d'ouvrage sont commercialisés par certaines SSII et fournissent aux

entreprises les compétences nécessaires qu'elles ne possèdent pas.

Les relations sont rythmées par divers comités périodiques dont le nom varie selon les sociétés.Cependant leurs objectifs sont identiques à savoir :

• Un comité stratégique des systèmes d'information qui réunit les MOA-S et les MOA-

D pour prendre les décisions essentielles, et en particulier pour définir le budget du

système d'information,

• Une coordination des maîtrises d'ouvrage qui assure l'animation des MOA-D en

termes de méthode, de veille, et qui s’assure de la qualité des relations avec

l'informatique.

)" >+$I,?

& '$(,

Le maître d'œuvre (ou maîtrise d'œuvre, notée MOE) est l'entité retenue par le maître d'ouvrage

pour réaliser l'ouvrage, dans les conditions de délais, de qualité et de coût fixés par ce dernier

conformément à un contrat.

& *+,

Le rôle du « maître d’œuvre » est d’organiser la réalisation. Il coordonne la réalisation, contrôleles résultats et met tout en œuvre pour une exploitation optimale. Les connaissances du MOE

sont très vastes et à ce titre reposent bien sur une entité et non une personne. La maîtrise d'œuvre

est donc responsable des choix techniques inhérents à la réalisation de l'ouvrage conformément

aux exigences de la maîtrise d'ouvrage. Le maître d'œuvre a ainsi la responsabilité dans le cadre

de sa mission de désigner une personne physique chargée du bon déroulement du projet (on parle

généralement de maîtrise du projet), il s'agit du chef de projet.

Force est de constater qu’on aborde ce sujet d’un point de vue projet mais qu’en est-il du MCO ?

&! %%,

Là encore, les chefs de projet MOE peuvent également encadrer et, ou coordonner des

interventions de fournisseurs extérieurs (ici les SSII peuvent être à nouveau présentes). En effet,

pour la réalisation de certaines tâches du projet, lorsqu'il ne possède pas en interne les ressources

nécessaires, le maître d'œuvre peut faire appel à une ou plusieurs entreprises externes, on parle

alors de sous-traitance (et chaque entreprise est appelée sous-traitant ou prestataire). Chaque

sous-traitant réalise un sous-ensemble du projet directement avec le maître d'œuvre mais n'a

aucune responsabilité directe avec la maîtrise d'ouvrage, même si celle-ci a un " droit de regard "

sur sa façon de travailler.





Imprimé le

)) &C!##

La distinction entre maître d'ouvrage et maître d'œuvre est essentielle dans le déroulement du

projet, car elle permet de distinguer les responsabilités des deux entités. Il convient ainsi de

s'assurer que la définition des besoins reste sous l'entière responsabilité de la maîtrise d'ouvrage.En effet, il arrive dans certains cas que la maîtrise d'ouvrage délègue à la maîtrise d'œuvre des

choix d'ordre fonctionnel sous prétexte d'une insuffisance de connaissances techniques (de façon

concrète le service informatique d'une organisation prend la main et pilote le projet dès la phase

d'expression des besoins). Or seul le maître d'ouvrage est en mesure de connaître le besoin de ses

utilisateurs. Une mauvaise connaissance des rôles des deux entités risque ainsi de conduire à des

conflits dans lesquels chacun rejette la faute sur l'autre.

D'autre part, s'il est vrai que le maître d'œuvre doit prendre en compte les exigences initiales du

maître d'ouvrage, il n'est, par contre, pas habilité à ajouter de nouvelles fonctionnalités au cours

du projet même si cela lui semble opportun. Le maître d'œuvre est cependant chargé des choixtechniques pour peu que ceux-ci répondent fonctionnellement aux exigences de la maîtrise

d'ouvrage.

Enfin il arrive qu'une maîtrise d'ouvrage estime qu'un produit existant soit susceptible de

répondre à ses besoins, l'achète, puis se retourne vers la maîtrise d'œuvre (le service informatique

par exemple) pour effectuer des adaptations du produit.

La distinction entre maîtrise d'œuvre et maîtrise d'ouvrage est encore plus difficile lorsque les

deux entités font partie de la même structure d'entreprise. Dans de pareils cas, il est d'autant plus

essentiel de bien définir contractuellement les rôles respectifs des deux entités.

). &++&##

Pour le bon déroulement du projet, il est nécessaire de définir clairement les rôles de chaque

entité et d'identifier respectivement un représentant au sein de la maîtrise d'ouvrage et de la

maîtrise d'œuvre. Un groupe projet associant tous les acteurs de la MOA et de la MOE doivent se

réunir lorsque cela est nécessaire pour résoudre les conflits liés aux exigences de la maîtrise

d'ouvrage ou à la coordination du projet.

Enfin, il est essentiel d'établir un plan de formation permettant à la maîtrise d'œuvre et à la

maîtrise d'ouvrage d'avoir un langage commun et de s'entendre sur une méthode de conduite de

projet, de conduite d'entretiens ou de réunions, etc. 18

) !&#B#J-,&+!*+

18 Une formation de ce type a été mise en place en .... par la DSI générale de Gaz de France pour favoriser cedialogue





Imprimé le

Les relations MOA-MOE vue par Michel Volle

Les relations MOA-MOE 19

Certains disent que la distinction entre maîtrise d’ouvrage et maîtrise d’œuvre est « franco-française ». Elle existe pourtant dans les pays anglo-saxons même si le vocabulaire y est

différent. Aux États-Unis les maîtres d’ouvrage délégués sont nommés « business

technologists » : c’est une spécialité à laquelle forment les universités.

)( *,&!&!:!+*

L’organisation de l’entreprise a dû évoluer pour faire une place à la maîtrise d’ouvrage, le rôle de

l’informatique a dû changer. Cela ne pouvait pas être facile. Il y a eu bien naturellement au début

des incompréhensions et des polémiques. Puis les choses ont évolué. Dans la plupart des grandes

entreprises, il n’est plus nécessaire aujourd’hui de se battre pour faire admettre la nécessité de lamaîtrise d’ouvrage et l’époque des polémiques avec l’informatique est révolue. Il est désormais

admis que le SI dépend de deux professions qui doivent coopérer : le maître d’ouvrage définit les

fonctionnalités du SI et surveille sa bonne utilisation ; l’informaticien est maître d’œuvre des

solutions techniques, architectures et plates formes.

Certes, il est délicat d’organiser une telle bipolarité mais il en existe d’autres dans

l’entreprise (que l’on pense aux relations entre « commerciaux » et « producteurs »). Le secret du

succès réside dans le respect mutuel entre les deux spécialités, respect qui n’interdira pas la

vigueur dans la négociation.La première priorité est donc de renforcer la qualité de la maîtrise d’ouvrage : le risque d’échec -

ou de surcoût - est élevé si celle-ci ne sait pas définir ses priorités pour rechercher la sobriété, ou

encore si elle tente de régler des problèmes politiques à travers le SI.

La demande des utilisateurs doit être classée selon un ordre de priorité et il faut la soumettre à

une sélection sévère. Un SI sobre est intelligent et évolutif.

19 Document intitulé « Maîtrise d’ouvrage / Maîtrise d’œuvre » issu de Comment ça marche(www.commentcamarche.net) disponible sous la licence Creative Commons





Imprimé le

Par ailleurs l’informatique passe par une phase de diversification en spécialités « pointues »

analogue à celle qu’a connue la médecine voici quelques décennies. Aucune entreprise ne peut

rentabiliser en interne toutes les compétences nécessaires à son SI, qu’il s’agisse du

développement, de l’architecture, de l’Internet ou de la sécurité. Chaque direction informatiquedoit donc définir les spécialités que l’entreprise maîtrisera en interne et celles qu’elle devra

demander à des prestataires extérieurs. En outre il faudra qu’elle soit devant ces prestataires un

client compétent et non un simple gestionnaire de contrats.

)/ +$&;

Comme le SI équipe tous les métiers de l’entreprise, il est normal que celle-ci lui consacre un

certain effort. Mais des progrès restent à faire pour maîtriser les dépenses. Dans certains cas les

entités dirigeantes sont bousculées par des phénomènes de mode au détriment des maturations

nécessaires (après avoir longtemps freiné l’utilisation de l’Internet, elles se sont au début 2000ruées vers l’e-business).

Le coût du SI comporte non seulement les dépenses informatiques, mais aussi celles de la

maîtrise d’ouvrage qui sont moins bien connues : temps interne et assistance consacrés aux

recueils d’expertise, spécifications, validations, recettes ; au déploiement, à l’organisation, la

formation des utilisateurs, l’animation, l’administration des processus etc. Si l’attention se

focalise sur les projets, épisodes héroïques, on examine de moins près les coûts de maintenance

et d’exploitation qu’ils induiront ; le coût de détention de l’application.

L’entreprise doit connaître le coût de son SI pour décider en connaissance de cause. A partir decette connaissance lucide, elle pourra appliquer des règles simples : réaliser par palier, sous une

stricte contrainte de budget et de délai, cela aide à obtenir un SI sobre. Il faut aussi savoir tirer

parti des nouvelles technologies : on aurait tort de dépenser des millions d’Euros de travaux sur

système classique qui ne coûtent que quelques dizaines de milliers d’Euros avec l’Intranet.

Enfin, s’il est difficile d’évaluer la rentabilité du SI, c’est parce qu’il est devenu impossible

d’imaginer une entreprise sans SI : elle disparaîtrait ! Le SI, même s’il a un coût, est rentable. Par

contre, rien n’empêche de chercher toutes nouvelles idées de fonctionnement ou d’organisations

qui permettraient d’augmenter sa rentabilité.

)< &!&

L’analyse de la société (entreprise) et de son Service Informatique en particulier, au vu des

mutations dont il a été l’objet (passage de l’ère de l’implantation à celui de la maturité), et des

acteurs (internes ou externes) qui interviennent dans la construction d’un ouvrage ou du MCO

d’une application, avait pour dessein de mettre en avant la nécessité de faire partager le pilotage

entre deux entités la MOA et la MOE et le rôle non négligeable des SSII.

Par ailleurs, il est apparu clairement que la diversité des IT implantées dans tous les services de

l’entreprise, impose la coopération entre MOA, MOE et SSII, comme une solution





Imprimé le

incontournable. L’objectif est donc bien de gérer au mieux les projets ou les produits livrés

(MCO d’applications) et de laisser prendre la responsabilité inhérente à chacune des instances.

Par contre, la définition de l’organisation de l’entreprise et des acteurs associés n’est pas

suffisante. En effet, il est important d’analyser également le cadre méthodologique dans lequelces acteurs vont évoluer et quels seront les outils ou référentiels sur lesquels ils pourront

s’appuyer.





Imprimé le

. =0

. &&

Nous venons de poser le cadre du problème induit par la réalisation d’un projet, la réception de

l’ouvrage (application) correspondant et son suivi en MCO dans un contexte où l’entreprise doit

mettre en place des moyens pour que l’ensemble des acteurs de l’entreprise (MOA-MOE)

contribue efficacement au fonctionnement de son IT.

La démarche que nous allons suivre, dans ce chapitre, consiste à :

• Répertorier dans les cadres théoriques pertinents, les méthodes, pratiques et outils de

référence susceptibles d’apporter des éléments de réponse à notre problématique,

• Identifier, parmi ces cadres, les bonnes pratiques qui seraient transposables au suivi et

à l’évolution de nos applications,

• Proposer une démarche de mise en œuvre indépendante de l’organisation de

l’entreprise.

La finalité de cette étape serait de disposer d’une liste de préconisations à suivre et d’une « check

list » d’actions à réaliser et utilisable par la personne qui aurait la charge d’assurer le passage en

MCO d’une application.

L’objectif est donc de regarder les différents cadres théoriques et de s’assurer que toutes les

étapes nécessaires à garantir le MCO d’un ouvrage, de sa réception à son exploitation, peuvent

être couvertes.

Ces référentiels doivent permettre, à la MOA de piloter ses applications, mais aussi à la MOE de

préparer la gestion des applications lorsqu’elles seront en exploitation.

Bien évidemment, avant de répondre au problème de MCO, une application est passée par toutes

les étapes projets. Et si le fait de mener un projet dans les règles de l’art suffisait à ce que

l’application soit ensuite facilement évolutive ou suffisait à garantir une utilisation sans risque, il

n’y aurait aucune action à mener. Mais ce monde est, bien entendu utopique ; rares en effet sont

les applications qui ne subissent aucun incident et qui ne subiront aucun changement qu’il soitd’ordre technique ou fonctionnel.

Nous allons donc analyser rétrospectivement les études méthodologiques qui font référence dans

le domaine et identifier celles qui pourraient être utilisées dans le cadre d’une démarche de

MCO.

Ainsi, les méthodes qui traitent notamment de l’assurance qualité, de la gestion des problèmes,

du changement, des coûts, des risques, des approvisionnements, du management des équipes,

(tout autant de processus qui concourent à la bonne gouvernance du SI et donc à la mise en place

de MCO dans des conditions optimales), sont à étudier avec attention.





Imprimé le

L’objectif ici, n’est pas de décliner toutes les étapes de la gestion de projet, ni tous les processus

liés à la gouvernance du SI mais au moins tous ceux qui y participent activement et de mesurer

leur complémentarité, de comprendre leur positionnement dans le cadre de fonctionnement de

l’entreprise et d’appréhender leur approche en matière de MCO. En d’autres termes, nous faireune idée de ce qui est induit par l’activité de MCO d’applications naissantes et de l’aborder

sereinement en commençant par analyser les processus de gestion de projet, puis en continuant

par les référentiels complémentaires tels que CobiT, CMMi, ITIL pour les principaux.

." +*8&&!&%%&&3

Les premières réflexions sur la gestion de projet datent de l’après Seconde Guerre Mondiale.

Elles avaient pour motivation de garantir la maîtrise et la coordination des travaux de grands

projets mobilisant plusieurs corps de métiers. Ces premières ébauches ont été largement

complétées et améliorées depuis.

L’émergence de l’informatique dans l’entreprise vers la fin de l’ère de l’implantation et au début

de celle du développement, a conduit différentes associations professionnelles et organismes de

normalisation à enrichir et cadrer le sujet pour l’appliquer aux projets SI.

En matière de SI, la « gestion de projet » est un sujet traité depuis de nombreuses années. C’est

un domaine arrivé à maturité, son utilité n’est plus à démontrer, son exercice est majoritairement

bien maîtrisé et surtout clairement décrit.

Sans détailler tous les aspects liés à la gestion de projet, abordons son champ d’application, sacouverture et tentons d’y saisir les éventuelles références à la maintenance ou tout du moins

toutes celles qui faciliteraient l’exploitabilité des applications, ou qui pourraient être utilisés dans

le cadre d’une transition vers le MCO.

." 4

En matière de gestion de projet, les auteurs de l’ouvrage « Management de projet IT » [WEKA,

2003] résument bien l’état des lieux, ce qui est communément admis par la profession : « Le plus

beau projet du monde, mal organisé et mal piloté, ne peut que donner des résultats décevants.

Sans un dispositif de gestion de projet efficace, il est difficile de garantir le succès d’une

opération de ce type ».

Un exemple de dispositif de gestion de projet efficace est celui proposé par le PMI (Project

Management Institute) à travers le guide du PMBOK (Project Management Body Of Knowledge

pour Corpus des connaissances en management de projet).

Ce dispositif est un standard reconnu par l’ANSI (American National Standards Institute,

pendant américain de l’AFNOR, Association Française de NORmalisation auprès de l’ISO,

Organisation Internationale de Normalisation) qui décrit les connaissances requises à l’exercice

de la gestion de projet. Le guide PMBOK comporte trois parties.





Imprimé le

."" &#K

La partie I définit le contexte en posant le « Cadre du management de projet ». On y trouve la

définition de termes clés et une description de l’environnement dans lequel se déroule un projet :

la connaissance du champ d’application, des normes et réglementations ou la compréhension del’environnement du projet.

Cette partie peut tout à fait être reprise dans le cadre du MCO d’application. En effet, l’équipe en

charge de MCO doit également connaître l’environnement dans lequel évolue son application.

D’ailleurs, certains des éléments peuvent être repris de la phase projet.

La partie II s’attache à décrire les cinq groupes de processus de management d’un projet :

Démarrage

Planification

ExécutionSurveillance

et maîtrise

Clôture

Démarrage

Planification

ExécutionSurveillance

et maîtrise

Clôture

Les cinq groupes du processus de management de projet

Un groupe de processus est un ensemble de processus élémentaires reliés entre eux par leurs

données d’entrée et de sortie. Chaque groupe de processus est spécialisé, ainsi, celui de :

• « Démarrage » définit et autorise le projet ou une phase du projet s’il est de grande

taille.

• « Planification » affine les objectifs et planifie le déroulement des actions nécessaires

à leur atteinte.

• « Exécution » intègre l’ensemble des ressources pour une bonne exécution du plan demanagement du projet.

• « Surveillance et maîtrise », telle une vigie, est le dispositif qui cherche à éviter tout

écart et, le cas échéant, à en permettre la correction pour maintenir l’atteinte des

objectifs du projet.

• « Clôture » conclut le projet (ou une de ses phases) par formalisation de l’acceptation

du (ou des) livrables(s).

Dans l'ensemble des groupes de processus et de leurs processus, les données de sortie des

processus sont en relation entre elles, et ont un impact sur les autres groupes de processus.





Imprimé le

Ce principe d’interactions a pour effet que chaque groupe de processus n’est pas indépendant des

autres. Leur bonne exécution se traduit par un chevauchement :

Interactions des groupes de processus dans un projet selon le PMBOK

Ici encore, lorsque l’équipe en charge du MCO doit gérer une évolution, elle peut tout à fait

suivre ces processus. Elle s’inscrit comme une phase projet d’un gros projet.

La partie III décrit l’ensemble des processus élémentaires des groupes de processus et les

organise à travers neuf domaines de connaissances :





Imprimé le

Vue d’ensemble des domaines de connaissance d’après le PMBOK

Pour être en phase avec l’approche la plus récente des associations professionnelles, il fautpréciser que la gestion de projet relève, avec la conduite de projet, de la fonction de management

de projet. Cette dualité conduite/gestion est motivée par la séparation de rôles dès lors que les

activités respectives pouvaient éventuellement être jouées par des personnes ou des entreprises

différentes. Elle a été proposée comme vocabulaire normalisé par l’AFITEP (Association

Francophone de Management de Projet) et l’AFNOR20 (Association Française de

NORmalisation) ».

Il n’est pas rare que les rôles soient attribués à des personnes différentes. La conduite de projet

est une activité assurée par une personne dont le rôle est de donner les orientations, prendre les

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





Imprimé le

décisions propres au bon fonctionnement de la structure de projet. C’est en général un directeur

de projet ; on dit qu’il assure le pilotage.

Les caractéristiques de la gestion de projet sont plutôt de faire vivre le projet, de collecter et de

préparer les informations nécessaires à la prise de décision. Elle est assurée par le chef de projet.Cette fonction se retrouve aussi sous les appellations « responsable de projet », « gestionnaire de

projet » selon les différentes classifications des emplois dans les entreprises.

Les deux fonctions peuvent être confondues et assurées par une seule et même personne 21. C’est

souvent le cas pour les petits projets SI ou lors de la gestion des évolutions sur une application.

Il n’est pas rare, non plus, qu’il existe deux chefs de projet, un qui appartient à la MOA et un

deuxième qui appartient à la MOE. Cette bicéphalie revêt l’avantage d’une meilleure cohésion

entre MOA et MOE, fluidifie la circulation de l’information entre les deux structures, et sécurise

la MOA dans sa vision de l’avancement du projet. Ce constat est bien en phase avec le résultat

de l’analyse des entités MOA-MOE du chapitre précédent.

La liste des activités principales, des domaines de connaissances du PMBOK, met en avant que

mener un projet SI ne nécessite pas uniquement des compétences informatiques. Les rubriques

« ressources humaines » ou « communications » en sont un exemple. La nécessaire

compréhension, que doit avoir un responsable de projet, de l’environnement du projet en est une

autre.

De plus, dans le cas de séparation des entités, la définition des rôles et des responsabilités est

primordiale.

Ainsi, l’adaptation au MCO de cette partie est la suivante :

1. La phase de transition avec les processus élémentaires suivants :

• Management des coûts du projet

• Management des approvisionnements du projet

• Management de la qualité du projet

2. La phase de gestion des changements avec les processus suivants :

• Management des ressources humaines du projet• Management des risques du projet

• Managements des communications du projet

Regardons plus précisément chaque processus élémentaire.

21 Au Pôle Clients du CSI, ces deux fonctions sont assurées par le POA (Pilote Opérationnel Applications)





Imprimé le

!"

Vue d'ensemble du management des coûts du projet

Chacune des activités du « Management des coûts de projet » peut être adaptée au MCO de

façon plus ou moins approfondie. De base, « l’estimation des coûts » reprend les éléments liés

aux évolutions potentielles de l’application faite selon des outils et techniques d’estimation par

analogie.

De même l’activité de « Budgétisation » est celle qui permet d’estimer le budget nécessaire aux

travaux d’évolutions en tenant compte d’éléments tels que des coûts de références.

Ces deux premiers points permettent d’estimer une enveloppe de maintenance évolutive utile

lorsqu’il faudra élaborer le cahier des charges nécessaire à notre besoin de mise en place d’une

TMA (Tierce Maintenance Applicative).

Le dernier point, la «Maîtrise des coûts » permet, en phase de MCO de mesurer le coût de

réalisation de la maintenance par rapport au coût budgétisé.





Imprimé le

Vue d'ensemble du management des approvisionnements du projet





Imprimé le

L’ensemble de ces activités, comme précédemment, est à décliner lors de la phase de transition.

L’objectif est de préparer, de planifier et de lancer les appels d’offres de recherche de TMA. En

effet, avant toute commande d’approvisionnement, il est impératif de lancer un appel d’offre

pour choisir le meilleur prestataire selon des critères définis préalablement. Cette action estlongue et assez laborieuse et doit être anticipée.

Management de la qualité du projet

Que l’on soit en phase projet ou en phase MCO, l’activité de « Management de la qualité » est

aussi importante. Elle se traduit par la mise en place d’un plan qualité produit, par l’identification

d’indicateurs de mesure de la qualité du MCO, et par la mise en place de moyens de contrôle

constitués de bilans d’activité, de retour d’expérience ; autant d’outils qui permettrontd’identifier par exemple les actions préventives.





Imprimé le

!"

Management des ressources humaines du projet





Imprimé le

L’activité de « Management des ressources humaines du projet » se focalise sur l’équipe projet et

ce, même en mode MCO.

Management des risques du projet

Toutes les rubriques du management des risques sont aussi à appliquer dans le cadre des

développements induits par des changements. Il est donc tout à fait envisageable d’utiliser les

mécaniques de ce processus dans le cadre de MCO. En effet, les risques liés à une interruption de

service ou à une régression de fonctionnement sont à anticiper, d’autant plus lorsque

l’application est en exploitation.





Imprimé le

Management des communications projet

Enfin, l’activité de « Management des communications du projet » souligne que « les processus

mis en œuvre apportent les liens indispensables entre les gens et les informations nécessaires à

une communication réussie ». Cette communication est évidemment aussi importante en phase

de MCO.





Imprimé le

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

• Une communication efficace, à savoir la maîtrise de l'échange d'informations,

• L'influence sur l'organisation, en quelque sorte la capacité de « faire faire les choses

»,• L'aptitude à diriger, en sachant développer une vision et une stratégie, et motiver les

personnes pour réaliser cette vision,

• La motivation, afin de stimuler l'énergie nécessaire pour atteindre de hauts niveaux

de performance et surmonter les obstacles au changement,

• La négociation et la gestion des conflits, en sachant conférer avec d'autres personnes

pour s'entendre ou parvenir à un accord,

• La résolution des problèmes, qui comprend la définition du problème,

l'identification et l'analyse d'alternatives, et la prise de décision..") &!&!!&!%&&3#

La démarche du PMBOK peut être utilisée dans le cadre du passage d’un projet en application et

notamment pour réaliser les opérations telles que la gestion des approvisionnements (lancer un

appel d’offre de TMA pour assurer le MCO), la gestion du management d’équipe (pour mettre

en place l’équipe adéquate), la gestion des coûts (pour définir le coût prévisionnel de la TMA et

maîtriser les dépenses), la gestion des risques (pour maîtriser un maximum de risques liés aux

changements subis par l’application), la gestion globale du projet (pour piloter les évolutions de

l’application), la gestion qualité du projet (pour s’assurer de l’efficacité du MCO) et pour finir lagestion de la communication.

Ainsi le MCO d’applications peut, comme les projets, être divisé en composants plus faciles à

gérer. Les sous projets sont souvent donnés en sous-traitance à une entreprise externe ou à un

autre service fonctionnel de l'entreprise réalisatrice. On peut citer les exemples suivants :

• Les sous-projets basés sur le processus du projet, tels qu'une phase spécifique du cycle

de vie du projet,

• Les sous-projets qui sont fonction d'exigences de compétences des ressources

humaines, voire la Tierce Maintenance Applicative en terme de SI,• Les sous-projets impliquant une technologie spécialisée, tels que les tests automatisés

de programmes informatiques dans un projet de développement de logiciel, Tierce

Recette Applicative (TRA).

Le lien entre le projet et le produit est représenté par les 2 schémas suivants :





Imprimé le

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

Le détail du cycle de vie du projet

La description initiale du contenu et les ressources que l'organisation est disposée à investir sont

de nouveau affinées lors du processus de démarrage. Le chef de projet est alors sélectionné s'il

n'est pas déjà affecté. Les hypothèses et les contraintes initiales vont aussi être documentées ànouveau. Le cycle de vie du projet est une phase répétitive de la vie du produit et est géré en

MCO.

.) +*8&&!&%5&+!*+

Comme nous l’évoquions en début de chapitre, au-delà de la gestion de projet « pure », il existe

des concepts connexes et complémentaires qui renforcent un dispositif déjà bien fourni.

Intéressons nous maintenant à la façon dont ils soutiennent la gestion de projet et s’ils

s’appliquent au MCO en matière de gestion des SI.





Imprimé le

Bien souvent dans les entreprises ces démarches, complémentaires à la gestion de projet

proprement dite, sont mises en œuvre et assurées par des structures de supports aux projets.

Les intervenants sont spécialisés et maîtrisent les sujets (qualité, risques, sécurité, contrôles,

changement, …) qui définissent en quelque sorte le cadre de fonctionnement au sein duquel ilfaut s’inscrire.

Le concept de gouvernance s’applique au niveau de l’entreprise dans sa globalité mais aussi au

niveau du seul système d’information. Elle permet de répondre aux nouveaux enjeux de la

politique de management des ressources IT.

C’est ce que l’on appelle « Gouvernance des SI » qui peut se définir comme : « une conséquence

du mécanisme de Gouvernance d’Entreprise visant à réduire les risques opérationnels engendrés

par les technologies de l’information à travers des processus d’audit et de contrôle, destinés à

garantir l’intégrité, la complétude et la traçabilité des informations »22 .

La mise en œuvre de ces « bonnes pratiques » est basée sur les outils méthodologiques qui

couvrent les différents sous-systèmes de l’entreprise.

En ne citant que certains de ces cadres, de ces outils, le schéma que nous nous proposerions de

construire serait :

ORIENTER DECIDER CONSTRUIRE DEPLOYER OPERER

AMELIORER

CONTROLER

DOCUMENTER

MODELISER

CobiT ITIL

CMMi

Activités 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

Activités 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 méthodologiques de référence

Ce schéma n’est pas exhaustif. Il existe d’autres outils méthodologiques23 qui ne seront pas

évoqués ici.

Nous allons juste appréhender de manière synthétique l’apport complémentaire de CobiT, CMMi

et ITIL en regard des activités SI, et du MCO en particulier.

22 « IT Gouvernance » de F Georgel – page 2423 « IT Gouvernance » de F Georgel





Imprimé le

.) &4

CobiT pour Control Objectives for Information and Technology est un cadre méthodologique qui

propose « un ensemble de moyens très puissants pour gérer les niveaux de contrôle devant être

exercés sur les ressources IT afin que ces dernières soutiennent efficacement la réalisation desobjectifs de l’entreprise »24 .

Ce cadre méthodologique a été développé, mis au point et maintenu par l’ISACA (Information

Systems Audit and Control Association). L’ISACA est une association internationale implantée

aux Etats-Unis qui effectue des travaux de recherche et des études dans le domaine de l’analyse

et des méthodes de contrôle des SI.

Il existe une version française de CobiT. Elle est réalisée par l’AFAI (Association Française del’Audit et du conseil Informatiques). L’AFAI, créé en 1982, est le chapitre français de l’ISACA

et le représentant de l’ITGI (Information Technology Governance Institute), centre de recherches

de l’ISACA. La dernière version de Cobit a été présentée aux Etats-Unis en décembre 2005 ;

c’est la « version 4 ».

-$".!

L’objectif de la gouvernance est de comprendre et de gérer les risques liés aux IT.

Les points clés, mis en avant par l’AFAI, pour mettre en œuvre CobiT dans une entreprise sont

que :

• L’entreprise ait une stratégie claire qui fixe les objectifs à atteindre,

• Les directions métiers traduisent et enrichissent ces objectifs en fonction de leur type

de contribution (les objectifs du marketing ne sont pas les mêmes que ceux de la

logistique),

• Les objectifs métiers soient traduits en objectifs SI,

• Ce « plan de bataille » fasse l’objet d’un suivi et d’un contrôle qui assurent le maintien

du bon cap (identifier et éviter les dérives voire apporter les corrections nécessaires sila dérive est amorcée).

CobiT ne s’adresse donc pas seulement à la DSI mais aussi aux directions métiers et aux

directions générales. Son positionnement se situe au niveau de la gouvernance ; gouvernance

d’entreprise comme gouvernance des SI.

Si cela peut paraître évident, rien ne sert d’espérer mettre en œuvre CobiT et d’en tirer quelque

bénéfice s’il n’y a pas de stratégie.

24 « IT Gouvernance » de F Georgel – chapitre 15





Imprimé le

Bien évidemment toutes ces opérations, tous ces programmes ou projets de transformation du SI

doivent faire l’objet d’une gestion de priorités et être suivis dans leur mise en œuvre.

La feuille de route que propose CobiT est un ensemble de préconisations qui s’articulent autour

de quatre thèmes principaux :• PO pour Planifier et Organiser : domaine de la stratégie de l’entreprise,

• AI pour Acquérir et Implémenter : domaine de la stratégie du système d’information,

• DS pour Délivrer et Supporter : domaine opérationnel de fourniture des services aux

utilisateurs,

• SE pour Surveiller et Evaluer : domaine du contrôle et de l’évaluation de la

performance et de la qualité.

Chaque thème, ou domaine, regroupe les processus clés qui lui sont propres. Le nombre de

processus total est de trente quatre.

La figure qui suit montre ce principe de décomposition25 :

25 document traduit de l’AFAI





Imprimé le

•

•

•

•

ApplicationsInformationsInfrastructuresPersonnes

DS1 Définir et gérer lesniveaux de service

DS3 Gérer la performance et la capacité

DS5 Assurer la sécuritédes systèmes

DS7 Instruire et former les utilisateurs

DS9 Gérer la configuration

DS11 Gérer les données

DS13 Gérer l’exploitation

DS2 Gérer lesservices tiers

DS4 Assurer un service continu

DS6 Identifier et imputer les coûts

DS8 Gérer le service d’assistance clientet les incidents

DS10 Gérer les problèmes

DS12 Gérer l’environnement physique

AI1 Trouver des solutions informatiques

AI 3 Acquérir une infrastructure technique et en assurer la maintenance

AI 7 Installer et valider les solutions et les modifications

AI4 Faciliter le fonctionnement et l’utilisation

AI6 Gérer les changements

AI 2 Acquérir des applications et en assurer la maintenance

AI5 Acquérir des ressources informatiques

PO1 Définir un plan informatique stratégiquePO2 Définir l’architecture de l’informationPO3 Déterminer l’orientation technologiquePO4 Définir les processus, l’organisation et les relations de travailPO5 Gérer lesinvestissements informatiquesPO6 Faire connaître les buts et les orientations du managementPO7 Gérer les ressources humaines de l’informatique

PO9 Évaluer et gérer les risquesPO10 Gérer les projets

PO8 Gérer la qualité

SE2 Surveiller et évaluer le contrôle interneSE3 S’assurer de la conformitéréglementaireSE4 Mettre en place la gouvernance des SI

SE 1 Surveiller et évaluer la performance des SI

SURVEILLER ET

EVALUER

PLANIFIER ET

ORGANISER

DELIVRER ETSUPPORTER

ACQUERIR ETIMPLEMENTER

RESSOURCES

• Efficience

• Intégrité• Disponibilité• Conformité• Fiabilité

Confidentialité•

Efficacité•

COBIT

OBJECTIFS METIER

OBJECTIFS DE GOUVERNANCE

INFORMATION

•

•

•

•


•

•

•

•


•

•

•

•





































































SE2 Surveiller et évaluer le contrôle interneSE3 S’assurer de la conformitéréglementaireSE4 Mettre en place la gouvernance des SI

SE 1 Surveiller et évaluer la performance des SISE2 Surveiller et évaluer le contrôle interneSE3 S’assurer de la conformitéréglementaireSE4 Mettre en place la gouvernance des SI

SE 1 Surveiller et évaluer la performance des SI

SURVEILLER ET

EVALUER

PLANIFIER ET

ORGANISER

PLANIFIER ET

ORGANISER

DELIVRER ETSUPPORTER

ACQUERIR ETIMPLEMENTER

RESSOURCES

• Efficience

• Intégrité• Disponibilité• Conformité• Fiabilité

Confidentialité•

Efficacité•

• Efficience• Efficience

• Intégrité• Intégrité• Disponibilité• Disponibilité• Conformité• Conformité• Fiabilité• Fiabilité

Confidentialité• Confidentialité•

Efficacité• Efficacité•

COBITCOBIT

OBJECTIFS METIER

OBJECTIFS DE GOUVERNANCE

INFORMATIONINFORMATION

Cadre de référence général de CobiT (source AFAI)

Le schéma traduit aussi l’importance qu’est la compréhension de l’utilité et de la contributionque doit avoir, et a, le SI de l’entreprise dans sa contribution à la stratégie globale.

CobiT aide les dirigeants à évaluer les risques et à contrôler les investissements dans un

environnement informatique souvent imprévisible. Il permet ainsi de vérifier que la gouvernance

des systèmes d’information est cohérente avec celle de l’entreprise, on parle alors d’alignement

stratégique.

Au-delà des processus, CobiT détaille chacun d’eux en activités. Il y en a au total deux cent vingt

que nous n’aborderons pas ici.

L’objectif ici est de mettre en place des processus qui permettent à chacun des acteurs(MOA/MOE) de maîtriser ses actions et plus précisément à la MOA de piloter son SI (d’avoir les





Imprimé le

cadres pertinents pour piloter ses ouvrages) et à la MOE de pouvoir s’appuyer sur sa MOA pour

toutes activités à la périphérie de son domaine de compétences et de responsabilités : « Chacun

ses responsabilités pour avancer sereinement et efficacement ».

! /

Même si tous les processus peuvent potentiellement être adaptés, certains d’entre eux sont à

mettre en avant plus précisément dans le cadre du MCO d’applications.

Ce sont par exemple, « surveiller et évaluer la performance SI », « S’assurer de la conformité

réglementaire » « Mettre en place une gouvernance SI », « Gérer la qualité », « Evaluer et gérer

les risques », « Gérer les changements», « Gérer les problèmes », « Acquérir les applications et

en assurer la maintenance », « Installer et valider les solutions et les modifier », « Faciliter le

fonctionnement et l’utilisation », « Définir les processus, l’organisation et les relations detravail » pour les principaux.

Une attention particulière est à apporter cependant aux processus « Gérer les changements »,

« Gérer les problèmes », qui précise un objectif général et les objectifs de contrôle détaillés.

L’objectif général est ici la maîtrise des changements apportés sur l’environnement de

production pour en garantir la stabilité. Les objectifs de contrôle détaillés mettent en avant :

• L’importance de procédures formelles de gestion des changements de leur

standardisation,

• La nécessité de prioriser les changements en fonction de leur importance etd’impliquer le demandeur par son autorisation formelle,

• L’existence d’une procédure particulière pour mettre en œuvre les modifications

d’urgence,

• La contrainte de documentation pour communiquer à toutes les parties prenantes sur

l’état d’avancement du changement et acter de son achèvement.

Un des instruments que fourni le guide de management est un tableau RGCI (Responsable,

Garant, Consulté et/ou Informé) qui identifie le niveau de responsabilité pour chaque fonction

par activité.Le dernier instrument donné pour chaque processus, est la liste des indicateurs de mesure qui

permettent d’évaluer la performance de l’exercice et d’en assurer le contrôle.

La dernière rubrique concerne le modèle de maturité. C’est une échelle à cinq niveaux qui

permet d’évaluer le degré de maîtrise du processus : de « inexistante » à « optimisée ». Cette

évaluation de la maturité au niveau de chaque processus permet, par consolidation, une

évaluation au niveau de chaque domaine puis à celui de l’entreprise. Le niveau de maturité

donne une indication de la qualité de l’alignement du système d’information à la stratégie de

l’entreprise.





Imprimé le

Un autre point important est la mise en place et la maintenance opérationnelle d’une structure de

coordination, de communication et de liaison optimale entre la fonction informatique et divers

autres professionnels à l’intérieur et à l’extérieur de cette fonction, comme le conseil

d’administration, la direction générale, les unités opérationnelles, certains utilisateurs, lesfournisseurs, les responsables de la sécurité, les responsables de la gestion des risques, le groupe

responsable de la conformité dans l’entreprise, les responsables chargés des prestations externes

(externalisation et sous-traitance). Ce point peut être complémentaire au processus de gestion de

projets de « Management des communications ».

Pour conclure ce focus sur CobiT, si nous ne devions retenir qu’une préconisation, ce serait celle

donnée, sous forme d’avertissement, par l’ITGI au début de son guide : « l’utilisation de CobiT

ne garantit pas de produire de façon certaine un résultat positif ».

L’idée qui veut que la qualité d’un outil soit fonction, plus de l’usage qui en est fait que de safaçon d’être respectée !

Ce point n’est pas anodin ; il est valable pour tous les référentiels. En effet une méthode pose les

bonnes questions ; elle ne donne pas les bonnes réponses.

En conclusion de CobiT, nous dirions qu’il s’agit d’un outil :

• Plutôt de préoccupation stratégique, orienté audit qui atteste de l’importance que revêt

le SI pour l’entreprise,

• Et que d’un point de vue MCO, il donne une marche à suivre pour maîtriser au

maximum les changements et les incidents (de même qu’en gestion de projet, le faitd’appliquer une méthodologie ne garantit pas un MCO de qualité)

.)" ##

CMMi, pour Capability Maturity Model Integration (Modèle de Maturité de Capacités Intégré),

traite de l’ingénierie du logiciel, des systèmes, du développement intégré de produit ou de

processus, et de la gestion des fournisseurs.

Bien que spécifique à l’ingénierie des systèmes et du logiciel, il s’agit d’un modèle de maturité

qui est généralisable à d’autres activités comme le développement de matériel, l’assistanceclient, les acquisitions, etc.

Il concerne tous les processus liés aux affaires et aux projets, du développement jusqu’à la

préparation de la production en série. Il s’intéresse aux processus de support du management afin

de s’assurer que les processus métiers disposent bien des moyens et ressources nécessaires.

Le modèle CMMi a été développé à la fin de la dernière décennie quatre vingt par le SEI

(Software Engineering Institute ou Institut de l’Ingénierie Logiciel) à la demande du départementaméricain de la défense (le DoD). Le DoD jugeait nécessaire de pouvoir évaluer ses fournisseurs





Imprimé le

informatiques en regard des bonnes pratiques relatives au « génie logiciel » (i.e. l'ensemble des

activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser

la production d’un logiciel et son suivi).

Les thèmes, les domaines particuliers des modèles de départ abordent par exemple :• La maturité des développements logiciels (en fait le premier modèle),

• La maîtrise des processus d’ingénierie,

• La capacité d’acquisition de logiciels (faire le bon achat),

• L’évaluation des fournisseurs de logiciels,

• …

La dernière version de CMMi est la version 1.2.

-$".!

En première analyse nous pouvons dire que l’approche CMMi est de nature périphérique au

thème de la gestion de projets SI. Elle propose à l’entreprise une démarche qui lui confère le

niveau de maturité nécessaire à la meilleure façon de mettre en œuvre ses projets SI.

En d’autres termes, CMMi permet de mesurer si une organisation, une entreprise, dispose des

compétences requises pour délimiter ses projets, s’assure de leurs bonnes spécifications

(périphérie de l’amont du projet), et du bon usage des produits délivrés (périphérie de l’aval au

projet).

La démarche est basée sur un système d’évaluation des bonnes pratiques nécessaires : comment

gagner en maturité en matière de développement logiciel (qualité, fonctionnalité, coût et délai).

Une particularité du CMMi est qu’il possède deux niveaux de représentation26

Représentation par niveau

(niveau de maturité)

Représentation continue

(profil d’aptitude)

• Cinq niveaux de maturité

• Un comportement organisationnelvraiment différent à chaque niveau

• Un ensemble de domaines de processus

à chaque niveau

• Une façon simple d’exprimer un but à

atteindre

=> priorité à la vision organisationnelle

• Six niveaux d’aptitude par domaine de

processus• Un algorithme qui donne la maturité

organisationnelle

• Sélection des domaines de processus

selon ses besoins et priorité

=> priorité à la vision processus

26 Guide des certifications SI –p 33





Imprimé le

Le SEI précise ces différences en indiquant que

• La démarche par étapes envisage une évaluation globale de l’organisation dont on

mesure le niveau de maturité,

• La démarche continue propose de mesurer des niveaux de capacité par grandecatégorie de processus (gestion de processus, gestion de projet, ingénierie et support).

Pour mieux se représenter ces différences, nous pourrions dire que pour la démarche par étapes,

l’entreprise doit progresser globalement du niveau de maturité le plus bas vers le plus élevé. Pour

la seconde, démarche continue, il peut exister un décalage de niveau de capacité entre les

catégories de processus (la capacité de l’entreprise peut être plus avancée dans l’une par rapport

aux autres) qui ne remet pas en cause l’ensemble.

Le nombre de niveaux varie selon la démarche considérée :

Niveau Niveaux de maturité dela démarche par étapes

Niveaux de capacité dela démarche continue

0 N/A Incomplet

1 Initial Pratiqué

2 Reproductible Reproductible

3 Défini Défini

4 Maîtrisé Maîtrisé

5 Optimisé Optimisé

Niveaux de maturité CMMi selon la démarche

CMMi couvre un ensemble de vingt-deux domaines d’application. Chaque domaine considéré

fait l’objet d’une description :

• De son but,

• De sa couverture,

• Des autres domaines auxquels il est lié.

La gestion de la planification, la gestion des risques, la gestion des achats, la gestion

développement et, la gestion du changement, sont des exemples de domaine.Chaque domaine d’application est détaillé par les objectifs visés, par les pratiques à mettre en

œuvre et les produits résultants.

Ainsi, un objectif visé peut être d’ordre général ou spécifique. S’il est d’ordre spécifique, il ne

s’applique qu’à lui même, par contre s’il est d’ordre général, il sera commun à plusieurs

domaines. Par exemple, le « lancement de la réalisation », la « Capacité de réaliser », la

« Conduite de mise en œuvre », etc. sont des objectifs communs à presque tous les domaines

La capacité, à atteindre à l’aide des domaines de connaissance, est évaluée par niveaux. Les cinq

niveaux de maturité de la démarche par étapes qualifient la maîtrise de la gestion de projet pourune organisation :





Imprimé le

Niveau 1

« initial »

caractérise une organisation plutôt habituée à subir les dépassements (délai,

coût), la non-qualité des produits livrés. Les situations de crises se répètent et

les succès restent exceptionnels. De ce fait, aucun domaine d’applicationn’est associé à ce niveau ; il n’implique pas de pré-requis.

Niveau 2

« reproductible »

désigne une organisation capable de gérer les exigences, planifier et répartir

la charge de travail, assurer la qualité des produits.

Niveau 3

« défini »

est celui d’une organisation qui sait capitaliser sur ses expériences. Les

processus de gestion existent, sont mis en œuvre, maîtrisés et assurent une

bonne cohérence des différents intervenants. C’est à ce niveau qu’uneorganisation dispose d’une méthode standard de gestion de projets.

Niveau 4

« maîtrisé »

confère à l’organisation un caractère plus efficient qu’efficace. Les

indicateurs qui permettent différentes mesures existent et sont utilisés.

Niveau 5

« optimisé »

est celui où la seule maîtrise des processus de gestion ne suffit plus.

L’organisation cherche l’amélioration continue de ses processus, de ses

méthodes et se met en situation de pouvoir anticiper.

La totalité des vingt deux domaines d’application n’est pas considérée à chaque niveau de

maturité ; on ne progresse pas sur la totalité en fonction du niveau atteint.

A chaque niveau de maturité correspondent des domaines d’application particuliers que

l’organisation doit maîtriser pour l’atteindre.

C’est au niveau cinq de maturité que l’ensemble des vingt deux domaines est couvert. Les

niveaux deux et trois sont ceux auxquels correspondent le plus de domaines d’application.





Imprimé le

1 : InitialProcessus non défini

2 : GéréProcessus organisé

3 : DéfiniProcessus standardisé

4 : Géré quantitativement

Processus prévisible

5 : En optimisationAmélioration continue

Structuration

Standardisation

Mesure/Prévision

Maîtrise du changement

R i s q u e

P er f or m an c e

1 : InitialProcessus non défini

2 : GéréProcessus organisé

3 : DéfiniProcessus standardisé

4 : Géré quantitativement

Processus prévisible

5 : En optimisationAmélioration continue

Structuration

Standardisation

Mesure/Prévision

Maîtrise du changement

R i s q u e

P er f or m an 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 d’application

requis.

Le niveau deux considère ce qui se passe du point de vue de la réalisation des projets SI. Le

niveau trois élargit le champ vers l’amont et l’aval de la réalisation.

Les deux derniers niveaux portent sur la maîtrise et l’amélioration continue de l’ensemble (nous

pourrions dire que mettre en œuvre CMMi c’est procéder par expansion).

!

De part le processus de gestion de configuration, le CMMi est bien adapté à la gestion des

évolutions aussi bien fonctionnelles que techniques.

La considération faite du MCO par le CMMi porte sur l’aspect infrastructure informatique ;

l’environnement de production. En effet, cet aspect sera traité par la capacité de la TMA à gérer

les changements et à répondre rapidement aux incidents de fonctionnement dans le cadre du

MCO.

En synthèse de cet aperçu de CMMi, nous pourrions dire que c’est un référentiel qui considère

les moyens de réaliser correctement les projets informatiques sans être une méthode de conduite

de projet ; il se positionne donc plutôt au niveau des études informatiques, ou de la TMA lorsque

ses études sont externalisées.

.))

ITIL pour Information Technology Infrastructure Library est un ensemble de bonnes pratiques

présentées sous forme de livres. Plus précisément, il s’agit d’un recueil de « conseils et recommandations qui s’appuient sur la pratique et la maîtrise du système d’information,





Imprimé le

orientés vers le client pour tendre vers l’excellence opérationnelle par le déploiement de

processus » [Lettre d’information ITIL]27. On parle généralement de bibliothèque ITIL.

Ce référentiel de bonnes pratiques est édité par l’OGC (Office of Government Commerce),

Office public Britannique du Commerce et, contrairement à d’autres, relève du domaine de

l’OSL (Open Source Library). Cela signifie que l’OGC n’en est pas le seul auteur ; des groupes

de travail issus d’autres structures contribuent à ITIL et contrôlent les termes et conditions de

distribution de leurs créations28.

ITIL a été initié au début des années 1980 par le gouvernement britannique afin d’améliorer le

service rendu par les différents services informatiques de l’état. C’est un dispositif élaboré et

enrichi par des praticiens alors que d’autres le sont plutôt par des utilisateurs (il faut comprendredes « personnes qui n’ont qu’une vision théorique »).

Depuis sa création, la bibliothèque a vu le nombre de livres se réduire. Il est, dans sa version

deux, au nombre de sept. Les deux livres les plus significatifs, d’ITIL, sont le :

• Fourniture des services qui traite des thèmes de « Gestion des contrats de service »,

« Gestion transversale des problématiques communes à tous les contrats de service »

et « Gestion financière »,

• Support des services qui aborde les thèmes de « Prise d’appels », « Résolution des

dysfonctionnements », « Gestion des évolutions », « Application des contrats deservice », « gestion des incidents ».

La version trois d’ITIL a été présentée en mai 2007. Le nombre de livres diminue encore :

ITIL version 2 ITIL version 3 (mai 2007)

Perspective de l’entreprise Stratégie des services

Fourniture de services Conception des services

Gestion de la sécurité Mise en production des services

Planification et mise en œuvre de la

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 d’information (ou newsletter) ITIL est rédigée par Christian NAWROCKI et publiée sur internet à

l’adresse http://www.newsitweb.info 28 La distinction entre « Open source » et logiciel libre est clairement précisé par F GEORGEL dans son ouvrage« IT Gouvernance », chapitre 16.





Imprimé le

-$".!

L’objectif d’ITIL est de fournir aux DSI les outils leur permettant d’améliorer la qualité des

services rendus à leurs clients (les directions métiers). Ce n’est pas incompatible avec le principe

de contribution aux objectifs de stratégie de l’entreprise. Elles ont, de plus, été largement

éprouvées dans le monde industriel.

Il y a fort à parier que les techniques de maintenance des outils d’une ligne de production, qui

doit être opérationnelle vingt quatre heures sur vingt quatre, soient applicables à des matériels de

centres de calculs (on utilise aussi l’anglicisme Data Center) et surtout tout aussi efficaces. Ce

parallèle industriel permet de souligner un des intérêts de la démarche ITIL : donner à

l’entreprise une capacité de mise en ordre de marche et de mobilisation de ses moyens (dont font

partie les infrastructures du SI) lorsqu’elle doit mener la « bataille » de mise en œuvre de sa

stratégie.

Les objectifs d’ITIL y contribuent en :

• Alignant les services informatiques aux besoins actuels et futurs de l’entreprise et de

ses clients (pas qu’au sens utilisateurs internes),

• Améliorant la qualité et réduisant les coûts des services fournis par l’infrastructure,

• Augmentant le taux de disponibilité et la productivité des ressources,

• Réduisant les coûts de fourniture des services à long terme,

• Proposant une démarche évolutive basée sur les processus au sens dispositif de

transformation.

En d’autres termes ITIL vise, pour les entreprises qui l’adoptent, à améliorer la qualité globale de

la production informatique et la rendre perceptible par les utilisateurs.

! $$(!$"!

Etant donné que la démarche ITIL propose un référentiel des meilleures pratiques, les plus

values de sa mise en œuvre, généralement constatées sont la :

• Satisfaction des utilisateurs (personnel et clients),

• Clarification des rôles,• Amélioration de la communication inter-services,

• Mise sous contrôle des processus avec des indicateurs pertinents et mesurables,

permettant d'identifier les leviers pour réaliser des économies,

• Meilleure compétitivité,

• Sécurité accrue (disponibilité, fiabilité, intégrité),

• Capitalisation des données de l'entreprise,

• Optimisation de l'utilisation des ressources,

• Outil de parangonnage (benchmarking) et outil de positionnement vis-à-vis de laconcurrence.





Imprimé le

En terme de MCO, le livre « Supports des Services » vise à répondre aux problèmes de gestion

opérationnelle (traiter les erreurs connues) et à assurer le maintien du bon alignement de la

production des services (rendus) avec l’exigence de services (attendus) des directions

utilisatrices.

Les changements apportés au niveau de l’infrastructure globale (matériels, logiciels, réseaux,

contrats de services et documentation qui en découlent) sont clairement identifiés comme une

des principales causes d’arrêt non planifié au niveau des infrastructures. ITIL détaille donc les

moyens de répondre de la meilleure façon aux problèmes rencontrés (c’est un lien avec le

processus de gestion des incidents29) mais aussi de se prévaloir de conséquences indésirables

causées par l’application de changements.

La gestion des changements induite par le MCO est :

• L’enregistrement et le filtrage des demandes : cette première fonction a pour objet la

traçabilité des demandes de changements. Elles peuvent être acceptées ou rejetées

mais doivent toujours être enregistrées ; c’est la notion de RFC (Request For Change

ou Demande de changement).

• La gestion des priorités : fonction dont l’objet principal est d’assurer une planification

des changements à apporter en regard de leur impact sur l’architecture et surtout de

leur urgence.

• La gestion des catégories : la catégorisation des demandes de changement permet leurclassement à partir de l’estimation de l’effort à consentir pour les mettre en œuvre.

• La planification : comme pour toute activité bien menée, un planning de gestion des

changements donne une vision globale des interventions à mener. La planification

facilite aussi l’analyse d’impacts en cas d’intervention urgente à mener.

• Le développement, les tests et l’implémentation : comme pour les développements

applicatifs, la mise en œuvre d’un changement technique ne se fait pas sans un

minimum de précautions, de garantie. L’objet de cette fonction clé est d’attester de la

bonne maîtrise du changement (au sens procédures de mise en œuvre comme au sensde son effet) sur un environnement le plus proche possible de celui de production. La

disponibilité d’un environnement représentatif de celui de production relève plus

souvent d’un vœu pieux que d’une réalité avérée. Les coûts d’acquisition et de

détention d’un environnement de « pré-production » ont souvent du mal à trouver une

justification aux yeux de ceux qui tiennent les cordons de la bourse …

Ces fonctions clés relèvent d’une approche plutôt orientée « technique ». Même si ITIL est

clairement positionné du point de vue production (i.e. le sous-système opérant), le référentiel ne

29 Décrit dans « ITIL la gestion des services » -p 161-164





Imprimé le

néglige pas l’aspect de la relation avec les objectifs des directions métiers. Il le fait à travers trois

autres fonctions clé :

• L’analyse d’impact : cette fonction a pour objet de comprendre les effets de bord que

pourrait avoir une demande de changement du point de vue des directions métiersmais aussi des autres engagements inhérents à la continuité du service offert. Un

exemple pourrait être la mise à niveau, la « montée de version », d’un système de

gestion de base de données. Si une telle évolution n’est pas sans risque, vis à vis de la

mise en production programmée d’une nouvelle application, il sera

vraisemblablement opportun de la différer.

• L’approbation : le principe de cette fonction clé est d’appréhender, en plus de la partie

technique, les aspects coût et portée fonctionnelle de la demande de changement. Ces

compléments d’analyse contribuent à la qualification de la demande ; l’approuver ou

pas.

• Le comité de gestion des changements30 : au même titre qu’un projet, les changements

font l’objet d’une gestion digne de ce nom. C’est pourquoi il existe, en la matière, une

instance de type comité (comme il y a un comité de gestion de projet) composé de

membres permanents, ou non, qui procède aux arbitrages nécessaires : le CAB

(Change Advisory Board). Une autre de ses fonctions, qui rejoint en cela les

approches précédemment abordées de CobiT et CMMi, est l’analyse « a posteriori ».

C’est ce qui permet d’identifier et de comprendre les causes d’échecs et donc

d’améliorer le processus lui-même.

.). E8:*'*!!E*

L’aperçu que nous venons de faire de ces trois référentiels « de base » permet de se faire une

idée assez précise de leurs complémentarités et de leurs relations à la gestion de projet.

L’organisation informatique doit disposer des bonnes méthodes et des bons outils pour rassurer

ses clients et accroître sa performance.

Rappelons que CobiT couvre l’ensemble des activités du IT, c’est un outil de gouvernance

remarquable, cependant sa mise en œuvre est semée d’embûches.CMMi est une méthode d’organisation pour le développement et la maintenance d’applications

afin de fournir un code de qualité et la documentation associée.

Et ITIL est un référentiel de meilleures pratiques dans la gestion des services.

La norme ISO 9000, non décrite précisément ici, est cependant le socle sur lequel s’appuient les

autres référentiels. Elle est issue de l’industrie et est un standard en terme de gestion de la qualité

dans le cadre des « Exigences qualité du client », « Exigences de mise à jour et d’applications »,

« d’Augmentation de la satisfaction client » et « d’Amélioration continue des performances »

30 Ce comité de gestion du changement est présent chez Gaz de France sous le Comité de pilotage Opérationnel





Imprimé le

La figure ci-dessous représente une approche symbolisée par une maison des référentiels :

La maison des référentiels31

CobiT, CMMi, ITL constituent les briques essentielles du pilotage des Systèmes d’Information

et de leurs directions, en alignement avec la stratégie d’entreprise. Rappelons qu’il existe

d’autres référentiels, non étudiés ici.

Ils définissent les meilleures pratiques dans leurs domaines de compétences respectives. Ces

référentiels ne sont pas « étanches » les uns vis-à-vis des autres. Il existe des passerelles, des

points communs comme peut l’être le concept de niveau de maturité de CMMi abordé par CobiT

et ITIL.

Pour une entreprise mettre en pratique l’un, ou plusieurs de ces référentiels est une action à

prévoir sur du long terme.

Ainsi, un état des lieux des entreprises utilisant des méthodologies, indique les résultats

suivants32 sachant que certaines d’entres elles en utilisent plusieurs:

• 56% utilisent méthodes internes,

• 24% ISO 9 001,

• 16% PMI,

• 8% ITIL,

• 4% Autre,

• 2% CMM,

• 13% aucune méthode.

31 ITIL et la Gestion des Services –T.Chamfrault & C. Durand –p 28032 Ces résultats sont issus d’une enquête menée par IDC en 2004 auprès des DSI de 170 entreprises etadministrations françaises





Imprimé le

.. &!&

Ces référentiels permettent d’aborder le MCO d’applications de manière homogène avec une

même préoccupation : éviter et/ou maîtriser les perturbations potentielles de ce qui doit

préférablement rester le plus stable possible (l’application, les architectures applicatives ou lesinfrastructures du SI). Ils ont également pour but de simplifier, rationaliser, mutualiser les

infrastructures et les coûts induits.

Dans le cadre du MCO, il est donc possible de se référer à tout ou partie de ces référentiels,

étant entendu que leur mise en œuvre n’est pas un gage de qualité mais bien une aide pour

arriver à un résultat.

De fait, CobiT sera utilisé par la MOA pour gouverner son système d’information, ITIL par la

MOE pour assurer la meilleure « gestion de service » et le CMMi par la SSII pour maintenir le

produit dans des conditions opérationnelles optimales.Les processus de chacun de ces référentiels sont à utiliser en fonction des attentes des instances

de Gouvernance du SI et avec un objectif « opérationnel ». Rien ne sert de décrire des processus

qui ne seront pas utilisés parce que trop complexes à suivre au quotidien.





Imprimé le

7#

&&

Dans les chapitres précédents, nous avons défini ce qu’est le MCO, décrit l’évolution del’organisation des instances IT de l’entreprise en mettant en avant les différentes composants

internes et externes. Nous avons également analysé les différentes méthodologies qui existent, de

la gestion de projet aux référentiels complémentaires liés à la « Gouvernance des SI » en rapport

avec le MCO.

Dans ce chapitre, nous allons décrire les actions à réaliser lorsque le projet devient une

application à gérer en MCO, détailler les activités principales à mener en MCO et les acteurs qui

les portent avec le niveau de responsabilité associé.

" &3#

Le découpage en phase du projet, du lancement à la mise en production, va permettre d’avoir une

visibilité suffisante pour déterminer la période probable de passage en MCO. Une des tâches à

déclencher lors de la clôture du contrat du processus « Management des approvisionnements du

projet » du PMBOK est donc de prévoir le lancement du contrat suivant. On peut donc dire que

la tâche « Planifier la clôture du contrat de réalisation » implique obligatoirement le lancement

de la mise en œuvre d’un nouveau contrat. Ainsi, il est nécessaire de mettre en oeuvre les étapes

d’une procédure achat dont l’issu est la production et la signature d’un contrat.

" &*8

Quelque soit le type de contrat, de réalisation ou de TMA pour ce qui nous intéresse, les

entreprises sont soumises à cinq grands principes d’achats qui sont les suivants :

• Une mise en concurrence systématique de plusieurs fournisseurs,

• Une non-discrimination,

• Une transparence de la consultation,

• Une traçabilité des différents documents, intervenant,

•

Une Ethique.Pour répondre à ces principes, la procédure d’achat va se dérouler comme suit :

• L’appel d’Offre. Un appel d’offre décrit les caractéristiques de la prestation attendue

(de l’achat), les conditions de la consultation, c’est à dire les délais et les éléments de

réponses attendus qu’ils soient techniques ou financiers. En général, le formalisme du

cadre des réponses est également fourni. Les critères qui permettront de qualifier les

réponses les une par rapport aux autres sont définis simultanément et sont regroupés

sous forme de grille d’analyse,

• Le dépouillement. Les réponses de chaque fournisseur sont ensuite analysées

(dépouillées), les grilles sont remplies et sont prêtes à être comparées. En général, les

fournisseurs dont la note à l’écrit atteint un seuil défini à l’avance sont convoqués à





Imprimé le

une soutenance orale. La même mécanique est appliquée pour qualifier ces

soutenances orales.

• Le choix. Le fournisseur choisi est celui qui a la meilleure notation moyenne, écrite et

orale cumulées.La procédure d’achat peut donc se concrétiser par l’achat de la prestation demandée formalisée

par un contrat.

"" &

Ainsi, un contrat est, en général, composé d’un lot ferme (avec la description des réalisations

impératives du contrat) et un ou plusieurs lots optionnels qui ont pour objet de prévoir à l’avance

les actions complémentaires éventuelles. Comme il n’est pas toujours aisé d’anticiper ces

actions trois ou quatre années à l’avance, le caractère optionnel de ces lots permet de prendre la

décision de les souscrire ou non une fois l’étape de réalisation terminée.

Dans le cadre plus précis d’un contrat de réalisation, il est possible de prévoir la rédaction d’un

lot optionnel de MCO avec pour cible de préparer la ou les premières années de vie du produit.

Pour qu’il soit utilisable, la description des activités, des responsabilités et des devoirs respectifs

de chaque instance doivent être détaillées. En général, ce n’est pas le cas puisque l’accent est mis

sur la phase de réalisation au détriment bien naturel du MCO. Dans ce contexte, le lot de MCO

est à prendre comme un moyen de prolonger l’extension de garantie due par l’intégrateur et

permettre à la DSI de la société de mettre en place l’équipe adaptée au maintien en condition

opérationnelle du produit, d’assurer les périodes de recouvrement nécessaire au transfert de

compétences et éventuellement de mettre en place les organisations pour fédérer les services.

L’appel d’offre pour assurer la TMA peut être lancé plus sereinement que s’il avait fallu le

paralléliser avec la phase de mise en production du projet.

En effet, le lancement d’un produit est toujours une phase suffisamment délicate pour quelle soit

menée indépendamment de toutes contraintes externes au projet.

") 8&

Dans tous les cas, cette phase permet d’assurer la transition entre la fin du projet et le début ducycle de vie du produit. Il est bien sûr nécessaire de prévoir un contrat de maintien en condition

opérationnelle spécifique où tous les aspects de maintenance (acteurs, actions, délais, moyens,

contraintes, sanctions) seront décrits en détail.

Dans le cas où le maintien en condition opérationnelle serait sous traité, le contrat à établir avec

le prestataire est un contrat de TMA.

Le passage en « MCO » signe donc théoriquement la fin du mode projet. Ceci se traduit très

concrètement par une démobilisation des équipes MOE, surtout lorsqu’elles s’appuient sur des





Imprimé le

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

contractualisation du lot optionnel de MCO peut permettre une démobilisation plus en douceur

de cette équipe.

Toutefois, c’est bien à cette période qu’il faut s’interroger sur la manière dont cette phase devrase dérouler (qui va assurer la gestion de services), préparer l’organisation adaptée à mettre en

place (interne et externe à la MOE du SI de l’entreprise), considérer les organisations existantes

et éventuellement y adhérer. En tout état de cause, la préparation du MCO du produit est à

construire.

Dans le cas où il serait nécessaire de faire appel à un ou plusieurs prestataires pour assurer les

actions d’assistance à maîtrise d’œuvre, d’expertise, d’assistance utilisateurs, de recette de

versions, d’expert technique en développement de logiciel et de gestion de l’exploitation

quotidienne, il faudra préparer et lancer un ou plusieurs appels d’offre pour choisir celui quiassumera les différents services. Pour la partie de « MCO » proprement dite, l’appel d’offre à

mener sera destiné à des SSII et devra tenir compte de tous les éléments détaillés dans le

chapitre concernant les « objectifs du MCO ».

) #

La phase de MCO va mobiliser également des acteurs MOA et MOE avec des profils souvent

différents de la période « projet ».

) #

Comme indiqué dans les chapitres précédents, le « maître d’ouvrage » est l’entité porteuse du

besoin (entreprise, direction, service). Cette responsabilité ne change pas pour la phase de

gestion et de suivi de l’application.

La MOA est en général représentée à deux niveaux distincts :

• Le niveau des utilisateurs regroupés autour d’un comité de suivi de l’application (ou

d’un club utilisateurs, un bon moyen de créer une entraide efficace) ; l’objectif ici est

de partager sur le caractère utilisable du produit : quels en seraient les axes

d’amélioration, ce qui est plus de l’ordre de l’anomalie de fonctionnement que del’évolution…

• Le niveau de décision de la MOA qui statut sur le bien fondé d’évolutions majeures en

terme de nécessité et de ROI. Ce deuxième niveau aura la charge de gérer le

portefeuille des demandes d’évolution en terme de recevabilité et de priorité. En

d’autres termes, elle aura la responsabilité de définir le contenu d’une nouvelle

version d’un produit, sa date de livraison en tenant compte des contraintes techniques

de mises à disposition et d’utilisation quotidienne.

33 Un contrat au forfait est un contrat « avec engagement de résultat » le produit est le livrable principal. En cas dedésaccord sur la qualité de ce livrable, la « charge de la preuve » s’il y a eu manquement, est à fournir par leprestataire





Imprimé le

La MOA est donc le contact privilégié des utilisateurs finaux. A ce titre, elle sera aussi

l’interface entre la MOE et les utilisateurs lors de la recette d’une nouvelle version de

l’application.

)" #

Pour la MOE, la grande différence entre la gestion de projet et le MCO réside dans le nombre de

personnes mobilisées et la manière dont les activités sont réparties.

Le pilotage des travaux confiés à la DSI pour le MCO d’un système informatique est assuré par

le chef de produit. Il est en général accompagné d’une équipe et s’appuie sur des contrats

externes.

Les éléments suivants sont le résultat d’une réflexion consolidée à partir de plusieurs modes

d’organisations existantes où les responsabilités hiérarchiques et fonctionnelles cohabitent etn’impactent ni les rôles ni les responsabilités individuels.

& ('%

Il est responsable des applications dont il a la charge. Il définit le calendrier des évolutions du

système.

A ce titre, son domaine d’activité est le suivant :

• Il pilote les appels d’offre liés à des renouvellements de contrats ou à de nouveaux

contrats de prestation,• Il gère les contrats et les budgets des prestations externes,

• Il pilote la prestation de TMA et valide les lotissements (versions),

• Il gère le respect des livraisons planifiées pour chaque version,

• Il valide les devis et gère les commandes d’approvisionnement,

• Il est garant vis à vis de la MOA de toutes les actions liées à la gestion des

changements, des incidents, des indisponibilités,

• Il pilote et arbitre les activités du gestionnaire opérationnel, du ou des experts

fonctionnels,• Il assure le reporting de l’activité de l’équipe vis à vis du responsable de domaine.

Certaines de ces activités peuvent être réalisées par délégation. La taille humaine de l’équipe

dépendra de l’importance de la ou des applications à maintenir.

34 Au CSI de Gaz De France, c’est le POA : Pilote Opérationnel d’Application





Imprimé le

& *$&

Il a la responsabilité du fonctionnement quotidien de l’application. Il assure et rend compte du

service rendu.

Si on se réfère au livre sur le « Support des Services » d’ITIL, l’objectif est bien de répondre

aux problèmes de gestion opérationnelle (traiter les erreurs connues) et d’assurer la production

des services rendus en tenant compte de l’exigence des services attendus par les entités métiers

utilisatrices ; A ce titre,

• Il prend en charge l’analyse des sollicitations36 utilisateurs reçues et enregistrées par

l’Assistance Utilisateur (AU). Il est le contact privilégié de la cellule AU de la DSI,

• Il est responsable du résultat des analyses faites en cas d’incident d’exploitation.

L’analyse des causes et des conséquences doit permettre de rétablir rapidement la

situation. La traçabilité des actions doit être menée pour capitaliser en cas de récidive.Des actions de maintenance corrective pérennes doivent être planifiées auprès de la

TMA pour éviter que l’incident ne se reproduise,

• Il s’assure que les travaux concernant les corrections de base de production sont

coordonnés entre les différents intervenants,

• Il synthétise les sollicitations et communique sur leur avancement à la MOA,

• Il assure la communication (reporting) en rendant compte de la nature (sollicitations,

incidents, etc.) et de leur nombre respectif vis-à-vis du Responsable d’application

mais aussi de la MOA. L’un des objectifs ici est de diminuer le nombre d’appels enidentifiant leur origine : de nouvelles formations peuvent être à planifier, une

attention particulière lors de la mise en production de nouvelles versions de

l’application sont à initier, (actions préventives, etc.).

&! #(!

Il a la responsabilité des demandes d’évolution des applications dont il gère le portefeuille de

réalisation.

Il réceptionne les demandes d’évolution de la MOA ; ces demandes sont fournies sous forme de« cahier des charges » ou d’expression de besoin ».

La MOA attend en retour une « étude de faisabilité » avec les impacts fonctionnels, techniques et

organisationnels s’il y en a, un coût financier prévisionnel et une charge de réalisation.

L’ensemble de ces informations est indispensable pour statuer sur la priorité des évolutions en

fonction d’un budget et d’impératif de disponibilité.

35 Selon le cas, il peut être appelé « Responsable de la Performance » ou « Gestionnaire Opérationnel »36 Une sollicitation est une demande d’aide à l’utilisation, une interrogation face à un dysfonctionnement del’application, etc.





Imprimé le

Ces demandes relèvent du processus « Gestion des changements » de CobiT qui permet de

décrire en commun accord, les rôles, les responsabilités et les livrables à répartir entre la MOA et

la MOE. En phase de MCO, le rôle de l’expert fonctionnel devient majeur.

A ce titre,• Il synthétise l’ensemble des demandes d’évolution et propose des versions cohérentes,

• Il rédige les études de faisabilité associées aux cahiers des charges et sollicite la TMA

pour les charges et les coûts prévisionnels de réalisation. Il met en avant d’éventuelle

connexion et/ou interférence avec d’autres applications et mutualise les analyses le

cas échéant,

• Il anime les ateliers métiers en fonction des demandes d’évolution en cours,

• Il rédige les spécifications générales destinées à la TMA pour prise en compte de

l’évolution et valide en retour les spécifications détaillées correspondantes rédigéespar la TMA,

• Il organise les recettes des versions et coordonne les activités liées aux livraisons

correspondantes avec le sous traitant en charge de l’intégration et de la recette à qui il

fournit le cahier de recette associé,

• Il rend compte de l’avancement des travaux de recette,

• Il analyse

o La qualité des livraisons en intégration/recette avec des indicateurs liés aux

nombres d’anomalies (bloquantes, majeures, mineures ou de confort) détectéespar livraison,

o la qualité des recettes avec des indicateurs qui comptabilisent les anomalies

détectées après la mise en production,

• Il est responsable de la qualité de la version livrée aux utilisateurs finaux pour recette,

• Il organise les recettes métiers,

• Il assure également le reporting concernant l’avancement sur les demandes

d’évolution en cours et sur l’avancement de réalisation des versions.

& !,#

Les autres acteurs de la MOE sont liés à la TMA, à l’AU et à la recette.

Leurs périmètres d’activités ont été définis lors de la signature du contrat de TMA d’une part et

de services pour l’AU et la recette.

Le responsable d’application est à même de qualifier leur prestation respective à l’aide

notamment des différents reporting fournis par son équipe.

Ici, l’aspect contractuel est mis en avant. La prestation fournie doit correspondre à la prestation

décrite dans les contrats.





Imprimé le

. &%&#

La phase de MCO comme celle de projet vit au rythme des instances de pilotage et de

coordination.

En effet, un des impacts de la formation d’équipe hétérogène de MCO (instance cliente, instance

AMOA, instance AMOE et instance MOE) est qu’il nécessite la mise en place d’instances de

pilotage et de coordination. Au cours de ces réunions, tous les points importants sont abordés,

débattus le cas échéants, statués et tracés.

. &&+*8&!5*!&3

La méthode de gestion de projet, comme indiqué dans les chapitres précédents, doit pouvoir être

appliquée également à la phase MCO lorsqu’il s’agit de gestion du changement. Ces

changements doivent être maîtrisés et répartis dans des versions. Ce constat est consécutif au faitqu’il est primordial d’atténuer les points faibles de la gestion projet, points accentués dans le

cadre du MCO.

En effet, en termes de méthodes, on touche aux limites de validité de celles employées sur les

projets. Ces faiblesses sont, lorsqu’elles existent, liées à l’absence de véritable structure projet :

• L’évaluation des charges à l’issue de la spécification : il est bien rare que l’on travaille

autrement qu’à « dire d’expert » pour évaluer les charges. La mise en route d’un

processus d’achat au forfait est trop lourde et finalement c’est le client qui s’engage,

rarement le prestataire,• Les tests : trop longtemps les parents pauvres des projets, restent le maillon faible tant

il est difficile de constituer et de maintenir un jeu de tests qui serait automatiquement

passé à chaque mise en service avec production automatique des écarts et des

anomalies. Ce point est en cours d’étude37 notamment par la mise au point de contrat

précis de recette passé avec des sous-traitants. Même si l’aspect contractuel doit

préciser les attentes réelles de la société et spécifier des indicateurs mesurables et

mesurés. La mise en place de structures et d’outils de tests automatisés reste un point

fort à ne pas négliger.

• L’intégration : la mise en production est souvent lourde et compliquée, elle exige desressources mobilisées en mode projet mais pas toujours disponibles en maintenance.

Cet aspect doit également être spécifié précisément avec le sous-traitant et être

contractualisé pour que ce dernier puisse mettre en place les actions nécessaires.

• La validation par les utilisateurs : elle se fait bien souvent en situation d’utilisation

réelle, faute de temps et d’environnement ad hoc. Ce point là est plus difficile à

résoudre. En effet, il est également possible de contractualiser ces éléments avec la

MOA, mais pour un utilisateur métier, il est toujours délicat de se dispenser de

37 Au PCL, et plus particulièrement à la cellule Recette de la TRA, des essais de suivi qualitatifs de tests sont encours notamment sur l’application VICTOR.





Imprimé le

l’activité quotidienne. Sur ce point, l’application des processus CobiT de

« Gouvernance du SI » et notamment de la procédure « Acquisition des applications »

peut être une solution. En tout cas, c’est à la MOA de régler ce problème vis-à-vis des

métiers. Il reste à la charge de la MOE de planifier les dates de recette et de ne pasles respecter.

Un des leviers pour diminuer ces faiblesses est de faire attention à ne pas multiplier le nombre de

versions sur une année. En effet, la multiplication des versions dégrade considérablement le

processus aval de la mise en production en relation avec les utilisateurs.

Cet inconvénient combiné à la difficulté de trouver des «fenêtres» de changement dans des

plannings de production souvent surchargés conduisent également à militer pour regrouper les

modifications dans une même version. Un nombre de quatre versions par an semble raisonnable

ce qui permet d’avoir un volume de changement conséquent quasiment assimilable à un projet etqui justifie la mise en place d’une structure adaptée et l’application de la méthode projet.

." &*!*+6*,&

Ces procédures concernent les points sensibles du MCO d’une application et ont été abordés

précédemment, elles concernent :

• La gestion du portefeuille des évolutions qui met en avant la relation « MOA-MOE-

TMA-Recette-AU »,

• La gestion des sollicitations qui met en avant la relation « MOA-AU-MOE »

o Poser tout type de questions concernant le fonctionnement des applications,

o Demander les codes accès aux applications,

o Signaler des anomalies,

o Demander des traitements particuliers (type extraction de données),

• La gestion des incidents qui met en avant la relation « MOA-AU-MOE-TMA »,

• La gestion des configurations : cette gestion est en générale abordée d’un point de vue

centre de développement ; cependant la DSI doit également pouvoir gérer ses

configurations et gérer les interactions entre les différents produits à maintenir en

condition opérationnelle. &>&&4!?

Les actions suivantes sont ou ont été menées avant la fin du contrat initial de réalisation, lot

optionnel inclus de MCO éventuellement :

1. Etablir un contrat de TMA : tout doit être défini précisément, l’idéal pour une DSI est de

posséder des contrats de TMA « type » qui précise les niveaux de services attendus et les

indicateurs pour les mesurer (délai de correction d’une anomalie bloquante, majeure,

mineure ; nombre d’anomalies détecté suite à la livraison d’une nouvelle version, etc.),





Imprimé le

2. Etablir un contrat de TRA (Tierce Recette Applicative) : définir les activités de cette

cellule (rédaction des scénarii de test de non régression, de versions, les mettre à jour) ;

définir un délai pour réaliser la recette de la version (au prorata du nombre de jours de

réalisation de la version par exemple), définir des indicateurs de qualité de la recette ensuivant les anomalies de production, etc.,

3. Etablir un contrat d’assistance utilisateur (AU) : c’est le centre de service, le point

névralgique de la relation client, ses activités sont orientées clients, il doit tout mettre en

œuvre pour informer au plus vite de sa capacité ou non à répondre à une demande. Le

contrat doit également préciser le niveau d’assistance apporté par l’AU aux clients. Les

indicateurs vont mesurer les délais entre la prise d’appel et la réponse apportée au client,

etc.,

4. Mettre en place un mode de gestion collaboratif avec la MOA et préciser au minimum lemode de communication pour :

a. La gestion des changements,

b. La gestion des incidents,

c. L’acquisition des applications,

5. Mettre en place un mode d’échange avec les différentes instances d’exploitation.

( &!&

Passer d’un projet à un produit exploitable et assurer son maintien en condition opérationnelle

est une tâche semée d’embûches.

La MOA devra mettre en place les éléments induits par le processus de « Gouvernance du SI » et

notamment gérer efficacement le portefeuille des évolutions.

La MOE de la DSI, fournisseur interne, devra quant à elle

• Mettre en place les processus de « Centre de services » pour être l’interface principale

entre la DSI et les utilisateurs, être le garant du respect des engagements de services,

mettre les moyens pour piloter les événements (incidents, demandes), fournir uneinterface avec les processus de production, proposer une plate-forme d’accueil de

services destinée aux utilisateurs, etc.,

• Anticiper la recherche d’une TMA quelques mois avant la fin de garantie ou la fin du

lot de MCO souscrit éventuellement avec le contrat de réalisation. De plus, il est

impératif de réfléchir et mettre en place une équipe chargée du MCO du produit

concerné.





Imprimé le

( 0

( *!'!*

L’objectif de cette étude consistait à mettre en avant les difficultés portées par la gestion enMCO d’une application, d’identifier, de définir et de mettre en œuvre l’ensemble des étapes et

des actions de la dernière phase du projet à la première phase de maintien en condition

opérationnelle du produit associé.

Pour ce faire, nous avons dans les précédents chapitres :

• Donné un sens à l’acronyme « MCO » en terme de contenu d’activité à réaliser et de

but à atteindre,

• Tracé et décrit l’évolution de l’organisation des instances informatiques de l’entreprise

et situé la période dans laquelle ces instances évoluent actuellement en mettantl’accent sur les axes et les actions stratégiques,

• Mis en avant le fait que beaucoup d’entreprises conservaient le pilotage de leurs

projets et de leurs applications mais avaient ou allaient externaliser leurs instances

techniques et utilisaient les services des SSII,

• Analysé les méthodologies tant en terme de gestion de projets que de référentiels mis

à disposition par différents types d’organismes de normalisation ou d’instances

gouvernementales,

•

Identifié également, que le cycle de vie du projet est une phase répétitive de la vie duproduit gérée en MCO

• Identifié, parmi les référentiels complémentaires ceux qui étaient les plus utilisés en

tenant compte des objectifs ciblés, ce qui a eu pour effet d’associer CobiT à la MOA

pour la « Gouvernance de son SI », ITIL aux instances informatiques Interne des

sociétés notamment pour la gestion des services et CMMi à la production industrielle

de logiciel,

• Mis en avant l’utilité pour les entreprises d’utiliser les méthodologies adaptées à

chaque situation selon qu’elle est « IT » ou « Métier ».

(" &!&%**!

Au vu du résultat de ces analyses, il est avéré que la maîtrise du processus de maintien en

condition opérationnelle d’un produit est une phase primordiale pour l’entreprise, comme l’a été

au cours des années 80, l’implantation d’une méthodologie de projet. L’impact est visible au

niveau global de l’entreprise, des instances métier à l’instance informatique. En effet, pour les

utilisateurs, un processus sous contrôle, propage un sentiment de sécurité quant à la fiabilité des

outils IT mis à disposition. Les relations, entre les différents acteurs et les actions menées au

sein des sociétés se sont clarifiées, décloisonnées et formalisées.

Attention, toutes ces méthodologies doivent être adaptées aux spécificités de chaque société et

non l’inverse. En effet, ce sont avant tout des moyens qui permettent de mieux travailler





Imprimé le

ensemble. Elles décrivent les bonnes pratiques à mettre en œuvre pour fiabiliser, industrialiser et

donc augmenter la rentabilité des IT. Cependant leur mise en œuvre ne garantit en rien un IT

performant. Rien ne sert de vouloir maîtriser toutes les phases du processus simultanément,

l’accent est à mettre sur celles qui induisent trop d’insatisfactions à savoir la gestion des serviceset plus précisément, la « Gestion des incidents » et la « Gestion des évolutions ».

() &!&&!

Cette étude couplée à la mission effectuée au PCL a mis en évidence la nécessité d’organiser la

phase de transition entre le projet et le MCO du produit en termes :

• Contractuel, c’est à dire s’assurer que les activités de maintenance sont prévues et que

le relais entre le contrat de réalisation et de TMA est planifié. Ainsi, pour

l’application VICTOR, une année de MCO via le contrat de réalisation a été souscrit.

Pour que la TMA soit opérationnelle à l’issu de cette prolongation, le cahier descharges, pièce indispensable au lancement d’un appel d’offre, sera rédigé en

septembre .... avec notamment l’ambition d’être suffisamment précis et complet pour

pouvoir être capitalisé au niveau du domaine (gestion transversale des problématiques

communes à tous les contrats de service d’ITIL),

• De communication entre la MOE et le PCL ; les processus liés à la « Gouvernance du

SI » issus de CobiT et plus particulièrement les procédures « Acquérir des

applications et en assurer la maintenance », « Gérer les changements » , « Installer et

valider les solutions et les modifications », « Gérer les problèmes » ont été adaptées à

la gestion du MCO de VICTOR et des applications futures à maintenir du domaine.

Les comités de coordination d’une part et de pilotage d’autre part sont en place.

• D’organisation de l’équipe de MCO ; sur ce point, les activités à assumer sont

identifiées et sont bien orientées vers la satisfaction des utilisateurs, la clarification

des rôles, l’amélioration de la communication. L’accent est mis sur la gestion des

changements et notamment sur l’enregistrement et le filtrage des demandes qui doit

se faire en un point unique, sur la gestion des priorités avec l’objectif d’organiser et

de planifier les versions et sur la recette. Les indicateurs pour mesurer la performance

sont en cours de construction.

La Cellule Opérationnelle du PCL a, entre autre, en charge de décliner et de contrôler le respect

des principes du CSI. A ce titre, les processus mis en place entre la MOA et le PCL, ainsi que la

gestion et le suivi des demandes d’évolutions et de gestion des incidents, vont être suivis et revus

périodiquement à la cellule Opérationnelle selon les retours d’expériences.





Imprimé le

@ @ @ @

7

AFAI Association Française de l’Audit et du conseil Informatiques

AFITEP Association Francophone de Management de Projet

AFNOR Association Française de NORmalisation

ANSI American National Standards Institute

AU Assistance Utilisateur

CAB Change Advisory Board

CIRAU Cellule Intégration Recette Assistance Utilisateur du CSI-PCL

CMMI Capability Maturity Model Integration. Méthode qui vise à porterl’entreprise au niveau de compétence (ou maturité) qui lui permet deréaliser correctement ses projets. CMMI est plutôt positionné sur lamaturité du développement logiciel

COBIT Control Objectives for Information and related Technologies.Référentiel méthodologique qui traite de la gouvernance.

CSI Centre de Services Informatiques

DGI Direction des grandes infrastructures de GDF SUEZ

DoD Département américain de la défense

GRDF Distribution aux particuliers – Direction GDF SUEZ

GRTgaz Transport de gaz (grosses canalisations) – Filiale GDF SUEZ

ISACA Information Systems Audit and Control Association

IT Governance Gouvernance du Système d’information

ITGI Information Technology Governance Institute

ITIL IT Infrastructure Library

MCO Maintien en Condition Opérationnelle

MOA Maîtrise d’ouvrage

MOA-D MOA Délégué – Mission d’expertise par délégation du directeur





Imprimé le

MOA-O MOA Opérationnelle- responsable de chaque domaine métier

MOA-S MOA Stratégique- Assiste le directeur pour les décisions relatives au SI

MOE Maîtrise d’œuvre

PCL Pôle Clients, entité du CSI

PCS Pouvoir Calorique Supérieur exprimé en kwh/m3

Est déterminé à l’entrée (alimentation) par analyse chromatographiquedes différents composants du gaz naturel (méthane, propane, butane,etc.) détermine la qualité du gaz

Il calcule la quantité d’énergie que dégage un m3 de gaz normal enbrûlant.

PMBOK Project Management Body Of Knowledge pour Corpus desconnaissances en management de projet

PMI Project Management Institute

PSI Pôle Système Industriel, entité du CSI

ROI Return Of Investment

SEI Software Engineering Institute ou Institut de l’Ingénierie Logiciel

SIMONE-GRT Application qui détermine les PCS aux points de livraison du réseau parle biais d’un algorithme de reconstruction, et de permettre ainsi deminimiser les coûts d’équipement et d’exploitation liés auxchromatographes supplémentaires à installer, tout en respectant lesfutures exigences réglementaires

SINDI Système d’INformation DécisIonnel

SSII Sociétés de Services en Ingénierie Informatique

SI Système d’Information

TMA Tierce Maintenance Applicative

TRA Tierce Recette Applicative

VICTOR Validation des Index de Comptage et des Télétransmissions etOrganisations des Restitutions

Application qui gère les données de comptage et effectue tous lestraitements sur ces données. Sa principale fonction est d’élaborer et demettre à disposition des autres applications les mesures horaires et

journalières en énergie et en volume pour tous les points de comptage(télé-transmis, à relève mensuelle ou fictive)





Imprimé le

" A7

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 Managementde Projet

http://www.afnor.org/ Association Française de NORmalisation

http://www.g9plus.org/interface/CR_ITGov_5Juil

_2006.pdf

L’ IT Gouvernance et panorama qualitéversus ITIL, CMMI & Cobit :quel avantagepour la DSI ?

http://www.volle.com/travaux/moa_du_si.htm Prospective de la maîtrise d'ouvrage

(cf. copyright : Michel Volle)

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

est rédigée par Christian NAWROCKI et

publiée sur internet à l’adresse

http://www.fr.capgemini.com/about/histoire/ Histoire de CapGemini

www.commentcamarche.net Document intitulé « Maîtrise d’ouvrage / Maîtrise d’œuvre » issu de Comment ça

marche

) 7

AFAI, COBIT « Objectifs de contrôle de l’Information et des technologies associées », 4ème édition traduite en français.

GEORGEL F, « IT Gouvernance », Dunod 2006.

PMI, PMBOK « Corpus des connaissances en management de projet », traduction française de la3ème édition.SIDI J, OTTER M, HANAUD L, « Guide des certifications SI », Dunod 2006

CHAMFRAULT T, DURAND C, « ITIL et la gestion des services », Dunod 2006

BENNASAR M, « Plan de continuité d’activité et système d’information », Dunod 2006

ALCON D, BOUTEL J-S, CARBONEL M, CHASSEFEIRE M-A, CLEUET F, MESDON B,MILOT D, SALZMAN C, “Management de projet I.T”, Weka 2003.

La maintenance du système d'information, par Fabien Cleuet, article Informatique

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

M2

Documents

Transcript of M2