LB Aubay Referentiels Qualite Gestion de Projet 2011

Rfrentiels Qualit & Gestion de Projet
Panorama et exemples dapplication

Par Cyrille Devaux I Rachid El Ouarghani I Thibault Estran

Livre Blanc Aubay - Rfrentiels Qualit et Gestion de Projet - 2

Pour tous renseignements complmentaires : cdevaux@aubay.com ou pesteves@aubay.com
2011 AUBAY. Tous droits rservs

Les informations contenues dans ce document reprsentent le point de vue actuel dAubay sur les sujets exposs, la date de publication. Dans la
mesure o les diteurs cits doivent sadapter aux conditions changeantes du march, Aubay ne peut pas garantir lexactitude des informations
prsentes aprs la date de publication.

Les noms de produits ou de socits dans ce document peuvent tre les marques dposes de leurs propritaires respectifs.

A PROPOS DES AUTEURS

Cyrille DEVAUX, Directeur chez Aubay Management
Titulaire dun master en Intelligence artificielle, reconnaissance des formes et robotique, et dun Executive MBA (HEC), Cyrille
Devaux est le plus globe-trotter des experts en technologies et systmes dinformation Aubay.
Aprs une adolescence passe Abidjan, Cyrille effectue son service civil lEcole Nationale des Sciences de lInformatique Tunis
(Tunisie). Puis il dbute sa carrire en 1992 la Dlgation Gnrale pour lArmement. En 1995, il part en mission chez TELMEX au
Mexique. Cest chez Marben, devenu Atos, quil rencontre Christian Aubert (plus tard, fondateur du Groupe Aubay) et Franois
Hisquin. En 1998, en collaboration avec ces derniers, il cre OCTO Technology, cabinet spcialis dans larchitecture de systmes
dinformation. En 1999 ouvre lagence espagnole dOCTO jusquau rachat du cabinet par le Groupe Aubay, quil rejoint en 2002.
Depuis 2007, Cyrille Devaux occupe le poste de Directeur au sein de la structure de conseil : Aubay Management.

Rachid EL OUARGHANI, Consultant Aubay Management
Aprs un diplme dingnieur IPSA obtenu en 2001, Rachid dcroche un poste de consultant chez Thales. En 2003, il dcide de
partir aux USA afin denrichir son parcours en effectuant un MBA en finance et stratgie. Ce MBA lui a permis dintgrer en 2005
la socit amricaine TIBCO o il a exerc en tant que Directeur de projets. Attir par la refonte des processus 6 sigma et conduite
de changement, il obtient le poste de Directeur projets au sein de la socit amricaine Meridium base Duba.
Dbut 2010, Rachid El Ouarghani rejoint lquipe Aubay Management.

Thibault ESTRAN, Consultant Aubay Management
Jeune collaborateur dAubay Management, Thibault Estran est titulaire dune double comptence en ingnierie et en marketing. Il
effectue ses dbuts dans lindustrie automobile o il dcouvre les prceptes de lamlioration continue et du Lean Management. Il
dveloppe par la suite ses comptences en gestion de projet dans laronautique. Trs intress par le secteur des systmes
dinformation, il intgre Aubay Management en tant que consultant afin de prendre en charge des missions dorganisation et de
management de projets.

Ont galement particip la constitution de ce libre blanc : Luc BERNARD, Antoine LAURENT, Nicolas ZUMINO, Jean-Baptiste
POTOKAR, Franck BERMAN et Emeline GUEZELLO.


SOMMAIRE

1 INTRODUCTION ..................................................................................................................................................................................................... 9
2 LE PROJET ET SES ACTEURS ................................................................................................................................................................................. 10
2.1 Le Projet ..................................................................................................................................................................................................... 10
2.2 Principales activits inhrentes la gestion de Projet ............................................................................................................................... 11
2.2.1 Gestion des risques ........................................................................................................................................................................... 11
2.2.2 Gestion budgtaire ............................................................................................................................................................................ 13
2.2.3 Planification ...................................................................................................................................................................................... 14
2.2.4 Reporting .......................................................................................................................................................................................... 15
2.2.5 Contrle qualit ................................................................................................................................................................................ 16
2.2.6 Gestion des engagements du projet ................................................................................................................................................. 16
2.3 Principaux acteurs de la gestion de projet. ................................................................................................................................................ 16
2.3.1 Directeur de Projet ............................................................................................................................................................................ 18
2.3.2 Chef de Projet ................................................................................................................................................................................... 19
2.3.3 Project Manager Officer .................................................................................................................................................................... 19
2.4 Gouvernance de projet .............................................................................................................................................................................. 20
3 PRINCIPAUX RFRENTIELS QUALITE .................................................................................................................................................................. 23
3.1 ISO 9001 ..................................................................................................................................................................................................... 24
3.1.1 Quest-ce que ISO 9001, exactement ? ............................................................................................................................................. 24
3.1.2 Quest-ce que nest pas ISO 9001 ? ................................................................................................................................................... 24
3.1.3 Que sattend-t-on trouver dans une entreprise certifie ISO 9001 ?.............................................................................................. 24
3.1.4 Sur quels principes repose la gestion de la qualit ISO 9001 ? .......................................................................................................... 25
3.1.5 Comment seffectuent les contrles ? ............................................................................................................................................... 26
3.2 CMMI (Capability Maturity Model Integration) ......................................................................................................................................... 26
3.2.1 Quest-ce que CMMI exactement ? ................................................................................................................................................... 26
3.2.2 Quest-ce que nest pas CMMI ? ....................................................................................................................................................... 27
3.2.3 Comment maintenir son niveau de maturit ?.................................................................................................................................. 27
3.2.4 Que sattend-t-on trouver dans une entreprise dont un service est valu selon CMMI ? ............................................................ 28
3.2.5 Quelles comptences pour mettre en uvre des activits ? ............................................................................................................ 28
3.2.6 Comment seffectuent les contrles ? ............................................................................................................................................... 28
3.3 ITIL (Information Technology Infrastructure Library) ................................................................................................................................. 29
3.3.1 Qu'est ce qu'ITIL ? ............................................................................................................................................................................. 29
3.3.2 quoi sert-il ? ................................................................................................................................................................................... 29
3.3.3 D'o vient ITIL ? ................................................................................................................................................................................. 30
3.3.4 Utilisation d'ITIL................................................................................................................................................................................. 30
3.3.5 Quels sont les bnfices de la dmarche ITIL ? ................................................................................................................................. 30
3.3.6 Les processus ITIL V2 ......................................................................................................................................................................... 31
3.3.7 ITIL en 3 points .................................................................................................................................................................................. 31
3.4 Rfrentiels et certification ........................................................................................................................................................................ 31
3.5 Conclusion .................................................................................................................................................................................................. 32
4 MTHODOLOGIES DOPTIMISATION DES PROCESSUS ........................................................................................................................................ 33
4.1 Mthodologies de niveau Stratgique ....................................................................................................................................................... 33
4.1.1 Balanced Score Card .......................................................................................................................................................................... 34
4.1.2 Six Sigma ........................................................................................................................................................................................... 37
4.1.3 Kaizen ................................................................................................................................................................................................ 39
4.1.4 Lean Management ............................................................................................................................................................................ 40
4.1.5 Comparaison rapide .......................................................................................................................................................................... 47
4.2 Mthodologies de niveau Tactique ............................................................................................................................................................ 48
4.2.1 Introduction au cycle de vie du projet ............................................................................................................................................... 48
4.2.2 Modles traditionnels de dveloppement logiciel ............................................................................................................................ 51
4.2.3 Modles agiles de dveloppement logiciel ....................................................................................................................................... 53
4.2.4 Conclusion sur les modles ............................................................................................................................................................... 61
4.3 Mthodologies et certification ................................................................................................................................................................... 62
4.4 Un changement ? Un accompagnement ! .................................................................................................................................................. 62

5 EXEMPLE DAPPLICATIONS .................................................................................................................................................................................. 67
5.1 Mise en place de rfrentiel Qualit .......................................................................................................................................................... 67
5.1.1 Qui est Aubay du point de vue des rfrentiels ? .............................................................................................................................. 67
5.1.2 Comment choisit-on un rfrentiel chez Aubay SA ? ........................................................................................................................ 67
5.1.3 Comment utilise-t-on un rfrentiel chez Aubay SA ? ....................................................................................................................... 68
5.1.4 Comment seffectue la mise en uvre ? ........................................................................................................................................... 69
5.2 Certification CMMI ..................................................................................................................................................................................... 70
5.2.1 Naissance dune volont ................................................................................................................................................................... 70
5.2.2 De CTRL CMMI ................................................................................................................................................................................ 70
5.2.3 Les premiers pas vers CMMI ............................................................................................................................................................. 70
5.2.4 Le vcu Aubay ................................................................................................................................................................................... 71
5.3 Un projet dvelopp en mode SCRUM ...................................................................................................................................................... 71
5.3.1 Contexte du projet ............................................................................................................................................................................ 71
5.3.2 Le choix de SCRUM ............................................................................................................................................................................ 72
5.3.3 Points cls ......................................................................................................................................................................................... 72
5.3.4 Les facteurs qui ont permis le succs de la mthode ........................................................................................................................ 73
5.3.5 Difficults et ajustements ................................................................................................................................................................. 73
6 CONCLUSION ...................................................................................................................................................................................................... 75
7 DTAIL SUR LES PROCESSUS ITIL V2 .................................................................................................................................................................... 76
7.1 Les processus du Soutien des Services ....................................................................................................................................................... 76
7.1.1 Le Centre de Services (Service Desk) ................................................................................................................................................. 76
7.1.2 La Gestion des Incidents (Incident Management) ............................................................................................................................. 76
7.1.3 La Gestion des Problmes (Problem Management) .......................................................................................................................... 77
7.1.4 La Gestion des Changements (Change Management) ....................................................................................................................... 78
7.1.5 La Gestion des Mises en Production (Release Management) ............................................................................................................ 79
7.1.6 La Gestion des Configurations (Configuration Management) ........................................................................................................... 79
7.2 Les processus de Fourniture des Services .................................................................................................................................................. 80
7.2.1 La Gestion des Niveaux de Service (Service Level Management ou SLM) ......................................................................................... 80
7.2.2 La Gestion Financire des services des TI (IT Services Financial Management) ................................................................................. 81
7.2.3 La Gestion de la Disponibilit (Availability Management) ................................................................................................................. 82
7.2.4 La Gestion de la Continuit des Services des TI (IT Service Continuity Management) ....................................................................... 84
7.2.5 La Gestion de la Capacit (Capacity Management) ........................................................................................................................... 84
8 REFERENCES BIBLIOGRAPHIQUES ....................................................................................................................................................................... 86
9 ACRONYMES ....................................................................................................................................................................................................... 87

TABLE DES FIGURES

Figure 1 : Les 3 axes de contrainte dun projet ................................................................................................................................... 10
Figure 2 : Les activits centrales de la gestion de projet ..................................................................................................................... 10
Figure 3 : Courbe de Farmer sur la gravit, probabilit et traitement des risques .............................................................................. 11
Figure 4 : Exemple de Matrice des risques .......................................................................................................................................... 12
Figure 5 : Courbe en S des cots ......................................................................................................................................................... 13
Figure 6 : Les principales activits lies la planification ................................................................................................................... 14
Figure 7 : Prconisations de planification ........................................................................................................................................... 15
Figure 8 : Une organisation projet type .............................................................................................................................................. 17
Figure 9 : Dcomposition dun portefeuille de projets ........................................................................................................................ 18
Figure 10 : Exemple de mise en place dune gouvernance .................................................................................................................. 20
Figure 11 : Cartographie des processus DSI et correspondance avec les rfrentiels SI existants ...................................................... 23
Figure 12 : Schma illustratif de ISO ................................................................................................................................................... 25
Figure 13 : Schma illustratif de CMMI ............................................................................................................................................... 26
Figure 14 : Schma illustratif de ITIL ................................................................................................................................................... 29
Figure 15 : Du rve la mise en uvre avec les mthodologies au service de la DSI ......................................................................... 33
Figure 16 : Exemples daxes doptimisation selon les 4 perspectives stratgiques ............................................................................. 34
Figure 17 : Exemple illustr dune balanced scorecard ....................................................................................................................... 35
Figure 18 : Le cheminement de la rflexion aboutissant laction ..................................................................................................... 36
Figure 19 : Processus damlioration continue ................................................................................................................................... 37
Figure 20 : Organisation des certifications Six Sigma ......................................................................................................................... 39
Figure 21 : Le modle Toyota .............................................................................................................................................................. 40
Figure 22 : Lean Management TPS ..................................................................................................................................................... 42
Figure 23 : Illustration du processus damlioration port par OPEX .................................................................................................. 42
Figure 24 : Les 4 phases de OPEX ........................................................................................................................................................ 43
Figure 25 : OPEX, un changement de culture ...................................................................................................................................... 44
Figure 26 : OPEX, une organisation impliquant tous les niveaux hirarchiques ............................................................................... 45
Figure 27 : Gouvernance OPEX, une vritable dynamique damlioration continue prenne ............................................................. 45
Figure 28 : Comptences Blue et Black Belt ........................................................................................................................................ 46
Figure 29 : Illustration du cycle de vie dun projet informatique (source CNRS) ................................................................................. 48
Figure 30 : Dtail du cycle de vie (source CNRS) ................................................................................................................................... 49
Figure 31 : Modle en cascade avec un maquettage et un prototypage ............................................................................................ 51
Figure 32 : Cycle de vie du processus unifi ........................................................................................................................................ 52
Figure 33 : Illustration du processus unifi.......................................................................................................................................... 53
Figure 34 : Illustration du modle RAD ............................................................................................................................................... 55
Figure 35 : Reprsentation de la mthode SCRUM - droulement dun Sprint ................................................................................... 56
Figure 36 : Comment construire le backlog ......................................................................................................................................... 57
Figure 37 : Illustration des 13 pratiques XP ........................................................................................................................................ 60
Figure 38 : Cycle de dveloppement XP .............................................................................................................................................. 60
Figure 39 : illustration dune itration XP ........................................................................................................................................... 61
Figure 40 : Accompagnement au changement : 3 axes dactions ....................................................................................................... 62
Figure 41 : Cycle dacceptation du changement ................................................................................................................................. 63
Figure 42 : Passage de la rticence laction ..................................................................................................................................... 63
Figure 43 : Exemple de plan de communication ................................................................................................................................. 64
Figure 44 : Une mthode daccompagnement en 4 grandes tapes ................................................................................................... 65
Figure 45 : Quelques causes dchec au changement ......................................................................................................................... 66
Figure 46 : Cycle de vie dun incident .................................................................................................................................................. 76
Figure 47 : Processus de gestion des incidents .................................................................................................................................... 77
Figure 48 : Processus de gestion des problmes ................................................................................................................................. 78
Figure 49 : Processus de gestion des changements ............................................................................................................................ 78
Figure 50 : Processus de gestion des configurations ........................................................................................................................... 80
Figure 51 : Relation entre les clients et la gestion des niveaux de service .......................................................................................... 81
Figure 52 : Processus de gestion de la disponibilit ............................................................................................................................ 83


1 INTRODUCTION

Plus que jamais, les responsables et gestionnaires des applicatifs mtiers sont confronts lmergence de normes et standards
reconnus internationalement. La pression est forte pour adopter et faire certifier son organisation par un label qui est sens non
seulement rpondre tous les problmes, mais aussi et surtout prouver aux tiers que lorganisation a adopt les bonnes pratiques .
CMMI, ITIL, ISO 9000, PMI, PRINCE2, COBIT, Six Sigma, etc. sont parmi les standards les plus rpandus.
Les avantages vendus avec ces normes, standards et rfrentiels sont multiformes et vont des performances oprationnelles les plus
concrtes aux avantages stratgiques permettant des gains de comptitivit. Nous ne cherchons pas nier les mrites intrinsques de
ces mthodes, mais il est vident que les cots dimplmentation sont trs importants et que les rsultats obtenus difficiles mesurer.
Le problme ne rside pas dans le rfrentiel en lui-mme, mais dans son application et son adquation avec le contexte particulier de
lorganisation qui ladopte. Toutes les mthodes ne sont pas adaptes une organisation donne.
Cet ouvrage sadresse aux Directeurs des Services Informatiques et toute personne qui souhaite amliorer la gestion des projets
grce la mise en application dun rfrentiel mthodologique cohrent et adapt lorganisation des services informatiques. La
question principale laquelle nous avons voulu rpondre est : Comment mettre en place et utiliser un rfrentiel mthodologique
Qualit dans une organisation de services ddie aux systmes dinformation et aux projets informatiques ? .
La premire partie du livre blanc dfinit donc ce quest un projet, le rle de ses principaux acteurs ainsi que les grandes fonctions de la
gestion de projets. La deuxime partie prsente un panorama structur mais non exhaustif des principaux rfrentiels et normes
reconnus internationalement. Il ne sagit pas dune simple numration et description des diffrents standards du march, mais dune
explication de leur succs et des bnfices attendus de leur adoption par les DSI. La troisime partie concerne le choix dune mthode
de gestion de projet. Enfin la cinquime partie prsente lexemple de la socit Aubay du point de vue du choix, de la mise en uvre et
de lutilisation dun rfrentiel Qualit et de diffrentes mthodes de gestion de projet.

2 LE PROJET ET SES ACTEURS
2.1 Le Projet
Un projet est un ensemble d'activits qui sont prises en charge, dans un dlai donn et dans les limites de ressources imparties, par
des personnes qui y sont affectes dans le but d'atteindre des objectifs dfinis (Source : AFNOR/Z 67-100-1). Ainsi, daprs lAFNOR : "
La gestion de projet est lensemble des mthodes, outils dvaluation, de planification et dorganisation permettant datteindre ses
objectifs en respectant les contraintes de performance, de dlais, et de cots .
La conduite de projet aura donc pour fonction de matriser la qualit, les cots et les dlais de dveloppement dans un souci
d'efficacit et de rentabilit (efficience). On peut ainsi dfinir la conduite de projet comme tant l'ensemble des activits destines
assurer le droulement d'un projet dans les meilleures conditions de cot, de dlai et de qualit des rsultats ; ces 3 conditions tant
antinomiques par nature.

Figure 1 : Les 3 axes de contrainte dun projet

La gestion de projet est une dmarche visant organiser et grer, de bout en bout, le bon droulement dun projet. Cette dmarche
repose sur certaines actions : mettre en place lorganisation et la planification de lensemble des activits visant atteindre les objectifs
du projet exprims en termes de qualit, cots et dlais (voir schma ci-dessus), effectuer leur suivi, anticiper les risques potentiels,
dcider et communiquer. Vous trouverez ci-dessous une description des principales fonctions de la gestion de projet et de ces
principaux acteurs.

Figure 2 : Les activits centrales de la gestion de projet

2.2 Principales activits inhrentes la gestion de Projet
2.2.1 Gestion des risques
D'aprs le National Institute of Standard Technology (NIST), le risque est la possibilit que quelque chose de dfavorable puisse
survenir (1995) puis le NIST a chang de dfinition en 2001 : impact net ngatif de l'exploitation d'une vulnrabilit considrant sa
probabilit et son impact de ralisation .
Nous nous rfrerons aux dfinitions issues de la norme ISO/CEI 73 : combinaison de la probabilit d'un vnement et de ses
consquences , et de lISO/CEI51 : combinaison de la probabilit dun dommage et de sa gravit.
Ainsi, la notion de risque repose sur deux concepts principaux : le facteur de risque, qui reprsente un lment prsent dans le projet,
susceptible de provoquer une perturbation, et la criticit qui, associe un facteur de risque, dsigne la combinaison entre la gravit
de limpact et la probabilit du risque.
Le risque est inhrent tous les projets. Dans le jargon de la gestion de projet, le risque dsigne un vnement incertain qui, sil
advient, aura un effet ngatif sur les objectifs du projet ainsi quun impact sur les cots, lchancier ou la qualit du projet. Il convient
donc de les identifier et den estimer limpact. Loccurrence et les consquences dun risque sont lies au cycle de vie du projet. En
dbut de projet la probabilit doccurrence dun risque est leve mais son impact gnralement faible, alors quen fin de projet la
probabilit doccurrence est faible mais son impact critique pour le projet.

Figure 3 : Courbe de Farmer sur la gravit, probabilit et traitement des risques

La premire tape dans la cration dun plan de rponse consiste rdiger un recueil de risques avec tous les intervenants du projet.
Les intervenants peuvent dfinir les risques en se fiant leur exprience. Ce document recueillera la description des risques identifis,
ainsi que le niveau de criticit associ, la nature de leur impact (cout, dlai, qualit), et une estimation du risque ainsi que le service ou
la personne responsable du suivi du risque.
Il est impossible de se prparer tous les risques mais les risques hautement probables et ayant des rpercussions considrables
doivent requrir une intervention immdiate. La rduction ou laccroissement des risques projet dpend de lefficacit de votre
planification. Comme tous les risques ne sont pas facilement identifiables au dbut du projet, il importe de prvoir rgulirement un
examen des risques lors de runions ddies avec lquipe projet. Les risques ainsi identifis doivent faire lobjet d'un rapport
soulignant la raction privilgie.


Figure 4 : Exemple de Matrice des risques

Ainsi, afin de se prmunir contre les diffrents facteurs de risques pouvant perturber le droulement dun projet, il est prconis de
dployer une procdure danalyse et de gestion des risques. Celle-ci peut suivre la dmarche suivante :
1) Inventorier les risques
Type de risques potentiels : financiers, organisationnels, techniques, sociaux, environnementaux.
Mthodes didentification : larges consultations, enqutes, exploration des archives, analyse de la mmoire des projets
antrieurs, consultation d'experts.

2) Evaluer et valoriser les risques.
Evaluer la criticit de chacun des risques en termes d'impacts, de dommages, de consquences et en termes de probabilit
doccurrence, afin dtablir un indice de criticit pour chaque risque. Puis traduire le risque en cot.

3) Dfinir les parades.
Lon peut identifier 4 ractions que lon peut adopter face un risque :
Lvitement : Si une activit prsente un risque, il est prfrable de l'viter.
L'acceptation : le risque est accept et des provisions sont alloues pour lamortir.
La rduction du risque : matrise des risques par des mesures de protection et de prvention : c'est la dmarche classique
de gestion des risques.
Le transfert : contraction dune assurance ou recours la sous-traitance (qualifie, mieux a mme de rduire le risque).

4) Identifier les points critiques
Les points critiques sont associs aux risques de criticit maximale. Il sagit ici didentifier les instants du droulement du projet
o il faudra redoubler de vigilance.

5) Construire et rviser la table des risques
Suivi de lvolution des risques au cours du projet.

Exemple dune table des risques :

Risque Criticit Action Responsable Dure Echance Ressources Cot (en heures)

6) Capitaliser lexprience
En renseignant par exemple une base de donnes des risques propre une typologie de projet.

2.2.2 Gestion budgtaire
Un budget a deux utilits fondamentales. Dune part, il permet de garantir au chef de projet les moyens financiers de son action et,
dautre part, il lui fournit un cadre dengagement vitant ainsi le risque de dbordements incontrls. Le budget se construit en lien
avec la planification du projet. Idalement, un budget devrait tre la dclinaison annuelle de la partie cots dinvestissement dun
plan dinvestissement. Le suivi budgtaire est un exercice permanent pour le chef de projet. Avant chaque engagement de dpense, en
fonction de sa nature, il en vrifie la disponibilit dans son budget.
Le budget est dfini suivant un processus destimation, qui est intrinsquement li lactivit de planification.
Toute activit de planification tant prospective, elle repose sur un processus destimation ; estimation de la dure (calendrier) et des
cots (efforts), couple une analyse des risques. Ce processus couvre une activit qui comporte des difficults intrinsques. Cette
estimation ne peut tre correcte que lorsque le logiciel est apprhend dans son intgralit, elle requiert dtre affine
progressivement.

Le processus destimation est dploy sur 3 phases :
lors de la rponse lappel doffres pour chiffrer la proposition et tablir le budget,
lors de la planification du projet pour tablir le plan du projet et le plan qualit, et btir ainsi le rfrentiel contractuel,
au cours du suivi du projet pour mettre jour le rfrentiel et affiner les prvisions.

Le processus destimation suit 3 tapes :
lestimation de la taille du produit, suivant le nombre de lignes de code, la mthode des points de fonction ou la mthode des
features points,
lestimation de leffort, en hommes / mois, suivant par exemple la mthode de COCOMO,
lestimation de la dure, en mois ou semaines calendaires, suivant llaboration de diffrents scnarios de planification.

Ces diffrentes estimations dfinissent la partie variable, les cots salariaux, laquelle il convient dajouter les frais fixes (locaux,
quipement) pour dfinir le budget prvisionnel.

Visualiser lavancement de son projet et les dpenses effectues.
La courbe en S est un outil graphique de suivi de l'avancement d'un projet pouvant mettre en lumire sa situation conomique. Cet
indicateur permet notamment de montrer l'volution des dpenses relles cumules ou "cot rel" au cours de l'avancement du projet
et d'estimer un instant T du projet des carts prvisionnels en termes de cots et de dlais.
La construction de cet indicateur s'appuie sur la ralisation de 3 courbes : une premire courbe appele Cot Budgt du Travail Prvu
reprsentant le budget prvisionnel du projet (cots + temps) ; une deuxime (Cot Rel du Travail Effectu) qui reprsente
l'avancement effectif du projet une date T. Et une troisime courbe "virtuelle" (Cot Budgt du Travail Effectu) qui symbolise
l'avancement physique du projet.

Pour raliser ce type de graphique, il faut en amont du projet
dfinir une premire courbe prvisionnelle de ralisation (CBTP)
au lancement du projet. Puis un instant T, le chef de projet
peut dfinir une seconde courbe, qui reprsente la courbe
relle de ralisation. Il peut enfin dfinir une troisime
courbe qui donnera la valeur du travail ralis en valeur
budgtaire, soit les dpenses en temps et en cots rellement
effectus au cours de la priode.
L'cart entre les courbes CBTE (3) et CRTE (2) sur l'axe des
abscisses illustre le retard d'avancement entre le travail
effectu et le travail prvu. L'cart entre ces deux courbes, sur
l'axe des ordonnes reprsente la diffrence en cots entre le
cot budgt et le cot rel.
Cette mthode permet donc de visualiser les carts, et
lventuelle drive budgtaire dun projet, charge au chef de
projet den analyser les raisons et dy apporter les correctifs
ncessaires. Dans des contextes budgtaires de plus en plus
tendus la direction de projet est souvent plus challenge sur la
tenue de son budget que sur certains aspects dlais ou qualit.

Figure 5 : Courbe en S des cots

2.2.3 Planification
Le planning est un outil fondamental du chef de projet. Il trace le cadre de travail du projet, fournit les objectifs (cots, dlais), et
prsente une perspective globale du travail en commun. Cest un lment fdrateur de motivation qui doit tre raliste. En cas de
drive, il est important de mettre en place des actions correctives, pour quil conserve son rle de stimulation. Le planning est un outil
de base pour le suivi de projet, il est indispensable tout bon pilotage. Son suivi permet la matrise des dlais, des cots et de la qualit
du projet. Ce suivi est une activit itrative qui commence avec linitialisation du planning et se termine avec la fin du projet.

Objectifs de la planification
Offrir une vision sur le long terme du droulement du projet : anticiper, prvoir.
Identifier et ordonnancer les actions du projet : organiser et piloter.
Allouer les ressources aux tches : grer les ressources et le travail.
Suivre lavancement et le respect des objectifs : contrler et corriger.
Reporter aux instances dcisionnelles : communiquer et informer.

Figure 6 : Les principales activits lies la planification

Ainsi, le planning prsente des informations fondamentales pour la prise de dcision.
La premire planification dtaille doit fournir une vision globale sur le long terme du projet, et dtailler les phases planifies sur au
moins 6 mois. Cette planification reprsente le scnario de dpart du projet, et tablit la baseline, le rfrentiel en termes de dlais et
de cots. En premier lieu, la construction dun planning sinitie par le choix dun Work Breakdown Structure (WBS), dterminant
larborescence (lorganisation du rseau de tches rcapitulatives et de sous-tches) du planning. Il semble prfrable de suivre un
WBS respectant au mieux la logique de dveloppement et donc les processus. Cependant, pour diverses raisons (contrle de gestion)
on pourra prfrer diffrents types de dcoupage .
A titre dinformation voici les diffrents types de dcoupage existants :
LOrganization Breakdown Structure (OBS), qui respecte lorganisation industrielle de lentreprise (dcoupage de la structure
arborescente par directions, services)
Le Product Breakdown Structure (PBS), dcoupage qui respecte larchitecture du produit dvelopp (dcoupage par ensembles,
sous-ensembles).
Le Resources Breakdown Structure, qui reprsente lensemble des ressources de lentreprise. Cest le prolongement de lOBS,
qui permet de planifier les tches en allouant des ressources nominatives (cest aussi possible avec un PBS ou un WBS).
Le Work Breakdown Structure, dcomposition hirarchique, axe sur les tches et activits que lquipe de projet doit excuter
pour atteindre les objectifs du projet et produire les livrables voulus. Cest le terme gnrique employ pour dsigner la
structure arborescente de dcomposition du projet, permettant sa planification. Le but tant daboutir une planification assez
fine pour obtenir des prvisions fiables.
Il est prfrable de choisir une structure logique se rapprochant le plus possible de la mthodologie de dveloppement (processus) de
lentreprise, pour construire un planning cohrent et logique. Ainsi, dans le cas des systmes dinformation, il semble judicieux
doprer un dcoupage suivant le cycle de dveloppement, qui offre une cohrence de regroupement (Dfinition, Dveloppement,
Exploitation, Maintenance/Evolution), et permet dintroduire une certaine logique chronologique.


Mthode prconise pour tablir la planification initiale :
Si des rfrentiels existent dans lentreprise, il est ncessaire de se les approprier, sinon, il convient de les concevoir.
1) Identification des grandes phases, des principaux livrables et des jalons majeurs relatifs au projet de dveloppement.
Ressources : processus standard de dveloppement et standards de gestion de projet de lentreprise. Le cas chant, animation
de groupes de travail spcifiques
2) Dcoupage des phases du projet en tches et sous-tches, allocation dune dure, dune charge et dun type de comptences
chaque tche.
Ressources : processus standards des diffrents services. Le cas chant, animation de groupes de travail spcifiques (ex :
construction de rtro-plannings dtaills).
3) Dfinition de la logique denchanement des tches pour construire le diagramme PERT.
4) Allocation des tches suivant lOBS, puis le RBS.
5) Analyse des rsultats de la planification : dlai final, chemin critique et marges.
6) Optimisation du planning, modification de lenchanement des tches et gestion de la charge / capacit.
7) Edition de la planification initiale sous forme claire et lisible, par un diagramme de GANTT.

Il est important didentifier clairement les livrables et les jalons (tches de dure et de travail nuls), car ils reprsentent eux seuls des
indicateurs de pilotage primordiaux.
Il est capital dintgrer les liens entre les tches (et entre les tches et leurs livrables), ainsi que les inputs ncessaires (livrables
externes), afin dobtenir une planification pertinente.

Figure 7 : Prconisations de planification

Une fois la planification tablie, on construit le plan de travail.

Illustration dun plan de travail :
Tche Description Responsable
Indicateur
de fin
(livrable)
Enchanement
(entre)
Dure Echance Ressources
Estimation
Du cot
(en heures)

A partir de ce plan de travail global, on transmet chaque service un ordre de travail, reprenant lensemble des tches qui le concerne.
Cet ordre de travail engage le service sur des objectifs prcis, et contractualise sa participation au projet.
2.2.4 Reporting
Le reporting reprsente la synthse ncessaire la matrise des objectifs et aux prises de dcision. Il est principalement un outil destin
fournir de linformation dcisionnelle. Cest est un document de synthse destin aussi bien la direction quaux quipes projet, il est
communiqu selon une priodicit dfinie, ce qui facilite la comprhension de lvolution des indicateurs du projet. Le reporting doit
permettre de comprendre rapidement la situation dun projet laide de synthses, notes chiffres, tableaux de bords ou KPI.
Un KPI (Key Performance Indicateur) est un paramtre qui se veut le plus reprsentatif de lactivit du projet et qui permet d'valuer la
performance globale de ce dernier en fonction des objectifs attendus. Ces indicateurs doivent tre jour en permanence pour pouvoir
rpondre aux besoins du top management. Le KPI peut porter sur tout type dinformation : ltat des dpenses du projet, les risques, la
qualit etc.
Il est primordial de ne slectionner que des indicateurs susceptibles de dlivrer une information de mesure de la performance
cohrente avec lobjectif poursuivi.

La complexit du calcul et la difficult de collecter les donnes ne sont pas les critres de valeur pour qualifier la pertinence dun
indicateur. Un bon indicateur doit tre simple construire sans ncessiter des donnes inaccessibles ou des calculs difficiles
comprendre. La forme du KPI (diagramme barre, camembert ou autre) na pas grande importance il se doit dtre avant tout visuel et
facilement comprhensible. Le KPI apporte une information, quil convient danalyser pour mettre en uvre les actions adquates.
2.2.5 Contrle qualit
Le processus qualit, spcifi par la norme ISO 9000-3, dcrit lensemble des activits et des produits qui certifient que le logiciel
dvelopp satisfasse aux exigences de qualit requises. Il remplit deux fonctions principales :
l'assurance qualit :
Dmarche prventive visant viter les problmes de non conformit la spcification et d'inadquation aux besoins,
ensemble des actions prtablies et systmatiques ncessaire pour donner la confiance approprie en ce qu'un produit
satisfera aux exigences donnes relative la qualit (dfinition AFNOR NFX 50-120). Lassurance qualit se formalise dans le
plan qualit, qui rpond aux clauses qualits exiges par le client.
le contrle qualit :
Ensemble des actions dont le but est de vrifier la conformit d'un produit et d'un processus de dveloppement, au plan qualit
prtabli (par l'assurance qualit). Le contrle qualit seffectue principalement par le biais des actions suivantes : les audits
(contrles permettant de vrifier le respect des procdures qualit), les revues (vrifications de la conformit des rsultats
d'une phase), les inspections (mesures de critres qualit), les lectures croises (vrifications de documents avant leur passage
en revue).
2.2.6 Gestion des engagements du projet
Les engagements majeurs dun projet sont en grande partie grs par le processus qualit.
Un contrle priodique permet le suivi de l'avancement du projet et le contrle de l'atteinte des objectifs. Ce contrle s'effectue par
des runions priodiques aux diffrents niveaux requis (oprationnel, dcisionnel), et est retranscrit aux diffrents partenaires lors des
comits projet et des comits de pilotage.
Au cours de ces runions, les principaux livrables de Gestion de projet sont mis jour : journal de bord, planning, fichier d'analyse des
risques et plans d'action.
Les problmes se rencontrent au fil du temps, et sont exposs lors des activits de suivi et de contrle priodique.
Les plans daction, chargs dy remdier sont construits parfois lors des runions de suivi elles-mmes (ceux-ci se btissent, stoffent
et sont suivis), parfois, pour les sujets plus techniques, lors de runions ddies.

Illustration dun plan daction standard :

Problme Action Description Responsable Dure Echance Ressources
Estimation
Du cot
(en heures)

2.3 Principaux acteurs de la gestion de projet.
Un projet est par dfinition un travail collectif, engageant plusieurs entits et de nombreux acteurs autour dobjectifs partags, qui se
matrialisent dans une ralisation concrte. La fonction premire de la gestion de projet est dorganiser et de contrler le processus
technique encadrant le dveloppement du nouveau produit. Lorganisation des activits a pour but de grer la complexit relationnelle
inhrente au projet, de diriger et de coordonner le travail des diffrentes entits et de la multitude dacteurs avec un souci constant
defficience.
Un des pr-requis essentiel une bonne conduite de projet est donc lidentification des entits engages.


Figure 8 : Une organisation projet type

Brve description des principales entits impliques dans la conduite dun projet :

Le Sponsor
Le Sponsor est le reprsentant du projet auprs des plus hautes autorits excutives de lorganisation. Il finance le projet, et ce titre il
est le plus expos aux diffrents risques, (allongement des dlais, augmentation des cots planifis, et dgradation de la qualit ou des
fonctionnalits). Il est donc un des acteurs majeurs des comits de pilotage. Le rle du sponsor est gnralement pris en charge par un
membre confirm de lexcutif de lorganisation ou par un groupe de management.

La matrise douvrage - MOA
Le terme matrise douvrage fait rfrence au commanditaire dun produit ou dun service pour lequel un projet spcifique va tre
dvelopp. La matrise douvrage est donc lentit porteuse du besoin. Elle dfinit les objectifs, le calendrier et le budget associs au
projet. Elle reprsente lutilisateur final. A ce titre, lune de ses fonctions fondamentales est dexprimer son besoin, de dfinir le
produit, et de spcifier ses exigences. En tant que commanditaire, elle assure un suivi rgulier du projet pour scuriser son
avancement. Elle dirige ltape de qualification pour vrifier la conformit du produit dvelopp avec ses exigences, participe
activement la conduite du changement et la mise en uvre du produit pour limplmenter dans son organisation. Une fois le
produit rceptionn, vrifi et valid, elle peut librement lexploiter, et assure son bon fonctionnement par la mise en place dune
maintenance adquate.

La matrise duvre - MOE
La matrise duvre est lentit retenue par la MOA pour raliser l'ouvrage, dans les conditions de dlais, de qualit et de cot fixes
par cette dernire conformment un contrat. Elle dirige donc le dveloppement du produit dfini par la MOA, assure sa conception et
sa ralisation. Elle simplique aussi fortement dans la conduite du changement et dans la mise en uvre du produit chez son client.
Ainsi matrise douvrage et matrise duvre ont des fonctions complmentaires et dterminantes pour le dveloppement dun projet.
La russite de celui-ci dpend donc directement de la relation entre ces 2 acteurs, de leur coordination et de la communication entre
ces 2 instances majeures.

Les fournisseurs
Un fournisseur est une organisation externe qui fournit des produits ou des services requis par un projet. Ayant des intrts communs
stratgiques, les fournisseurs et leurs clients dveloppent des relations partenariales fortes, concrtises le plus souvent par un
processus de certification interne.

Lquipe Projet
Lquipe projet intgre lensemble des acteurs internes fonctionnels impliqus dans la conduite et la ralisation dun projet. Afin de
mener bien un projet complexe, lquipe projet regroupe des membres aux profils et aux comptences complmentaires. Ceux-ci
peuvent tre : un ou des chefs de projet, des analystes dveloppeurs, des architectes (techniques et fonctionnels), des administrateurs
de donnes. Afin dassurer lefficience et la coordination du travail dquipe que reprsente un projet, diffrentes mthodes de
management ont t labores, dont lune des plus clbres est la mthode SCRUM.

Ainsi, les activits de gestion de projet peuvent mobilises de nombreux acteurs tels que :
Responsable dun portefeuille de programmes ou de projets
Directeur dun programme
Directeur de projet
Chef de projet
PMO
Responsable fonctionnel
Directeur oprationnel
Directeur de la qualit
Client

Il convient de prciser que le rle de ces acteurs reste trs dpendant du niveau de maturit de lentreprise dans la mise en uvre des
processus de management de projets, cependant leur existence est globalement garantie dune organisation lautre. En fonction de
limportance du projet, diffrents intervenants sont amens exercer une activit de management, il est donc important de connatre
la typologie des projets, la dcomposition dun portefeuille de projets.

Figure 9 : Dcomposition dun portefeuille de projets

Selon limportance du projet, son positionnement dans le portefeuille de projets, diffrentes fonctions relatives au domaine de la
conduite de projets, sont requises pour assurer le pilotage. Quelques unes de ces dernires sont dcrites ci-dessous.
2.3.1 Directeur de Projet
Le directeur de projet supervise la conception et la ralisation de projets importants, stratgiques, et souvent de dimension
internationale.
Le directeur de projet est donc responsable de l'aboutissement d'un projet sur le plan :
du budget/cot
des dlais (planning, jalons)
du respect de la rponse aux besoins (spcifications)
de la qualit (tests, recettes...)

Il coordonne les travaux de la MOA, de la MOE ainsi que ceux de tout autre acteur impact par le projet (juridique, marketing,
informatique, technique, formation des personnels, organisation, logistique, communication...)
Il doit sassurer que les travaux sont conduits dans les rgles de l'art (standards qualit, mthode, techniques, rglementaires) et dans
le respect du cadre fix au projet (budgets, dlais, rponse aux besoins). Il est garant que l'ensemble des impacts sur les diffrentes
fonctions de l'entreprise ou de l'organisation soit bien identifi et pris en compte. Les difficults ventuelles doivent donc tre bien
identifies et anticipes suffisamment tt. Il est responsable de la bonne valuation et matrise des risques et des mesures
dvitements ncessaires. Il sassure que des solutions sont proposes avec des argumentations suffisantes (avantages, inconvnients,
scnarios, impacts, ...).Le directeur de projet prend les dcisions en fonction des enjeux (gestion des priorits) tout en les hirarchisant.
En termes doutils, le Directeur de projet utilisera principalement des Comits de Pilotage et par consquent, ses qualits
principales devront tre davoir une bonne capacit d'analyse et de synthse.
En rsum, le Directeur de projet pilote le projet dans le cadre fix par la matrise d'ouvrage et en accord avec les chefs de projet de la
matrise d'uvre. Il veille au respect des spcifications, des dlais, du budget et des standards de qualit. Il doit anticiper les impacts en
s'assurant que les rpercussions des changements sur les diffrentes fonctions de l'entreprise ou de l'organisation sont bien prises en
compte. Il a en charge la conduite du changement notamment dans le cas de rorganisations, de fusions,... Il arbitre en prenant les
dcisions ncessaires dans le respect des impratifs, objectifs et contraintes des diffrents acteurs de l'entreprise ou de l'organisation,
tout en veillant rapporter ces dcisions aux enjeux et aux objectifs fixs par la matrise d'ouvrage. Le Directeur de Projet conduit donc
un projet complexe, souvent avec plusieurs entreprises, des contrats importants et des quipes nombreuses. Le plus souvent, le projet
implique plusieurs pays et plusieurs cultures.
2.3.2 Chef de Projet
Le chef projet est la personne charge de mener un projet et de contrler son bon droulement. De manire gnrale, il dirige ou
anime une quipe pendant la dure du projet dont il a la charge.
Il est responsable d'un projet de taille limite, souvent interne un seul dpartement et avec une quipe rduite, il peut tre charg de
contrler le bon droulement du dveloppement d'un logiciel (ex projet informatique). Il peut avoir mettre en place une nouvelle
organisation au sein d'une entreprise (ex projet organisation) ou dvelopper un nouveau produit (ex projet R&D). Il peut aussi avoir
construire un outil de production (ex projet industriel).
Pour mener bien son projet, il le structure pour arriver une date cl. Il doit contrler son bon droulement. Il a galement la charge
de fdrer, diriger et animer une quipe ddie au projet. Il sassure de la bonne communication des informations du projet avec les
dirigeants, soutien indispensable au bon droulement du projet.
Il travaille avec le sponsor pour faire clarifier et formaliser les objectifs. Il peut galement avoir organiser des ateliers utilisateurs ou
d'expression de besoin en dbut de projet pour impliquer les utilisateurs.
Ses outils sont aussi bien les Comit de Projet (comit de pilotage, comit de suivi etc.) que les outils de gestion de planning (Gantt,
PERT) ou lanalyse fonctionnelle.

Ses qualits
matrise instrumentale du pilotage de projet (les outils)
matrise des champs techniques impliqus dans le projet (le mtier technique)
comptences sociales (le travail en groupe)
comptences de traduction entre les langages des mtiers (le rle de facilitateur)
bonnes capacits relationnelles
connaissances techniques dans les domaines concerns
En rsum, le chef de projet est central sur tous ces aspects. Il reprsente statistiquement 75% des facteurs de succs du projet. Il est
souvent trs proche d'un rle de gestionnaire de projet ou de planificateur, c'est le bras droit du Directeur de projet.
2.3.3 Project Manager Officer
Le PMO est lentit ou le groupe dans une entreprise qui dfinit et maintient le rfrentiel des processus lis la gestion de projet. Le
PMO a pour objectif de standardiser et dindustrialiser les projets. Le PMO a en charge la documentation, le tutorat et l'valuation de la
gestion des projets, ainsi que le suivi de la mise en uvre.
Le PMO a la charge de fournir une liste et une situation jour des projets. Il doit avoir une comprhension des interdpendances entre
les projets ou programmes et par l permettre une reprogrammation rendue ncessaire par les changements rapides des priorits et
du march. Il est amen appliquer ou mettre en uvre des processus permettant aux managers datteindre les rsultats dans les
dlais, les cots et les spcifications requises. Le PMO est galement responsable de fournir de linformation jour et en temps voulu

qui permettra une optimisation en termes de prparation, dallocation et de management des ressources. Il informera de lvolution
des risques majeurs et des correctifs mis en uvre.
Il est charg d'aligner ses projets sur un plan stratgique ; c'est--dire de disposer dune visibilit sur les projets permettant une
Direction Gnrale de dcider et darbitrer en connaissance de cause, doptimiser les ressources, de scuriser le droulement des
projets majeurs (Fonction portefeuille de projets). Il doit faciliter l'intgration des chefs de projets dbutants, et disposer dun
rfrentiel partag qui facilite le dialogue (stratgique, oprationnel et conomique) et la matrise des projets (Fonction Normes et
Mthodes). Le PMO travaille amliorer la qualit du management de projet, acclrer les projets travers une meilleure
comprhension des acteurs externes et des attendus et des rles de chacun (Fonction Formation). Il aide mieux matriser les projets,
amliorer les comptences et les comportements des chefs de projets (Fonctions conseil et coaching). Il doit galement prendre en
charge les diffrents tches rptitives (mise jour du planning projet, des feuilles de temps et des actions, archivage et historique de
projet...) afin que le chef de projet se concentre sur le management et les points (Fonction support).

Ses outils
Le PMO doit avoir une bonne connaissance doutils tels que Planisware, Augeo, Artemis, Compuware, CA, SAS, Oracle HP, IBM-Cognos.
Il doit tre capable de fournir des tableaux de bords et indicateurs synthtiques permettant une comprhension de ltat rel du ou
des projets dont il a la charge. Le PMO est galement responsable de la bonne utilisation et animation des outils de planification.

Ses qualits
confiance, leadership et motivation
rigoureux, organis, curieux et pugnace
got des chiffres
capacit rcuprer puis transmettre linformation

En rsum, le PMO sassure que les projets lancs soient pertinents (stratgiquement, conomiquement, techniquement), il doit tre
capable de prioriser les projets entre eux. Il scurise et matrise les projets enjeux majeurs (objectifs tenus : stratgiques,
oprationnels, conomiques) et dispose dun tat davancement des projets conformes la ralit. Il sassure que limpact des projets
sur le fonctionnement quotidien de lentreprise soit sous contrle (projets internes) et fait fonctionner de concert les niveaux
stratgiques, oprationnels et conomiques.

2.4 Gouvernance de projet
Il est important et ce quelque soit la taille du projet de se poser le plus tt possible les bonnes questions quant la gouvernance
projet comme ; quelle est lorganisation de lentreprise ? Faudra-t-il crer des instances ? Pourrons-nous utiliser les instances
existantes ? Comment faire prendre et par qui les dcisions ou arbitrages ? etc..
La gouvernance d'un projet recouvre l'ensemble des instances mettre en place pour assurer un bon pilotage d'un projet. En fonction
de la taille du projet, on aura une complexit de gouvernance croissante.

Figure 10 : Exemple de mise en place dune gouvernance

Rles et responsabilits de chaque Instance de gouvernance

Comit de Pilotage Programme
Il pilote le budget global allou au programme, dfinit les priorits et ralise les arbitrages inter-chantiers, il effectue le suivi des KPI du
Programme. Il pilote la mise en uvre du programme : validation du macro-planning consolid et garantie du respect des jalons cls du
programme, revoit lavancement global et les vnements cls, pilote les risques transverses au programme ; Il valide la
communication du Programme vers les utilisateurs.

Comit de suivi du Programme Restreint
Il assure la coordination fonctionnelle et mtier entre les chantiers. Il effectue / prpare les arbitrages entre les chantiers. Il effectue le
suivi du Programme : suivi des risques, suivi budgtaire (budget, plan strat), suivi des actions, valide les rgles de fonctionnement du
Programme et suit les pratiques de pilotage des projets. Il prpare les Copil Programme, et il pilote le plan de charge et le sourcing du
programme.

Comit de suivi du Programme Sinistres - Elargi
Il supervise la bonne gestion oprationnelle des projets du Programme et assure la coordination entre les Chantiers et les
Coordinations, de manire ce quil ny ait pas de zone dombre :
Suivi de lavancement des Coordinations et des Chantiers : faits marquants, risques / alertes / problmes
Communication des orientations stratgiques ou des dcisions prises dans le cadre dautres instances
Partage des rgles de fonctionnement sur le Programme
Suivi du budget consolid du Programme
Partage du planning, des tapes mtier
Suivi des actions
Pilotage du staffing du programme (remonte des besoins, problmes de staffing Programme)
Il garantit la mobilisation de lensemble des contributeurs et maintient un niveau dinformation homogne sur le programme.

Comit de Pilotage Chantier
Il garantit la mise en uvre des orientations stratgiques sur le chantier et la ralisation des gains associs au chantier. Il pilote la mise
en uvre du chantier en sappuyant sur les indicateurs de pilotage : revues davancement global du chantier, garantie du respect des
jalons cls, pilotage des risques, etc. Il dfinit les priorits, valide les arbitrages ncessaires au sein des projets et prend les dcisions
cls sur le chantier :
Dcisions mtier
Arbitrages inter-projets, jalons cls, budget, etc.
Il prpare le reporting et la communication vers le COPIL Programme et il ralise un suivi rgulier des gains / KPI associs.

Comit de Suivi Chantier
Il suit lavancement de lensemble des projets du chantier : jalons et livrables, consomms et reste faire, activits ralises et
raliser. Il prsente les indicateurs de suivi du chantier et partage les analyses correspondantes et il gre les adhrences entre les
projets du chantier. Il pilote le sourcing des projets du chantier et consolide les analyses de risques des projets et les plans dactions
associs. Il prpare le reporting et sujets faire valider ou arbitrer par le COPIL Chantier.

Comit de Pilotage Projet
Il met en uvre les orientations dfinies par le COPIL Chantier, il assure les revues davancement du projet sur les jalons cls. Il suit et
analyse les indicateurs de pilotage du projet et valide les arbitrages raliser au sein du projet. Il prpare la communication et les
sujets faire valider ou arbitrer par le COPIL Chantier :
Arbitrage sur les changements de primtre du projet : extension, arrt, re-planification, proposition de diffrents scnarios en
fonction des ambitions et des moyens
Actions de matrise des risques


Comit de Suivi Projet
Il suit le bon droulement du planning et fait le point sur les activits du projet (ralises et raliser), il prsente les indicateurs de
suivi du projet et partage les analyses correspondantes. Il coordonne lintervention des diffrents contributeurs sur le projet, et analyse
la faisabilit du plan de charge par rapport aux objectifs et contraintes du projet (notamment jalons cls). Il fait le point sur les
livraisons du projet et identifie et anticipe les risques sur le projet, examine et rsout les difficults rencontres. Il prpare les reporting
et sujets faire valider ou arbitrer en comit de Pilotage Projet.
Comme voqu prcdemment lorganisation de la gouvernance dpendra beaucoup de la taille du projet, de son cot ou de son
impact pour lentreprise.

3 PRINCIPAUX REFERENTIELS QUALITE
Quest-ce quun rfrentiel ?
Un rfrentiel est une collection de bonnes pratiques sur un sujet donn. Lorsque quil fait lobjet dune large diffusion et quil est
reconnu par le march on parle alors de standard. Les rfrentiels doivent tre perus comme une bote outils de laquelle lexpertise
extrait les bonnes pratiques dont elle a besoin pour rsoudre un problme donn ou pour rpondre un besoin. (ex : ITIL pour la
gestion de la production).
La norme se diffrencie des rfrentiels dans la mesure o il sagit dun document dit par une instance de normalisation
indpendante, par exemple lISO, faisant ltat de lart dun sujet donn (ex : ISO 27001 pour la scurit de linformation). La norme
peut avoir un niveau de contrainte supplmentaire par rapport au rfrentiel.
Les rfrentiels sont au cur des processus de la DSI, car ils permettent aux DSI damliorer le degr de matrise de leur SI.
La nomenclature, quant elle permet de dcomposer une problmatique (Ex : les cots de la DSI) en lments plus fins et homognes
permettant de se comparer dautres entreprises. Enfin la mthodologie est une dmarche structurante pour raliser une tche
donne, exemple : le dveloppement en cycle en V.
Les rfrentiels sont nombreux et dans le domaine de linformatique, on peut citer : ISO 27000, CMMI, ITIL, TOGAF, ISO 9001, COBIT,
etc. Nous en dtaillons 3 dentre eux.

Selon le CIGREF, les 3 rfrentiels les plus cits par les entreprises sont ITIL pour la production, ISO 27001 pour la scurit et la
nomenclature RH des emplois mtiers du CIGREF.
Les rfrentiels de gouvernance (COBIT), de dveloppement (CMMI), de gestion de projet, de qualit (ISO9001) et de suivi des cots
(benchmarking) les suivent.
Les trois rfrentiels les moins utiliss, daprs leur enqute, sont TOGAF pour larchitecture dentreprise, Prince 2 pour la gestion de
projet et eSCM pour la gestion de la relation clients fournisseurs.

Figure 11 : Cartographie des processus DSI et correspondance avec les rfrentiels SI existants

3.1 ISO 9001
3.1.1 Quest-ce que ISO 9001, exactement ?
En guise de prambule, prcisons quun rfrentiel est une collection de bonnes pratiques sur un sujet donn. Une norme se
diffrentie des rfrentiels dans la mesure o il sagit dun document dit par une instance de normalisation indpendante, en
loccurrence, ISO (International Organization of Standardization), qui dispense le plus souvent, suite un audit, une accrditation gage
de qualit et de comptence.
ISO 9001 est une norme internationale qui dfinie les exigences de la gestion de la qualit dune entreprise ou dune de ces entits
(filiale, dpartement, service). Elle est une norme internationale de gestion gnrale de la qualit. En ce sens, elle est comparable au
Plan Comptable de la comptabilit gnrale.
Elle prend en compte la gestion non financire de lentreprise, de la mme faon quIFRS/IAS prend en compte la gestion financire de
lentreprise. La bonne corrlation de ces deux gestions est au cur de la production de richesse et, notamment, de linnovation.
Les exigences rpertories par ISO 9001 sont analogues des pratiques gnriques applicables tous les mtiers. De fait, toutes sortes
dentreprises peuvent faire certifier conforme ISO 9001, leurs solutions de gestion de la qualit : un restaurant dentreprise, un centre
hospitalier, une SSII.
Un certificat dure 3 ans. Il est renouvelable chaque anne. Ainsi de la mme faon que la gestion financire peut tre certifi conforme
IFRS/IAS par des commissaires aux comptes. Chaque anne, des commissaires aux comptes qualits ralisent un audit de la gestion
de la qualit.
3.1.2 Quest-ce que nest pas ISO 9001 ?
ISO 9001 nest pas un rfrentiel de bonnes pratiques spcifiques un mtier. De la mme faon quil serait absurde de demander
IFR/IAS une expertise sur les mtiers de lentreprise, de la mme faon ISO 9001 ne fournit pas de rponse dexperts mtiers pour la
mise en uvre des meilleures pratiques mtiers.
Les bonnes pratiques doivent prexister et sur ce socle vient se greffer la gestion de leur qualit. Cette gestion de la qualit accroit la
visibilit sur les bonnes et les mauvaises pratiques. Elle est un outil daide la dcision qui permet didentifier les activits les plus
porteuses de satisfaction client. Elle fiabilise la mise en uvre rgulire et stable des activits prvues et de leurs rsultats attendus.
Elle garantie que lentreprise rflchit collectivement et mthodiquement en vue de samliorer en permanence.
3.1.3 Que sattend-t-on trouver dans une entreprise certifie ISO 9001 ?
Une entreprise certifie ISO 9001 est une entreprise de confiance, dynamique, qui bouge en permanence, qui accroit ses performances
avec une gestion de la qualit garantie.
Cette entreprise possde :
Un dispositif de surveillance du bon niveau de satisfaction client dont la prise en compte mthodique des rclamations
ventuelles. Dans une entreprise certifie, toute non-conformit, dont une rclamation client, est prise en compte, ses causes
sont analyses. Un plan dactions correctives et prventives est men terme de faon radiquer les causes du
mcontentement ;
Du personnel comptent. Chacun a un poste bien dcrit et sait qui fait quoi dans lentreprise. Une gestion prvisionnelle des
emplois et des comptences est mise en uvre. Le personnel est form rgulirement pour maintenir ses comptences et les
faire voluer en fonction des besoins. Plan de formation, bilan de formation, catalogue de formation sont des outils ordinaires
de la gestion des comptences;
Des environnements de travail qui respectent les dispositions lgales et un document unique de prise en compte des risques du
travail qui est maintenu jour ;
Une production de la qualit qui fait lobjet dune gestion tablie connue de chaque membre du personnel ;
Des activits professionnelles bien dcrites et maitrises sur la base desquelles des dcisions factuelles sont prises et des
amliorations permanentes sont ralises ;
Une Direction Gnrale qui simplique dans une progression constante de lefficacit de la gestion de la qualit en suivant
latteinte des objectifs qualit considrs comme des lments cls de la performance rgulire de lentreprise ;
Des rgles de gestion transparentes de la qualit :
- Une documentation professionnelle maitrise et tenue state of the art .

- Des activits cls dont les traces sont archives, scurises et analyses pour samliorer sur une base pragmatique et
apporter des preuves de leur ralisation.
- Sil en existe des non-conformits dans les activits et leurs rsultats, celles-ci sont mthodiquement traites pour
empcher leur utilisation. Ceci est systmatique quil y ait des engagements contractuels ou pas.
- Les non-conformits existantes sont traites de faon radiquer toutes celles qui sont analogues mme si elles ne sont
pas encore signales, puis traiter les causes de celles qui pourraient potentiellement survenir.
- La gestion de la qualit est rgulirement et formellement audite en interne en sus des audits de suivi des auditeurs
Veritas.
3.1.4 Sur quels principes repose la gestion de la qualit ISO 9001 ?
Huit principes prsident une gestion de la qualit conforme la norme internationale de gestion de la qualit ISO 9001.
Chaque entreprise certifie met en uvre chacun de ces principes.
Lorientation client : les objectifs non-financiers sont prioriss afin damliorer le fonctionnement des activits dans le but de
contribuer significativement aux objectifs daffaire dfinis par la Direction Gnrale.
Le leadership : la Direction Gnrale tablit les objectifs et les orientations daffaire qui sont communiqus aux rgisseurs des
activits mtiers. Ces derniers simpliquent en dterminant les objectifs non-financiers et leur dispositif de suivi.
Limplication du personnel : la Direction de la Qualit, avec le relais des rgisseurs des activits mtier, assure la promotion de
la politique de gestion de la qualit auprs du personnel.
Lapproche processus : chaque rgisseur mtier assure la bonne tenue de linventaire de ses activits qui sont classes par
finalit et pour lesquelles les ressources et les parties prenantes sont dcrites.
Management par lapproche systme : les offres de service de valeur sont le plus souvent le fruit de la contribution
constructive de plusieurs patrimoines mtiers. Identifier, comprendre et grer ses contributions participent la performance.
Une matrice dinteraction entre patrimoines identifie les changes prvus pour des interactions constructives.
Lamlioration continue : chaque rgisseur mtier contribue de faon autonome ou concerte lamlioration de la valeur, de
la notorit et la performance. Laspect continu consiste en laptitude proposer des objectifs intermdiaires raisonnables et
tals dans le temps pour atteindre un objectif complet de faon fiable et progressive.
Lapproche factuelle pour la prise de dcision : les dcisions efficaces se fondent sur lanalyse des donnes et dinformations
issues, par exemple, de tableaux de bord de suivi dactivit.
Relations mutuellement bnfiques : lentreprise favorise la construction de relations durables de partenariats avec ses clients
et avec ses fournisseurs. En interne, les patrimoines mtiers sont interdpendant et sont encourags partager des ressources,
tablir des activits communes damlioration, bref, travailler ensemble. Enfin, lattractivit de lentreprise, vis--vis des
investisseurs et des coles, est pilote afin dentretenir des relations mutuellement bnfiques.

Figure 12 : Schma illustratif de ISO

3.1.5 Comment seffectuent les contrles ?
Les contrles seffectuent plusieurs fois par an par des revues et des audits :
Une revue de direction annuelle est obligatoire selon un ordre du jour tabli par la norme internationale ISO 9001. Elle prouve
que la D. Gnrale et le personnel rgisseur de la qualit simpliquent et rflchissent la surveillance de la satisfaction client,
la gestion des comptences, la maitrise des risques, au fonctionnement des activits, leur progrs permanent et au
traitement systmatique et durable des carts
Un audit interne annuel mthodique qui examine le respect du cahier des charges de la norme internationale ISO 9001
Un audit de suivi annuel par un bureau de certification accrdit, les commissaires aux comptes de la qualit.
Au final sur la dure dun certificat, le respect des exigences de la norme internationale est vrifi 9 fois dont 3 fois par un bureau
accrdit qui peut, chaque anne, suspendre le certificat ou le renouveler.

3.2 CMMI (Capability Maturity Model Integration)
Cr aux Etats Unis dans les annes 80, sous le signe CMM par les SEI (Software Engineering Institute), il a depuis volu
pour arriver aujourdhui tre dclin en diffrents secteurs : dveloppement, service,
3.2.1 Quest-ce que CMMI exactement ?
Ce modle permet dvaluer des pratiques mises en place en fonction de critres trs prcis et trs pragmatiques. Une entreprise qui
souhaiterait fonder son systme de gestion de projet sur lunique base du guide CMMI, irait lchec. On ne fabrique pas un bateau
partir de tests de flottabilit.
Cette comprhension de ce quest CMMI et de ce que nest pas CMMI est fondamentale pour une socit qui entreprend une telle
dmarche de certification. Lexprience dAubay dans ce domaine, en est une illustration.
CMMI analyse lensemble de lactivit dun projet par zones de fonctions. Ces zones sappellent Process Area (PA). Ces zones sont au
nombre de 22. Pour chacune de ces PA, CMMI dtermine des pratiques spcifiques, regroupes par Specific Goals (SG), et 15 pratiques
gnriques communes toutes les PA (GP), regroupes par Generic Goals (GG)
Quelques exemples de PA/SG/SP :
Project Planning
Project Monitoring and Control
Risk Management
Process and Product Quality Assurance

Ces PA sont affects des niveaux, de 2 5, par ordre croissant de conformit au modle complet (Le niveau 1 correspond un niveau
reposant uniquement sur les connaissances des personnes, sans surveillance, sans documentations, sans stratgie. Il nest pas sujet
certification).
Ainsi, pour obtenir une certification de niveau 2 (managed), seuls 7 PA sont analyses. Il y en a 11 de plus pour le niveau 3 (defined),
encore 2 de plus pour le niveau 4 (quantitatively managed) et enfin 2 de plus pour le niveau 5 (optimizing).

Figure 13 : Schma illustratif de CMMI

CMMI est donc :
Un thermomtre de la maturit, gradu et talonn, pour valuer officiellement la maturit dun dpartement de
dveloppement logiciel dune entreprise ;
Un moyen de comparaison objectif de la maturit des dpartements de dveloppement logiciel de diffrentes entreprises ;
Un outil pour piloter des amliorations de la maturit des activits de dveloppement logiciel et raliser des mesures
intermdiaires ;
Un rfrentiel sectoriel de qualit analytique pour les pratiques des projets de dveloppement logiciel et de maintenance
applicative.
3.2.2 Quest-ce que nest pas CMMI ?
CMMI nest pas un rfrentiel dans lequel piocher des bonnes pratiques dployer. Les bonnes pratiques sont inventer et dployer
par chaque entreprise. Ensuite, cest la compatibilit de ces pratiques avec CMMI qui sera mesure. Autrement dit, il ne sagit pas de
dployer les pratiques du modle de maturit CMMI pour obtenir le niveau de maturit escompt. Ainsi, chaque dpartement certifi
doit dfinir et ancrer trs solidement ses propres pratiques de dveloppement logiciel afin dtablir la maturit vise. Il en dcoule,
dans cette optique, une certaine rigidit qui, pour une socit de service, doit saccompagner dun cadre dintgration mthodique et
efficient des pratiques de dveloppement logiciel de ses clients. En effet, lune des exigences frquentes des clients, lgard de la
socit de service, se formulerait paradoxalement ainsi : savoir mettre en uvre les pratiques de dveloppement logiciel de chaque
client avec la maturit requise .
CMMI nest pas un modle unique. Il y a en fait trois constellations CMMI :
CMMI-DEV, le modle historique destimation de la maturit des activits de dveloppement logiciel dun dpartement,
CMMI-ACQ, le modle pour lestimation des activits dacquisition (un service achat ou une direction mtier pourrait, chez un
grand compte, dcider datteindre un niveau de maturit 2 ou 3),
CMMI-SVC, le modle pour lestimation de la maturit des activits de service delivery (un dpartement dexploitation
informatique pourrait dcider datteindre un niveau de maturit 2 ou 3 ; nous avons compris que cette constellation entrait en
concurrence avec ITL/ISO 20000).
CMMI fournit la cible atteindre et une faon de mesurer objectivement une collection de processus, mais il ne dit pas comment
dfinir une solution pour atteindre la cible le plus efficacement possible. En consquence, le conseil dexperts accompagnateurs et
valuateurs est quasiment obligatoire afin de garantir en permanence la compatibilit de la solution en construction avec la cible CMMI
vise.
CMMI est donc un modle dvaluation des pratiques de gestion de projet. Il est important de bien intgrer que ce nest pas un guide,
ni un mode demploi, ni une proposition de fonctionnement.
3.2.3 Comment maintenir son niveau de maturit ?
Une valuation CMMI, dtes scampi A, est acquise pour une dure de 3 ans et publiable sur le site de linstitution CMMI, le Software
Engineering Institute
1
.
Le plus souvent, un gros effort initial est fait pour obtenir une valuation conforme au niveau de maturit escompt. Trois ans plus
tard, quen est-il de leffort faire pour renouveler lvaluation pour un niveau de maturit au moins quivalent ? Quen est-il de
lintrt du management pendant ces 3 ans ?
Une des solutions les plus frquemment rencontres est dallier la qualit gnrale ISO 9001 la qualit analytique sectorielle CMMI
La qualit gnrale ISO 9001 avec son audit annuel amne, porter rgulirement et mthodiquement lattention, chaque
anne, au moment de la revue de direction annuelle, sur les pratiques de gestion maitrise de la qualit ;
Au niveau 2 de maturit, la gestion des activits est porte par chaque projet. Chaque projet est oblig de mettre en uvre son
propre dispositif de gestion chaque fois. La capitalisation entre les projets est faible. Autrement dit, le cot de maintenance
de ce niveau est assez lev. A ce niveau, il y a une multitude de projets, tous biens grs et administrs par le dpartement de
dveloppement logiciel valu. Or ISO 9001 amne porter le regard sur lefficacit de la gestion. En consquence, ISO 9001
encourage la gestion efficace des processus dont ceux de dveloppement logiciel inclus dans le modle CMMI-DEV.
Au niveau 3 de maturit, une infrastructure damlioration est tablie au niveau du dpartement de dveloppement logiciel. La
capitalisation inter projet est relle et les cots sont rpartis. A ce niveau, les activits dingnieries, de gestion des processus
de dveloppement font lobjet dune estimation au mme titre que celles de gestion et de support dun projet. Ici le
dpartement logiciel valu possde un vritable savoir-faire collectif quil redistribue, de faon adapte leur contexte,

1
voir http://sas.sei.cmu.edu/pars/pars.aspx

auprs de chaque projet mis en uvre. Chaque projet, son tour, enrichit le savoir-faire collectif du dpartement. Lorsque le
niveau 3 est bien tabli, son cot de maintenance est beaucoup plus faible que celui du niveau 2 la condition que le
management continue simpliquer rgulirement. Dans ce cas, ISO 9001 permet de maintenir continument lintrt du
management pour la gestion efficace des processus.
3.2.4 Que sattend-t-on trouver dans une entreprise dont un service
est valu selon CMMI ?
Une entreprise qui justifie dun dpartement de maturit CMMI dau moins 2 fournit :
La garantie davoir en permanence du personnel comptent sur les activits de dveloppement logiciel. Par consquent,
lentreprise peut fournir les ressources comptentes escomptes lorsquelle ralise un projet ;
Un savoir-faire pour la gestion maitrise du droulement rgulier de chaque projet conduit par le dpartement valu ;
La preuve que les activits de dveloppement logiciel constituent une activit rgulire, bien tablie et bien gre dans le
service valu de lentreprise ;
Un essaimage des bonnes pratiques de dveloppement du dpartement travers lentreprise, dans la mesure o la rotation du
personnel, dans le dpartement certifi, est bien organise.
3.2.5 Quelles comptences pour mettre en uvre des activits ?
La maturit dun dpartement est lie aux pratiques quil met en uvre donc aux comptences du personnel du dpartement. Sans
comptences disponibles et pertinentes, pas de pratiques donc pas de maintien de la maturit. Ainsi, le personnel doit tre en
permanence form, impliqu, inform. Ceci surtout lorsque le turnover est important ou en cas de recours la sous-traitance.
A quelles pratiques former le personnel ?
Aux pratiques de dveloppement logiciel du dpartement et non pas aux pratiques CMMI.
Quel est lintrt de connatre le modle CMMI ?
Suivre le cours dintroduction officiel CMMI garantira que le personnel a compris limportance dapprendre et de mettre en
uvre les pratiques de dveloppement logiciel du dpartement.
Donner confiance un client sur le srieux du prestataire. Cependant, en aucun cas, cela ne remplacera lapprentissage des
pratiques de dveloppement locales du dpartement dans lequel le prestataire ralise sa mission.
3.2.6 Comment seffectuent les contrles ?
Les contrles CMMI sont :
Une valuation approfondie qui a lieu tous les trois ans ;
Aucun contrle formel nest exig durant la priode de validit de 3 ans de lvaluation. Bien videmment, le bon sens et les
cots de maintenance veulent quun contrle informel rgulier soit effectu et que les carts soient traits.

3.3 ITIL (Information Technology Infrastructure Library)
3.3.1 Qu'est ce qu'ITIL ?
ITIL est l'acronyme de "Information Technology Infrastructure Library", ce qui peut se traduire en franais par "Bibliothque de
l'Infrastructure des Technologies de l'Information". En ralit, ITIL n'est pas une mthode mais un ensemble de bonnes pratiques. Il
s'agit d'une collection de livres qui recense, synthtise et dtaille les meilleures pratiques du monde entier dans la fourniture de
services informatiques.

Figure 14 : Schma illustratif de ITIL
3.3.2 quoi sert-il ?
L'adoption des bonnes pratiques d'ITIL par une entreprise permet d'assurer ses clients, internes comme externes, un service
rpondant des normes de qualit prtablies au niveau international.
ITIL permet, grce une approche par processus clairement dfinie et contrle, d'amliorer la qualit des systmes d'information et
de l'assistance aux utilisateurs en crant notamment la fonction, au sens dpartement de l'entreprise, de Centre de Services (ou Service
Desk).
ITIL a pour cible privilgie le fait que les services dlivrs par les technologies de l'information soutiennent le mtier de l'entreprise et
les activits associes, de manire efficace et rentable. Les directions informatiques trouveront avec ITIL une mise en uvre qui leur
permettra d'atteindre leurs objectifs de qualit et de matrise des cots.
Sur ce primtre, ITIL reprsente l'approche la plus complte et la plus structure du march.

3.3.3 D'o vient ITIL ?
ITIL est ne en Angleterre la fin des annes 80, la suite de la politique de "Market Testing" (mise en concurrence systmatique des
prestations internes, notamment informatiques, avec l'offre du march) impose par le gouvernement Thatcher aux administrations et
entreprises publiques britanniques.
Ce rfrentiel de meilleures pratiques a t labor par des groupes de travail runissant des responsables oprationnels, des experts
indpendants, des consultants spcialiss et des formateurs, sous l'gide de la CCTA (Central Computer & Telecommunications
Agency). La CCTA est une agence gouvernementale anglaise charge d'amliorer l'efficacit et la qualit des services informatiques
centraux des ministres. Depuis, elle est devenue l'OGC (Office Government of Commerce).
ITIL a connu un essor rapide en Angleterre. Puis elle a t adopte par plusieurs dpartements ministriels et par de grandes
entreprises publiques et prives aux Pays-Bas. Elle a poursuivi son dveloppement dans de nombreux pays travers le monde,
devenant ainsi un standard de facto, sous l'impulsion de l'ITSMF (IT Service Management Forum une association des utilisateurs
d'ITIL).
Le dveloppement d'ITIL est assur aujourd'hui conjointement par l'OGC, l'ITSMF, l'ISEB et l'EXIN. L'ISEB (Information Systems
Examination Board) et l 'EXIN (EXamination INstitute) sont deux organismes publics, respectivement anglais et hollandais ayant pour
principales responsabilits la dfinition des programmes de certification pour les individus (professionnels intresss par l'ITIL) ainsi
que l'accrditation des organismes de formation habilits dlivrer des certifications ITIL.
3.3.4 Utilisation d'ITIL
La philosophie d'ITIL est d'adopter une dmarche suffisamment souple pour s'adapter toutes les organisations, petites ou grandes.
Elle part du principe que la gestion des services est constitue d'un certain nombre de processus troitement lis entre eux et
fortement intgrs.
Pour que les principaux objectifs en matire de gestion des services puissent tre atteints, ces processus doivent utiliser les ressources
humaines et les produits de manire efficace, rentable et conomique de sorte que les services lis aux technologies de l'information
soient innovants, de haute qualit et adapts aux processus de l'entreprise.
Les organisations ne doivent pas tre trop ambitieuses lors de la mise en uvre de la gestion des services. La plupart d'entre elles
possdent dj des lments d'organisation dploys et oprationnels.
L'activit de mise en uvre de la gestion des services concerne donc plutt l'amlioration des processus existants. Pour ce faire, il est
ncessaire de bien connatre son point de dpart en valuant la maturit de ces processus. De plus, pour engager une telle dmarche, il
est ncessaire de s'assurer la fois de l'implication du management et que les conditions d'un changement culturel soient satisfaites.
Les processus de gestion des services peuvent tre mis en uvre les uns la suite des autres ou simultanment et chaque processus
peut tre dcompos en une srie d'activits. L'utilisation de ces meilleures pratiques est soutenue par un ensemble de formations et
de certifications utilises dans le monde pour reconnatre les comptences professionnelles des individus.
3.3.5 Quels sont les bnfices de la dmarche ITIL ?
Les bnfices de l'adoption de la dmarche ITIL pour une entreprise constituent une meilleure traabilit de l'ensemble des actions du
dpartement informatique.
Ce suivi amlior permet d'optimiser en permanence les processus des services pour atteindre un niveau de qualit maximum de
satisfaction des clients.
Les plus values constates, lors de sa mise en uvre, sont gnralement les suivantes :
la satisfaction des utilisateurs (personnel de l'entreprise ou clients),
la clarification des rles,
l'amlioration de la communication entre les diffrents services de l'entreprise,
la mise sous contrle des processus l'aide d'indicateurs pertinents et mesurables permettant d'identifier des leviers
d'conomies,
une meilleure comptitivit,
une scurit accrue (disponibilit, fiabilit, intgrit),
la capitalisation des donnes de l'entreprise,
l'optimisation de l'utilisation des ressources.
ITIL permet aux entreprises de capitaliser sur une exprience pratique de bientt 20 ans sur la gestion des services informatiques et de
gagner du temps en vitant de rinventer des lments (processus, rgles de gestion, descriptions de postes, etc.) dj tests et
prouvs par de nombreuses autres entreprises dans le monde. ITIL apporte donc un cadre de rfrence commun avec l'apport d'un
vocabulaire cibl et d'une structuration des activits pour l'optimisation des services informatiques.

ITIL permet de faciliter le dialogue entre les diffrents acteurs :
entre DSI et DG,
entre DSI et utilisateurs ou clients,
entre DSI et quipes informatiques,
entre DSI et prestataires externes.

3.3.6 Les processus ITIL V2
Deux grandes catgories de processus forment la base de ITIL V2.

Processus de type Soutien des services
(Service Support)
Processus de type Fourniture des Services
(Service Delivery)

Ces processus sont abondamment dtaills en annexe.

3.3.7 ITIL en 3 points
Pour rpondre l'adquation entre le mtier de l'entreprise et les services fournis par les technologies de l'information, on peut retenir
trois ides importantes qui sous-tendent la philosophie ITIL :
L'orientation client
L'utilisateur ou le client est positionn au centre des proccupations de la direction informatique et toutes les activits de
l'informatique doivent s'inscrire dans une relation client-fournisseur.
2
Les services s'apprhendent travers un cycle de vie
La gestion des services, pour tre efficace, doit tre prise en considration en amont des projets informatiques, ds les
phases d'tude et de conception.

L'approche par les processus
La qualit de service repose sur un modle d'activits se dclinant dans la mise en place de processus informatiques
appropris en troite corrlation avec les processus mtiers.

3.4 Rfrentiels et certification
Passer une certification sur un rfrentiel Qualit, cest se donner un temps, une respiration (parfois assez longue) pendant laquelle
lentreprise sinterroge sur ses pratiques internes et annonce au monde 3 vrits :
1- Oui je sais ce que je dois faire ! : ses processus mtiers sont identifis
2- Oui je sais comment le faire ! : ses processus sont dfinis en termes dtapes et dacteurs
3- Et oui je peux le refaire ! : ses processus sont tracs et reproductibles

Lentreprise sest value, elle se connat parfaitement (ses processus) et le fait savoir.

Mais si le chemin vers la connaissance est parfois sem dembche et la dmarche de certification lourde, elle assoie la lgitimit de
lentreprise dans son secteur dactivit. Dans le domaine de linformatique, cest devenu de plus en plus un pr-requis pour les SSII qui
ambitionnent de grer des forfaits de plus en plus importants.
Une certification officielle sur au moins un de ces rfrentiels est une ncessit mais hlas, elle nest pas suffisante. Les SSII et DSI
peuvent aussi avoir besoin doptimiser leurs processus. Le chapitre suivant dcrira donc de manire large quelques unes des
mthodologies doptimisation des processus.
3.5 Conclusion
Deux phnomnes parallles expliquent le besoin de mettre en uvre un rfrentiel de gestion des projets lis au SI.
Lalignement stratgique, dune part, est un besoin fondamental prendre en compte pour la gestion des SI. Il sagit tout simplement
de reconnaitre que pour la plupart des organisations, les SI ne font pas partie du cur de mtier . Ils ont donc une fonction support.
Ainsi, la Direction des SI participe la ralisation et au succs des objectifs mtiers. Lalignement stratgique nest autre que
lassurance que la stratgie et la gestion des SI est en conformit troite avec les objectifs mtiers. Cette assurance ne peut tre
obtenue que par ltablissement de processus de communication, de contrles et de dcisions conjointes systmatiques entre le
mtier et les quipes des SI. Les rfrentiels de mthode et de bonnes pratiques peuvent aider et guider dans la mise en place de ces
processus et principes de gouvernance. Ils permettent de systmatiser les processus de dcision et standardiser les contrles afin de
matriser la gouvernance et contrler la qualit des applicatifs livrs.
Les rfrentiels rpondent aussi un autre besoin qui dcoule dune ralit simple : La gestion des SI est rgie par une obligation de
moyens et non pas de rsultat. Ce constat est le corollaire logique du fait que les SI sont une fonction support. Au contraire du produit
final, les applicatifs supports ne sont pas directement sanctionns par le march, sauf lorsquils sont entirement externaliss. Les
rsultats doivent tre jugs selon un critre de qualit. Or la qualit perue des SI dpend en grande partie de la satisfaction des
utilisateurs, cest une donne essentiellement subjective et mesure posteriori, ce qui constitue deux inconvnients majeurs. La
solution qui consiste passer dune obligation de rsultat vers une obligation de moyens permet la fois dtablir des critres objectifs
(respect des normes, bonnes pratiques tablies) et dutiliser les mesures afin dvaluer la qualit des rsultats futurs. Les rfrentiels
mthodologiques rpondent ce problme et permettent de mettre en place des mesures objectives de respect des obligations de
moyens. Ces mesures ont lavantage dtre plus facilement mesurables, et de donner une assurance de qualit des services futurs,
puisque ce nest pas la qualit du projet livr qui est juge, mais la maturit de lorganisation travers limplmentation de processus
standards de contrle et de mesure. Les rfrentiels mthodologiques impliquent un glissement de la nature de lobligation. On
demandera aux responsables de projet de prouver que les processus ont t respects, au lieu de leur demander que leurs projets
aboutissent sans incidents.
Nous avons donc voulu poser le problme du point de vue de lorganisation, de la DSI qui souhaite tirer avantage de limplmentation
de ces standards.
Il ressort de notre exprience que ce nest pas tant le choix dune mthodologie particulire qui pose problme, mais surtout la
manire dont ces normes et standards sont appliqus et mis en place concrtement pour chaque activit. Le choix des normes et
standards mthodologiques doit tre fait selon une analyse stratgique de lexistant et des objectifs long terme. Les objectifs de la
DSI sont dtermins en amont sur la base du principe dalignement des Systmes dInformation aux objectifs mtiers de
lorganisation. Mais sils sont dcids en amont, cest lors de la mise en uvre de la stratgie quils sont raliss. Ces objectifs doivent
donc tre poursuivis constamment lors du choix dun rfrentiel pour la DSI et tout autant au niveau de lapplication de ce rfrentiel
dans la gestion des projets au quotidien. Depuis les choix les plus stratgiques jusquaux recommandations de mise en uvre des
mthodes de projet, les bnfices attendus doivent tre clairement retranscrits et rester le souci permanent de tous les acteurs du
changement.
Le principal problme est organisationnel et non technique. Il sagit de transformer les pratiques, les processus et les rles afin de
modeler une organisation ayant une mme logique dun bout lautre de la chane de valeur. Par exemple, une fois une mthode
choisie comme standard, la mise en uvre peut tre diffre dans le temps et sur un primtre plus ou moins tendu, et pousse des
degrs divers de perfectionnement. Ces phases de mise en uvre dpendent tout particulirement des efforts fournis en conduite du
changement.

4 METHODOLOGIES DOPTIMISATION DES PROCESSUS
Aprs le prcdent rapide parcours des principaux rfrentiels qualits, le chapitre suivant a pour ambition de prsenter quelques
mthodologies doptimisation des processus que lon trouve au sein dune DSI. Ces mthodologies peuvent se rpartir selon diffrents
niveaux :
Les mthodologies de niveau Stratgique traitent des axes budgtaires, de la satisfaction des clients (utilisateurs), des
processus et du capital humain. Exemple de mthodologie de ce niveau : Balanced Scorecard, benchmark, Lean Management,
etc. Les outils de ce type de mthodologies sont proches des analyse SWOT, forces de Porter, chane de valeurs, matrice du
BCG,
Les mthodologies de niveau Tactiques ont plus orientes vers loptimisation des processus oprationnels. Louvrage
comportera un chapitre spcifiquement ddi aux mthodes de gestion de projet de dveloppement. A ce niveau, il existe
plthore de mthodes comme RUP, Scrum, XP Dans cette catgorie, on note la tentative de normalisation de la gestion de
projet par lorganisation PMI (Project Management Institute).

4.1 Mthodologies de niveau stratgique
Les mthodologies de niveau Stratgique sont importantes connaitre car, en plus dtre applicable directement par la DSI pour ses
propres besoins damlioration de ses processus internes, elles peuvent aussi provenir de la Direction Gnrale qui demande la DSI
dappliquer ses recommandations.

Figure 15 : Du rve la mise en uvre avec les mthodologies au service de la DSI

4.1.1 Balanced Score Card
Le Balanced Scorecard (BSC) propose un nouveau mode de management et de pilotage de l'entreprise en s'appuyant sur la mise en
place d'un cadre rigoureux d'laboration et de dploiement de la stratgie garanti par l'quilibre permanent de 4 perspectives.
Perspective financire : que faut-il apporter aux actionnaires ? Quelle est notre performance au sens des actionnaires ?
Perspective client : que faut-il apporter aux clients ? Quelle est notre performance au sens des clients ?
Processus interne : quels sont les processus essentiels la satisfaction des actionnaires et des clients ? Quels sont nos
avantages internes ?
Apprentissage organisationnel : comment piloter le changement et l'organisation ? Allons-nous progresser et comment ?

Le rsultat vis est de niveau stratgique . Par exemple :
Satisfaction des actionnaires
Clients enchants
Processus efficaces et efficients
Motivation des ressources humaines

Figure 16 : Exemples daxes doptimisation selon les 4 perspectives stratgiques

Le dispositif BSC permet donc de dfinir une stratgie ou une vision en phase avec des objectifs terrains ralistes. Il sappuie sur une
analyse terrain, autour des processus, des hommes et de lorganisation qui confirme que la stratgie est faisable et qui met en
vidence dun ct les risques, de lautre les conditions de succs. L'valuation de la performance est effectue l'aide de cartes de
scores (scorecard) et la rmunration des managers est directement lie la performance ainsi exprime.


Figure 17 : Exemple illustr dune balanced scorecard

Quelques prcautions prendre dans lapplication de la mthode :

1) raisonner par mtiers et activits homognes : trouver les indicateurs judicieux de mesure de la cration de valeur par branche et
ses spcificits (pas de dmarche qui part de la direction gnrale dun groupe plusieurs activits)
2) boucler avec la stratgie en fin de parcours. Si lon dmarre par ce volet, on prend trois risques : philosopher, attendre que la
stratgie soit dfinie et se couper du terrain.
3) sappuyer sur une analyse correcte et dimensionne des Processus et de leurs conditions de russite. En effet, la naissance de la
performance est issue :
dune organisation efficace des processus ;
dhommes forms, motivs, comptents ;
de linnovation, de la veille, de la recherche ;
doutils informatiques manags et matriss ;
dune matrise de la technologie du mtier, etc.

Le mot important dans balanced scorecard est "balanced".

La traduction franaise "tableau de bord quilibr" est prfrable "tableau de bord prospectif". Elle convient mieux l'ide des
auteurs. Robert Kaplan et David Norton ont opt pour le terme de "balanced" scorecard afin de mettre l'accent sur la notion
d'quilibre.
Equilibre entre les objectifs court et moyen/long terme
Equilibre entre les indicateurs financiers et non-financiers
Equilibre entre les indicateurs mesure de la performance passe et les indicateurs "prospectifs"
Equilibre entre la perception externe et la performance ralise interne

Lobjectif ntant pas ici de dtailler la mthode pour laquelle il existe de nombreux ouvrages de rfrence, le balanced scorecard est,
en rsum, un outil ayant pour objectif de traduire la mission et la stratgie dune organisation en indicateurs et initiatives concrets,
mesurables qui se dclinent ensuite en autant dactions et dinitiatives entreprendre pour raliser la stratgie.


Figure 18 : Le cheminement de la rflexion aboutissant laction

Selon cette introduction, son application doit donc permettre de mesurer la performance dune DSI en tant quorganisation. Tentons
lexercice. Voici ce que pourraient tre les objectifs et mesures associs une DSI :

Perspectives Objectifs Mesures ou indicateurs
Finances Contrle des cots
Budget global de la DSI,
ROI des projets
Rpartition CAPEX / OPEX
Cot de maintenance du parc applicatif
TJM par profil type
Clients (directions
oprationnelles)
Satisfaction du service reu
Adquation des applications aux
processus mtiers

Satisfaction utilisateurs
Nombre de dysfonctionnements remonts
Respect des dlais de livraison des applications
Ergonomie conviviale
Taux dutilisation du support papier
Processus
Activit dachat
Gestion dquipement
Rapidit des dveloppements
Performance des recettes
Nombre rduit de fournisseurs
Dlais (court) de livraison des dveloppements
Taux dindisponibilit des applications
Capital humain
Implication du personnel (motivation)
Capacit dvolution (adaptation aux
nouvelles technologies)
Capacit dinitiative et dautonomie
Taux de rotation
Taux dabsentisme
Taux de formation
Dpense en recherche et dveloppement

La mthode ne se termine jamais, en effet, elle boucle sur un processus damlioration continue comme illustre ci-aprs.


Figure 19 : Processus damlioration continue

4.1.2 Six Sigma
Mthode structure de management visant une amlioration de la qualit et de l'efficacit des processus. La mthode Six Sigma a
dabord t applique des procds industriels avant dtre largie tous types de processus, notamment administratifs, logistiques,
commerciaux et d'conomie d'nergie.
La mthode Six Sigma se base sur une dmarche fonde la fois sur la voix du client (enqutes, etc.) et sur des donnes mesurables
(par indicateurs) et fiables. Cette mthode est utilise dans des dmarches de rduction de la variabilit dans les processus de
production (ou autre) et au niveau des produits et vise ainsi amliorer la qualit globale du produit et des services.
Six Sigma repose sur les notions de client, processus et mesure ; il s'appuie en particulier sur :
les attentes mesurables du client ;
des mesures fiables mesurant la performance du processus mtier de l'entreprise par rapport ces attentes ;
des outils statistiques pour analyser les causes sources influant sur la performance ;
des solutions attaquant ces causes sources ;
des outils pour contrler que les solutions ont bien l'impact escompt sur la performance.

Chaque tape possde des outils diffrents qui sont regroups dans une dmarche cohrente. Typiquement, la gamme d'outils utiliss
dans chacune des phases est (cette liste n'est pas exhaustive) :
Dfinir : voix du client, cartographie des processus,
Mesurer : analyse de systmes de mesure, capacits, diagrammes d'Ishikawa
Analyser : cartographie dtaille des processus (par exemple, analyse de la valeur ajoute), tests d'hypothses (ANOVA, ,
tests de variances, ), plans d'exprience
Amliorer : plans d'expriences, AMDEC, poka yoke
Contrler : plans d'exprience, MSP

Bnfices directs Bnfices indirects, intangibles
Contrle des tailles dquipe Gain de productivit
Rduction des cots directs Effet de conservation des clients
Rduction des dlais Morale quipe en augmentation
Augmentation des investissements

Par contre, les barrires lapplication de la mthode peuvent tre nombreuses :

Freins potentiels Consquences possibles
Objectifs peu clairs de linitiative Incomprhension des acteurs impliqus
Valeur de la mthode non reconnue Faible motivation des acteurs impliqus
Perception que la mthode est consommatrice de
temps
Faible motivation des acteurs impliqus
Confiance fiable durant les premires tapes Faible motivation des acteurs impliqus
Manque de sponsoring de la direction Droulement chaotique du process
Attente de rsultat immdiat Effet de dception sur le court terme
Manque de coaching adquate Effet de dception sur le court terme

Afin dviter ces checs dans le droulement de la mthode, une certification des acteurs coachs est indispensables. Les diffrents
niveaux de certification sont :
Le Green Belt ( ceinture verte ), dont on attend qu'il consacre partiellement son temps (souvent autour de 25%) la conduite
de projets d'amlioration.
Le Black Belt ( ceinture noire ), chef d'quipe qui se consacre plein temps l'amlioration (conduite de projets, formation
des Green Belts voire d'autres Black Belts) et doit matriser la mthode dans son ensemble. Il est plus spcialis soit en DMAIC,
soit en DFSS.
Le Master Black Belt, mentor et formateur de Blacks Belts, garant du respect de la dmarche, encadre les Blacks Belts
hirarchiquement.
Le Deployment Leader ou Champion (en France, directeur du dploiement ou plus souvent directeur du systme
d'excellence ), charg d'laborer la stratgie, le contenu de la formation, les budgets, etc.


Figure 20 : Organisation des certifications Six Sigma

Notons que le lean-six-sigma associe les mthodes qualitatives du lean management et du six sigma pour amliorer de manire
substantielle la performance logistique de l'entreprise.
Les dfauts du processus de production sont analyss et modifis en consquence. L'ide qui a donn son nom la mthode est de
rpondre aux possibilits de non conformit de part et d'autres de la moyenne de 3 carts-types (les fameux 6 sigma). Ces causes de
non conformit doivent tre matrises grce l'utilisation de tableau de bord tel que les KPI logistiques.
Elle ncessite un investissement de tous les acteurs de l'entreprise, de la direction aux utilisateurs. Certaines notions fondamentales de
la gestion d'un projet sont naturellement requises (communication, formation, implication des utilisateurs, etc.).
Les KPI logistiques sont des outils qui rpondent au besoin d'analyser le fonctionnement, les flux et les processus d'une entreprise
(performances de la supply chain). Le choix de ces indicateurs est primordial et dpend du secteur tudi ainsi que des objectifs
principaux de l'entreprise (le respect des dlais, la rduction des cots logistiques, etc.).

4.1.3 Kaizen
La mthode Kaizen d'amliorations incrmentales et continues est un concept de gestion initialement japonais pour un changement
(amlioration) progressif et continu (incrmental). Kaizen est rellement une philosophie de mode de vie. Il suppose que chaque
domaine de notre vie mrite tre constamment amlior. La philosophie Kaizen est sous-jacente beaucoup de concepts de gestion
japonais comme : Contrle Qualit Totale, Cercles de Contrle Qualit, activits en petit groupe, relations de travail.
Les lments principaux de Kaizen sont : qualit, effort, participation de tous les employs, volont de changer, et communication. Les
entreprises japonaises distinguent entre : Innovation, une forme radicale de changement, et Kaizen, une forme progressive de
changement. Kaizen signifie littralement : changez (kai) pour devenir bon (zen).

Les cinq lments de base du Kaizen
Travail d'quipe.
Discipline personnelle.
Moral amlior.
Cercles de qualit.
Suggestions pour l'amlioration.


Figure 21 : Le modle Toyota

4.1.4 Lean Management
Historique
Lcole de gestion Lean ( maigre ) puise ses sources au Japon dans le Toyota Production System (TPS).
Le Lean sest initialement dvelopp dans lindustrie, plus particulirement autour des activits de gestion de production. Gnrique et
adaptable tous les secteurs conomiques, ses prceptes se propagent dsormais jusquaux activits de services.
Le Lean Management repose sur les pr-requis de la production Juste A Temps (JAT). Le JAT consiste fournir au client le nombre de
produits quil demande au moment o il le souhaite, lendroit dsir et dans le standard de qualit et de cot fix (selon Techniques
de lingnieur, AG 5190).
Le JAT peut aussi tre dfini comme une philosophie base sur llimination de tous les gaspillages et sur la mise en uvre dune
stratgie de progrs permanent en terme de productivit (selon lAPICS).
La mise en place dun systme Lean repose sur trois fondements :
une saine gestion des stocks,
une bonne matrise des cots,
une politique de progrs permanent.

Le TPS est n aprs la seconde guerre mondiale, qui fut particulirement prouvante pour le Japon. Lindustrie japonaise moribonde
devait absolument raliser des prouesses pour survivre, malgr la relative scurit (fermeture) de son march intrieur. Eiji Toyoda,
alors directeur de lentreprise chargea Taiichi Ohno dgaler la productivit de Ford. Le systme de Ford reposait sur une production de
masse, un flux continu des lignes de production, et une conception scientifique du travail ouvrier (MTM, standardisation). Or, le
march japonais se caractrise par des petits volumes et une demande fragmente. Une simple transposition du modle amricain
tait voue lchec.
Au cours des visites dans les usines amricaines, Ohno se rendit compte de limperfection du systme amricain (chaque ligne produit
au maximum, sans coordination) qui entranait surproduction, encours colossaux, dfauts de qualit, flux chaotiques Pour Toyota, le
systme amricain se caractrisait principalement par le gaspillage, et du fait de sa situation prcaire, la chasse au gaspillage tait une
priorit absolue. Les fondements du TPS taient poss : initier une chasse drastique au gaspillage, dvelopper un flux continu, flexible
et instaurer une politique damlioration continue.

Lean Management: version Toyota Production System TPS
Les objectifs de la version TPS du Lean Management consistent liminer les gaspillages de temps et de ressources, dintgrer la
qualit dans les systmes, identifier des alternatives peu coteuses mais fiables des nouvelles technologies onreuses, perfectionner
les processus oprationnels et btir une culture damlioration continue. Cette dmarche de gestion consiste privilgier des solutions

simples et conomiques. La conception de lactivit du point de vue client permet de dfinir la valeur du produit ou service, son flux, sa
mise en uvre, sa mise en place (Kanban) et sa recherche de lexcellence.
Ainsi, lactivit se dfinit comme une succession de processus gnrateurs de valeur, sans interruption, flux tirs, en
rapprovisionnant au plus juste, brefs intervalles. A lchelle macroscopique, lentreprise fait preuve dempathie en se plaant
systmatiquement du point de vue client ; lchelle microscopique, chaque processus est considr par rapport son processus client
(le suivant).

Le Lean Management, daprs Jeffrey Liker, peut tre dvelopp suivant 14 axes de travail :

Philosophie long terme.
1 Fondez vos dcisions sur une philosophie de long terme mme au dtriment des objectifs financiers court terme.
Le bon processus produira les bons rsultats.
2 Organisez les processus en flux pice pice pour mettre jour les problmes.
3 Utilisez des systmes tirs pour viter la surproduction.
4 Lissez la charge de travail.
5 Inculquez une culture de rsolution immdiate des problmes, dobtention de la qualit du premier coup.
6 La standardisation des tches est la base de lamlioration continue et de la responsabilisation des employs.
7 Utilisez des contrles visuels pour quaucun problme ne reste cach.
8 Utilisez uniquement des technologies fiables, longuement prouves, qui servent vos collaborateurs et vos processus.
Valorisez lentreprise en dveloppant vos employs et vos partenaires.
9 Formez des responsables qui matrisent parfaitement le travail, sont imprgns de la philosophie et lenseignent aux autres (+
promotion interne).
10 Formez des individus et des quipes exceptionnels, qui appliquent la philosophie de votre entreprise.
11 Respectez votre rseau de partenaires et de fournisseurs en les encourageant et en les aidant progresser.
La rsolution continue des problmes pilote lapprentissage de lentreprise.
12 Allez sur le terrain pour bien comprendre la situation (Genshi Genbutsu)
13 Dcidez en prenant le temps ncessaire, par consensus, en examinant en dtail toutes les options. Appliquez rapidement les
dcisions.
14 Devenez une entreprise apprenante grce la rflexion systmatique (Hensa) et lamlioration continue.


Figure 22 : Lean Management TPS

Lean Management: version Excellence Oprationnelle OPEX
LExcellence Oprationnelle OPEX, au del dtre un ensemble de mthodes, repose sur le facteur humain. Il suggre que le personnel
travaille dans un tat desprit orient vers la diminution du gaspillage et des pertes dans les processus et la rduction des tapes non
gnratrices de valeur. La motivation et les comportements des hommes sont ncessaires pour une application efficace.
Le Lean Management sefforce daboutir spcifiquement dans un cycle de vie de bout en bout dans chacun des processus pour parvenir
une totale satisfaction client. Llimination du cot des rebuts de qualit ds le premier coup est moyen et effort continu pour
svaluer et constamment se contrler.
Dans un processus damlioration du service client par exemple, lexprience clients optimise fidlise la clientle. Il revient moins cher
de conserver et dtoffer une clientle rentable que dinvestir dans de nouvelles activits. Les clients fidliss assurent eux-mmes la
promotion de la socit dans leur entourage.

Figure 23 : Illustration du processus damlioration port par OPEX


Lobjectif dans labsolue tant de rechercher constamment des moyens damliorer les oprations tout en satisfaisant la clientle
rentablement, lapproche OPEX doit suivre les quatre phases essentielles sa russite. Durant la premire tape, il sagit de
comprendre les besoins clients et cadrer le projet. Ensuite, mesurer la situation actuelle par rapport aux besoins clients. Analyser les
causes premires et gnrer des solutions permet dtablir une relation entre les causes et effets de rebuts de qualit dans un
processus donn. En dernire partie vient llaboration dun plan damlioration et mise sous contrle des progrs.

Figure 24 : Les 4 phases de OPEX

Phase 1 : Dfinir le Projet
Lidentification et dfinition des problmes et des attendus des clients permet de mieux comprendre lenjeu durant la premire phase
de la mthodologie OPEX. Cette phase permet didentifier les besoins des clients et de fixer les objectifs, notamment par une
cartographie de processus de haut niveau pointant le processus amliorer. Une analyse cots et bnfices de haut niveau synthtise
le primtre du projet afin que le sponsor consente la poursuite du projet ou non. Dans le cas o le projet est valid et promu, le
sponsor constitue une quipe, dfinit les premiers jalons, met toutes les parties prenantes en adhsion pour fixer des objectifs
spcifiques et mesurables.
Lobjectif de la dfinition du projet et de sassurer que les ressources soient alloues aux projets prioritaires. Ensuite, identifier le
problme et lobjectif du projet en des termes mesurables pour mieux comprendre la complexit du projet, ses bnfices et sa
logistique. Par consquent, les besoins clients seront bien dfinis, les quipes mieux prpares ainsi que le mandat du projet qui sera
prcis avec une dfinition claire de la problmatique et des objectifs, des paramtres du projet, du planning par jalons et des bnfices.

Phase 2 : Mesurer la situation actuelle
La mesure de la situation actuelle revient cartographier le processus actuel et en mesurer les dfauts. Cette mesure porte sur la
collecte de donnes concernant les problmes identifis durant la prcdente phase. La cartographie du processus As Is permet
lquipe de mieux le comprendre en ltat actuel et daller au-del de la perception initiale. Cette analyse de lexistant permet aussi
didentifier les Quick Wins.
Le mandat de projet constitue un document dorientation pour lquipe projet et dfinit son cadre de travail. Le mandat clarifie ce que
lon attend de lquipe et permet lquipe de respecter les priorits de lorganisation. Le document dorientation autorise le transfert
du projet du Sponsor lquipe damlioration et identifie les problmes, explique la complexit du projet et fixe des objectifs en des
termes mesurables. Ainsi, la logistique de la constitution de lquipe de
projet est identifie et le mandat de projet devient un document vivant, qui volue mesure que le projet se prcise. Les livrables du
mandat de projet sont lharmonisation et quilibrage en prsentant la valeur et de la ncessit du projet.
Lnonc des bnfices tirer du projet et de son calendrier dexcution (pourquoi lentreprendre maintenant ?), tout en fournissant
lexplication des raisons qui justifient le projet.

Dans 85% des cas, la raison pour laquelle nous ne parvenons pas rpondre aux attentes du client, est
que nos sytmes et nos processus sont dfectueux, et non que nos employs ne sont pas la hauteur Le
rle de la Direction est de changer le processus plutt que dinsister sur une amlioration de lindividu.
Le Lean en tant que philosophie, Edwards Derning

Phase 3 : Analyser et gnrer des solutions
La phase danalyse des donnes et dcouverte des causes des dfauts consiste examiner de plus prs les donnes, afin de dterminer
les causes profondes des problmes avant de proposer des solutions de fond. La conception des solutions qui traitent des causes
profondes induit lamlioration et la satisfaction des objectifs du projet. Apporter des solutions en laborant une cartographie du
processus cible, nomm To Be en anglais avec tous les outils de contrle pour le suivi de la performance du nouveau processus. Une
fois, le processus cible dfini, il est crucial dinviter toutes les parties prenantes procder une tude critique de la proposition et, si
possible, dployer un programme pilote travers des ateliers de travail et de communication. La conception du modle financier,
comme input de lanalyse cots et bnfices, dmontre de manire plus dtaille les avantages financiers la mise en uvre de la
solution propose.
Il est important dexaminer les clients et de les segmenter en groupes logiques. Lquipe est ainsi mme daxer les travaux sur les
clients les plus importants pour le projet en dfinissant des segments logiques de clients (Lieu gographique, taille, valeur, type
dactivit, segment de march, etc.). partir des donnes collectes auprs des clients, il est possible de dfinir prcisment ce que le
client attend du produit ou du service. Les besoins des clients se traduisent en besoins critiques au niveau du processus, spcifiques et
mesurables.

Phase 4 : Amliorer et mettre sous contrle
Test de tout ou partie dune solution propose, petite chelle, en vue de mieux comprendre les effets de cette solution et de
dcouvrir comment optimiser sa mise en uvre grande chelle et de maitriser sa prennit des amliorations apportes durant la
prcdente phase. Un plan dactions correctives doit tre dress, expliquant comment ragir si les performances du processus
changent ou scartent des normes tablies. Une fois le plan de contrle identifi, le plan de mise en uvre de la solution doit tre
finalis. Le projet passe en mise en uvre, les solutions sont testes et valides. Avant le transfert de responsabilit du nouveau
processus au propritaire, lquipe projet surveille attentivement la performance du processus et valide le modle financier travers
lobservation des gains.
La cartographie de processus confre une structure simple et visible de raisonnement pour un processus complexe. Ses
objectifs sont, entre autres, comprendre les interdpendances en cours du processus (passages de relais, goulots dtranglement et
boucles de correction), instaurer une communication (propice au travail dquipe) entre les dpartements via une sensibilisation aux
problmes potentiels du processus cibles.
La mthode OPEX est structure en 4 phases de travail composes elles-mmes de 12 tapes spcifiques supportes par 50 outils Blue
et ~ 40 outils complmentaires Black.

Lapplication de cette mthode reprsente aussi un changement de culture par rapport lapproche classique comme illustr ci-
dessous :

Figure 25 : OPEX, un changement de culture

De nouvelles performances appellent videmment de nouvelles comptences !
Un programme de formation et de certification OPEX permet de dvelopper ses comptences en matire damlioration des processus.

Figure 26 : OPEX, une organisation impliquant tous les niveaux hirarchiques

Des nouvelles performances appellent aussi une gouvernance favorisant des prises de dcisions quilibres.

Figure 27 : Gouvernance OPEX, une vritable dynamique damlioration continue prenne

Rle du Champion Central OPEX
Le Champion Central OPEX met en place le programme OPEX et assure lanimation globale d'OPEX au quotidien. Il conoit
l'infrastructure OPEX incluant les systmes supports comme la formation, les approbations de projet, les ressources humaines, les
systmes de reporting, et sassure de la cohrence et de lvolution de la mthode. Au moins une fois par trimestre, le champion
central rapporte /informe le Comit Excutif sur l'avancement du dploiement d'OPEX et apporte lappui des quipes centrales BB et
MBB aux units si besoin. La mise en uvre dun plan de communication pour lentreprise se fait avec les champions locaux.

Rle du Champion local
Le Champion local dploie la dynamique dans chaque Unit de lentreprise et il est responsable du dploiement d'OPEX dans son Unit.
Le travail de coordination est tabli avec le Champion Central pour mettre en uvre l'infrastructure OPEX et le champion local dfinit
avec les responsables de l'unit ses buts et ses objectifs, et s'assure qu'ils sont aligns sur la stratgie du COMEX. Celui-ci dcline ces
buts et ces objectifs par l'identification d'aires d'opportunits prioritaires et facilite l'identification, la dfinition de l'tendue et la
priorisation des projets pour les sponsors. L'identification et le choix de candidats Blue Belt et Black Belt pour le comit de direction
sexcutent avec les plans de formation avec le Champion Central. De ce fait, le Champion local dveloppe un plan de communication
pour l'Unit et supprime les barrires rencontres par les Black Belt et leurs quipes pendant leurs projets. En conclusion, il assure
l'implication du bon niveau de ressources et suit et communique l'avancement des projets OPEX au champion central.

Rle du Sponsor
Le sponsor en gnral assure lidentification, le lancement et le suivi de ses projets OPEX prioritaires au moins N-2 dun membre du
COMEX. Le sponsor prend en charge lidentification et la validation des projets prioritaires conduire dans son unit, en cohrence
avec la stratgie de lentreprise et en coordination avec le champion local. Le sponsor communique au champion local et, si besoin au
COMEX, ltat davancement de ses projets. En bref, il libre les ressources ncessaires (quipe, temps, budget) et prend charge du bon
droulement du projet et des points de dcisions aux diffrentes tapes du projet.

Rle dun OPEX Master Black Belt
Le Master Black Belt est un expert OPEX et un agent du changement encadrant et conseillant des Blue Belts et des Black Belts.
Egalement, il assure le dploiement de la mthodologie et le coaching des Black Belt et possde de solides comptences statistiques et
savoir utiliser tous les outils. Pour la validation des projets et clture de projets, il assiste et supporte les champions et les responsables
de processus dans le choix, le cadrage et la gestion des projets OPEX. Le Master Black Belt maintient et met jour si ncessaire la
mthodologie OPEX et assure le partage dexprience et la diffusion des meilleures pratiques. En conclusion, il mne des projets trs
complexes et/ou trs forts enjeux, pour la plupart multifonctionnels et/ou travers plusieurs units.

Rle dun OPEX Blue Belt
LOPEX Blue Belt est un acteur du changement dans son environnement oprationnel et travaille sur des projets d'une plus petite
tendue, et typiquement dans son domaine/secteur de travail. Le Blue Belt, communique ltat du projet et livre les rsultats du projet.
Egalement, il contribue au maintien de la performance du processus aprs amlioration, tout en intgrant les outils et la mthodologie
OPEX ses fonctions actuelles. Le Blue Belt, insuffle au quotidien les principes OPEX dans ses quipes par son comportement.

La russite dun projet OPEX ncessite des acteurs du changement
Les principales comptences dun Blue / Black Belt consistent la mise en uvre de la mthodologie OPEX adapte au contexte, la
diffusion des meilleures pratiques et la maitrise des projets trs complexes trs fort enjeux.

Figure 28 : Comptences Blue et Black Belt

En rsum sur lamlioration de processus utilisant OPEX Lean Management
Les organisations sont rgies par des processus, gres par des personnes, payes par des clients et finances par des actionnaires. Il
est primordial de comprendre les besoins de nos clients et de sassurer que nos processus satisfont ou outrepassent leurs besoins. Pour
exceller dans leur secteur, les organisations doivent savoir comment mesurer, amliorer et contrler lensemble de leurs processus.
Pour garantir une gestion efficace et efficiente des processus, il faut une force de travail suffisamment engage et discipline pour
amliorer lefficacit et lefficience des processus.

4.1.5 Comparaison rapide
Six Sigma Lean Kaizen
Thorie Rduire les variations Rduire le gaspillage Amliorer la qualit
Dmarche Dfinir
Mesurer
Analyser
Amliorer
Matriser
Identifier ce qui cre la valeur
Identifier la chane de valeurs
Amliorer le flux
Pull (JiT client)
Viser la perfection
Ordonner (i.e. commander)
Ordonn (i.e. tri)
Propret
Nettoyage normalis
Discipline
Cible Problme Flux Cible simple et tactique
Hypothses Problme existe.
Quantification.
Loutput du systme augmente si on
rduit les variations dans tous les
processus.
Rduire le gaspillage amliore la
performance de lentreprise.
Plusieurs petites amliorations rapides
sont prfrables lanalyse du
systme.
Emphase sur la vitesse et le
volume.
Utilise les systmes en place.
Processus interdpendants.
Impact
premier
Output uniforme des processus Amlioration du dbit Dbit rapide
Effets
secondaires
Moins de rebuts
Dbit amlior
Moins de stocks
Les fluctuations comme mesure du
rendement de la gestion.
Qualit amliore.
Moins de variations
Dbit plus uniforme
Moins de stocks
Nouvelle comptabilit
Le dbit comme mesure de rendement
de la gestion
Qualit amliore
Moins de rebuts
Moins de stocks
Nouvelle comptabilit
Dbit comme mesure de
rendement de la gestion
Qualit amliore
Critiques Interactions non considres.
Processus amliors de faon
indpendante.
Contrle statistique et analyse de
systme non exploits
Peu de participation de
lemploy
Analyse des donnes peu
exploite

Conclusion
Ainsi, le Lean Management est une vision globale de lentreprise, qui se caractrise par une philosophie long terme et qui se vit avec
tous les employs. Cest aussi un travail permanent sur les processus, orient vers llimination systmatique du gaspillage et plus
largement des 3M : muda (gaspillage), mura (irrgularit), muri (surcharge), une gestion respectueuse des employs qui sont
considrs comme la principale ressource de valeur de lentreprise, et enfin une culture de rsolution continue des problmes qui
guide lapprentissage et dveloppe les comptences de lentreprises.
La pense classique occidentale concevait jusqualors le dveloppement et lamlioration de la production par lunique biais de lourds
investissements sur les processus gnrateurs de valeur. Le Lean Management exacerbe leffort continu sur la rduction drastique des
processus non gnrateurs de valeur par le biais dactes simples et conomiques (Lean).
Enfin, au niveau de la gestion des flux, il insiste sur limportance dinstaurer des flux tirs, avec pour ultime objectif dobtenir un flux
pice pice (ou livrable dentre livrable de sortie, dans le cadre de la gestion de projet), synonyme de ractivit, de rendement, et
rvlateur de problmes (chasse au gaspillage). En effet, la diminution progressive et systmatique du niveau des stocks et des encours
conduit faire affleurer les problmes jusqualors immergs sous la marge de scurit des stocks. On peut et lon doit alors amliorer
les points nfastes et donc la productivit.
Initialement cantonn l'organisation de la production, l'cole lean se rvle tre une mthode pertinente pour combattre tous les
types dinefficacit, son utilisation stend notamment aux processus documentaires et lectroniques, aux services administratifs (lean
office), au dveloppement de produit (lean development).
Par une analyse minutieuse de la chane des valeurs, il permet de dceler les activits non productives ou sans aucune valeur ajoute
relle, et doptimiser par la suite le processus global de cration de valeur.
La rsolution continue des problmes rencontrs aboutit un systme pensant , dveloppant ses comptences.

4.2 Mthodologies de niveau Tactique
Il sagit ce niveau doptimiser les processus plus oprationnels dune DSI. Cela signifie pour lessentiel de mieux maitriser son
processus de gestion de projet (par exemple, lors du dveloppement dune nouvelle application ou du dploiement dun progiciel).
La gestion de projet repose fondamentalement sur un dcoupage dcrivant lenchanement des phases, tapes et tches effectuer
pour aboutir aux livrables finaux spcifis. Ce dcoupage, exhaustif pour la prise en compte de toutes les composantes et contraintes,
permet une prise en charge affine du projet sur chacune de ses portions lmentaires.
Un cycle de vie propose une modlisation du cycle de dveloppement logiciel, focalise sur certains facteurs particuliers. Il fournit un
cadre thorique global la gestion de projet, et induit un certain type dorganisation et de mthodologie.
4.2.1 Introduction au cycle de vie du projet
Le cycle de vie du logiciel dfinit l'enchanement chronologique des diffrentes phases dlaboration et dutilisation d'un logiciel, depuis
lmergence du besoin (lide) jusquau retrait de service du produit.

Figure 29 : Illustration du cycle de vie dun projet informatique (source CNRS)

Le projet est compos de 4 phases : ralisation, dveloppement, exploitation /utilisation et maintenance / volution.
Les volutions majeures sont traites comme des projets indpendants (V1, V2,).


Figure 30 : Dtail du cycle de vie (source CNRS)

Prsentation des diffrentes phases du cycle de vie (Source : Gnie logiciel, Anne-Marie Hugues 19/12/02 2-3)

a. Dfinition des Objectifs
Le management tudie la stratgie et dcide de la ncessit de fabriquer ou acheter un nouveau produit.
C'est pendant cette phase qu'est dfini un schma directeur dans le cas de la cration ou de la rnovation d'un systme
d'information complet d'une entreprise prenant en compte la stratgie de l'entreprise (voir mthode Merise).

b. Dfinition des Besoins
Un cahier des charges est tabli par le client aprs consultation des divers intervenants du projet (utilisateurs, encadrement...),
un appel d'offres est ventuellement lanc.
Le cahier des charges dcrit, en langage naturel, les fonctionnalits attendues du produit ainsi que les contraintes non
fonctionnelles (temps de rponse, contraintes mmoire...). Dans le cas de la refonte d'un systme complet on peut avoir un
cahier des charges par sous domaine. Le produit intermdiaire obtenu l'issue de cette phase est le cahier des charges.
On peut dcrire le produit partir de diffrents scnarii d'utilisation (Use Case).

c. Dfinition du Produit
Les spcifications prcises du produit sont dcrites ainsi que les contraintes de ralisation.
A l'issue de cette phase, les fournitures intermdiaires sont le dossier de spcifications fonctionnelles et une premire version
du manuel utilisateur. On peut galement dsigner cette phase par le terme analyse des besoins. A l'issue de cette phase, le
client et le fournisseur sont d'accord sur le produit raliser et les contraintes auxquelles il doit obir ainsi que sur la faon de
l'utiliser et en particulier sur l'interface utilisateur qu'il s'agisse d'une interface homme-machine ou d'une API.
Les produits intermdiaires l'issue de cette phase sont :
le dossier d'analyse comprenant les spcifications fonctionnelles et non fonctionnelles du produit,
une bauche du manuel utilisateur,
une premire version du glossaire contenant les termes propres au projet.

d. Planification et gestion de projet
Il est vident que le client comme le dveloppeur doivent tre d'accord sur les cots et la dure du projet. La phase de
planification permet de dcouper le projet en tches, de dcrire leur enchanement dans le temps, d'affecter chacune une
dure et un effort, calcul en homme*mois. Il est galement important de dfinir les normes qualit qui seront appliques
comme la mthode de conception choisie ou les rgles qui rgiront les tests. On notera galement les dpendances extrieures
(comme par exemple l'arrive d'une nouvelle machine ou d'un nouveau logiciel) afin de mesurer les risques encourus.
Les produits intermdiaires l'issue de cette phase sont :
le plan qualit,
le plan projet destin aux dveloppeurs,
une estimation des cots rels (utile pour le management),

un devis destin au client prcisant le prix payer, les dlais et les fournitures,
une liste des dpendances extrieures.
En cas de ralisation du produit par un sous-traitant le dossier de spcifications fonctionnelles ainsi que le plan projet et le plan
qualit terminent cette phase et sont contractuels.

e. Conception globale
Pendant cette phase l'architecture du logiciel est dfinie ainsi que les interfaces entre les diffrents modules. On veillera tout
particulirement rendre les diffrents constituants du produit aussi indpendants que possible de manire faciliter la fois
le dveloppement parallle et la maintenance future.
A l'issue de cette phase les produits intermdiaires sont :
le dossier de conception,
le plan d'intgration,
les plans de tests,
le planning mis jour.

f. Codage et tests unitaires
Chaque module est ensuite cod et test indpendamment des autres.
A l'issue de cette phase les produits intermdiaires sont :
les modules cods et tests,
la documentation de chaque module,
les rsultats des tests unitaires,
le planning mis jour.

g. Intgration
Chaque module test est intgr avec les autres suivant le plan d'intgration et l'ensemble est test conformment au plan de
tests. A l'issue de cette phase, les produits intermdiaires sont:
le logiciel test,
les tests de rgression,
le manuel d'installation,
la version finale du manuel utilisateur.

h. Qualification
Lorsque le logiciel est termin et les phases d'intgration matriel/logiciel acheves, le produit est qualifi, c'est dire test en
vraie grandeur dans des conditions normales d'utilisation. Cette phase termine le dveloppement. A l'issue de cette phase le
logiciel est prt la mise en exploitation.

i. Maintenance
Lorsque le produit a t accept, il passe en phase de maintenance jusqu' son retrait. C'est pendant cette phase que tous les
efforts de documentation faits pendant le dveloppement seront particulirement apprcis de mme que la transparence de
l'architecture et du code.

4.2.2 Modles traditionnels de dveloppement logiciel
Le cycle de dveloppement du logiciel (dfinition AFNOR Z61-102) reprsente l'ensemble des activits mises en uvre dans un ordre
donn pour effectuer le dveloppement d'un logiciel. Il existe diffrents modles de dveloppement du logiciel, chacun mettant
laccent sur diffrents enjeux projet, et bien sr prsentant un certains davantages ou dinconvnients diverses.

Modle en cascade : modle bas sur les livrables (fournitures de fin de phase livres au client).
Toutes les phases sont excutes sans exception dans l'ordre indiqu. Chaque phase se termine par un jalon, tche de vrification et
validation des rsultats (afin d'liminer les anomalies et les incohrences). Le passage la phase suivante est conditionn par la revue
de jalon. Le retour est uniquement autoris pour la phase prcdente : on ne peut changer que les dcisions prises la phase
prcdente. Cette mthode permet de distinguer clairement les phases du projet et impose un certain rythme de dveloppement,
squenc par les revues de jalons.
Par contre, les inconvnients sont que le modle est peu adaptatif aux volutions des besoins et la vrification des fonctionnalits
dveloppes arrive tardivement (en fin de cycle). Le retour en arrire est complexe car demanderait des modifications des
spcifications.
Ce modle est donc plus adapt aux petits et moyens dveloppements, dont les besoins et spcifications sont clairement exprims.
Lun des problmes majeurs rsidant dans son manque de flexibilit quant au changement de spcification, il est cependant possible
dinclure une boucle de prototypage pour scuriser ladquation du produit avec les besoins.

Modle avec prototypage : permet la validation des spcifications par exprimentation (pour expliciter lanalyse des besoins et les
spcifications fonctionnelles). Le prototype exprimental est utilis pour valider des options de conception ou pour obtenir le produit
final par itrations successives.

Figure 31 : Modle en cascade avec un maquettage et un prototypage

Modle en V : modle normalis par l'AFCIQ (Association Franaise pour le Contrle Industriel et la Qualit), l'AFNOR et l'ISO. Il
reprsente une variante du modle en cascade en se focalisant sur les tapes de spcification et de vrification / validation. La
conception va du plus large (systme) au plus spcifique (sous-ensembles, composants), et chaque tape de spcification est associe
une tape de vrification / validation / test.

Modle en W : extension du modle en V, il introduit une phase de dfinition des interfaces externes permettant lutilisateur de
juger, ds le stade de la conception, les interfaces utilisateur du futur produit.

Modle par extensions successives : variante du modle en cascade dans lequel le systme est dcoup en plusieurs sous-ensembles
logiques ; les fonctionnalits sont tendues progressivement partir d'une 1re ralisation (noyau regroupant les fonctionnalits
minimum).Ce modle permet de limiter les cots et risques (par exemple en arrtant le projet la premire itration si ncessaire). Il
permet de maitriser les dlais et les cots en scurisant le dveloppement par des livrables intermdiaires. Enfin, la motivation
reprsente par des objectifs dfinis court terme amliore la vitesse de travail de lquipe. Par contre, les difficults rsident dans la
gestion des extensions qui peut tre complexe (le dveloppement de nouvelles extensions ne doit pas remettre en cause larchitecture
globale du produit).

Modle en spirale : tient compte de la possibilit de rvaluer les risques en cours de dveloppement, il emprunte au prototypage
incrmental mais lui adjoint une dimension relevant de la prise de dcision managriale et non purement technique. Il sinspire de
lide dextensions successives : approche itrative du processus de dveloppement du logiciel reprsente par les boucles successives
de la spirale, chaque boucle se droule en quatre phases :
dtermination des objectifs du cycle, des alternatives pour les atteindre et des contraintes ; partir des rsultats des cycles
prcdents, ou de lanalyse prliminaire des besoins ;
analyse des risques, valuation des alternatives partir de maquettage et/ou prototypage ;
dveloppement et vrification de la solution retenue, un modle classique (cascade ou en V) peut tre utilis ici ;
revue des rsultats et vrification du cycle suivant.
Ce modle est adapte aux projets dvelopps en interne, en effet il est assez difficile de quantifier le travail et donc de contractualiser
sa ralisation un sous traitant.

Modle unifi. Le Processus Unifi (PU ou UP en anglais pour Unified Process) est une mthode de gestion du cycle de vie dun logiciel,
dveloppe par I. Jacobson, J. Rumbaugh et G. Booch (1997).Cest une mthode de dveloppement gnrique, itrative et
incrmentale, pour les logiciels orients objets. Le processus unifi semploie conjointement la mthode de modlisation systmique
UML (oriente objet). Il complte cette mthode de dveloppement et fournit un cadre thorique gnrique prenant en compte le
cycle de vie du logiciel. Lune des implmentations les plus utilises du processus UP est la mthodologie RUP (Rational Unified
Process).

PU sappuie sur 6 bonnes pratiques : un dveloppement itratif, la gestion des exigences, la gestion des demandes de changement,
lutilisation des architectures base de composants, la modlisation graphique des exigences, et la vrification continue de la qualit
du logiciel. PU fonctionne suivant une srie de cycles, aboutissants chacun un livrable : la livraison dune version du produit aux
clients. Un cycle sarticule en 4 phases : cration (inception), laboration, construction et transition, chacune dentre elles se
subdivisant son tour en itrations.

Figure 32 : Cycle de vie du processus unifi

La phase de cration correspond la phase de dfinition du projet (avant-projet), elle inclut les tapes de ltude dopportunit
et de ltude de faisabilit.
La phase dlaboration correspond aux tapes dorganisation du projet et de conception.
La phase de construction correspond aux tapes de dveloppement et de ralisation.
Enfin, la phase de transition correspond la mise en uvre du logiciel.

PU propose lutilisation intensive des schmas et modles graphiques :
Modle des cas dutilisation : dcrit les cas dutilisation et leurs relations avec les utilisateurs.
Le terme utilisateur renvoie aux utilisateurs humains et galement aux autres systmes. Lutilisateur reprsente donc une
personne ou une chose dialoguant avec le systme en cours de dveloppement. Les cas dutilisation transcrivent les besoins
fonctionnels et leur ensemble constitue le modle des cas dutilisation qui dcrit les fonctionnalits compltes du systme.
Le dveloppement est pilot par les Diagrammes de Cas d'Utilisation.
Modle danalyse : dtaille les cas dutilisation et procde une premire rpartition du comportement du systme entre
divers objets.
Modle de conception : dcompose la structure statique du systme en sous-systmes, classes et interfaces ; et dfinit les cas
dutilisation raliss sous forme de collaborations entre les sous systmes, les classes et les interfaces.
Modle dimplmentation : intgre les composants (code source) et la correspondance entre les classes et les composants.
Modle de dploiement : dfinit les nuds physiques des ordinateurs et laffectation de ces composants sur ces nuds.
Modle de test : dcrit les cas de test vrifiant les cas dutilisation.

Figure 33 : Illustration du processus unifi

A partir du modle des cas dutilisation et des diagrammes associs, les dveloppeurs crent une srie de modles UML danalyse, de
conception, et de dploiement. Tous ces modles sont ensuite rviss pour contrler leur conformit par rapport au modle des cas
dutilisation. Enfin, les testeurs testent limplmentation pour sassurer que les composants du modle dimplmentation mettent
correctement en uvre les cas dutilisation.
4.2.3 Modles agiles de dveloppement logiciel
Une mthode agile est une mthode de dveloppement informatique permettant de concevoir des logiciels en impliquant au
maximum le demandeur (client), ce qui permet une grande ractivit ses demandes. Les mthodes agiles se veulent plus
pragmatiques que les mthodes traditionnelles. Elles visent la satisfaction relle du besoin et non d'un contrat tabli pralablement. La
notion de mthode agile est ne travers un manifeste sign par 17 personnalits (parmi lesquelles Ward Cunningham, l'inventeur du
Wiki), crateurs de mthodes ou dirigeants de socits.
Les grands principes des mthodes agiles se retrouvent dans le manifeste agile et se traduisent par quatre oppositions aux
concepts traditionnels :
Individus et interactions contre processus et outils,
Logiciel qui fonctionne contre documentation exhaustive,
Collaboration du client contre ngociation de contrat,
Rponse au changement contre suivi d'un plan prdfini.
Un des buts fondateurs des mthodes agiles est dviter leffet tunnel dallongement des dlais et de glissement des jalons, en
multipliant les interactions avec le client par le biais ditrations et de livraisons courtes. Lagile est une dmarche qui vise produire
les bonnes fonctionnalits dans une optique de qualit. Lide nest pas de dvelopper plus vite et moins cher, mais de faire la bonne
fonction au bon moment !


RAD : RAPID APPLICATION DEVELOPMENT
L'organisation du projet s'appuie sur un principe fondamental : la sparation des rles et des responsabilits entre matrise d'ouvrage
(MOA) et matrise d'uvre (MOE). Cette dichotomie renforce par la prsence dune instance danimation RAD (Groupe dAnimation et
de Rapport) implique une vritable ringnierie des mthodes de conduite de projet et impose aux deux matrises une redistribution
des rles oprationnels et un apprentissage.
La mthode RAD structure le cycle de vie du projet en 5 phases :
LInitialisation dfinit lorganisation, le primtre et le plan de communication.
Le Cadrage dfinit un espace dobjectifs, de solutions et de moyens.
Le Design modlise la solution et valide sa cohrence systmique.
La Construction ralise en prototypage actif (validation permanente).
La Finalisation est un contrle final de qualit en site pilote.

Principes de la mthode
La phase de spcification/conception est remplace par une phase de prototypage mene conjointement avec le client.
Ce modle dploie une dmarche participative des intervenants du projet : les utilisateurs et les concepteurs collaborent au cours
dateliers afin daboutir un consensus sur les besoins couvrir.
Le manifeste Agile
En 2001, les tnors du monde agile se sont runis pour extraire de leurs pratiques et mthodes respectives la substantifique
moelle. Il en a rsult un certain nombre de choses trs intressantes, mais on retient principalement quatre points, que lon
appelle le manifeste agile (http://agilemanifesto.org/).
On remet le facteur humain au centre. Cest bien lui qui construit lapplication, et non le processus ou des outils. Ces derniers ne
sont l que pour aider, et surtout pas pour commander . Dans des organisations du type de celle de France Telecom, o il y a
beaucoup de gens, il est difficile de fonder la russite du projet sur la confiance dans la qualit du travail que fournira chaque
intervenant. Cest pourtant une des ides fortes de lagilit : on confie un rle quelquun, on le responsabilise et on lui fait
confiance. Cela comporte une petite part de risque, mais on constate lusage, dans lnorme majorit des cas, que cette prise de
risque a t payante.
La contractualisation tente de substituer la volont de bien faire par des obligations contraignantes. On a limpression que parce
quon a sign un contrat, on est labri des problmes. Il ny a rien de plus faux ! Est-ce quun contrat a vit un dcalage du
planning ?
Pratiquement toujours, la rponse est non. Par contre, il a nuit la relation entre les partenaires.
Imaginons maintenant que chaque acteur du projet accepte cet objectif : faire une application utile au mtier. Chacun va alors
collaborer pour obtenir le meilleur rsultat possible. Bien sr, des problmes pour survenir au fur et mesure, mais on cherchera
des solutions ensemble (en collaborant). De toute faon, ces problmes auront tre rgls, et le contrat ne fera rien, ou alors il
faudra un avenant. Que dnergie, dargent et de temps perdu lorsquon ne collabore pas, mais quon exige sans prendre en
compte les contraintes, et on pourrait presque dire, la ralit des choses.
Plutt que de figer au maximum les choses pour esprer garantir un rsultat, on va accepter ds le dpart que des changements
sont possibles. Et on aura raison !
Si le fonctionnel change, il est dans lintrt du mtier que ce changement soit pris en compte au plus tt.
Si les contraintes techniques change, ou que le code se rvle plus difficile que prvu crire, il faut aussi le prendre en compte,
puisque cest la ralit !
Enfin, mme si il est indispensable de documenter un projet, le plus important est en premier davoir un logiciel qui fonctionne.
L encore, ce qui parat tre du bon sens nest pas forcment appliqu sur le terrain : on juge le projet la compltude de sa
documentation, aux comptes-rendus des diffrents passages de jalon, au respect des dates annonces, mais on accepte trs
souvent quune application parte en production alors quon sait quelle contient encore des bogues. Nest-ce pas tonnant ? A-t-
on encore lesprit de dlivrer une application utile au mtier ?


Figure 34 : Illustration du modle RAD

Cette mthode est adapte aux projets dvelopps en interne, en effet il est assez dur de quantifier le travail et donc de
contractualiser. Le manque de conception inhrent la dmarche a rendu ncessaire une amlioration du modle, dont est issue la
mthode DSDM. Cette mthode est adapte aux petites applications de gestion, n'ayant pas de cycle de vie d'une trop longue dure.

SCRUM
SCRUM est une mthode agile de gestion de projets ; elle est itrative, incrmentale et adaptative. Cest un processus de
dveloppement de logiciels qui s'intresse plus l'organisation du projet qu'aux aspects techniques.
Cette mthode gnrique ne couvre pas le cycle de dveloppement dun logiciel, il est donc ncessaire de lui adjoindre une mthode
complmentaire telle que lExtreme Programming.
Les processus de dveloppement traditionnels squentiels correspondent de moins en moins aux nouveaux besoins applicatifs.
Or, il semble, dans la pratique, que nous ne sommes pas bons pour estimer : seulement 31% des projets informatiques tiennent les
dlais et le budget, et quen moyenne un projet cote 189% de ce qui tait initialement prvu.
Lapproche adaptative mise en avant par SCRUM au contraire introduit lacceptation dun certain changement en partant dune
planification initiale et accepte les rvaluations au fur et mesure des itrations pour sadapter aux volutions du besoin.
SCRUM, dans son approche adaptative, se distingue des approches prdictives dans le sens o ses dernires :
Tentent de limiter lincertitude au plus tt du projet en sappuyant sur un planning exhaustif et prcis
Ncessitent la dfinition complte du produit avant de lancer les dveloppements
Demandent de stabiliser les exigences de lapplication finale au dbut du projet

Le terme Scrum est emprunt au rugby XV et signifie mle. Ce processus s'articule en effet autour d'une quipe soude, qui cherche
atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mle.
Un principe fort de Scrum est la participation active du client pour dfinir les priorits dans les fonctionnalits du logiciel et pour choisir
celles qui seront ralises dans chaque sprint. Il peut tout moment complter ou modifier la liste des fonctionnalits raliser, mais
jamais celles qui sont en cours de ralisation pendant un sprint.

Principes de la mthode
Cette mthode repose sur des dveloppements itratifs de fonctionnalits, chaque itration tant appele Sprint .
Chaque sprint a pour finalit de produire une version du produit incluant certaines fonctionnalits.
Un groupement de Sprints, aboutissant la livraison dune version du produit incluant des fonctionnalits dfinies, est appele release.
La ralisation dun Sprint (figure ci dessous) est rythme par quatre moments cls :
1) Llaboration de la liste des besoins mtier ;
2) La prparation du sprint venir ;
3) Lexcution du sprint ;
4) La revue et rtrospective du Sprint coule.


Figure 35 : Reprsentation de la mthode SCRUM - droulement dun Sprint

Llaboration de la liste des besoins mtier
Lensemble des fonctionnalits raliser est appel le backlog du produit (product backlog).
Le backlog de produits est le cur de Scrum.Cest la liste priorise de besoins et exigences que veut le client, exprims dans son
vocabulaire et sa terminologie mtier.
Le product backlog reprsente "l'ensemble des fonctionnalits du produit que l'on veut dvelopper".
Il priorise les diffrentes fonctionnalits, le but tant d'implmenter en premier ce qui a le plus de valeur (meilleur ratio entre ce que
rapporte une fonctionnalit et ce qu'elle cote).
Le product backlog prsente plusieurs niveaux de granularit.
ce qui doit tre ralis court terme doit tre de granularit fine
pour ce qui est long terme, une description grosse maille suffit (rien ne sert de tirer des plans sur la comte !)

Le product backlog est sous lentire responsabilit du Directeur de produit (product owner).
Le Directeur de produit est l'interlocuteur des mtiers dans la dmarche.
Dans ce cadre, le Directeur de produit doit :
- tre le reprsentant du client ou des utilisateurs.
- rcolter les attentes, besoins, exigences du client ou des utilisateurs et les priorits associes.
- formaliser le backlog de produit avec le niveau de prcision adapt la priorit.
- tre en mesure de les expliquer au Scrum Master et lquipe de dveloppement ou dinviter le client et/ou un utilisateur
pour le faire.
- dfinir le planning des releases dans lesquels les Sprints sinscriront.
- dfinir les tests de bon fonctionnement attendus lors de la dmonstration.
-
Le Directeur de produit dfinit, partir des donnes issues des mtiers le contenu de chaque version et la date souhaite.
Le contour de la version est revu avec le Scrum Master (coach et facilitateur de lquipe de dveloppement) pour valider la date de
livraison et identifier le nombre de Sprints ncessaires.
Les contours de version sont accepts par les mtiers, le COPIL,
Le contour de chaque Itration donne lieu la cration dun Backlog de sprint (backlog d'itration / Sprint backlog) revu avec lquipe
de dveloppement.

La prparation du sprint venir
Avant de dmarrer un sprint toute lquipe de dveloppement se runit. Dautres personnes peuvent assister en temps que spectateur
cette runion (Clients, ). Elles ne peuvent y intervenir sans invitation pralable dun membre de lquipe (par exemple pour fournir
des claircissements).


Figure 36 : Comment construire le backlog

Cest lquipe en concertation avec le Directeur de produit et le Scrum Master qui dfinit lorganisation et planification du sprint
venir, comportant :
la dfinition du but du sprint,
la revue du budget, chiffrage et estimation du cot,
la dtermination du backlog, des jalons, de lquipe,
la dfinition de larchitecture gnrale, de la conception gnrale (1
er
sprint),
le choix des items du backlog du produit raliser,
lidentification et analyse des risques,
la dcomposition des items du backlog du produit en items du backlog du sprint (puis pour finir celle de ces items en tches
lmentaires),
lestimation de la charge / dure pour chaque tche lmentaire.

Lexcution du sprint
Scrum ne couvre pas les moyens et les techniques mettre en uvre pour la ralisation du produit.
Nanmoins, la mthodologie prvoit des runions quotidiennes, aussi appele mles (scrum en anglais), qui permettent tous les
membres de lquipe de dveloppement de faire le point sur lvolution des tches du backlog du sprint et sur les difficults
rencontres.
Au cours de cette brve runion, de maximum 15 minutes, lquipe fait le point sur :
Les ralisations engranges depuis la dernire mle.
Les ralisations envisages jusqu la prochaine mle.
Les problmes et difficults rencontrs. Les difficults qui ne peuvent tre surmontes par lquipe de manire autonome sont
prises en charges par le Scrum Master dont la mission principale est dviter que ces difficults ne perturbent le droulement
du sprint.
Le rsultat de cette runion est une mise jour du backlog du sprint, que ce soit en termes de tches raliser ou en termes
dvaluation du reste faire .
Un outil particulirement intressant pour la mesure du progrs et du reste faire est le graphique davancement. Ce graphique
reprend, de manire quotidienne, le volume de travail raliser pour atteindre lobjectif. Lvolution de la courbe permet de mesurer
rapidement si ce dernier pourra ou non tre atteint et prendre ainsi les mesures ncessaires.

La revue et rtrospective de litration coule
Une fois le sprint termin, et donc des produits raliss lors de celui-ci, une, voir deux runions distincte, de revue du sprint et de
rtrospective, ont lieu.
La revue du sprint a pour but de vrifier la conformit du ralis (intgration et jeux de tests), ainsi que de soccuper de la mise jour
la documentation.
La rtrospective, quant elle, a pour objectif de capitaliser sur le retour dexprience dans le but damliorer, de manire continue, la
performance de lquipe et la qualit du produit.

Synthse & Smantique/Terminologie

SCRUM, un processus simple, quelques dfinitions dacteurs et doutils de la mthode.

3 acteurs :
Directeur de produit (Directeur de produit) : personne responsable de produire et maintenir jour le backlog de produit. C'est lui qui
en dtermine les priorits et qui a le pouvoir dcisionnel dans le projet.
Scrum Master : membre de l'quipe dont l'objectif principal est de la protger des perturbations extrieures. Il est compltement
transparent pour la communication entre l'quipe et les clients et n'a aucun pouvoir hirarchique sur l'quipe. C'est en revanche un
facilitateur pour les problmes non techniques de l'quipe ; il encadre le dveloppement du produit suivant la mthodologie SCRUM.
Lquipe : elle fonctionne suivant un principe dautogestion.

3 artfacts :
Backlog de produit (Product Backlog) : liste des fonctionnalits qui devront tre ralises par le logiciel, liste priorise de besoins et
exigences que veut le client, exprim dans son vocabulaire et sa terminologie mtier
Backlog de sprint (Sprint Backlog) : liste des tches accomplir pendant un sprint. Elles correspondent la ralisation des items de
backlog du produit affects au sprint.
Graphique d'avancement (Burndown Chart) : graphique qui montre la tendance du reste faire total de jour en jour (pour les sprints)
ou de sprint en sprint (pour les releases).

4 rendez-vous :
Planification de sprint.
Sprint est le terme dsignant une itration dans Scrum. Cette itration dure 30 jours calendaires en thorie, mais en pratique on utilise
plutt entre 2 et 4 semaines. Pendant une itration, l'quipe doit dvelopper une liste d'items du backlog de produit qui a t dfinie
au dbut de ce sprint.
Mle quotidienne (Daily Scrum) : runion quotidienne de 15 minutes qui a pour but de faire le point sur ce qui a t fait depuis la
dernire mle, ce qui est prvu de faire jusqu' la prochaine et quelles sont les embches rencontres durant le travail.
Revue de sprint : jalon Qualit, vrification de la conformit du ralis (intgration et jeux de tests).
Rtrospective : retour dexprience pour capitalisation et amlioration continue.
Le travail dune tche peut tre estim en points relatifs (suivant la suite de Fibonacci : 1, 2, 3, 5, 8, 13), qui dterminent sa complexit.
La vlocit de lquipe reprsente le nombre de points relatifs quelle peut raliser en un sprint.
Lanalyse rtrospective revient sur le travail effectu durant le sprint pour dterminer la vlocit de lquipe, revoir les estimations de
planification, afin de peaufiner lorganisation du sprint suivant.

Inconvnients
Requiert une forte implication du client pour
- Prioriser les fonctionnalits ;
- Mettre en uvre de tests priodiques chaque release ;
- Participer aux runions de dfinition et de priorisation du backlog : tre force de proposition, faciliter le processus de
priorisation, respecter les arbitrages du Directeur de produit ;
- Etre disponible pendant les itrations ;
- Etre prsent (sur invitation) au runion de Dmonstration ou fin d'itration pour :
Valider les ralisations avec le Directeur de produit.
Identifier des volutions ou des nouvelles fonctionnalits et les prioriser.
Ncessite une forte cohsion et implication de lquipe, ainsi quun certain isolement (pour limiter les perturbations).
Principaux inconvnients des modles itratifs (voir modle par extensions successives)
2

Avantages
Engendre un processus damlioration continue.
Fdre et responsabilise lquipe.
Principaux avantages des modles itratifs (voir modle par extensions successives)
3

Mthode Extreme Programming (XP)
Cette mthode a t invente par Kent Beck, Ward Cunningham et Ron Jeffries en 1999.
Cest une mthode agile de gestion de projets informatiques qui est applicable pour des quipes rduites, rpondant des besoins
changeants. XP est la fois un processus de dveloppement, un tat desprit et des valeurs, et un ensemble de bonnes pratiques. XP
est une mthode itrative qui prconise des bonnes pratiques, et qui repose sur une forte collaboration de lquipe et une forte
implication du client.
Elle sappuie sur 5 valeurs fondamentales : la communication, la simplicit, le feedback, le courage et le respect.
Les 5 valeurs de XP sont dclines en 13 pratiques :

2
Difficult de planification (quantification du travail) et donc de contractualisation (baseline de dpart floue). Gestion complexe des extensions, le
dveloppement progressif de nouvelles extensions ne doit pas remettre en cause larchitecture globale du logiciel.
3
Permet de limiter les cots et les risques (arrt ds la premire itration). Permet la matrise des dlais et des cots de dveloppement (scuriss par
les livrables intermdiaires). Amliore la vlocit grce la motivation des objectifs courts termes. Permet de sadapter rapidement aux modifications
des besoins des utilisateurs. Fournit de nombreuses versions prototypes pour scuriser les fonctionnalits. Permet daffiner le besoin et les solutions.
Permet la capitalisation de lexprience au fil des extensions. Facilite la validation (puisquelle est semi-continue).

Figure 37 : Illustration des 13 pratiques XP
La prsence du Client sur site, celui-ci est le rfrent pour les besoins et la priorisation. Il crit les scenarios (user stories), les
priorise et tablit les tests de recette.
La planification continue et volutive (planning game), celle-ci value diffrents scnarios pour implmenter les fonctionnalits
lors dune itration (de 1 3 semaines).
Lintgration continue, le produit complet est mise jour en continue au fil des itrations, le client ralise frquemment des
tests dintgration (il crit les tests de recette).
La frquence des livraisons, conjointement lintgration et aux tests continus elle rduit considrablement le cot de
livraison et les risques.
Le rythme de dveloppement soutenable (pas de surcharge).
Le dveloppement pilot par les tests, tests de recette (ou tests fonctionnels) chaque itration et tests unitaires pour chaque
fonctionnalit (ils sont crits avant le code tester). On privilgie au maximum lautomatisation des tests.
Une conception simple, focalise pour chaque itration sur les scnarios slectionns.
Lutilisation de mtaphores ou danalogies pour dcrire le systme et son fonctionnement, et faciliter ainsi sa comprhension.
Le refactoring, amlioration continue de la qualit du code.
Lappropriation collective du code, pour une collaboration efficace de lquipe.
Les conventions de nommage, normes facilitant le travail en quipe.
La Programmation en binme, permet de capitaliser les connaissances, et de scuriser le dveloppement.
Le travail dquipe, lquipe travail de manire collaborative, en favorisant lautogestion.

Figure 38 : Cycle de dveloppement XP

La phase de planification release tablit la planification initiale, qui volue en continu avec les itrations. Le planning dfinit les dates et
contenus (scenarios) de chaque itration et de chaque release.
La premire itration, dune dure moyenne dun mois aboutit un prototype fonctionnel.

Figure 39 : illustration dune itration XP
En premier lieu, une phase exploratoire analyse les scnarios qui seront fournis pendant cette itration, en fonction de la priorisation
du client et de la vlocit de lquipe lors de la prcdente itration. Puis, l'quipe dcompose les scnarios en tches raliser et
conoit les tests fonctionnels associs. Chaque dveloppeur s'alloue des tches et les ralise en binme ;
Une fois tous les tests fonctionnels valids, le produit est livr.
Inconvnients
Requiert une forte implication du client pour la priorisation des fonctionnalits et la mise en uvre de tests priodiques
chaque release.
Ne couvre pas les phases en amont et en aval du dveloppement : capture des besoins, support, maintenance
Elude la phase danalyse, si bien quon peut dpenser son nergie faire et dfaire.
Assez flou dans sa mise en uvre: quels intervenants, quels livrables ?
Ncessite une forte cohsion et implication de lquipe, ainsi quun certain isolement (pour limiter les perturbations).
Avantages
Engendre un processus damlioration continue.
Fdre et responsabilise lquipe.
Simple mettre en uvre.
Fait une large place aux aspects techniques : prototypes, rgles de dveloppement, tests
4.2.4 Conclusion sur les modles
Les caractristiques et lefficacit de ces modles de conduite de projet dpendent grandement des modalits de leur application.
Cependant, ils prsentent certaines particularits, illustres dans le tableau ci-dessous.

Ils accentuent chacun leur tour, certaines composantes principales de la conduite de projet :
le squenage prcis (en accord avec le cycle de vie), la tenue et la matrise rigoureuse des objectifs (revues de jalons), et une
orientation qualit pour les processus squentiels.
la flexibilit et ladaptabilit afin daffiner lanalyse des besoins, et la ralisation de boucles de conception / dveloppement afin de
valider en continue le produit pour les modles itratifs.
limplication du client, la cohsion et la responsabilisation de lquipe, afin de capitaliser lexprience et denclencher un processus
damlioration continue (organisation apprenante) pour les mthodes agiles.

La connaissance de ces diffrents modles rappelle notre connaissance des perspectives fondamentales de la gestion de projet, qui
doivent nous guider dans notre activit de pilotage.

Aucun de ces modles nest bien sr parfait, cependant chacun est plus au moins adapt un contexte spcifique, et doit tre employ
aprs rflexion et analyse sur un projet logiciel. Le choix pertinent dun modle repose fondamentalement sur les acquis, la culture de
lentreprise et de lquipe projet. Il semble, en effet, particulirement difficile dappliquer une mthode agile au sein dune entreprise
rompue au processus squentiel.

Enfin, bien que le plus souvent focalise sur une mthodologie particulire notre dmarche de conduite de projet peut emprunter
chacun de ces modles des items pertinents pour dvelopper une mthodologie ad hoc.

4.3 Mthodologies et certification
La certification titre personnelle sur lune de ces mthodologies est bnfique, a minima pour faire monter en connaissance une
population de jeunes chefs de projet.
Lacteur est ainsi reconnu par ses pairs comme ayant acquis une connaissance qui se transformera en comptence avec la pratique. Il
acquire et peut ainsi justifier dun savoir-faire dans un premier temps, puis, lexprience dencadrement saffirmant, il dmontrera un
certain faire-savoir.
Sur PMP, la certification est clairement affiche et favorise. Elle se prsente sous diffrentes formes :
Certified Associate in Project Management (CAPM) et Project Management Professional (PMP) sont des certifications dlivres par
le Project Management Institute PMI ou par des centres agrs.
La premire, CAPM, justifie d'une connaissance acquise des concepts et principe de la gestion de projet.
Certified Associate in Project Management (CAPM) sur le site PMI
La seconde, PMP, est une vritable certification professionnelle justifiant d'une exprience et d'une expertise. Celle-ci devra tre
complte et valide rgulirement.

4.4 Un changement ? Un accompagnement !
Admettons : le projet informatique est en cours. Les mthodologies de conduite de projet informatique garantissent laboutissement
du dveloppement, de la recette et de la mise en production de lapplication.
Au pralable, les mthodes de modlisation de processus ont permis doptimiser lorganisation de lentreprise et ladquation du
systme logiciel aux besoins de lutilisateur. Les mthodes de pilotage de projet garantissent le bon aboutissement du projet dans les
dlais et les budgets en levant les risques.
Cependant, si la solution est parfaite dans sa rponse au besoin et dans ses qualits techniques, rien ne dit quelle soit utilis par ses
utilisateurs. En parallle, une autre rflexion doit sengager qui doit garantir la prise en main de loutil informatique par les utilisateurs.
Ds lors la dmarche soriente non plus sur la technologie ou sur lorganisation, mais sur la connaissance, les savoir-faire et les
comportements.

Figure 40 : Accompagnement au changement : 3 axes dactions

De nombreuses applications trs abouties et portant un fort espoir de progrs ne sont que peu utilises, voire jamais utilises. Tous les
efforts consentis se trouvent rduits nant car les utilisateurs nacceptent pas leur nouvel outil.
La raison en est souvent une rsistance au changement. Tout changement dans notre cadre de vie, nos habitudes, quil provienne de
faons de travailler ou doutils utiliser provoque des rticences. Rciproquement, souvent un bel objet suscite lintrt et lattirance.
Lobjectif des actions de conduite du changement est donc de lever les freins au changement puis de susciter lintrt, de passer de
lincomprhension ladhrence, puis limplication.

Figure 41 : Cycle dacceptation du changement

Le prcdent montre trois points essentiels sur ce passage de la rticence vers limplication :
Il procde par tapes, et certaines dentre elles sont invitables, notamment le dclic de la rticence ladhsion
Il nest pas instantan ; il demande un certain temps
Il demande de lnergie, il nest donc pas donn, il faut mme le provoquer.

Figure 42 : Passage de la rticence laction

Les mthodes de conduite du changement ont donc pour objectifs de passer ses tapes, dans un dlai optimis mais qui ne peut tre
nul et dapporter les lments et lnergie ncessaires pour franchir les caps. Le risque inhrent au changement fait que dans la plupart
des grands projets, un chantier spcifique conduite du changement est mis en place. Ces actions peuvent tre classes en 4
catgories :
Linformation
Laccompagnement
La formation
La coordination et le pilotage

Il est important de comprendre que ces actions ont lieu dans la dure et ds le dmarrage des premires phases projet. Les actions
dinformation de formation, daccompagnement senchanent jusqu la prise en main de la solution ce qui entretient un rythme
continu et implique les personnes concernes.

Figure 43 : Exemple de plan de communication

Les actions dinformation sont ralises tout le long du projet depuis le dmarrage du projet et au-del de la mise en uvre.
Linformation concerne toutes les tapes de la ralisation du projet depuis le lancement jusqu la mise en uvre. Son cadencement
permet danticiper et de prparer les personnes aux vnements.
Les supports dinformation sont plutt de type indirect et collectif, mais linformation peut tre dlivre tout moment.
Laccompagnement a pour objectif damener les utilisateurs simpliquer dans la construction et la mise en uvre concrte du
changement. Elle doit permettre chacun d'exprimer ses doutes et rticences par rapport au changement annonc. Les rsistances
sont dautant moins fortes si elles sont immdiatement coutes, reconnues et comprises par le management de proximit.
Laccompagnement fait lobjet dune communication de type direct et individuel. Laccompagnement type se fait au travers datelier
sous un mode participatif ou chacun est amen sexprimer et proposer des solutions. Ces actions dinformation et
daccompagnement sont dfinies, listes, planifies et suivi dans le plan de communication qui est un des deux livrables cls de la
mthode de conduite du changement.
Bien sr, toute nouvelle organisation ou outil informatique ou changement doit donner lieu des actions de formation qui dtaillent
les objectifs et le fonctionnement mis en uvre. Un point important de ces informations est quau-del du fonctionnement
proprement dit qui doit tre clair et didactique, il faut prciser quoi sert la solution et contextualiser le fonctionnement : Quels sont
les bnfices attendus ?, en quoi la solution est un progrs ?. Il est ncessaire de projeter lutilisateur dans un projet et dans un rle
afin qui ressentent en quoi il est utile.

Enfin, les actions lies la conduite du changement doivent tre pilotes. A tout moment, il doit tre possible de dresser un bilan des
actions ralises et de leur efficacit, des risques encourus afin danticiper les problmes et prendre les actions ncessaires. Les
mthodologies standard structurent ces actions en 4 phases :

Figure 44 : Une mthode daccompagnement en 4 grandes tapes

Diagnostiquer et analyser pour adapter la mthode et la porte des actions, identifier les points durs, dfinir une stratgie
Planifier et budgtiser, dfinir la gouvernance de pilotage
Mettre en uvre les actions spcifiques de la conduite du changement vues prcdemment
Raliser le bilan de la dmarche, mesurer la satisfaction, savoir o lon en est

Il est important que le dmarrage de cette dmarche intervienne trs tt dans le processus projet afin danticiper les risques et les
problmes, dadapter les actions en consquence, dinformer les utilisateurs officiellement avant la mise en uvre dfinitive du
changement.

Les principaux livrables raliser sont :
Le plan de communication
Le plan de formation
Les supports de communication : prsentation support des ateliers, lettre et mail dinformation, flyers
Les supports de formation : prsentation support, manuel utilisateur

Ils mettent en uvre les techniques de communication et de mise en participation.
Si lon a dcid de mettre en uvre une dmarche de conduite du changement, on limite forcment les consquences de nombreux
risques lis la prise de loutil de ladaptation une nouvelle organisation.
Cependant, une dmarche de conduite du changement nest elle-mme pas labri du risque et de lchec. Il est crucial de pouvoir
anticiper les risques et de faire le point trs rgulirement (lors des points hebdomadaires par exemple) sur les diffrentes causes
dchec possible.
Un outil intressant pour cela est sur la matrice des causes dchecs suivante, partir de laquelle on peut se rfrer pour conduire son
analyse de risque.
A-t-on bien explicit puis communiqu sur la vision du projet, le contexte de mise en uvre, les progrs attendus, les objectifs
atteindre et donc donner une vision claire chacun des changements en cours ?
Les comptences pour sadapter la nouvelle organisation ou pour utiliser le nouvel outil sont-elles bien au rendez-vous et la
formation jouera-t-elle son rle ?

Chacun se sent-il bien reconnu dans son rle ? Les diffrentes personnes impliques seront-elles bien les acteurs du changement ?
Ne faut-il pas insister sur les ateliers participatifs ?
A-t-on bien anticip le besoin en ressource ?
Le plan daction est-il raliste, cohrent ? A-t-on bien identifi les diffrentes contraintes externes (congs, rorganisation, impacts
des autres projets, ?

Figure 45 : Quelques causes dchec au changement

5 EXEMPLE DAPPLICATIONS
5.1 Mise en place de rfrentiel Qualit
5.1.1 Qui est Aubay du point de vue des rfrentiels ?
Lactivit, les clients, les offres de la socit Aubay sont trs bien dcrites sur le site de lentreprise
4
ainsi que sur celui spcialement
destin aux jeunes diplms
5
. Nous invitons le lecteur consulter ces sites qui sont des mines dinformations pertinentes
rgulirement tenues jour.
En bref, disons seulement que Aubay est un acteur de proximit valeur ajoute qui dlivre des services de conseil en technologies,
R&D et intgration de systmes dinformation (Banque/Finance, Assurance, Industrie, Tlcoms) et rseaux trs haute vitesse. La
socit dispose de 2072 collaborateurs rpartis dans 11 bureaux, travers 6 pays europens (France, Belgique, Luxembourg, Italie,
Espagne et Portugal).
Les activits et les comptences en dveloppement logiciel et infrastructure IT sont au cur des mtiers de Aubay. En consquence, le
choix et lutilisation des rfrentiels se comprennent dans le contexte de promotion de nos activits front-office, de la notorit et de
la prennit de Aubay.
5.1.2 Comment choisit-on un rfrentiel chez Aubay SA ?
Nous le comprenons, la pondration des critres qui prside au choix dun rfrentiel chez Aubay peut tre significativement trs
diffrente de la pondration de ces critres pour nos clients DSI.
Voici trois critres majeurs :
Faciliter ladaptation permanente
Signification pour Aubay : Aubay opre sur un march dadaptation. La dure de vie dune offre est gnralement de 3 ans, ce qui est
aussi la dure ordinaire dun certificat. Il est donc illusoire de certifier des offres et donc beaucoup plus profitable dassurer la
notorit des activits et des comptences durables qui composent ces offres.

Contribuer la performance et la rgularit
Signification pour Aubay : chez Aubay un rfrentiel doit accompagner la performance de lentreprise. Il doit donc contribuer la
promotion des offres qui constituent notre front-office, assurer le fonctionnement efficient du middle et du back-office et contribuer
lattractivit de lentreprise pour le personnel, les candidats et les investisseurs.
Etablir un rfrentiel dentreprise prend entre 24 et 36 mois en moyenne. Or une personne reste en moyenne 4 ans chez Aubay. En
consquence, la prennisation des comptences et des pratiques professionnelles dans lentreprise ncessite de trouver un quilibre
raisonnable entre la facilit de mise en place dun programme de certifications individuelles et la prennit dune certification
dentreprise plus lourde tablir.
In fine, un rfrentiel chez Aubay doit accompagner la croissance organique et externe en contribuant optimiser les performances.

Aider tablir un rfrencement durable
Signification pour Aubay : pour Aubay les principaux rfrentiels sont choisis afin que le rfrencement et lattractivit de lentreprise
soient bien tablis pour les clients et les prospects, dune part, pour les investisseurs, le personnel et les candidats, dautre part. Ainsi,
un rfrentiel aide au dveloppement doffres pluriannuelles (centres de services et TMA). Aubay se place, dors et dj, parmi le top
10 des fournisseurs de ses plus importants clients.

4
www.aubay.com
5
http://jeunedip.aubay.com

5.1.3 Comment utilise-t-on un rfrentiel chez Aubay SA ?
Pour piloter lattractivit de lentreprise
Le rfrentiel historique utilis chez Aubay est constitu des normes comptables internationales IFRS/IAS. Ces normes internationales
sont destines conforter lattractivit de lentreprise lgard des investisseurs et des clients grands comptes en tablissant la
confiance en la gestion prenne de lentreprise.
En quelques chiffres :
en 2004, le rfrentiel IFRS IAS est tabli et prenne. Aubay est alors un groupe en forte croissance, de 60 M, introduit en bourse,
dont leffectif est denviron 700 personnes en Europe dont environ 200 personnes en France. Les prestations de conseils en
technologie sont innovantes. La valeur ajoute de celles-ci provient principalement de lexpertise des ingnieurs qui les dlivrent.
Le mode de dlivrance est essentiellement lassistance technique. Lattractivit de lentreprise est aussi assure vis--vis des
collaborateurs par des relations solides avec les coles dingnieurs et la cooptation.
en 2005 et 2008, Aubay obtient la labellisation OSEO-ANVAR entreprise innovante. Valable 3 ans, cette labellisation fera
nouveau lobjet dun dpt de dossier en 2011.Ceci contribue tablir lattractivit de lentreprise sous ses diffrentes
perspectives et la prparer satisfaire des offres engagements diversifis demandes par le march.

Le rfrentiel IFRS IAS et le label OSEO-ANVAR sont bien tablis et prennes.

Pour piloter le front-office et la satisfaction client
Afin de se prparer poursuivre une forte croissance interne et externe donc assurer des prestations engagement profitables la
fois pour Aubay et ses clients, un rfrentiel de gestion matris des actifs mtiers est mis au point et abouti, en 2006, une
certification qui tablit que la gestion maitrise de la qualit de Aubay France est conforme aux exigences de la norme internationale
ISO 9001.
En 2006, un premier palier est atteint, le groupe Aubay ralise environ 120 M, leffectif, qui dpasse 2000 personnes, a t multipli
par 6 en France.
Ainsi, tout en prservant les acquis en termes dattractivit et dinnovation, il est dsormais essentiel dassurer la gestion maitrise de
la qualit de plus de 1000 prestations simultanes en Ile de France. Ces prestations se droulant, en 2006, principalement en
Assistance Technique.
Le palier de 2006 fut atteint principalement par croissance externe et les rfrentiels IFRS IAS et ISO 9001 ont permis doptimiser la
fois lintgration financire et lintgration mtier. En effet, IFRS IAS et ISO 9001 fournissent des cadres de rflexion pour piloter
lattractivit et la satisfaction des clients pendant la phase transitoire dintgration.
Le rfrentiel de qualit gnrale ISO 9001 est tabli depuis 2006. Il renforce IFRS IAS et le label OSEO ANVAR.

Pour piloter le middle et back-office dune grande entreprise
En sus de la contribution la croissance du CA par le biais des rfrencements et du pilotage de la satisfaction client via les activits
front-office, la gestion maitrise de la qualit gnrale sapplique loptimisation du middle office et du back-office qui contrlent et
administrent les activits. Les enjeux dun bon fonctionnement sont loptimisation des dlais de paiement qui contribuent une bonne
trsorerie, la diminution des dysfonctionnements et de leurs impacts sur le front-office (rclamation, pnalit), la diminution du stress
et de ses impacts sur lattractivit de lentreprise. La norme internationale ISO 9001 couvre loptimisation du fonctionnement du
middle et du back office.
Le rfrentiel de qualit gnrale ISO 9001 est tabli depuis 2006 et renforce IFRS IAS.

Pour piloter des activits front office rgulires dune grande entreprise
A cot des activits innovantes labellises OSEO-ANVAR trs forte valeur ajoute, il existe chez Aubay des activits rgulires
pluriannuelles valeur ajoute qui se renouvellent un rythme plus lent que celui des activits purement innovantes.
Les normes internationales et gnrales IFR IAS et ISO 9001 couvrent lensemble des activits. Cependant, cot de la comptabilit
gnrale et de la qualit gnrale, ces activits rcurrentes ont besoin de rfrentiels de qualit analytique sectorielle comme CMMI
ou ITIL, pour ne citer queux.
Les activits rcurrentes sont soumises plus que les activits innovantes :
1) des comparatifs mthodiques,
2) une mise en concurrence systmatique,
3) lexternalisation des sites clients et des regroupements,
4) une pression sur les prix qualit constante

Quelles sont les consquences ?
Il est ncessaire pour ces activits, dont le CA pluriannuel augmente, de saligner sur des rfrentiels sectoriels qui permettent, dune
part, nos clients de comparer leurs fournisseurs et, dautre part, une gestion analytique de ces activits spcifiques (dveloppement
de logiciel, exploitation des infrastructures IT, scurit informatique).
Ainsi, ces rfrentiels sectoriels permettent de continuer avoir voix au chapitre. Cependant, ils ne font pas toujours par eux-mmes
une diffrence comptitive.
En consquence, aprs avoir montr patte blanche grce la conformit aux exigences ncessaires de ces rfrentiels sectoriels, une
analyse de la Direction Gnrale prouve que lavantage comptitif de Aubay se situe dans sa position dacteur de proximit. Aussi,
aprs avoir fait le ncessaire, il convient de bien continuer piloter cette relation de proximit qui donne entire satisfaction.
5.1.4 Comment seffectue la mise en uvre ?
Depuis sa cration en 1997, Aubay a toujours t sensible la qualit de ses prestations, la satisfaction de ses clients et la
comptence de ses collaborateurs en faisant preuve de responsabilit sociale et environnementale. Ces dernires annes, la direction
gnrale du Groupe Aubay a dcid de dvelopper de manire significative son programme dactions vers l'optimisation de la
satisfaction de ses clients, le respect de lenvironnement, la formation de ses collaborateurs, ainsi quune approche collaborative o
chaque collaborateur bnficie en continu de la comptence collective du Groupe. Aubay place ainsi la qualit et linnovation au cur
de sa stratgie de dveloppement.
Le bureau Veritas, leader mondial de lvaluation et de la certification, atteste que la gestion de la qualit de Aubay SA est conforme
la norme ISO 9001-2008.
Aubay SA traduit ses valeurs fondamentales au quotidien par des rflexes mtiers organiss selon sa politique de gestion de la qualit
C-T-R-L. La politique C-T-R-L est donc un catalogue de critres non-financiers, valids par la Direction Gnrale, sur lesquels doit
saligner le dispositif de gestion de la qualit patrimoniale qui vise la matrise du bon droulement des activits et lobtention des
rsultats escompts.
La politique C-T-R-L snonce, sous la forme dun acrostiche :
Comprhension des besoins
Impliquer les acteurs
Collecter les amliorations
Dcrire les activits

Tenue des engagements
Planifier avant de raliser
Traiter les carts
Appliquer les directives

Ressources performantes
Fournir des ressources professionnelles
Affecter clairement les responsabilits
Former et informer les acteurs

Livrables pertinents
Piloter par rapport au plan
Grer les configurations
Evaluer la conformit

Sur la dure de trois ans dun certificat, le respect des exigences de la norme internationale ISO 9001 est formellement vrifi 9 fois
dont 3 fois par bureau Veritas qui peut, chaque anne, suspendre le certificat ou le renouveler.

5.2 Certification CMMI
5.2.1 Naissance dune volont
Fort de sa certification rpte au fil des ans sur la norme ISO, grce son approche CTRL, Aubay a accueilli avec confiance la pression
du march visant se faire certifie conforme au modle CMMI.
En effet, les plus grands clients de notre socit Aubay ont entam en 2008 une marche vers le modle CMMI, dans laquelle ils ont
souhait emmener leurs principaux fournisseurs pour 3 raisons :
1) Sassurer que les quipes intgres mlant internes et externes seraient capable daccomplir cette mutation ;
2) Sappuyer sur lexpertise qualit de leurs fournisseurs pour booster leur propre dmarche ;
3) Disposer dun critre de tri supplmentaire vis--vis de ces fournisseurs.
Une SSII ne peut de son ct reste insensible une dmarche qui :
1) lassocie une volution importante voulue par ses clients,
2) assure une plus-value commerciale,
3) propose un accroissement de lefficacit et de la prennit du travail de ses quipes.
5.2.2 De CTRL CMMI
La certification ISO 9001-2008 est une certification globale de lentreprise, dont une des phrases biens connues de synthse est : on
crit ce quon fait, on fait ce quon crit . Au-del de cet aspect rdactionnel exig par la norme, celle-ci au cours de son
dveloppement, insiste de plus en plus sur la logique, la prennit, lefficacit, le suivi des processus dentreprise.
Ces valeurs sont des valeurs que lon retrouve dans le modle CMMI, au travers des pratiques gnriques notamment. Cependant il
existe des diffrences fondamentales entre ces deux approches. La premire est la spcificit de CMMI sur des projets dingnierie,
versus lapproche entreprise de ISO.
De ce fait, CMMI va beaucoup plus loin que ISO sur des aspects dingnierie, de mtier informatique.
Inversement, ISO aborde dautres aspects plus gnraux lentreprise, sur son fonctionnement interne.
ISO sapplique sur toute sorte dentreprise, industrielles, artisanales, tertiaires, et ce dans tous les secteurs de lconomie.
Lapproche est donc extrmement gnrique. Cest une des forces de la norme.
CMMI peut sappliquer si et seulement si le mtier de lentreprise ou dun dpartement de lentreprise est le dveloppement
informatique, ou le service
Ainsi, le terrain commun CMMI et ISO 9001 est tnu, mme sil est sous tendu par des valeurs universelles de bonne gestion, comme
lalignement de lorganisation aux besoins de lentreprise, la mise disposition de moyens adquats, lengagement de la direction
auprs des oprationnels, etc.
5.2.3 Les premiers pas vers CMMI
La dmarche retenue par Aubay vers la certification CMMI est progressive.
En effet, devant le niveau dexigence du modle, et le dtail des critres dligibilit, il nous apparat ncessaire de commencer par un
tat des lieux appliqu. Cet tat des lieux, qui doit analyser, Process Area par Process Area, Specific Practice par Specific Practice, est
ncessaire afin dapprhender sur des cas rels, les exigences du modle, et de mesurer dans le dtail la maturit de lentreprise.
Cest cette occasion que lon peut identifier les carts entre lexistant et le modle, et envisager un projet damlioration adquat.

La notion de maturit
Le terme maturit est un terme consacr dans CMMI. D'aprs la dfinition donne dans le CMMI, la maturit d'une organisation est le
degr auquel celle-ci a dploy explicitement et de faon cohrente des processus qui sont documents, grs, mesurs, contrls et
continuellement amliors.
Un niveau de maturit (Maturity Level) correspond l'atteinte d'un niveau de capabilit uniforme pour un groupe de processus. Un
niveau de capabilit (Capability Level) mesure l'atteinte des objectifs d'un processus pour le niveau donn. En clair, un niveau de
capabilit est un degr de maturit pour lensemble des processus

Lexigence de la norme
La norme est entirement dfinie dans un livre, le Guidelines for Process Integration and Product Improvement. Ce livre est disponible
en franais aussi, bien que parfois la traduction puisse tre source de confusion.
Ce livre de plus de 600 pages est extrmement bien fait, et dtail le contexte, les certifications, les PA, les SG, les SP, les GG, les GP.
Pour chacune il donne une dfinition, des exemples de preuve, des ides, des illustrations.
Cette compltude est en phase avec le niveau dexigence dune certification. Cette exigence peut -tre source de dsillusion si des
personnes non expertes du modle tentent dexaminer les processus existants en regard du modle.
En effet, comme tous les modles pragmatiques, CMMI ninvente rien de rvolutionnaire. Les pratiques listes sont des pratiques de
bon sens, que tout ingnieur connat, et prtend suivre peu ou prou.
En premire lecture, la norme apparat donc comme un pense-bte permettant un oprationnel de lister les actions ne pas oublier.
Cest dailleurs une utilisation possible du modle, mais qui nest pas celle retenir dans loptique dune certification.
Certaines pratiques toutefois sont de nature alerter le lecteur sur la complexit de latteinte dun niveau. Dans les processus avancs,
un service peu mature dans le mtier de lingnierie peut dtecter des activits pas du tout adresses. Citons par exemple, dans la PA
REQM (Requirement Management) la SP 1.4 (Maintain Bidirectional Traceability of Requirement), qui indique que le lien entre une
demande client et un produit livr doit tre trac, et quil doit tre possible en permanence de le suivre dans un sens comme dans
lautre.

Une dmarche ncessairement accompagne
La marche vers un niveau 2 est estime environ 18 mois. Cette dure inclut un tat des lieux, une confrontation au modle, la mise
en place de nouveaux processus, et la prparation de laudit.
Il est illusoire de prparer un audit sans se faire accompagner par un expert du modle. En effet, lexigence de la norme, ainsi que la
complexit du modle, excluent tout amateurisme dans la dmarche.
5.2.4 Le vcu Aubay
Aubay est en phase de certification de niveau 2 sur lensemble des projets de son Centre de Service Bancaire. Pour cela, Aubay se fait
accompagn par diffrents cabinets dexpert, reconnus sur le march et par ses clients.
Aprs une premire phase danalyse des carts, et un premier plan damlioration, qui a permis de progresser significativement lors de
deux readiness en 2010, la dernire ligne droite est aborde avec confiance, puisque les volutions apportes sur la dmarche projet
lont t en concertation entre les experts externes, la direction de la qualit, la direction technique, les oprationnels, et la direction
gnrale.
Ce consensus global est absolument ncessaire tant est grand limpact dune mise niveau CMMI au cur dune palette de projets
concernant diffrents clients, diffrents chefs de projets, diffrentes technologies, diffrentes approches commerciales.
En effet, dans loptique dun niveau de maturit 3, une SSII comme Aubay peut souffrir de laffrontement dune part de la volont
duniformisation de ses pratiques au niveau de lensemble de ses projets et dautre part de linfluence puissante des choix
dorganisation des clients afin de favoriser la gestion et lintgration de ses prestations engagement de rsultats et de moyens.

5.3 Un projet dvelopp en mode SCRUM
Ce chapitre dcrit une application de la mthode SCRUM au sein dun projet pilot par la socit AUBAY.
5.3.1 Contexte du projet
La mthodologie SCRUM a t utilise dans le cadre du projet ARGO ralis pour le compte de Sigedis, ASBL (association sans but
lucratif) dans le secteur public des pensions belge.
Sigedis est un organisme qui a pour mission de centraliser et damliorer la qualit des donnes identitaires et carrire des salaris
(employs et ouvriers) belges ou travaillant en Belgique. Ceci afin de permettre in fine le calcul de la pension lgale de ceux-ci.
Dans le cadre de sa mission, Sigedis est amen changer de nombreuses donnes avec dautres organismes et plus de deux milles
partenaires du rseau de la scurit sociale belge, mais galement traiter manuellement ces donnes.

L'objectif du projet tait :
lors d'une premire phase, de migrer le systme existant dun mainframe vers une plateforme JavaEE et
lors d'une seconde phase, dajouter de nouvelles fonctionnalits au systme tel que :
- Des services web destination des diffrents partenaires et organismes du rseau de la scurit sociale
- Un portail destin au citoyen, afin que ce dernier puisse consulter ses donnes, son dossier de pension et faire un calcul de
simulation du montant de la pension lgale.
Le systme ARGO a t implment dans une architecture JavaEE, avec les outils suivants :
le serveur applicatif JBoss,
le systme de base de donnes relationnelle Oracle,
l'orchestrateur BPEL d'Oracle,
le systme de gestion documentaire Alfresco et
loutil ddition de rapports Business Objects, utilis galement comme interface vers un datawarehouse.
Le projet a t ralis dans le cadre dun march public forfaitaire. Le projet a dbut en octobre 2006. La premire phase a t mise
en production en juin 2009 et la deuxime phase a t mise en production par lots entre juin 2010 et mars 2011.
5.3.2 Le choix de SCRUM
Ce projet, men conjointement avec SIEMENS, possdait des contraintes contractuelles fortes, telles qu'un budget dtermin d'avance
et un dlai fixe, correspondant deux annes civiles, assortis d'astreintes importantes, correspondants aux cots de fonctionnement et
de maintenance de l'ancien systme mainframe pendant une dure d'une anne, en cas de retard de livraison.
Etant donn la taille du projet, le fait qu'une phase de pr-analyse existait dj et les dlais impartis, le choix sest port naturellement
sur une mthodologie de type Waterfall.
Mais rapidement il s'est avr que cette mthode ne convenait pas pour les raisons suivantes :
1) Ncessit et dure de l'Analyse du projet. Ni le cahier de charges ni la documentation du systme mainframe n'taient
suffisamment clairs pour dmarrer la premire phase de ralisation du projet (migration/rcriture du systme mainframe
existant). Ceci a amen la ralisation d'une phase d'analyse trs importante (de l'identification des processus mtier l'analyse
fonctionnelle dtaille).
Un cycle lourd de runions, rdaction, validation de documents d'analyse, rdaction, nouvelle runion, nouvelle validation, s'en
est suivi.
Cette phase d'analyse s'est ternise, le client (secteur public) se dissipant et ne tenant pas compte des contraintes de temps
critiques pour le matre duvre.
2) Vu la taille du projet, diffrentes quipes ont t formes par discipline (analyse, dveloppement, test, base de donnes), sans
prvoir de relles couches de communication transversales. Ce qui a amen des clivages et intrts contraire au sein du mme
projet.
Aprs six mois d'analyse, sans rel autre rsultat que des dossiers d'analyse non valids, il a t dcid :
de recentrer le primtre du projet sur base du systme existant.
d'opter pour une mthode agile, Scrum en l'occurrence, afin de limiter le surcot dune trop grande formalisation,
ainsi que de favoriser la communication et la validation informelle et rapide, et ainsi montrer au matre douvrage
que son projet volue correctement.
de prioriser et de dcider du phasage des fonctionnalits du systme avec le client.
5.3.3 Points cls
Voici ici quelques autres points essentiels sur la mise en uvre de Scrum dans le cadre du projet Argo :
1) Tous les matins, l'ensemble de l'quipe se runit heure fixe pour permettre chacun de rpondre aux 3 questions suivantes :
Ce qui a t ralis la veille. Ces prestations sont reportes sur un tableau Excel affich au mur et qui permet de visualiser
rapidement l'tat d'avancement des diffrentes tches.
Ce qui est prvu pour le jour-mme.
Les difficults rencontres qui ncessite une intervention extrieure.
En outre, des messages gnraux peuvent tre changs lors de cette runion :
informations sur l'tat de l'application. Un outil de build en continu produit, de manire quotidienne, diffrents indicateurs sur
l'tat du projet. Ces indicateurs sont :
- le nombre d'incidents ouverts traiter.

- le nombre de tests unitaires qui ne sont pas drouls correctement.
- la part du code couvert par ces tests unitaires.
- la qualit de la documentation technique (javadoc).
communications du chef de projet

2) Au dbut de chaque Sprint, une runion est organise avec l'ensemble de l'quipe pour survoler le contenu du Sprint. Ensuite, c'est
par "User Story" qu'est organise une runion avec uniquement les membres de l'quipe concerns par cette user story. Voir
galement le point 5.3.5. Difficults et ajustements ce sujet.

3) A la fin de chaque Sprint, une runion de rvision du sprint est organise pour revoir les points forts et les points faibles de
l'organisation courante. A l'exception des premires fois o toute l'quipe a t runie, ces runions ne reprenaient que les
personnes cls dans l'quipe.

4) Mme si ceci n'est pas particulirement li l'utilisation de SCRUM comme base pour la mthodologie de travail, la qualit de
l'application est contrle en permanence par un outil de build en continu. L'utilisation d'un tel outil permet de ragir rapidement
aux problmes rencontrs. Dans notre cas, tant donn la taille de l'application et la dure d'un cycle complet de build, chaque
fois qu'un dveloppeur publie du code, seule une compilation est ralise qui dure de 15 30 minutes. A intervalle rgulier (de 1
3 fois par jour en fonction des priodes du projet), un cycle complet de build (y compris l'excution de tous les tests unitaires, des
tests d'intgration automatiss et la construction des indicateurs du projet) est ralis. Ce cycle dure environ 2 heures.
5.3.4 Les facteurs qui ont permis le succs de la mthode
L'utilisation de SCRUM dans ce projet a t un succs, notamment grce :
la disponibilit plein temps d'un interlocuteur du client, ayant un niveau de connaissance lev du mtier de Sigedis et du
milieu de la scurit sociale belge, et disposant dun pouvoir de dcision rel.
La prsence dun rfrentiel applicatif, savoir le systme remplacer, comme base pour la validation du nouveau systme.
Des cycles de dveloppement relativement courts permettant de limiter et davoir une vision claire du primtre des
fonctionnalits raliser au cours de chaque itration, tant au niveau de leurs analyses quau niveau de leurs mises en uvres.
Le feedback rapide des utilisateurs cls, permettant dintgrer rapidement les corrections et amliorations utiles dans des
dlais relativement courts.
La visibilit permanente de lvolution du produit, permettant ainsi chacun de juger de la bonne marche du projet.
5.3.5 Difficults et ajustements
Le contexte particulier d'un projet implique, la plupart du temps, de s'adapter des contraintes et des situations particulires.
1) Une premire difficult rencontre dans le cas prsent a t le cadre forfaitaire pour la ralisation du projet. Ceci a eu pour
implication, dans le chef du matre duvre, de contrler de manire stricte le scope de l'application raliser, tout en faisant
preuve de flexibilit pour permettre d'y inclure des demandes de changements par rapport au cahier des charges initial. Etant
donn le nombre d'intervenant dans le chef du matre d'ouvrage, la gestion du scope des diffrentes versions de l'application a
ncessit certains arbitrages "politiques" et a requis une certaine flexibilit dans l'laboration et l'volution des sprint backlog .

2) Une deuxime difficult a t le nombre de fonctions de l'application et la taille de l'quipe. Etant donn que l'quipe a compt
jusqu' 40 personnes, il aurait t ingrable de runir l'entiret de l'quipe pour la planification des diffrentes versions. Ainsi le
choix des "user stories" faisant partie d'un sprint, de mme que son estimation initiale en termes de charge de travail, n'tait pas
du ressort de l'quipe dans son ensemble mais seulement d'une partie de celle-ci. Afin de rpartir et de suivre au mieux le travail
sur chaque user story faisant partie d'un sprint, une proposition de rpartition des ressources tait galement tablie lors de la
planification du sprint. Ainsi, pour chaque "User Story", une sous quipe tait dsigne au sein de l'quipe globale. Cette sous
quipe tait compose de :
un analyste ayant une connaissance suffisante de la fonctionnalit dvelopper,
un analyste-programmeur expriment ou architecte ayant pour responsabilit de coordonner les choix techniques dans le
cadre de cette user story
des programmeurs pour la ralisation technique.
Un membre de l'quipe projet pouvait tout fait tre planifi sur plusieurs "User stories", en fonction de ses comptences, de ses
affinits et de sa disponibilit.
Chacune de ces sous quipes commenait, avant tout dveloppement, par se runir pour fixer les dtails du dveloppement :
l'laboration de la liste des tches raliser.
la rvision des estimations faites lors de la planification du sprint.
la rpartition des tches entre les diffrentes personnes.


3) Une troisime difficult tait la trop grande spcialisation de la plupart des membres de l'quipe-projet. Trois grands types de
profils s'y sont ctoys, pas facilement interchangeables : analystes mtier, techniciens (analystes-programmeurs, programmeurs
et architectes) et testeurs. Ils interviennent diffrents moments dans le cycle de dveloppement d'une user story. Ainsi, pour
permettre une occupation optimale de l'ensemble des personnes dans l'quipe, 2 sprints successifs se sont superposs d'une
semaine. Par consquent, lors de la dernire semaine d'un sprint, pendant que les testeurs taient en plein tests de validation des
user stories, les techniciens commenait dj le travail de dveloppement du sprint suivant, tout en assurant la correction des
problmes dtects lors des tests. Le gestionnaire de version des sources a t indispensable pour permettre le travail sur plusieurs
versions en parallle.

4) Enfin, une dernire difficult rencontre a t la dure ncessaire pour les tests de qualifications entre la livraison d'une version de
l'application et sa mise en production. Cette dure (4 6 semaines) a parfois amen des problmes, ncessitant des patches
correctifs, n'tre dtects que trs tard durant le sprint suivant. A nouveau, l'utilisation intelligente du gestionnaire de sources et
la flexibilit dans la gestion du planning a permis de rpondre aux situations urgentes.

6 CONCLUSION

Le choix dune mthode de dveloppement de projet est parfois dlicat. Certaines ont cependant fait leurs preuves et rencontrent un
rel succs, tant chez les praticiens que chez les thoriciens.
Mais le sujet est en perptuelle tude et volution car la marge de progrs est encore leve sur le taux de russite des projets
informatique. Il suffit pour cela de comparer les benchmarks pour bien raliser que cette science est encore jeune et ne peut donc par
rivaliser avec les 3000 ans de pratique de celle du BTP par exemple
A ce jour, les mthodes les plus reconnues sont celles dcrites dans le prsent ouvrage et pour lesquelles la socit Aubay possde de
relles comptences.

Concernant les rfrentiels Qualits dentreprise, leur mise en uvre se rapproche dun projet au long court plus quune preuve
laborieuse comme certains retours dexprience pourraient le laisser croire Mais leur certification est un passage oblig pour toute
SSII qui souhaite prendre la responsabilit de Centres de Services, TMA ou autres projets au forfait.

Cependant, il ne sagirait pas doublier que le succs de toute entreprise conduite par des hommes repose essentiellement sur les
valeurs intrinsquement humaines des individus participants au projet et ce constat est particulirement vrai pour le Chef de projet,
dont les qualits de charisme, denthousiasme, desprit de dcision, de rigueur et de ngociation seront primordiales.

7 DETAIL SUR LES PROCESSUS ITIL V2

7.1 Les processus du Soutien des Services
Le Soutien des Services (Service Support) permet d'effectuer les oprations quotidiennes ncessaires au maintien et l'amlioration de
la qualit des services rendus aux utilisateurs.
7.1.1 Le Centre de Services (Service Desk)
Le point d'entre unique (encore appel Guichet Unique) de la production informatique est le Centre de Services ou Service Desk. Le
Centre de Services est le point de contact unique entre les diffrents acteurs oprationnel : clients, utilisateurs, quipes de production
et organisations tierces (socits de sous-traitance ou d'externalisation).
Il s'agit d'une fonction et non d'un processus. Elle est stratgique dans l'entreprise car elle est probablement la fonction la plus
importante dans lorganisation de la production informatique. Le Centre de Services est la seule composante visible dans l'entreprise
du niveau de service et du professionnalisme dune organisation (en termes de perception et de satisfaction clients).
Diffrences de terminologies :
Le Centre dAppels (ou Call Center) permet la gestion d'un volume trs important dappels tlphoniques,
Le Centre de Support (ou Help Desk) permet la gestion, la coordination et la rsolution des dysfonctionnements utilisateurs
aussi rapidement que possible,
Le Centre de Services (ou Service Desk) s'tend toutes les demandes de la production informatique et effectue une approche
client globale en intgrant l'ensemble de ses demandes.
En arrire-plan du Centre de Services, se trouvent les activits oprationnelles de la production informatique.
7.1.2 La Gestion des Incidents (Incident Management)
Un incident est un vnement qui ne fait pas partie du fonctionnement standard d'un service et qui cause, ou peut causer, une
interruption ou une diminution de la qualit de ce service.

Figure 46 : Cycle de vie dun incident

L'objectif de la Gestion des Incidents est de :
restaurer aussi vite que possible le fonctionnement normal des services,
minimiser limpact ngatif sur les activits mtiers,
sassurer ainsi que les meilleurs niveaux de qualit de service et de disponibilit sont maintenus.


Figure 47 : Processus de gestion des incidents

Les rles du Centre de Services dans la Gestion des Incidents sont :
tous les incidents doivent tre remonts vers le Centre de Services et doivent tre enregistrs par celui-ci (y compris les
remontes automatiques),
la majorit des incidents (jusqu 85%) doivent tre rsolus par le Centre de Services,
le Centre de Services constitue une fonction indpendante de suivi de lensemble des incidents jusqu leur rsolution
complte,
le Centre de Services effectue la coordination des quipes de support intervenant dans la rsolution des incidents.

7.1.3 La Gestion des Problmes (Problem Management)
Un incident est la consquence dchecs ou derreurs de traitement dans linfrastructure informatique. La cause dun incident peut tre
vidente et radique directement par le Centre de Services sans investigation complmentaire.
Quand la cause sous-jacente dun incident nest pas connue, il est ncessaire d'initialiser un problme dans le processus de Gestion des
Problmes.
Un problme est ainsi le signe dune erreur inconnue dans linfrastructure. Plusieurs incidents peuvent sembler partager la mme
origine donnant lieu la dfinition dun problme unique.
Un problme est indpendant des incidents qui lui sont associs. Lanalyse du problme peut continuer mme si les incidents ont t
rsolus et ferms.
La rsolution dun problme consiste en l'identification de lerreur sous-jacente et en la mise au point dune solution de
contournement ou l'mission dune demande de changement.
Le problme devient alors une erreur connue.
Dfinitions :
un problme est la cause inconnue d'un ou plusieurs incidents.
une erreur connue est un problme diagnostiqu correctement et pour lequel soit une solution de contournement existe, soit
une demande de changement a t mise.
une demande de changement est une demande dajout, de modification, dvolution ou de suppression de composants de
linfrastructure informatique ou pour tout autre aspect de la production informatique.
Les interactions entre les processus de Gestion des Incidents et de Gestion des Problmes sont complexes mais il est ncessaire de les
matriser afin de bien sparer ces deux processus dont les finalits sont trs diffrentes.
L'objectif de la Gestion des Problmes est de :
minimiser limpact ngatif sur les activits de lentreprise, des incidents et problmes causs par des erreurs dans
linfrastructure informatique,
prvenir la rapparition des incidents induits par ces erreurs.
Pour cela, la Gestion des Problmes recherche la cause premire des incidents et initie des actions d'amlioration ou correction de la
situation.


Figure 48 : Processus de gestion des problmes

7.1.4 La Gestion des Changements (Change Management)
Un Changement est un processus permettant une transition dun tat stable vers un nouvel tat stable en optimisant lexposition aux
risques, limpact et la svrit des dysfonctionnements conscutifs limplmentation de ce changement.
L'objectif de la Gestion des Changements est de sassurer que des mthodes et procdures standards sont utilises pour une prise en
main efficace et rapide de tous les changements.
Le but est de minimiser limpact des incidents conscutifs limplmentation de ces changements et, par consquent, damliorer
lexploitation quotidienne.
Lorsqu'un changement est rendu ncessaire, il faut valuer les risques de sa mise en uvre et la continuit de lactivit mtier pendant
et aprs cette mise en uvre.
L'approbation des changements se fait au cours d'un Comit Consultatif des Changements (Change Advisory Board ou CAB).
Le CAB constitue lautorit de dcision permettant d'approuver une Demande de Changement (ou Request for Change ou RFC), sauf en
cas de changement mineur. Il est constitu des reprsentants de la plupart des autres fonctions de lentreprise.
La Gestion des Configurations doit sassurer que toutes les informations de configuration sont fournies (impacts possibles dtects et
prsents correctement).

Figure 49 : Processus de gestion des changements

Les processus de Gestion des Changements, des Configurations et des Nouvelles Versions sont troitement lis. La Gestion des
Changements ne comprend pas :
l'identification des composants de linfrastructure impacts par un changement (Gestion des Configurations),
le dploiement et la mise disposition aux utilisateurs des modifications et ajouts de composants (Gestion de Nouvelles
Versions).
7.1.5 La Gestion des Mises en Production (Release Management)
L'objectif de la Gestion des Mises en Production est de protger lenvironnement de production et ses services, par :
lutilisation de procdures formelles,
des vrifications lors de limplmentation des changements.
Les changements sont intgrs dans les Distributions et implments en production lors de Dploiements.

La Gestion des Mises en Production permet :
de planifier et superviser le dploiement dun logiciel et du matriel associ,
d'laborer et implmenter les outils de distribution et dinstallation des changements,
de sassurer que les matriels et logiciels changs sont traables, srs et que seules les versions correctes, autorises et testes
sont installes,
de communiquer et de grer les attentes des clients pendant la planification et le droulement des dploiements,
de valider le contenu exact dune distribution et le scnario de dploiement en liaison avec la Gestion des Changements,
dinstaller les nouvelles versions logicielles et les matriels en production en respectant les procdures de la Gestion des
Changements et des Configurations,
de sassurer que les distributions dorigine de tous les logiciels sont stockes et scurises dans la Bibliothque des Versions
Logicielles Dfinitives (Definitive Software Library ou DSL) et que la base de donnes des configurations (Configuration
Management DataBase ou CMDB) est mise jour (cf. Gestion des Configurations).
7.1.6 La Gestion des Configurations (Configuration Management)
La Gestion des Configurations fournit un modle logique de linfrastructure informatique en identifiant, contrlant, maintenant et
vrifiant les diffrents lments au cours de leur dure de vie.

Les objectifs pratiques de la Gestion des Configurations sont les suivants :
rendre compte lorganisation de tous les biens et configurations de la Production Informatique,
fournir une information pertinente sur les configurations pour le support des autres processus,
fournir des bases solides pour la Gestion des Incidents, des Problmes, des Changements et des Nouvelles Versions,
comparer linformation stocke linfrastructure et corriger les diffrences.

Le rle de la Gestion des Configurations est l'identification, l'enregistrement et la restitution de linformation sur tous les composants
de linfrastructure informatique.
Le primtre intgre :
les matriels,
les logiciels et applications,
les documentations associes.
La gestion des composants inclut leurs versions, leurs sous-composants ainsi que les interrelations entre eux.


Figure 50 : Processus de gestion des configurations

7.2 Les processus de Fourniture des Services
La Fourniture des Services (Service Delivery) permet
d'effectuer le suivi des contrats de services passs avec les utilisateurs,
de grer toutes les actions relatives aux problmatiques globales (tous les contrats de service) et transversales (toutes les
quipes techniques de la production informatique).
7.2.1 La Gestion des Niveaux de Service (Service Level Management ou
SLM)
La Gestion des Niveaux de Service est indispensable pour :
permettre toute organisation des systmes d'information de dterminer le niveau de service dlivrer pour supporter les
mtiers de lentreprise,
initialiser un suivi permettant d'identifier si les niveaux de services demands ont t atteints ou non et, si non, pourquoi.
Le but de la Gestion des Niveaux de Services est de maintenir et amliorer la qualit de service des systmes d'information au travers
d'un cycle permanent daccords.
Ces accords sont agrments de suivis et de reporting sur latteinte des objectifs et sur les actions menes pour radiquer la mauvaise
qualit (support des mtiers ou justification des cots).
Une meilleure relation entre la DSI et services mtiers peut tre dveloppe partir de la gestion de ces accords.
Le primtre de la Gestion des Niveaux de Service contient :
la prparation, la coordination, la rdaction, la signature, le suivi et le reporting de ces accords,
la revue permanente de latteinte des objectifs pour sassurer que la qualit de service requise et budgtairement justifiable est
maintenue et amliore progressivement.
Les Accords de Niveaux de Services (Service Level Agreements ou SLA) dfinissent des objectifs spcifiques sur lesquels les
performances de lorganisation des systmes d'information peuvent tre juges.
Les SLA portent sur tous les services fournis par les systmes d'information.
Les contrats sous-jacents ou Contrats de Sous-Traitance (Underpinning contracts ou UC) et les Accords de Niveaux Oprationnels
(Operational Level Agreements ou OLA) concernent tous les fournisseurs internes et externes.
L'Accord de Niveau de Service est un accord sign entre le fournisseur de services (systmes d'information) et le client. Il dfinit les
objectifs et les responsabilits des deux parties.


Figure 51 : Relation entre les clients et la gestion des niveaux de service
7.2.2 La Gestion Financire des services des TI (IT Services Financial
Management)
La gestion financire des services informatiques a pour but la mise en place de processus budgtaires et comptables, voire de
processus de refacturation clients, afin de justifier les cots de fonctionnement et de mise en uvre de Services.
La gestion financire dans une entreprise supporte lorganisation en planifiant et en mettant en uvre les objectifs mtiers.
Pour une Production Informatique, cela se concrtise avec trois processus principaux :
la budgtisation,
la comptabilit,
la facturation.

Le processus de budgtisation
Il s'agit d'un processus de prvision et de contrle des dpenses dans une organisation :
un cycle priodique de ngociation pour dfinir les budgets (gnralement annuels),
un suivi quotidien de ces budgets.
Le but de la Budgtisation est de sassurer que les cots rels correspondent aux cots prvisionnels.
Les budgets sont, en gnral, issus de ngociations grosses mailles: les services mtiers allouent des budgets informatiques
proportionnels leur budgets de fonctionnement et ce, souvent en fonction des indications de cot de la Production Informatique.
Par la suite, il est important, pour les services mtiers, de dterminer quelle hauteur les budgets informatiques seront consomms
avant la fin de la priode et de prendre les bonnes dcisions pour grer au mieux ces budgets.

Le processus de comptabilit
Il s'agit d'un ensemble de processus permettant la Production Informatique de comptabiliser la manire dont sont dpenss les
budgets (ventilation par clients, par services ou par activits).
Certaines organisations (comme dans le cas de l'externalisation de la production) doivent mettre en place de vritables processus
comptables pour leurs ressources informatiques.
La comptabilit des SI peut tre utilise pour connatre la consommation exacte de CPU, d'espace-disque et de bande passante mais il
nest pas recommand d'utiliser ces critres comme base de refacturation pour les clients car le cot de ce service comptable reste
prohibitif.

Il est de lintrt de toutes les parties de dfinir un cot minimum de gestion comptable et de mettre en place le systme de
refacturation le plus simple possible mme si cela doit se faire aux dpens de la prcision absolue.
Une pratique courante consiste utiliser la comptabilit des SI pour :
aider les investissements et les dcisions de renouvellements,
identifier les comptabilisations improductives (dont le cot de mesure est suprieur au cot de refacturation) en les remplaant
par des cots fixs pour une Capacit donne,
Cette Capacit peut tre dtermine par les Accords de Niveaux de Service (SLA) et le suivi des cots des Services ainsi
globaliss.

Le processus de facturation
Il s'agit d'un ensemble de processus ncessaires pour refacturer aux clients le cot des services quils utilisent.
La refacturation est souvent effectue sur une base priodique (par exemple, 1/12
me
de la facturation chaque mois).
Des facturations complmentaires peuvent tre ralises sur des services situs en dehors des Accords (par exemple :
dmnagements, dploiement majeur, mise niveau systme imprvue, etc.).
7.2.3 La Gestion de la Disponibilit (Availability Management)
L'objectif de la gestion de la disponibilit est d'optimiser la capacit de linfrastructure informatique, des services et de lorganisation
de support, pour dlivrer la Disponibilit adquate (niveau suffisant et cot optimis) permettant aux activits mtiers de satisfaire
leurs objectifs.
En comparant les besoins et la capacit relle, la Gestion de la Disponibilit permet de :
sassurer que les services des SI sont dfinis pour dlivrer les niveaux de disponibilit requis par les mtiers,
fournir des rapports sur la disponibilit, la fiabilit et la maintenabilit,
optimiser la disponibilit de linfrastructure en termes de cot,
diminuer durablement la frquence et la dure des incidents ayant un impact sur la disponibilit,
sassurer que les petites interruptions de disponibilit soient identifies et radiques,
crer et maintenir un plan prvisionnel pour amliorer globalement la disponibilit afin danticiper les besoins mtiers futurs
sur les aspects de disponibilit.

Primtre
La gestion de la disponibilit devrait sappliquer :
tout nouveau service ou service en cours ayant des besoins dfinis en Disponibilit ou tant lis des activits mtiers critiques
(SLA en place ou non),
tous les fournisseurs (internes et externes) avant la mise en place de SLA formels.
Cependant, ce processus n'est pas responsable du Plan de Continuit Mtiers (Business Continuity Plan) et du rtablissement des
activits mtiers en cas de dsastre majeur (cf. Gestion de la Continuit).

Concepts de base
La Disponibilit fournie par les services informatiques dpend de :
la complexit des SI,
la fiabilit des composants et de lenvironnement des SI,
la capacit du support informatique grer linfrastructure,
du niveau et de la qualit de la maintenance apports par les fournisseurs,
la qualit des procdures et processus oprationnels.

Les niveaux de disponibilit sont gnralement prciss dans les Accords de Niveaux de Service (SLA).

Trois principes fondamentaux sous-tendent la gestion de la disponibilit des services informatiques :
Principe n1 : La disponibilit est au cur de la satisfaction des utilisateurs et des mtiers.
Principe n2 : Reconnatre que mme si les choses se passent mal, il est encore possible dobtenir la satisfaction des utilisateurs.
Pendant une interruption de service, le niveau de satisfaction des utilisateurs ne dpend pas seulement de la
rapidit de redmarrage.

Les organisations mtiers et les utilisateurs ont des besoins diversifis en terme de services informatiques (et pas
uniquement la rapidit de redmarrage du service). C'est pourquoi c'est lensemble de ces besoins qui doivent tre
traits.
Principe n3 : Lamlioration de la disponibilit ne peut dbuter que lorsque lon a compris comment les services des SI
supportent les activits mtiers.
En effet, lanalyse doit porter sur l'ensemble des transactions mtiers et non pas sur chacun des composants
techniques utiliss par ces transactions.

Terminologie
Disponibilit
C'est la capacit pour un service ou un composant SI remplir sa fonction un instant donn ou sur une priode de temps
prdtermine.

Fiabilit
La fiabilit dun service peut tre dfinie comme tant son indpendance vis--vis des dysfonctionnements oprationnels.
Elle est dtermine par :
la fiabilit de chacun des composants utiliss pour dlivrer le service,
le niveau de redondance (ou resilience) de linfrastructure, cest--dire la capacit de linfrastructure masquer le
dysfonctionnement dun composant et continuer dlivrer le service normalement.

Maintenabilit
C'est la capacit dun composant de linfrastructure rester, ou tre restaur, dans un tat oprationnel.
La maintenabilit peut tre divis en 7 tapes spares :
lanticipation des pannes,
la dtection des pannes,
le diagnostic des pannes,
la rsolution des pannes,
le redmarrage aprs panne,
la restauration des donnes et des services,
les niveaux de maintenance prventive permettant dviter lapparition des pannes.

"Serviabilit" (ou serviceability)
Il s'agit d'un concept qui dcrit les accords contractuels signs avec les fournisseurs tiers de la DSI et dfinissant la disponibilit, la
fiabilit et la maintenabilit des composants et services des SI sous leur responsabilit.

Figure 52 : Processus de gestion de la disponibilit

7.2.4 La Gestion de la Continuit des Services des TI (IT Service
Continuity Management)
La Gestion de la Continuit des Services Informatiques a pour objectif de permettre la DSI d'tre capable, lors dune interruption
importante des activits (mtiers et/ou informatiques), de continuer fournir un niveau prdtermin et accept de services pour
soutenir les activits mtiers critiques.
Le but est de permettre aux activits mtiers de ne pas perdre dargent ou, en cas dinterruption trs importante, de permettre
lentreprise de survivre tout simplement.
La Gestion de la Continuit des Services Informatiques concerne lentreprise dans sa globalit et dpasse le cadre de la DSI seule.
Pour l'entreprise, le Plan dUrgence (ou Contingency Planning) ou encore la Gestion de la Continuit Mtiers (ou BCM ou Business
Continuity Management) prvoit tous les scnarios de reprise de chacune des activits.
En mettant en uvre, au niveau des mtiers, le Plan de Continuit Mtiers (Business Continuity Planning), et au niveau des services
informatiques, le Plan de Gestion de la Continuit des Services (IT Service Continuity Management Planning).

Concepts de base
Les activits mtiers sont de plus en plus dpendantes des services fournis par la DSI.
La disponibilit des services (Gestion de la Disponibilit) met en place et gre des technologies permettant de diminuer les risques
(redondance du matriel, politique de sauvegarde/restauration, etc).
La Gestion de la Continuit des Services sappuie sur la Gestion de la Disponibilit des services (ainsi que dautres processus) et
ncessite limplication non seulement de la Direction de lentreprise mais aussi de tous les niveaux hirarchiques.
Des tests rguliers doivent tre effectus afin de vrifier la coordination de lensemble des techniques prvues concernant une
interruption importante.

Bnfices : la gestion des risques
La Gestion de la Continuit doit tre considre comme une assurance couvrant des risques prdtermins.
Cela permet une entreprise didentifier, danalyser et de prendre ses responsabilits face une ventuelle concrtisation de lun de
ces risques.
La DSI peut grer de manire proactive son infrastructure afin de rduire limpact du dysfonctionnement de l'un de ses lments
(depuis un composant l'ensemble d'un site).
La DSI peut aussi, au travers de la Gestion de la Continuit, contribuer la cration de valeurs :
Diminution potentielle des primes dassurance,
Obligations de rgulation,
Relations pousses avec les organisations mtiers,
Marketing positif sur les capacits de reprise en cas de sinistre majeur.

7.2.5 La Gestion de la Capacit (Capacity Management)
La Gestion de la Capacit a la responsabilit dassurer que la Capacit de linfrastructure des SI est en adquation avec les demandes
croissantes des organisations mtiers (cots et performances).
Le processus comprend :
le suivi des performances et des dbits des services et des composants de linfrastructure,
les activits doptimisation (tuning) de lutilisation des ressources existantes,
la comprhension des demandes actuelles en ressources informatiques et la production de prvisions pour les demandes
venir,
linfluence sur les demandes de ressources, en collaboration avec le processus de Gestion Financire des Services,
la production dun Plan de Capacit permettant d'assurer la qualit des Services fournis.

La Gestion de la Capacit est une question d'quilibre
La Capacit achete par une DSI se justifie en termes de besoins mtiers ET doit tre utilise de manire optimale.
La puissance informatique correspond la demande mtier (actuelle et venir). Demande mtier qui peut influencer la demande sur
une ressource informatique particulire.

La Gestion de la Capacit fournit aux organisations informatiques les donnes ncessaires pour leur permettre de dcider :
la nature des composants remplacer (CPU, espace disque, bande passante, ),
le moment idal de leur remplacement (trop tt induit un surcot du la sur capacit, trop tard induit des dfauts de
performance et gnre l'insatisfaction des utilisateurs),
le cot de leur remplacement (donnes prvisionnelles financires destines ltablissement des budgets informatiques).

Le gestionnaire de capacit devra sassurer en permanence :
quil existe toujours de la capacit informatique disponible et justifiable financirement,
que cette capacit soit toujours ajuste aux besoins mtiers prsents et venir,
que la puissance et la performance de linfrastructure informatique actuelle et future sont fournies de manire rentable.
Pour cela, le gestionnaire de capacit analysera :
les besoins mtiers (la fourniture de services demande),
le fonctionnement de la DSI (la fourniture de services actuelle),
linfrastructure informatique (les moyens de fournir les services).

8 REFERENCES BIBLIOGRAPHIQUES

[1] CIGREF
Ouvrage Les rfrentiels de la DSI - octobre 2009

[2] Jeffrey Liker
Le modle Toyota : 14 principes qui feront la russite de votre entreprise

[3] Institut de laudit interne
Audit des projets informatiques

[4] C. Chevallier
Cours sur la conduite de projet

[5] Anne Marie Hugues
Cours sur le Gnie Logiciel

[6] Master ISIL - ESTI
Cours Mthodologies de Dveloppement

[7] Gauthier Picard
Introduction leXtreme Programming

[8] F. Miller
eXtreme Programming, vers plus dagilit

[9] Decostre Alain et Ducochez Clment
Le processus unifi (UP)

[10] Cours du CNAM (F. Di Gallo)
Mthodologie UML

Sites internet :
http://agile.thierrycros.net.
http://dszalkowski.free.fr
http://www.dsi.cnrs.fr/conduite-projet.
http://www.techno-science.net
http://www.jerome.capirossi.org/prj_mgt/cycle_10.htm
http://www.rad.fr/
http://sabricole.ftp-developpez.com/UP.pdf
http://www.guideinformatique.com/fiche-itil_v3-831.htm
http://itilfrance.com/

Wikipedia :
http://fr.wikipedia.org/wiki/Information_Technology_Infrastructure_Library#Bibliographie
http://fr.wikipedia.org/wiki/Extreme_programming
http://fr.wikipedia.org/wiki/Scrum_%28m%C3%A9thode%29
http://fr.wikipedia.org/wiki/Rational_Unified_Process

9 ACRONYMES

BB Black Belt
BSC Balanced Score Card
CAPEX capital expenditure ou dpenses dinvestissement
CMMI Capability Maturity Model Integration
COBIT Control Objectives for Information and related Technology
COCOMO Constructive Cost Model
COPIL Comit de Pilotage
DSI Direction des Systmes dInformation (ou service informatique)
ISO International Organization of Standardization
ITIL Information Technology Infrastructure Library
JAT Juste A Temps (JIT = Just in time)
KPI Key Performance Indicator
MBB Master Black Belt
MOA Maitrise dOuvrage
MOE Maitrise duvre
OBS Organization Breakdown Structure
OPEX operational expenditure ou dpenses de fonctionnement
PBS Product Breakdown Structure
PMI Project Management Institut
PMO Project Management Office
POS Plan dOccupation des Sols
QoS Quality of Service
RAD Rapid Application Development
RBS Resources Breakdown Structure
RUP Rational Unified Process
SI Systme dInformation
SOX Sarbanes-Oxley
SSII Socit de services en ingnierie informatique
SWOT Strengths (force), Weaknesses (faiblesses), Opportunities (opportunits), Threats (menaces).
TJM Taux Journalier Moyen
TPS Toyota Production System
WBS Work Breakdown Structure
XP Extreme Programming

2011 AUBAY. Tous droits rservs

LB Aubay Referentiels Qualite Gestion de Projet 2011

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

LB Aubay Referentiels Qualite Gestion de Projet 2011

Diunggah oleh

Hak Cipta:

Format Tersedia

Rfrentiels Qualit & Gestion de Projet

Panorama et exemples dapplication

Anda mungkin juga menyukai