Représentations systémiques d’une organisation opérationnelle en s’appuyant sur la méthode graphique OSSAD (Full)

Management des Systèmes d'Information Répartis
PROMOTION 2004/2006
THÈSE PROFESSIONNELLE
Représentations systémiques
d’une organisation opérationnelle (service d’étude informatique)
en s’appuyant sur la méthode graphique OSSAD
Jean-Pascal Perrein – décembre 2006

Thèse MSIR 2004-2006 Jean-Pascal Perrein Représentation systémique d’une organisation
10/04/2007 MSIR2004-2006 - Thèse JPP - V3,81.doc Page 2/158
Mots clefs
Organisation, vue, méthode, France-Telecom, CRISTAL, AGATHONE, incidents, proces-
sus, ISO9000 - 2000, procédure, OSSAD, six sigma, pareto, systémique, pensée complexe,
manager, Merise, QQOQCCP, Diagramme de cause à effet

Remerciements
« Je suis en proie à une étrange sensation.
Si ce n'est pas une indigestion, ça doit être de la gratitude ! »
Benjamin Disraeli1
.
Cette étude était riche mais difficile, mais avoir été accompagné jusqu’au bout de mes ré-
flexion est une grande satisfaction et une grande gratitude que j’adresse à celles et ceux qui
ont fait ce bout de chemin avec moi.
Maria, Daniel, Théodore et Archimède merci pour votre présence, vos appuis, votre patience
et votre aide
Aussi j’adresse mes remerciements pour les bons conseils de Guillaume Balan ainsi qu’à
Monsieur Dominique Briolat pour sa rigoureuse patience et inébranlable neutralité dans le
suivi de cette étude. Je remercie de même Florent pour ses critiques très stimulantes.
Enfin je tiens à remercier la société C - LOG International qui m’a offert gracieusement
l’usage de son logiciel OSSAD PROCESS DESIGN ainsi qu’une formation appropriée.
L’ensemble des schémas OSSAD a été réalisé avec ce logiciel.
A toutes et tous
« Un seul mot, usé, mais qui brille comme une vieille pièce de monnaie : merci ! »
Pablo Neruda2
1
Benjamin Disraeli a été le premier ministre de la Reine Victoria du Royaume Uni en 1868 (Né à Londres le 21 décembre
1804, décédé le 19 avril 1881)
2
Neftali Ricardo Reyes Basoalto est un poète Chilien (Né à Paral (Chili) le 12 juillet 1904, décédé le 23 septembre 1973) –
Prix Nobel de littérature en 1971

Résumé
Il peut être judicieux pour un responsable opérationnel de s’enrichir avec une ré-
flexion et une approche qui soit fondé sur des représentations différentes de son or-
ganisation.
Celle que son entité lui demande d’appliquer : L’organisation théorique,
Celle que lui et son équipe vivent : Une des organisations existantes,
Celle qu’il serait nécessaire de mettre en place : L’organisation souhaitée.
Pour représenter et échanger sur ces organisations, il est possible d’utiliser une mé-
thode graphique appelé OSSAD (Office Support Systems Analysis and Design).
Cette méthode est fondée sur un principe de réflexion systémique, c'est-à-dire qui
considère la référence à étudier comme étant un système : un ensemble délimité
d’éléments qui interagissent entre eux.
A travers l’exemple d’un service d’étude informatique travaillant sur une applica-
tion métier de France Telecom, cette thèse aborde une réflexion en deux grandes
parties :
la situation : qui est la délimitation de tous les éléments permettant
d’appréhender au mieux l’étude. Ce sont les ressources de l’étude.
la réalisation : qui est la construction, l’analyse et la comparaison des 3
organisations.
La comparaison finale de trois vue différentes d’une même organisation fait ressor-
tir des incohérences de définition de rôles et des fonctionnements trop exactes qui
occultent un certain nombre d’information susceptibles d’apporter de fortes amélio-
rations.

Introduction
Nous vivons dans un monde d’organisation, personnelle, sociale, industrielle, informatique,
biologique, …. Néanmoins, lorsqu’on parle d’organisation au niveau d’une entité juridique,
nous avons souvent sous les yeux une macro - organisation, au plus simple un organigramme
(linéaire, fonctionnel ou matriciel).
Si l’on souhaite plus de détail, on regarde alors au niveau des processus, qui permettent de
représenter "une série d'activités qui, à partir d'un intrant, y ajoute de la valeur pour pro-
duire un extrant" [Harrington, 1987]. Ainsi nous avons une vue plus précise sur ce que fait
l’entité, ses finalités, ses rôles, ses missions. Afin que ces processus soient connus, opéra-
tionnels et cohérents entre eux, ils sont alors décrits, parfois cartographiés.
Un pas supplémentaire dans le niveau de détail, et nous arrivons à des organisations opéra-
tionnelles, c'est - à - dire qui doivent réaliser les opérations définies au niveau supérieur, et
qui en général s’appuient sur un ensemble de procédures.
Stratégique
Tactique
Opérationnel
B
A
C
E
Organisation
opérationnelle
Figure. 1 - Pyramide de décisions
Sur la figure 1, sont représentés trois éléments constitutifs de l’environnement de décision
d’une entreprise :
sa stratégie : quelle orientation doit - elle prendre ?
sa tactique : comment va - t - elle réaliser sa stratégie ?
son opérationnel : ce avec quoi elle va la réaliser.
C’est à ce dernier niveau, au cœur de l’opérationnel, que se trouve la plus petite forme
d’organisation hiérarchique de l’entreprise (l’élément le plus petit sur un organigramme).
Cette dernière utilise des ressources et a une vie propre qui évolue dans le temps et en fonc-
tion des interactions avec l’extérieur, elle peut être représentée par le schéma suivant
(Figure. 2 - Les interactions d’une organisation générique) où l’on voit apparaître des zones
de responsabilité, des liens d’interactions, des acteurs, des outils (dossier, bases de données,
ordinateurs, . .), …. C’est un système d’action intelligent évoluant par interactions entre cha-
cune de ses parties.

B
A
C
E
Figure. 2 - Les interactions d’une organisation générique
Cet ensemble d’interactions, appelé Système a des objectifs à suivre, et les acteurs qui le
composent nécessitent l’appui d’une personne qui en est responsable. Ce dernier, que nous
appellerons Manager3
a la mission de conduire ce système en prenant en compte un certain
nombre de variables : l’organisation cible (pour réaliser ce qui est nécessaire à l’entreprise),
ce qui existe (ce que chacune voit et vit) et ce qui est souhaité (ce qui convient à tou (te) s).
(Figure. 3 - Le révérenciel d’une organisation générique)
Manager
Organisationnécessaire
Organisation souhaitée
O
rganisation
existante
B
A
C
E
Figure. 3 - Le révérenciel d’une organisation générique
3
Dans le périmètre de notre étude cette personne est aussi appelée Chef de projet Maitrise d’œuvre, à ne pas confondre avec
une autre personne qui est Chef de projet Version, dont nous parlerons aussi par la suite.

« Newell et H. A. Simon (1972, 1986) ont montré que l’on pouvait toujours représenter un
système d’action intelligente par un système de computation symbolique, donc par un arte-
fact (une machine de Turing) » [Le Moigne, 1994].
Il se trouve que dans un cas fondé en partie sur des composants humains, cette représentation
formelle comporterait un très grand nombre de données fortement variables. Effectivement,
l’être humain en tant que tel nécessiterait une gigantesque analyse et un grand nombre de
traitements mathématiques pour pouvoir être représenté sous forme d’équation. Il serait né-
cessaire de recueillir une infinité de variables qui serait démultipliée lorsqu’il s’agirait
d’intégrer la notion de groupe. Même en simplifiant excessivement, une réflexion analytique
de ce type, serait longue et très incertaine.
Une autre manière serait de définir ce Système comme étant complexe « est complexe ce qui
ne peut se résumer en un maître mot, ce qui ne peut se ramener à une loi, ce qui ne peut se
réduire à une idée simple » [Morin, 1990]. Cette approche systémique serait fondée sur les
composants du système et ses interactions. Pour travailler de cette façon, nous avons choisi
d’utiliser une méthodologie de représentation graphique : OSSAD (Office Support Systems
Analysis and Design), construite en s’appuyant sur de nombreuses méthodes comme Merise
et étant très adaptée à des analyses systémiques. Elle a de plus le mérite d’être simple et donc
de permettre une collégialité regroupant des utilisateurs, chef de projet, manager, ….
Cette approche s’appliquera dans l’étude en s’appuyant sur un cas concret : « la mise en
place d’un pilote sur une montée de version d’une application d’un Opérateur de télécom-
munications » le Système étant le service informatique en charge de cette application. Ainsi
grâce à la concrétisation de cette approche nous nous efforcerons de représenter au plus prés
de la réalité, différentes vue d’organisation de ce service.
Au final cette étude permettra de répondre à une question du manager qui serait :
« Comment puis - je comprendre, mon organisation, afin de connaître et de maîtriser le
fonctionnement des ressources qui la composent, et le cas échéant l’améliorer ou l’adapter
afin de mieux répondre au besoin de ma Direction et de sa stratégie ? »
Cette étude aidera à trouver des réponses par une démarche qui, s’imprégnant d’un certain
nombre d’outils, méthodes et concepts, présentera une organisation sous trois vues
d’interprétation : ce qui doit être, ce qui est, ce qui pourrait être.

Organisation du document
Etude
Situation Réalisation
Entités
concernées
Présentation de
l’étude
Bases de
mûrissement
Compréhension de
l’organisation
théorique
Analyse de
l’organisation
existante
Projection des
organisations
souhaitées
Représentation
Organisation
Méthode
Figure. 4 - Organisation du document – Présentation
Ce document est composé de deux parties chacune ayant 3 chapitres. Nous
aborderons, dans la première partie, l’ensemble des éléments permettant de si-
tuer, cadrer et comprendre ce que nous allons traiter dans ce document. La se-
conde partie sera la mise en application des représentations d’organisations et
leurs analyses en se fondant sur un cas concret.

Sommaire
RREESSUUMMEE 44
IINNTTRROODDUUCCTTIIOONN 55
OORRGGAANNIISSAATTIIOONN DDUU DDOOCCUUMMEENNTT 88
SSOOMMMMAAIIRREE 99
TTAABBLLEE DDEESS FFIIGGUURREESS 1122
SSIITTUUAATTIIOONN 1155
1. Entités concernées_________________________________________________________ 16
1.1. Le groupe France Telecom 16
1.1.1. Activités 16
1.1.2. La Stratégie de France Telecom 17
1.1.2.1. Le programme NExT 18
1.1.3. Organisation 19
1.1.3.1. France Telecom 19
1.1.3.2. Le SI Client 21
1.2. L’application CRISTAL 22
1.2.1. Présentation 22
1.2.2. Composition de l’application 23
1.3. La Maîtrise d’œuvre CRISTAL 25
1.4. Les directions Régionales 27
1.5. Synthèse des entités concernées 29
2. Présentation de l’étude _____________________________________________________ 30
2.1. Problématique 30
2.1.1. Problème à résoudre 30
2.1.2. Démarche de résolution envisagée 32
2.2. Cadrage de l’étude 35
2.2.1. Définition unitaire du sujet 35
2.2.2. Les limites 36
2.3. Contexte de l’étude 37
2.3.1. Le cycle de vie d’une montée de version 37
2.3.2. La mise en place d’un pilote (MPP) 38
2.3.3. La gestion des signalisations 40
3. Bases de mûrissement______________________________________________________ 44
3.1. Introduction 44
3.2. Méthodologies, concepts et langage 44
3.2.1. Les processus et leurs représentations 44
3.2.1.1. ISO 9000 V2000 44
3.2.1.2. La définition de processus 46
3.2.1.2.1. Les processus opérationnels ou de réalisation 47
3.2.1.2.2. Les processus de support 47
3.2.1.2.3. Les processus de management 48
3.2.2. La méthode OSSAD 48
3.2.2.1. Présentation 48
3.2.2.2. Le modèle abstrait 49

3.2.2.3. Les modèles descriptifs 49
3.2.2.3.4. Le modèle descriptif de procédures 50
3.2.2.3.5. Le modèle descriptif de rôles 50
3.2.2.3.6. Le modèle descriptif d’opérations 51
3.2.2.4. Le modèle prescriptif 51
3.2.2.5. Le dictionnaire OSSAD 52
3.2.2.6. Les principes OSSADIQUES 52
3.2.2.7. La notion de zoom 53
3.3. Outils employés pour la modélisation 54
3.3.1. OSSAD PROCESS DESIGN 54
3.3.2. QQOQCCP 58
3.4. Synthèse du mûrissement 59
RREEAALLIISSAATTIIOONN 6611
4. L’organisation théorique – (Agathone)________________________________________ 62
4.1. Présentation 62
4.1.1. Le cycle de vie Agathone 62
4.1.2. La mise en place Pilote 64
4.2. Les processus 67
4.3. Les phases 68
4.4. Les rôles 69
4.5. Un exemple : La gestion des signalisations 69
5. L’organisation existante____________________________________________________ 70
5.1. Présentation 70
5.2. Les phases et processus 72
5.3. Les rôles 75
6. Projection de l’organisation souhaitée ________________________________________ 82
6.1. Progression 82
6.2. Les phases et processus 83
6.2.1. Les rôles 86
7. Synthèses ________________________________________________________________ 91
7.1. L’organisation théorique 91
7.2. L’organisation existante 94
7.3. L’organisation souhaitée 96
7.4. Remarques 98
CCOONNCCLLUUSSIIOONN 110000
AAPPPPOORRTT PPEERRSSOONNNNEELL 110022
AANNNNEEXXEE 110033
8. Bibliographie ____________________________________________________________ 104
9. Glossaire _______________________________________________________________ 106
10. Complément : Le dictionnaire OSSAD______________________________________ 108
11. Complément : Méthodes et outils complémentaires ___________________________ 111
11.1. Six Sigma 111

11.2. MERISE 113
11.3. UML114
11.4. Ishikawa. 116
11.5. La Loi de Pareto 118
12. Complément : Recueil des composants de la MPP__________ 120
12.1. Les Pôles autour de Cristal 120
12.2. Le Pôle MPP 121
12.2.1. Les livrables 121
12.2.2. Les outils 121
12.2.3. Les réunions 121
12.2.4. Les rôles 122
12.3. Les Pôles contributeurs directs 123
12.3.1. La qualification 123
12.3.1.1. Les rôles 123
12.3.1.2. Les outils 124
12.3.2. Le référentiel 124
12.3.2.1. Les rôles et activités associées : 124
12.3.2.2. Les livrables 125
12.3.2.3. Les outils 125
12.3.3. Les études 125
12.3.3.1. Les rôles et activités associées : 125
12.3.3.2. Les livrables 126
12.4. Les Pôles contributeurs indirects 126
12.4.1. Les rôles 126
12.4.2. Les livrables 127
13. Complément : Documentation des activités AGATHONE MPP _________________ 128
13.1. Descriptif des processus AGATHONE 128
13.1.1. (A) MO_ORGANISATION, AVANCEMENT ET SUIVI 128
13.1.2. (A) MO_QUALIFICATION MOE SI 131
13.1.3. (A) MO_INSTALLATION 132
13.1.4. (A) MO_FORMATION METIERS 134
13.1.5. (A) MO_COMMUNICATION 135
13.1.6. (A) MO_RELATIONS AVEC LE SITE PILOTE 137
13.1.7. (A) MO_QUALIFICATION UTILISATEURS 138
13.2. Représentation OSSAD des processus AGATHONE MPP 139
13.2.1. Les activités du processus AGATHONE MPP 139
13.2.2. Les phases du processus AGATHONE MPP 146
13.2.3. Les relations avec les autres processus 154

Table des figures
Figure. 1 - Pyramide de décisions 5
Figure. 2 - Les interactions d’une organisation générique 6
Figure. 3 - Le révérenciel d’une organisation générique 6
Figure. 4 - Organisation du document – Présentation 8
Figure. 5 - Organisation du document – Situation 15
Figure. 6 - Positionnement CRISTAL au sein de France Telecom 16
Figure. 7 - Le comité de direction Générale de France Telecom 19
Figure. 8 - Organisation globale de France Telecom 20
Figure. 9 – Les processus métier de France Telecom 22
Figure. 10 – Macro - composants de CRISTAL 24
Figure. 11 - Macro - composants de CRISTAL Infocentre 24
Figure. 12 - Pilotage d’une mise en place d’un pilote 26
Figure. 13 - Carte des Directions Régionales de France Telecom 27
Figure. 14 - Organisation d’une Direction régionale chez France Telecom 28
Figure. 15 - Différences entre différentes organisations 31
Figure. 16 - Différences et relations entre organisations 34
Figure. 17 - Cycle de vie d’un projet de montée de version 38
Figure. 18 - Cycle de vie : Étapes ayant une relation forte avec le pilote 39
Figure. 19 - Signalisations : Les différents évènements et leurs traitements 40
Figure. 20 - Signalisations : Processus d’escalade simplifié 41
Figure. 21 - Signalisations : Différentiation des mémoires 42
Figure. 22 - Cartographie simplifiée des normes autour d’ISO 9000 V2000 (Source AFNOR) 45
Figure. 23 - Présentation d’un processus 46
Figure. 24 - ISO 9000 - Les trois familles de processus 47
Figure. 25 - OSSAD – Méta Modèle abstrait (UML) 49
Figure. 26 - OSSAD – Méta Modèle descriptif de procédures (UML) 50
Figure. 27 - OSSAD – Méta Modèle descriptif de rôles (UML) 50
Figure. 28 - OSSAD – Méta Modèle descriptif d’opérations (UML) 51
Figure. 29 – Macro schéma des modèles OSSAD 53
Figure. 30 - Écran de base d’OSSAD Process Design 55
Figure. 31 - OSSAD Process Design – Modèle abstrait 55
Figure. 32 - OSSAD Process Design – Modèle descriptif de procédures 56
Figure. 33 - OSSAD Process Design – Graphe des rôles 56
Figure. 34 - OSSAD Process Design – Modèle descriptif des opérations 56
Figure. 35 - OSSAD Process Design – Matrice des processus et rôles 57
Figure. 36 - OSSAD Process Design – Graphe des unités organisationnelles 57
Figure. 37 - QQOQCCP – Quelques questions 58
Figure. 38 - Organisation du document – Réalisation 61

Figure. 40 – AGATHONE - Le cycle en Y 63
Figure. 41 - AGATHONE – les processus et phases 63
Figure. 42 - AGATHONE – les relations du processus MPP avec les autres processus 64
Figure. 43 - AGATHONE – Les regroupements du processus MPP 65
Figure. 44 - AGATHONE – Les activités de suivi des signalisations 69
Figure. 46 – Ensembles des composants de la MPP 71
Figure. 47 – (Organisation existante) – Phase préparation 72
Figure. 48 – (Organisation existante) – Phase installation 73
Figure. 49 – (Organisation existante) – Suivi et bilan 74
Figure. 50 – (Organisation existante) – UML des rôles 75
Figure. 51 – Organisation et positionnement de la MOE CRISTAL 76
Figure. 52 – Equipes de la MPP 77
Figure. 53 - Signalisations : Processus d’escalade simplifié 78
Figure. 54 - AGATHONE – Les activités de suivi des signalisations 78
Figure. 55 – Processus existant de gestion des signalisations 79
Figure. 56 – Vie d’une signalisation : visibilité de la MPP 81
Figure. 57 – Différences et relations entre organisations 82
Figure. 58 – Ensembles des composants de la MPP 82
Figure. 59 – (organisation souhaitée) - Phase préparation 83
Figure. 60 – (organisation souhaitée) - Phase initialisation 84
Figure. 61 – (organisation souhaitée) - Phase lancement 84
Figure. 62 – (organisation souhaitée) - Phase réalisation 85
Figure. 63 – (organisation souhaitée) - Phase terminaison 85
Figure. 64 – Les phases projet 86
Figure. 65 – Processus cible gestion des signalisations 88
Figure. 66 - Signalisations : Les différents évènements et leurs traitements 89
Figure. 67 - AGATHONE – Complexité de la méthodologie 91
Figure. 68 - AGATHONE – La notion de cycle de vie d’une information 92
Figure. 69 - Six Sigma - Coubre de satisfaction avant 111
Figure. 70 - Six Sigma - Courbe de satisfaction après 112
Figure. 71 - MERISE – Les modèles de données et de traitements 113
Figure. 72 - UML – Une Classe 115
Figure. 73 - UML – Une association 115
Figure. 74 - UML – Une multiplicité 116
Figure. 75 - UML – Une Agrégation 116
Figure. 76 – Le modèle de diagramme de causes à effet 117
Figure. 77 – Pareto ou le 80/20 118
Figure 78 – AGATHONE, Activité : Organisation, avancement et suivi. 139
Figure 79 – AGATHONE, Activité : Qualification MOE SI 140

Figure 80 – AGATHONE, Activité : Installation 141
Figure 81 – AGATHONE, Activité : Formation métiers 142
Figure 82 – AGATHONE, Activité : Communication 143
Figure 83 – AGATHONE, Activité : Relation avec le site pilote 144
Figure 84 – AGATHONE, Activité : Qualification utilisateurs 145
Figure 85 – AGATHONE, Phase 1 MPP : Mûrissement 146
Figure 86 – AGATHONE, Phase 2 MPP : Recherche du site pilote 147
Figure 87 – AGATHONE, Phase 3 MPP : Préparation du déploiement (1/2) 148
Figure 88 – AGATHONE, Phase 3 MPP : Préparation du déploiement (2/2) 149
Figure 89 – AGATHONE, Phase 4 MPP : Initialisation du site pilote 150
Figure 90 – AGATHONE, Phase 5 MPP : Installation 151
Figure 91 – AGATHONE, Phase 6 MPP : Suivi et Bilan 152
Figure 92 – AGATHONE, Phase 7 MPP : Post Bilan 153
Figure 93 – Abstrait MA - Agathone MPP - Relation avec les autres processus 154
Figure 94 – Abstrait MA - Agathone MPP - synthese MO par Activité 155
Figure 95 – Abstrait MA - Agathone MPP - synthese MO par phase 157
Figure 96 – Abstrait MA - Agathone MPP - synthese MO par Activité 157
Figure 97 – Abstrait MA - Agathone MPP - synthese MO par phase 158

Situation
Etude
Entités
concernées
Présentation de
l’étude
Bases de
mûrissement
Compréhension de
l’organisation
théorique
Analyse de
l’organisation
existante
Projection des
organisations
souhaitées
Représentation
Organisation
Méthode
Figure. 5 - Organisation du document – Situation
La « situation » est la première étape de notre réflexion. Nous considérons que
notre thèse est un système, qui est donc composé d’un ensemble d'éléments qui
interagissent entre eux, et qui échangent des informations. La délimitation de ce
système se fait par l'énumération des composants qui par leurs présences intègre
des créations, modifications ou suppressions de contraintes.
Ainsi, cette première partie sera la délimitation de la thèse. A savoir : donner au
lecteur l’ensemble des briques nécessaire à la bonne compréhension de
l’ensemble de notre démarche : les limites, les composants et les contraintes.

1.ENTITES CONCERNEES
Dans ce chapitre, nous situons l’environnement qui a permis de réaliser la partie ap-
plication de l’étude. Pour cela nous aborderons l’entreprise à travers sa stratégie et
son organigramme, pour au final présenter la Maîtrise d’œuvre CRISTAL et son or-
ganisation du moment. Nous parlerons aussi des Directions Régionales qui sont les
clients finaux de l’application et donc les témoins des Pilotes. L’application CRIS-
TAL4
sera plus détaillée car au centre de notre étude.
Figure. 6 - Positionnement CRISTAL au sein de France Telecom
1.1. Le groupe France Telecom
Le groupe France Telecom, d’envergure mondiale, a été créé en 1988, et est l’un
des principaux opérateurs de télécommunication. Il dispose d’atouts technologiques
déterminants qui lui permettent d’être à la pointe des différents secteurs de la télé-
communication.
1.1.1. Activités
En 2005, avec un effectif de 199 557 salariés, France Télécom a généré un chiffre
d’affaires de 47 157 millions d’Euros.
Ses activités se répartissent autour de quatre secteurs :
Le téléphone fixe5
: Activité historique de France Telecom, le téléphone fixe
concerne 49,25 millions de lignes téléphoniques. Ouvert à la concurrence, le
téléphone fixe est l’une des activités majeures de France Telecom.
4
Application commerciale et technique de gestion des lignes fixes et des offres associées.
5
L’activité de la téléphonie fixe est la raison d’être de l’application CRISTAL.
France Telecom
Division Réseau et
Système d’Information Direction Développement
du Système d'Information Direction Système
d’Information Client Direction Processus
Livraison
CRISTAL
Etudes
Réferenciel
Qualification
Réalisation
Pilote
Direction Régionale
Direction Régionale

Les mobiles : Leader en France et en Angleterre du marché de la téléphonie
mobile avec Orange, France Telecom est aujourd’hui l’un des principaux
opérateurs mobiles dans le monde.
Internet : Fournisseur d’accès à Internet par l’intermédiaire de Wanadoo,
l’ensemble des métiers Internet est représenté dans le Groupe avec des portails
généralistes et spécialisés, du commerce électronique, des annuaires et des
solutions d’hébergement.
Services aux entreprises : A travers sa filiale Equant, France Telecom offre une
gamme de produits et services comprenant l’IP, le Frame Relay, l’ATM, la voix,
l’intégration voix - données, l’hébergement et les applications et services aux
professionnels.
Afin d’avoir une meilleure visibilité de la taille du groupe et donc de la criticité des
applications orientées client final (exemple : CRISTAL), voici un état numérique du
Parc Client de France Télécom au 30 septembre 2005 :
Pour le monde : 130, 7 millions de clients.
Mobile : 70 millions de clients dont 57, 9 millions de clients Orange
Fixe5
: 49, 25 millions de clients
Internet : 11. 41 millions de clients
Pour l’Europe : 120, 18 millions de clients (France incluse)
Mobile : 60, 46 millions de clients dont 51, 33 millions pour Orange
Fixe5
: 48, 36 millions de clients
Internet : 11, 35 millions de clients
Pour la France : 60, 933 millions de clients
Mobile : 21. 67 millions de clients
Fixe5
: 33. 64 millions de clients
Internet : 5. 61 millions de clients
1.1.2. La Stratégie de France Telecom
L’objectif cible de France Telecom est de devenir le fournisseur de services télé-
coms de référence en Europe. Le groupe ayant réussit à rembourser ses dettes de-
puis la fin du premier trimestre 2005, peut désormais arrêter de se limiter dans les
investissements.
Solidement positionné sur ses métiers et porté par des activités à forte croissance
dans les domaines de l'Internet, du haut débit et des mobiles, sa stratégie est orienté
sur une croissance rentable fondée sur l'innovation et l'intégration. Il est à la fois un
fournisseur de services de télécoms et un opérateur de réseaux télécoms.
S'appuyant sur un portefeuille complet d'offres et de solutions, sur sa maîtrise de
tous les réseaux et sa capacité d'innovation intégrée, France Télécom est en train de
développer un nouveau monde de services dans le domaine de la communication,
de l'information et des loisirs, de la vie pratique ainsi que des services aux entrepri-
ses. Ce « nouveau monde » est décrit dans un Programme (NExT) de façon à
communiquer en interne et externe sur les orientations prises.

1.1.2.1. Le programme NExT
NExT (Nouvelle Expérience des Télécoms), est un programme de transformation
qui a été lancé en Juin 2005 et s’étalera jusqu’en 2008. Son objectif est
d’accompagner l’ensemble des entités du Groupe vers l’objectif stratégique de de-
venir opérateur intégré. Ceci afin de faire de France Télécom le fournisseur de ser-
vices de référence en Europe en matière d'innovation, de qualité de services, et de
performance économique.
Cette orientation s’explique de par les habitudes de communication qui évoluent :
avec la généralisation des usages Internet et mobiles, nous sommes passés d'une of-
fre mono forme, assujettie à la durée et la distance, à une offre fondée sur l'abon-
dance. L’ouverture de la boucle locale (ce qui relie l’utilisateur final au moyens
d’extrémité de l’opérateur historique), a favorisé une concurrence qui pour se dé-
marquer a orienté sa stratégie vers de la diversification d’offres6
.
Face à ce foisonnement d’offres sur le marché et à la multiplicité des moyens de
communication, les consommateurs comme les entreprises attendent une simplifica-
tion des usages, avec des terminaux et équipements qui leur facilitent la communi-
cation, faciles à utiliser et qui communiquent entre eux. Ils veulent définir et per-
sonnaliser leurs services, qui deviennent multi - accès, et recréer de façon
instantanée leurs univers de communication.
Cet évolution du marché apporte la notion de convergence des technologies afin, de
dissocier l’offre et les services associés à l’aspect technique des produits. La projec-
tion finale de cette évolution pourrait être l’indépendance des besoins que nous
pourrions avoir dans notre vie de tous les jours avec l’architecture technique néces-
saire à leurs résolutions. Par exemple, avoir un artéfact qui permettrait de téléphoner
de n’importe où (Internet sur WiFi à la maison ou le réseau d’un opérateur à
l’extérieur), pourrait être télécommande de la TV et chaîne HiFi, serait synchronisé
automatiquement avec le carnet d’adresse et l’agenda du bureau et de la maison,
permettrait de régler des transactions à distance (parcmètres, magasins, . .) etc.
L’utilisateur pourrait en changer sans avoir à faire de paramétrage, toutes les don-
nées seraient associées à son empreinte digitale, ….
Cette « révolution » a un impact très fort au niveau des systèmes d’information, car
pour avoir au final un ensemble d’offres et de services, il est nécessaire d’avoir un
système d’information intégré, c'est - à - dire qui soit capable de comprendre qu’une
offre peut toucher, entre autre, à la fois le domaine du fixe, du mobile et de
l’internet. En clair le système d’information doit être réactif et suffisamment mal-
léable pour répondre au besoin du marché qui pousse à l’affranchissement de
contraintes techniques. La présentation hiérarchique qui suit permettra d’avoir une
vue globale de l’organisation de France Telecom et de la situation de l’Étude à tra-
vers l’organigramme.
Un autre aspect très important lié à cette « révolution », est la volonté de France
Telecom de mettre en place une convergence le plus rapidement possible, à com-
6
Un phénomène complémentaire s’aperçoit de plus en plus et qui est de regrouper un grand nombre de ces offres dans des «
packages » .

mencer par la fusion des systèmes d’informations des différentes entités du Groupe.
Cette volonté de fusion, liée à l’évolution du marché et l’importance de la concur-
rence, apporte de très nombreux effets de bord, à commencer par des réductions de
coûts, et des priorités posées sur des projets stratégiques.
Ces remaniement impliquent des baisses de budgets, et poussent à des réorganisa-
tions en bout de chaîne, principalement sur les projets jugés moins importants. C’est
le cas notamment des équipes autour de l’application CRISTAL, dont nous parle-
rons par la suite. Ces remaniements sont une des raisons de l’étude.
1.1.3. Organisation
1.1.3.1. France Telecom
Figure. 7 - Le comité de direction Générale de France Telecom
Il est à noter que le comité de direction intègre le responsable de la Direction Ré-
seaux et Système d’Information. Cela s’explique par le fait que le cœur de métier
est le réseau (opérateur de télécommunication) et bien sûr l’importance du Système
d’Information dans la stratégie de l’entreprise (aspect réactivité au marché).

Figure. 8 - Organisation globale de France Telecom
Au niveau de son organisation structurelle, France Télécom est fondée sur un orga-
nigramme matriciel, il possède :
Quatre divisions métier : Elles sont chargées de l’amélioration de la performance
opérationnelle du Groupe (ce sont les Maîtrises d’œuvre au niveau du système
d’information) :
La division Contrôle de Gestion :
La division Ressources Humaines,
La division Communications et Relations Extérieures,
La division Transformation et développement,
Sept divisions opérationnelles ; elles sont orientées vers la demande du client et
les marchés correspondants (ce sont les Maîtrises d’ouvrage au niveau du système
d’information) :
La division Services Entreprises,
La division Réseaux, Opérateurs et Système d’Information,
La division Développement,
La division Ressources,
La division Grand Public – Services Fixes,
La division Grand Public – Internet,
La division Distribution,
La division qui nous intéresse est Réseaux, Opérateurs et Système d’Information,
elle a la responsabilité :
de définir les politiques de développement et d'assurer le pilotage des réseaux de
France Télécom, toutes technologies confondues,
de piloter le développement et la maintenance de l'ensemble des systèmes
d'information du Groupe et de mieux intégrer, dans le réseau et le SI, tout ce qui
permettra aux lignes de produits de créer des services intégrés,
elle est également en charge de la vente de services aux opérateurs tiers, aspect
important de part l’ouverture à la concurrence, qui oblige France Telecom à
revendre une partie de ses services à la concurrence.

Au sein de cette division se trouve la Direction Développement du Système d'In-
formation (DDSI) qui a en charge le pilotage du développement des systèmes
d’information des différents domaines du Groupe (commercial, facturation, réseau
et services) et des processus métiers du Groupe. Cette direction héberge le Système
d’Information Client (SI Client).
1.1.3.2. Le SI Client
Le service sur lequel se positionne l’étude est le SI Client. Cette direction est très
fonctionnelle, son organisation est majoritairement fondée sur des processus métier
(Études, Livraison, …), elle a plusieurs missions principales :
Conduire le développement de processus métier,
Contribuer à mutualiser les compétences et les solutions SI et obtenir des
synergies entre les entités,
Orienter les équipes SI vers les clients pour pouvoir servir avec réactivité et au
meilleur coût les besoins SI du domaine.
En termes d’employés, le SI Client représente un peu plus de 1000 personnes.
Au sein de la Direction SI Client, on trouve la Direction de projet Livraison7
dont le
projet CRISTAL fait partie. Cette Direction gère l’ensemble du processus Livraison
à travers deux applications : CRISTAL pour le marché des particuliers et AGATHE
pour le marché des professionnels.
Il est à noter qu’en fait CRISTAL gère aussi le processus Commande8
, ceci de par
son évolution historique.
7
Le processus Livraison prend en compte l’ensemble des actions à réaliser afin de répondre à une commande (actions principalement tech-
niques).
8
Le processus métier Commande, englobe l’ensemble des actions permettant de traiter une demande d’un client. Cela signifie de le quali-
fier (possible ou non), de le mémoriser, de le chiffrer, et de demander un règlement.

1.2. L’application CRISTAL
1.2.1. Présentation
CRISTAL signifie Commandes Résidentiels Intégrant un Système de Traitement et
d’Affectation des Lignes (CRISTAL) et a pour objectif premier de simplifier le pi-
lotage du processus de livraison pour l’élaboration des Ordres de Travaux (OT) et la
mise en service technique des Accès Réseaux (AR), par un dialogue plus efficace
entre les applications sollicitées.
CRISTAL est un véritable outil de gestion interfacé avec un ensemble
d’applications de gestion commerciale et technique, qui se base pour la prise de
commande sur le marché Résidentiel. Aujourd’hui c’est une application transverse,
et fédératrice, car utilisée à la fois par les acteurs de la vente pour la prise de com-
mande et par les acteurs de la livraison pour le suivi de la réalisation technique.
C’est aussi un système de référence dans l’application des processus Commande et
Livraison.
Figure. 9 – Les processus métier de France Telecom
Pour information, la Figure. 9 – Les processus métier de France Telecom présente
la cartographie des processus métier de France Telecom. Nous avons entouré le
processus Commande Livraison dans lequel s’insère CRISTAL. On remarque que
ce dernier est à cheval sur les processus Client (Customer) et Livraison (Service De-
livery).

Deux raisons à cela :
Cristal était à l’origine une application de gestion de la livraison. Elle a évolué
en prenant en compte une partie du processus de commande.
Il existait, historiquement, deux processus indépendant : La livraison et la
commande de service. Ces derniers sont restés dans les usages.
Le processus Commande et Livraison associe l’ensemble des étapes de la com-
mande à ceux de la livraison dans une suite continue et cohérente permettant
d’assurer la réponse au besoin exprimé du client.
Pour une commande, cela débute dès la prise en compte du souhait du client et
s’achève après sa réalisation avec l’envoi de la première facture. La date de la
commande est donc le point de départ : c’est la date à laquelle un client manifeste sa
volonté claire et affichée de commander un accès réseau, un produit ou un service.
Cette commande se matérialise par un bon de commande ou son équivalent, quel-
que soit le contexte de la commande : physique, téléphonique ou écrite.
De façon résumée le processus Commande - Livraison suit par l’intermédiaire de
CRISTAL, les trois étapes suivantes :
La commande : la prise de commande est réalisée par les conseillers - vendeurs,
elle se termine à l’enregistrement de la commande.
La réalisation : elle débute avec l’édition des ordres de travaux et se termine par
le compte rendu de l’application qui pilote l’exécution de la réalisation
Le compte rendu de réalisation : il est automatique et permet de solder la
commande par l’émission des fiches de liaison vers l’application de facturation.
Afin de reporter les évolutions de ces processus, l’application doit vivre et s’adapter
au mieux aux modifications nécessaires. Ces besoins du marché, une fois transcrits
en expressions fonctionnelles, sont développés et appliquées par modifications des
composants de l’application. Ces derniers sont parmi les éléments clefs du cycle de
vie de l’application.
Nous nous permettons de préciser que la stratégie du groupe France Telecom impli-
que des demandes d’évolutions majeures qui sont très difficiles à réaliser et pous-
sent indirectement à modifier les organisations de travail.
1.2.2. Composition de l’application
Au niveau technique, CRISTAL s’insère dans un environnement très riche en ter-
mes de produit et de matériel. Afin de rester sur l’essentiel, nous représentons ici les
macros - composants de CRISTAL qui vont nous être directement utiles. Ils peu-
vent être regroupés en 2 familles :
Les composants applicatifs : (Ceux qui peuvent être représentés sous forme de
produits binaires)
CRISTAL Serveur : Comporte l’ensemble des produits livrables s’installant
sur le serveur CRISTAL et constituant le cœur de l’application,

CRISTAL Client : Composé par les produits livrables s’installant sur les
serveurs clients de CRISTAL (redondant par Direction régionale),
CRISTAL Services : Composants permettant de mettre à jour l’interface de
type « MiddleWare » et s’ouvrant vers d’autres applications.
Les composants référentiels : (ceux qui sont représentés par des données, en
générale sous forme de code SQL)
Catalogue : Contient l’ensemble des offre, services, matériels, … composant
l’application CRISTAL,
Règles de traduction : Contient les traductions pour l’interface CRISTAL
Service, permettant de traduire les ordres émis et reçus d’autres applications
CRISTAL,
Tables de références : Contient des données de lien et de fonctionnement au
niveau Catalogue.
Cristal
Cristal Serveur
Cristal Client
Cristal Services
Catalogue
Table
de
référence
Règles
de
traduction
Données
Spécifiques
CRISTAL
Figure. 10 – Macro - composants de CRISTAL
A noter que CRISTAL est aussi composé d’un infocentre qui est la réplique du
CRISTAL de production, aussi bien en termes de données que des composants Ser-
veur de l’application.
Infocentre
Cristal
Cristal Serveur
Catalogue
Table
de
référence
Données
Spécifiques
CRISTAL
Figure. 11 - Macro - composants de CRISTAL Infocentre
L’ensemble de ces éléments sont générés par une équipe d’étude, appelé Maîtrise
d’œuvre CRISTAL, qui prend en compte la gestion des évolutions de l’application,
ceci en terme de correction (maintenance applicative) et d’évolutions (cycle de prise
en compte des demandes d’évolution).

1.3. La Maîtrise d’œuvre CRISTAL9
La maitrise d’œuvre (MOE) CRISTAL fonctionne en mode projet10
elle a en charge
la maintenance applicative de l’application CRISTAL et est composée de 4 pôles :
Études : Réalise la conception et le mûrissement des futures évolutions de
l’application.
Qualification : Pilote et réalise la qualification des composants de CRISTAL,
qualifie les incidents lors du pilote.
MPP : Mise en Place Pilote, prend en charge l’ensemble de la mise en place du
pilote d’une nouvelle version. De la réception des livrables, à la terminaison
validé du pilote.
Référentiel : Gère, à partir de demandes, les mises à jour des référentiels
La réalisation des livrables de CRISTAL est sous traitée à une Tierce Maintenance
Applicative (TMA) pilotée par la Direction de Service (DS) ; elle s’assure de la
bonne réalisation des développements, et est responsable du support niveau 3 en
Activités Récurrentes (hors mode projet). Elle est en renfort sur le pilote.
Ce service gère l’ensemble du cycle de vie de l’application CRISTAL ; ce cycle de
vie est alimenté par des corrections et des évolutions à mettre en œuvre ; c’est alors
un processus de montée de version qui se met en place.
Pour piloter ce processus, intervient un chef de projet version (CPV) qui va suivre
l’ensemble du déroulement du cycle à partir de la réception des choix des évolu-
tions et correctifs (décidé par une maîtrise d’ouvrage), jusqu’à la généralisation.
Ce chef de projet version délègue une partie de son travail lors de la Mise en Place
d’un pilote (MPP), rôle qui est pris en compte par le pôle MPP de la MOE que nous
appellerons pilote de la MPP.
9
La Maîtrise d’œuvre (MOE) CRISTAL sera abordée en détail dans le cadre de cette étude, c’est pourquoi nous ferons une présentation
succincte dans cette partie, ceci afin de transmettre suffisamment d’éléments pour permettre la bonne compréhension de la suite du docu-
ment.
10
On appelle mode projet un fonctionnement suivant un cycle de vie. C'est-à-dire ayant un début et une fin et composé d’étapes planifiées.
Le support n’est pas en mode projet, car il est en activité continu de réaction à un événement.

Pilotage
Besoins
(évolutions/
correctives)
Spécifications
Conception
Codage
Qualification
Intégration
Pilote
Généralisation
MOA
CPV
MPP
Figure. 12 - Pilotage d’une mise en place d’un pilote
Sur le schéma (Figure. 12 - Pilotage d’une mise en place d’un pilote), on voit appa-
raître les étapes d’une montée de version d’une application11
ainsi que les liens de
pilotage du pilote MPP et du chef de projet. Le Pilote de la MPP se concentre prin-
cipalement sur les étapes directement liées à l’installation de la nouvelle version de
l’application (Qualification, Intégration) et à celle de la Généralisation (le Client du
Pilote). Le chef de projet est directement relié à l’ensemble des étapes.
Il est à noter que le chef de projet version ne dépend pas de la MOE CRISTAL, tan-
dis que le Pilote de la MPP l’est (la MOE CRISTAL est pilotée par un manager ap-
pelé chef de projet MOE).
L’objectif de cette répartition est de permettre au chef de projet version d’avoir un
meilleur appui de pilotage au moment critique qu’est la mise en place du pilote. Ef-
fectivement, le Pilote de la MPP faisant partie intégrante de la MOE sa maîtrise de
l’organisation en place le rend donc plus réactif.
La vie de la maîtrise d’œuvre est rythmée par des montées de version qui s’achèvent
par une mise en place pilote suivi d’une généralisation. Il est important de noter que
le pilote s’appuie sur des Directions Régionales afin de valider les étapes qui servi-
ront pour la généralisation. Ces directions, une fois choisies font partie intégrante de
la mise en place pilote et apportent à ce titre des ressources permettant la validation
de la version et de l’organisation.
11
Ce cycle de vie sera détaillé par la suite (2.3.1 Le cycle de vie d’une montée de version)

1.4. Les directions Régionales
Les Directions Régionales sont les premières utilisatrices de l’application CRIS-
TAL.
Figure. 13 - Carte des Directions Régionales de France Telecom
Dans le cadre de notre étude, ce sont aussi les clients directs des Pilotes sur cette
application à ce titre il est utile de présenter leur organisation ainsi que les rôles ma-
jeurs pouvant être rencontrés dans le cadre d’un Pilote. La France est découpée se-
lon le schéma de la figure ci-dessus.
Concernant la téléphonie Fixe, ces Directions Régionales (DR) sont autonomes au
niveau des processus Commande et Livraison, elles possèdent des entités capables
de livrer le service chez le Client.
Chacune de ces directions régionales se compose d’une ou plusieurs Agences, qui
possèdent des services avec des rôles bien définis et chaque agence maîtrise la tota-
lité du cycle de commande/livraison en réunissant une équipe de vente et une
équipe de production.

Les rôles rencontrés en DR sont :
Le vendeur : accueille le client, écoute ses besoins, traduit sa demande en terme
compatible TELECOM, se situe à un accueil physique ou téléphonique,
Le service consommateur 14 et 36 58 : traite les différés de règlements, règle les
litiges sur les contrats en cours,
Le Soutien Applicatifs et Méthodes (SAM) : joue le rôle de soutien auprès d’un
groupe de vendeurs est un relais de formation local,
Le pilote de livraison : surveille le bon déroulement de la réalisation des actions
de livraison, suit les rendez - vous pris avec les clients, débloque certaines
commandes tombées en anomalie, est le garant de la tenue des délais de livraison,
Le rôle d’affectation des ressources réseau : réalise les études permettant
d’affecter des ressources transport et distribution, est sollicité pour donner certains
délais de livraison de la commande, utilise l’application de gestion des données
réseau appelée 42C,
Le rôle de contrôle des ressources commutation : contrôle de la programmation
des commutateurs, les équipes d’intervention lignes réalisent les travaux liés aux
lignes téléphoniques : pose de jarretières, installations terminales,
Les agents des commutateurs : réalisent la pose de jarretières sur le répartiteur,
Le Responsable Qualité des Données : assure différentes tâches de prévention et
de corrections des données, vise à éviter la dégradation des données. Les
personnes suivantes sont concernées :
La cellule d’intervention Locale (CIL),
Les responsables qualité des données (RQD),
Les administrateurs des tables locales et régionales.
Direction
Régionale
Contrôle de Gestion
Transformation et
développement
Ressources Humaines
Communication et
Relations Extrérieures
Agences
Distribution
Agences
Unité Intervention
Client
Unité Régionale
de Réseaux
Agences
Entreprises
Agences Vente
Indirecte et
Publiservices
Direction developpement
managériale et emploi
cadre
Secrétariat
Figure. 14 - Organisation d’une Direction régionale chez France Telecom
On peut remarquer l’orientation de la Direction régionale vers la vente (Agences,
processus Commande) ), possède ses entités de support (Unité, processus Livraison)
et un certain nombre d’entités de soutien (Ressources Humaines, secrétariat,
Contrôle de gestion, …).

1.5. Synthèse des entités concernées
France Telecom passe à travers une révolution culturelle où les clients recherchent
des services riches et multiples, tout en étant extrêmement accessibles. Ce couple
extrême entre la nécessité de complexité et la simplicité d’apparence a poussé cette
entreprise à orienter sa stratégie vers de la convergence de technologie, et son mar-
keting vers du regroupement de services.
Cette (r)évolution très rapide a un impact fort au niveau des systèmes d’information
impliquant des évolutions plus rapides et des équipes plus réactives afin de permet-
tre aux briques du système d’information d’évoluer de façon optimale. Pour piloter
ces mouvements, des équipes prennent en charge l’ensemble des étapes qui permet-
tent de répondre à ces évolutions, ceci en se calquant sur un cycle qui se termine par
la mise en place d’un pilote puis d’une généralisation. Ces deux dernières étapes
nécessitent de faire appel aux utilisateurs finaux de l’application dont il est ques-
tion ; ce sont les Directions Régionale qui, afin de valider le processus « pilote »
vont devenir pendant un certain temps, des acteurs à part entière du projet
d’évolution.
L’ensemble de ce chapitre à présenté les entités qui seront la base sur laquelle se ré-
alisera l’étude. Ces bases permettront de mieux situer le contexte et la raison de
l’étude.
Le chapitre suivant présentera le pourquoi ainsi que l’ensemble du cadrage de
l’étude.

2.PRESENTATION DE L’ETUDE
L’objectif est de poser l’ensemble des briques d’information, qui permettront de
comprendre la démarche et la réflexion décrite par la suite. C’est le Pourquoi de
l’étude.
Il est nécessaire de comprendre le sens donné ici au mot Organisation. On appelle
organisation, « un ensemble d'individus regroupés au sein d'une structure régulée,
qui ont comme but de répondre/d'atteindre à un/des besoin (s) /objectif (s) détermi-
né (s) » [Wikipédia]. Pour adapter cette définition, à cette étude, parlant de la struc-
ture régulée, nous préciserons : « la plus petite structure régulée reconnue dans les
organigrammes de la dite entreprise » . Concrètement l’organisation dont il est
question dans l’étude est la Maîtrise d’Œuvre de CRISTAL.
2.1. Problématique
2.1.1. Problème à résoudre
Karl Marx (1818 - 1883) : économiste et philosophe allemand a dit : "L'humanité ne
se pose que les problèmes qu'elle peut résoudre"
La première partie de notre « problème à résoudre » se trouve donc dans la défini-
tion du mot « problème » . Un problème n’existe que lorsque l’on constate un «
dysfonctionnement » . Or il se trouve qu’il y a « dysfonctionnement » lorsque «
l’existant à un moment donné » n’est pas ce qu’il « doit être » . Ce « dysfonction-
nement » est communément appelé un problème.
Que se passe t’il s’il y a perte du « ce qu’il doit être » ? En toute logique il n’y a
plus de problème possible, c’est soit la situation idéale, soit une perte totale de
contrôle de l’objectif de l’organisation, soit une satisfaction naïve sur un environ-
nent qui existe sans réels objectifs que ceux du moment.
Ce raisonnement très simple résume la base de réflexion de cette étude.
Ne pas forcément partir d’un problème pour lancer une action visant à amélio-
rer une organisation.
Dans le schéma qui suit, dans lequel nous entrerons plus en détail par la suite, nous
présentons quatre niveaux concernant une Organisation :
Existante : celle qui existe à un moment donné,
Ressentie : chaque membre ayant son point de vue, plus on entre dans le détail,
plus son point de vue devient différent des autres membres. Il est donc multiple,
Souhaitée : la cible du manager, celle qu’il estime être la meilleure dans son
contexte,
Nécessaire ou théorique : ce qui devrait être afin de suivre aux normes définies
par l’entreprise.

Il va de soi que sans impulsion orientant un service vers une organisation théorique
(donc avec un effort), la tendance de chacun et donc du groupe sera d’aller vers sa
propre organisation, qui dépend d’intérêts « non normalisés » (intérêts pouvant être
différents de ceux de l’entreprise) ; nous appelons cela la tendance naturelle.
Effortvolontaire
Tendanceinvolontaire
Figure. 15 - Différences entre différentes organisations
Une seconde partie de notre « problème à résoudre » se trouve être dans la cible de
ce que l’on veut faire. Considérant que les organisations d’un service donné peuvent
être multiples en fonction du poste d’observation que l’on a, un ingénieur qualité
verra l’organisation théorique, un manager verra l’organisation souhaitée, les mem-
bres de l’équipe verront l’organisation ressentie et tout ce monde évoluera dans une
organisation existante. Ce n’est pas un problème, que d’avoir ces différences, cela
peut l’être de ne pas les maîtriser ou de ne pas en être conscient.
Là se trouve notre seconde raison de cette étude.
Être conscient et capable de connaître une organisation réelle existante afin de
pouvoir la comparer à d’autres (théorique, souhaitée, . .)
La dernière partie de notre « problème à résoudre » concerne le positionnement de
notre réflexion. La société d’aujourd’hui est très orientée qualité de service au client
final. Nous sommes passés successivement d’une ère où la demande était plus forte
que l’offre, impliquant une production de masse, à une ère où la demande rejoint
l’offre avec une socialisation de l’entreprise, impliquant une optimisation des pro-
cessus de production, pour arriver aujourd’hui à une ère où l’offre est plus forte que
la demande et le client plus capricieux, impliquant une réorientation de l’entreprise
vers le client final.
Au cours du temps il se trouve que les orientations stratégiques liées aux évolutions
du marché, provoquent des réajustements nécessaires dans l’organisation des entre-

prises. Ces réajustements se font souvent sur des orientations stratégiques qui met-
tent en place une tactique impactant l’ensemble des opérationnels de l’entreprise.
Qu’en est-il justement de cet opérationnel ? Comment va - t - il appliquer cette tac-
tique, comment pourra se faire son adaptation à ces grands mouvements qui sont
souvent compris qu’à moitié (lorsqu’il en est conscient) ?
La réponse se trouve dans le rôle des managers ; ils sont parmi les plus petits élé-
ments exécutifs de l’entreprise, ils ont la responsabilité de s’adapter et de faire
adapter leurs équipes aux mouvements stratégiques initiaux. Ils pourront difficile-
ment le faire s’ils ne maîtrisent pas leur propre organisation.
Là se trouve la dernière raison de cette étude :
Aider le manager à maîtriser son organisation.
2.1.2. Démarche de résolution envisagée
Ainsi nous sommes face à une organisation avec comme objectif premier de cher-
cher à la connaître afin de mieux la maîtriser.
A cet objectif, nous rajouterons :
Être capable de représenter visuellement une organisation de façon à pouvoir
communiquer et travailler collégialement avec la même vue. Et être capable de
comprendre la raison d’avoir une organisation cible.
Considérant l’organisation comme étant composée d’individus, il est important de
prendre en compte la notion de complexité du système étudié. Vouloir mettre en
équation un système complexe serait illusoire. « la pensée complexe aspire à la
connaissance multidimensionnelle. Mais elle sait au départ que la connaissance
complète est impossible : un des axiomes de la complexité est l'impossibilité, même
en théorie, d'une omniscience. » [Morin, 1990].
Effectivement une étude analytique s’applique à des éléments simples, éventuelle-
ment compliqués mais non complexes, des éléments qui peuvent être fragmentés en
unités élémentaires. Une organisation est un système vivant, composé de relations
récurrentes et aléatoires. Elle nécessite d’être vue à travers une analyse systémique
qui se fonde sur des interactions, liens et complexités et qui définit des éléments par
leurs rôles et activités plutôt que par leurs effets formels.
Cette approche systémique permettra d’aborder l’organisation comme étant un sys-
tème complexe, J. - L. Le Moigne définit un système comme "quelque chose d'iden-
tifiable, dans un environnement, muni d'une finalité (projet), qui fonctionne (activi-
té), au moyen d'une forme stable (structure), et qui se transforme dans le temps
(évolution) " [Le Moigne, 1984]. A cela nous pouvons rajouter la vue de L Von
Bertalanffy, « le point d'entrée de l'exploration systémique est le... système, c'est - à
- dire ses composants, ses flux » [VON BERTALANFFY, 1973].

Ainsi nos objectifs évoluent vers :
Nous souhaitons être capables de présenter l’organisation réelle existante par
des représentations visuelles en utilisant une approche systémique.
Notre stratégie étant posée, il apparaît nécessaire de définir la tactique.
L’organisation sur laquelle nous allons nous appuyer est un service de maîtrise
d’œuvre informatique qui a en compte les évolutions d’une application qui est cen-
trale au Processus métier Commande/Livraison. Nous sommes donc en face d’un
service où l’ensemble du travail est fondé sur un fonctionnement Projet.
Le mode projet que suit ce service est fondé sur une méthodologie propriétaire qui
s’appelle AGATHONE ; cette méthodologie est très orientée processus et prend en
compte l’ensemble des étapes du cycle de vie d’une application (entre autres).
Nous sommes donc dans un environnement projet fondé sur des processus, dont le
travail est principalement bureautique, et s’appuyant sur une méthodologie projet
d’entreprise. Cet environnement sera pour nous l’organisation théorique (théorique)
12
.
La représentation de l’organisation de ce service d’études ne serait pas complète si
elle était dissociée de l’environnement projet dans lequel elle doit évoluer. Cette
contrainte nous aidera à justifier de la nécessité d’adapter notre réflexion afin de re-
présenter l’existant par rapport à la cible.
Un aspect important dans la représentation d’un existant est qu’elle est fondée sur
des retours d’entretiens de personnes appartenant ou non à l’organisation cible. Et
que chacune de ces personnes n’a pas la même vision de l’organisation, de par ses
rôles, ses activités, ses compétences, son vécu et ses expériences.
Ces organisations ressenties constituent l’organisation réelle existante.
L’importance de différencier les deux organisations est de bien faire comprendre
que l’organisation existante est dépendante des personnes qui la composent, ainsi un
mouvement de personne implique une modification de l’organisation existante.
L’ensemble des attributs qualifiant une personne et ses rôles doit donc faire partie
intégrante de notre réflexion.
La cible finale du manager étant bien sûr d’orienter son service vers les recomman-
dations de l’entreprise, tout en tenant compte des particularités de son environne-
ment propre et de ses équipes. Le schéma ci - dessous résume cet aspect. Il repré-
sente les différentes organisations avec une vue par niveau.
12
Cette organisation sera celle décrite par la méthodologie du groupe France Telecom : AGATHONE

Organisation représentable
Organisation
réelle existante
Organisations
ressenties
Organisation
Souhaitée
Organisation
théorique
Différence a
Différence b
Différence c
Figure. 16 - Différences et relations entre organisations
Ainsi, comme le présente Edgar Morin, « La pensée de la complexité se présente
(…) comme un édifice à plusieurs étages » [Morin, 1990], il sera nécessaire de rai-
sonner par “étages” mais aussi en ayant la possibilité d’enrichir ces étages des dé-
tails qui nous seront nécessaires.
Nous devrons donc progresser dans le raisonnement :
en tenant compte de l’aspect systémique de l’environnement ;
en se rapprochant le plus possible d’un raisonnement processus ;
en faisant des regroupements de détails par « étages » .
Cette partie a permis de traiter de la cible de notre étude, en justifiant de la nécessité
de prendre en compte une organisation sous différents angles et surtout d’avoir une
approche systémique. Cette cible nécessite un enrichissement quant à son orienta-
tion et au niveau du périmètre de réalisation. Ce cadrage sera effectué au cours de la
partie suivante.

2.2. Cadrage de l’étude
2.2.1. Définition unitaire du sujet
Afin de délimiter le sujet, il est nécessaire de définir unitairement les composants
qui constituent le sujet, et ceci dans le cadre de notre étude.
Service d’étude informatique : Un service informatique est une organisation
prenant en compte l’ensemble des tâches nécessaires afin de livrer un ou plusieurs
composants logiciel modifiant, créant ou remplaçant un logiciel existant. Ce
service informatique inclus généralement un bureau d’étude, des équipes de
développement, de tests et recette, de qualification, …
Montée de version : Dans un système d’information informatique, il arrive qu’il
soit nécessaire de faire évoluer une application en production. L’opération de
montée de version consiste à prendre en compte l’ensemble des actions faisant
passer l’application d’origine vers un nouvel état portant les modifications et/ou
nouveautés.
Mise en place d’un Pilote : Lorsque l’on doit toucher à un élément du système
d’information, il est important de valider que cet élément nouveau ou modifié
répond bien à ce qui était souhaité et soit le moins possible impactant au niveau
des utilisateurs finaux. Pour cela on met en place un Pilote. Le Pilote est un
ensemble d’utilisateurs qui vont tester les fonctionnalités ayant été impactées de
près ou de loin par le nouvel élément ou la modification d’un élément applicatif
existant.
Organisation : « Une organisation est un ensemble d'individus, regroupés au
sein d'une structure régulée, dans le but de répondre/d'atteindre à un/des besoin (s)
/objectif (s) déterminé (s) » [Wikipédia]
Flux : « Le flux est un ensemble d'éléments (données, énergie, matière, ...)
évoluant dans un sens commun » [Wikipédia]
Processus : Ensemble cohérent d’activités, d’opérations, d’interactions
humaines qui traite des informations entrantes et en restitue de nouvelles.
Représentation : « Action de présenter à nouveau » (Larousse), que l’on peut
compléter par « par l’usage de composants visuels » .
En s’appuyant sur les définitions précitées, l’objet du sujet est donc de :
Reproduire de façon interprétable, des séquences de phénomènes dynamiques
ayant au moins une entrée et au moins une sortie, ainsi que des mouvements
d’ensembles d’éléments évoluant dans des sens communs pour un ensemble
d’individus regroupés dans une structure régulée et ayant des objectifs
déterminés. Ceci se faisant pour un service d’étude qui met en place un pilote
pour une montée de version.

Reformulé notre sujet sera :
Reproduire visuellement, de façon la plus simple possible, comment les
membres d’une organisation d’étude informatique fonctionnent lorsqu’une
mise en place pilote se fait pour une nouvelle version d’une application.
Le périmètre ainsi défini, la présentation des limites ci-après permettront à la réali-
sation de cette reproduction visuelle de se faire de façon contrôlée.
2.2.2. Les limites
A partir du moment où il est question de comportement et fonctionnement humain,
apparaît une très forte richesse difficilement formalisable. Ce mémoire va traiter de
façon mixte l’aspect “industriel” et l’aspect “humain”. Le premier dans la création
et la formalisation de ce qui doit être, la seconde dans la reproduction de ce qui est.
Les comportements humains ont des logiques qui ne sont pas universelles et donc
non reproductibles sous forme de modèles car ils sont complexes.
Ce mémoire ne se positionnera pas sur :
la gestion des compétences, mais pourra être une bonne base pour lancer un
projet de ce type.
un audit organisationnel ; même si cela peut y ressembler voire être utilisé à
cette fin, l’objectif est de sensibiliser sur une démarche.
une représentation générique d’un service d’études. Même si la majorité des
éléments sont présents et pourraient être reproduits dans d’autres organisations,
l’idée est de livrer une représentation d’un service d’étude spécifique en utilisant
une démarche particulière.
l’analyse de la méthode OSSAD : Cette méthode étant un des outils de cet étude.
La granulosité des représentations s’arrêtera à ce qu’il peut être nécessaire de dé-
crire pour comprendre. Les événements unitaires et aléatoires seront volontairement
omis et considérés comme bruit. Cela ne veut pas dire qu’ils sont inutiles au jour le
jour, mais seulement qu’ils sont trop détaillés pour être élucidés dans le cadre de ce
document. Ces représentations couvriront un périmètre déterminé que nous défini-
rons dans la partie suivante.

2.3. Contexte de l’étude
L’étude se déroule au sein de la maîtrise d’œuvre CRISTAL. Cette organisation est
calquée sur un cycle de vie de montée de version d’application métier. Ce cycle de
vie se termine par la fin de la phase Mise en Place Pilote qui est la base même de
l’étude.
2.3.1. Le cycle de vie d’une montée de version
Dans le cadre du cycle de vie d’une application, apparaît une récurrence
d’opérations appelée « montée de version » . Cette opération suscitée par des be-
soins comporte un ensemble d’activités que nous regrouperons en trois phases prin-
cipales :
Étude : Cette phase comprend toute la partie qui consiste à partir d’un besoin de
livrer des spécifications suffisamment explicites pour que la réalisation puisse se
faire (expression des besoins, proposition de solution, spécifications
fonctionnelles et techniques, …),
Réalisation : La réalisation comprend l’écriture ainsi que la compilation du code
permettant de mettre en œuvre les modifications/évolutions spécifiées par les
livrables de la phase d’étude, une fois ce codage réalisé,
Qualification : Elle permet de réaliser les tâches de tests et validation des
éléments livrés (tests unitaires, de non régressions, …), et de qualifier les
incidents rencontrés au cours de la mise en place d’un pilote (MPP),
Déploiement : La phase de déploiement prend en compte l’intégration des
éléments livrés par la Réalisation afin de pouvoir être intégrés en production. La
mise en place d’un pilote permet de valider à grande échelle les modifications
apportés et la généralisation de l’étendre à l’ensemble du Système d’information.
Au cours de la mise en place d’une nouvelle version, apparaîtront deux nouvelles
phases que nous détaillerons par la suite : la chaîne de soutien et la production.

Phase Déploiement
Phase RéalisationPhase d’étude
Besoins
(évolutions/
corrections)
Spécifications
Conception
Codage
Qualification
Intégration
Pilote
Généralisation
Cycle réccurent
Figure. 17 - Cycle de vie d’un projet de montée de version
La mise en place d’un pilote est en fait l’aboutissement final du cycle de vie d’un
projet de montée de version d’une application. La généralisation étant une reproduc-
tion industrielle de ce qui a été fait en Pilote, qui lui est la dernière étape pour ajus-
ter ce qui sera mis en production. Notre étude s’appuie sur cette étape Pilote que
nous appelons « Mise en Place du Pilote » .
2.3.2. La mise en place d’un pilote (MPP)
La Mise en Place du Pilote est le point le plus interactif vis - à - vis de toutes les au-
tres étapes du cycle de vie, les doubles flèches en pointillés (Figure. 18 - Cycle de
vie : Étapes ayant une relation forte avec le pilote) représentent les interactions for-
tes existantes avec les autres étapes.
On voit aussi apparaître la notion de support et d’exploitation. Effectivement, la
chaîne de soutien est activée afin de suivre les incidents qu’apporte le projet Pilote,
et l’exploitation est mise à contribution afin de prendre en compte l’installation des
produits livrés.

Phase Déploiement
Phase RéalisationPhase d’étude
Besoins
(évolutions/
correctives)
Spécifications
Conception
Codage
Qualification
Intégration
Pilote
Généralisation
Cycle réccurent
Chaîne de soutien .
Prise d’appel
(Niveau 1)
Résolution
(Niveau 2)
Correctifs
(Niveau 3)
Utilisateurs
Production
Exploitation
Figure. 18 - Cycle de vie : Étapes ayant une relation forte avec le pilote
Dans notre périmètre, la chaîne de soutien, est décomposée en trois niveaux de ges-
tion des événements :
Niveau 1 : prise d’appel et résolution des problèmes simples et connus et
accompagnement de l’utilisateur sur un usage du logiciel,
Niveau 2 : prise en compte des appels n’ayant pu être résolus au niveau 1,
résolution des incidents connus, qualification détaillé du problème afin de le
réacheminer vers d’autre support,
Niveau 3 : prise en compte de problèmes ne pouvant être résolus par des actions
simples : Incidents nécessitants une retouche du code, ou des manipulations
sensibles des données de l’application. Ce niveau est le même qui code les
évolutions dans notre cas d’étude.
Il est à noter que les relations du Pilote avec tous les acteurs du service (qualifica-
tion, chaîne de soutien, conception, intégration, généralisation, exploitation, . .) ne
sont actives que lorsque la phase pilote est activée ; ce ne sont pas des relations per-
sistantes.
Ainsi ce schéma présente le contexte de l’étude qui prendra en compte
l’organisation de l’étape Pilote incluant ses acteurs directs au cours de la mise en
place d’une nouvelle version.

2.3.3. La gestion des signalisations
Dans le cadre de la MPP existe un processus, qui est récurrent sur toute la durée de
test de la nouvelle version, c’est la gestion des signalisations13
. Ce processus sera
utilisé comme exemple afin de décrire et comparer les différentes organisations,
leurs niveaux de détails et leurs cohérences.
Dans le cadre de ce mémoire, il y a 3 grands éléments importants à connaître
concernant la gestion des signalisations :
Evénement
Incident
Information
Evolution
Bruit
Patch
Correctif
Traité
Supprimé
Redirigé
Information
Tâche
Redirigé
Traité
Service continu
Figure. 19 - Signalisations : Les différents évènements et leurs traitements
Les évènements : Lors d’un projet, un certain nombre d’éléments non prévisibles
vont venir impacter le projet ; on appelle en général ces éléments des évènements.
Dans le cadre de notre étude certains seront appelés « signalisations » . Ces évène-
ments peuvent être des incidents, des erreurs, des informations, du bruit, des de-
mandes, …. Ils sont multiples, ont chacun des caractéristiques particulières et né-
cessitent des prises en compte et des traitements tout aussi particuliers. Dans le
schéma (Figure. 19 - Signalisations : Les différents évènements et leurs traite-
ments), un exemple est donné pour un processus de traitement d’évènements, afin
de présenter les différents évènements ainsi que les résultants du traitement de ces
derniers :
Incident : c’est une anomalie qui a été remontée par un acteur (il peut y avoir
différents acteurs et pour lesquels il faudra gérer les incidents de façon
différente),
Information : une demande de renseignement, un complément d’information
qui nécessite d’être relevé et noté car pouvant impacter le projet, ou se
transformer en incident,
Évolution : un incident ou une information peuvent se transformer après
qualification ou analyse en une demande d’évolution. Officiellement la
13
Une signalisation est, pour le Groupe France Telecom, quelque chose qui a fait l’objet d’une déclaration puis d’un enre-
gistrement. Un incident est par exemple une signalisation.

demande d’évolution doit suivre un circuit externe à la MPP, mais il est
possible que cela passe dans une corrective14
,
Bruit : un évènement sans intérêt.
L’ensemble de ces évènements sont traités et se transforment en :
Correctif : Une modification du programme qui corrige une erreur ou qui
améliore un fonctionnement. Cette modification passe à travers un processus
qualité,
Patch15
: une opération qui modifie le fonctionnement du programme de
façon temporaire (des fois du temporaire durable),
Information : Une information à l’origine peut rester une information. Un
incident peut se transformer en information s’il est exceptionnel ou sans impact
ou aléatoire. Une information étant un élément qu’il est nécessaire de connaître,
Tâche : Un incident ou une information peuvent se transformer en action qui
nécessite par exemple une communication.
Pour finir, ces évènements peuvent être supprimés, une trace est gardée, sinon trai-
tés ou redirigés, dans ce cas ils sortent du suivi et sont transmis à d’autres acteurs.
Figure. 20 - Signalisations : Processus d’escalade simplifié
Le processus d’escalade : Un évènement connu va poursuivre un cheminement
particulier qui lui permettra d’être correctement traité dans un délai maitrisé. Cela
signifie qu’un certain nombre d’acteurs, de compétences et d’expertises différentes
sont disponibles pour ce traitement. Certains de ces acteurs ne peuvent pas être acti-
vés à chaque évènement, c’est pourquoi il est nécessaire de filtrer l’évènement au
fur et à mesure de sa non - possibilité de prise en compte (trop complexe).
L’événement poursuit différents étages de prise en compte où plus il avance et plus
les équipes en place auront d’expertise pour le traiter. C’est le processus d’escalade.
14
Une ‘corrective’ est la désignation logicielle de la correction d’une ou plusieurs anomalies. On dit « passer une correc-
tive » afin d’exprimer l’action d’installer dans l’environnement de production un ou plusieurs composants logiciels qui ré-
soudront les anomalies qu’ils doivent corriger.
15
Le patch n’existe théoriquement pas car non acceptable à un niveau qualité (il est ce qui n’a pas été fait en amont, donc
suite à une lacune)

Projet (phase MPP) Service continu
Occurrences événements
Emetteur
d’un
Evénement
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Niveau 1
Niveau 2
Emetteur
d’un
Evénement
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Niveau 1
Niveau 2
Emetteur
d’un
Evénement
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Niveau 1
Niveau 2
Emetteur
d’un
Evénement
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Redirection
Mémorisatio
n
Résolution
Niveau 1
Niveau 2
Mémoire des évènements
Mémoire des
évènements
Figure. 21 - Signalisations : Différentiation des mémoires
La différenciation des mémoires : Une des clefs de la maitrise d’un projet est
d’être capable de mémoriser l’ensemble des mouvements du projet, en particulier
les évènements. Cette mémorisation se fait par l’intermédiaire de plusieurs bases, en
fonction du dit évènement. Incidents, demande récurrente, compte rendu, ordre de
travail, information, …. Lorsqu’on travaille en mode projet, une règle est d’être
complètement autonome et non perturbant pour le service continu16
; cela signifie
que les évènements du projet ne doivent pas interférer avec ceux du service continu
et vice versa. Un évènement sera donc qualifié à sa détection pour savoir s’il sera
pris en compte par le projet ou par le service continu. Il sera fait de même au cours
de son escalade, et à la fin de sa vie (cet évènement il devra être rebasculé pour trai-
tement par le service continu à la fin du projet ?). Afin de tracer les évènements,
France Telecom utilise deux outils :
Genesis : Est un outil de gestion et suivi des appels. Chaque appel fait l’objet
d’un enregistrement appelé « signalisation »,
OGA : Cet outil permet de mémoriser et suivre les enrichissements d’une
anomalie. OGA est utilisé en fin de chaîne, lorsque l’anomalie a été identifiée et
qu’il est possible de la corriger par un développement. Par abus de langage
nous appelons un incident mémorisé sous OGA : « une OGA » .
Pour France Telecom, un incident déclaré est une signalisation, qui après qualifica-
tion estimant la nécessité de le corriger, devient une OGA. Nous utiliserons de fa-
çon plus large, et ce volontairement, le terme d’évènement. Ceci afin de ne pas se
fermer à des possibilités d’interprétation des organisations que nous observerons.
Il est à noter que le service continu est appelé « Actions récurrentes » chez France
Telecom. Nous pourrons donc citer le service continu pour des explications généri-
ques et Actions Récurrentes lorsque nous parlons spécifiquement de France Tele-
com.
16
Est appelé Service continu (ou activités récurrentes) l’ensemble des actions nécessaire au fonctionnement d’un système
donné sur une période non déterminée.

Un aspect que nous aborderons dans les exemples que nous prendrons sera
l’évolution de l’événement vers une signalisation puis vers une OGA. Une OGA est
un enregistrement d’un incident qui pourrait être corrigé par modification du code
de l’application. Lors de l’application des correctives de la MPP, cela concerne la
mise en place de correction attaché à des OGAs. Les circuits de traitement des si-
gnalisations et des OGA sont très différents. Les signalisations sont traitées aux ni-
veaux 1 et 2 (prise d’appel et résolution sur incidents connus) et l’OGA l’est au ni-
veau 3 (nécessite une modification du code).
La gestion des signalisations sera l’exemple utilisée pour étayer et enrichir notre
étude.

3.BASES DE MURISSEMENT
3.1. Introduction
des éléments, bases pour mûrir la démarche, seront détaillés ici afin de présenter le
raisonnement appliqué pour construire l’objectif cible : comprendre et représenter
une organisation.
A l’origine, mon souhait était d’utiliser un certain nombre de méthodes et concepts
existants (principalement MKSM, UML et la notion de processus ISO 9000 V2000)
sur lesquels je pourrais m’appuyer pour modéliser les différentes organisations (ré-
elle, existante et cible). Durant la phase de mûrissement du sujet de cette étude, j’ai
découvert OSSAD qui s’est avéré être une méthode graphique très adapté à la re-
présentation de processus orienté organisation.
Cette étude utilise donc majoritairement OSSAD. Néanmoins, il a été nécessaire de
m’appuyer sur d’autres méthodes, outils et concepts, ceci afin d’avoir un système
d’étude complet pour retranscrire l’ensemble de la réalisation, et surtout mûrir ma
perception de l’environnement dans lequel j’allais évoluer.
Il m’a semblé nécessaire d’insérer en annexe des présentations résumées ainsi qu’un
avis sur les autres éléments qui ont influencé mon mûrissement. Le lecteur pourra
s’y reporter le cas échéant.
3.2. Méthodologies, concepts et langage
3.2.1. Les processus et leurs représentations
3.2.1.1. ISO 9000 V2000
L’Organisation International de Normalisation (ISO) est un organisme de normali-
sation mondial qui a comme objectif premier d’élaborer des normes techniques. Mis
en place en 1947 par 25 pays, cet organisme est aujourd’hui représenté à travers 156
pays par des instituts donc le secrétariat général, fondé à Genève, assure la coordi-
nation.
« L'ISO 9000 traite du "management de la qualité", ce terme recouvrant tout ce que
l'organisme réalise pour améliorer la satisfaction des clients en répondant à leurs
exigences et aux exigences réglementaires applicables et en améliorant à cet égard
continuellement ses performances. » [AFNOR, 2000], ces notions « d’amélioration

de performance » et « d’amélioration de la satisfaction au client » sont les deux axes
principaux d’ISO 9000 V200017
.
Ainsi ISO permet, à tout organisme qui souhaite appliquer cette norme, de suivre
des orientations à travers le respect d’exigences de qualité, sans stipuler de com-
ment faire, afin de rendre générique et indépendant son application.
ISO 9000 oriente la démarche des entreprises vers un certain nombre de points :
Mettre en place un système de management de la qualité, le documenter, le
maintenir,
Avoir un système documentaire à jour, maitrisé et utilisé,
Identifier les processus nécessaires au système de management de la qualité et
leur application dans tout l'organisme,
Mettre en place et suivre un système d'indicateurs fiables sur les processus clefs,
Améliorer continuellement ces processus,
Rechercher, mesurer, et améliorer de façon permanente la satisfaction client,
Manager sur la base de prises de décision motivées et argumentées,
…
Figure. 22 - Cartographie simplifiée des normes autour d’ISO 9000 V2000 (Source AFNOR)
Sur la figure (Figure. 22 - Cartographie simplifiée des normes autour d’ISO 9000
V2000 (Source AFNOR)), nous pouvons voir représentés les fascicules de documen-
tation AFNOR permettant d’orienter un système qualité vers ISO 9000 V2000. La
partie qui concerne plus particulièrement les processus est la norme FD X 50 - 176.
17
L’ancienne version ISO 9000 datait de 1994 et n’avait pas la notion de processus ; son orientation était dans la formalisation des métho-
des et du fonctionnement de l’organisme qui souhaitait l’appliquer. « Écrire ce qu'on fait et faire ce qu'on écrit" » cette maxime, résumant
cette norme, ne prenait malheureusement pas en compte l’aspect satisfaction au client final. Chose faite avec la nouvelle version d’ISO
9000 V2000

En plus de l’aspect documentation, management et qualité, il apparaît que la norme
ISO 9000 V2000 a évolué vers la notion de processus pour conduire son orientation
qualité.
3.2.1.2. La définition de processus
Harrington le définit ainsi : "Un processus d'entreprise est une série d'activités qui, à
partir d'un intrant, y ajoute de la valeur pour produire un extrant"... [Harrington,
1987].
Un processus est une collaboration de traitements élémentaires ayant comme objec-
tif commun la transformation d’éléments en entrées en éléments de sortie (Figure.
23 - Présentation d’un processus). Les entrées et les sorties sont généralement des
produits, des équipements, des matériaux, des informations ou des ressources finan-
cières. Pour que les activités du processus se déroulent correctement, il est impor-
tant d’attribuer les ressources (moyens, acteurs, . .) appropriées. Il est également
important d’analyser la performance du processus et d’analyser les caractéristiques
des entrées et des sorties en utilisant un système de mesure. Un processus est mis en
œuvre par l’application d’un ensemble de tâches formalisées sur un document appe-
lé procédure, qui lui - même est composé d’opérations (nous retrouverons plus en
détail ces notions dans la description d’OSSAD).
Figure. 23 - Présentation d’un processus
Pour reprendre les termes de l’ISO 9001 version 2000 : « l’organisme doit établir,
documenter, mettre en œuvre et entretenir un système de management de la qualité
et en améliorer en permanence l’efficacité... Il convient que les processus nécessai-
res au système de management de la qualité décrits ci - dessus comprennent les pro-
cessus relatifs aux activités de management, à la mise à disposition des ressources, à
la réalisation des produits et aux mesures. »
Ainsi on trouve une classification en 3 grandes familles de processus :
Les processus de réalisation dit opérationnel :
Les processus de support relatifs aux ressources
Les processus de management orientés décision et mesure

Figure. 24 - ISO 9000 - Les trois familles de processus
L’ensemble de ces trois familles de processus s’inclut dans une organisation qui a
comme objet la livraison de services à des Clients pilotés par une nécessité de satis-
faction au client final (Figure. 24 - ISO 9000 - Les trois familles de processus).
3.2.1.2.1. Les processus opérationnels ou de réalisation
Ils contribuent à la réalisation du produit ou service, de la détection des besoins et
attentes des clients à leur satisfaction. Ils regroupent les activités dédiées au cycle
de vie de produit ou service. C’est souvent un processus métier.
Exemples : La conception, la fabrication, la vente, …
3.2.1.2.2. Les processus de support
Également appelés processus de soutien, ils concernent les systèmes dédiés aux res-
sources humaines (implication du personnel, formation et qualifications), et les res-
sources liées aux infrastructures. Ils contribuent au bon fonctionnement des autres
processus par l'apport de ressources nécessaires.
Exemples : Gestion des compétences, formation et qualification des auditeurs, ges-
tion de la trésorerie...

3.2.1.2.3. Les processus de management
Ils contribuent à la détermination, à l'élaboration de la politique et au déploiement
des objectifs dans l'organisme. Ils sont les fils conducteurs des procès opérationnels
et de soutien.
Exemples : Pilotage de l'amélioration continue, Management de la qualité. .
Il est important de noter que la nature des processus est fonction de l’environnement
de l’entreprise et de son cœur de métier, la gestion de compétence, peut être un pro-
cessus de soutien dans une entreprise industrielle mais un processus de réalisation
dans une entreprise d’intérim.
Dans une réflexion orientée processus, ce qu’il est important à la base c’est de maî-
triser le processus en tant que tel, une fois cela fait, sa classification est relative aux
orientations données au projet le nécessitant. Dans notre cas notre étude est fondée
sur des processus de réalisation. Cette thèse étant orientée vers l’analyse de repré-
sentation de processus dans le cadre d’une organisation, la classification ne nous
concernera que pour compréhension. De plus la méthode OSSAD que nous allons
utiliser permet de représenter ce qui est souhaité, dans notre cas des processus mais
nous aurions aussi pu appeler cela des systèmes (aspect systémique vu précédem-
ment).
3.2.2. La méthode OSSAD
La méthode OSSAD (Office Support System Analysis Design) a été choisie pour
cette étude afin de représenter les organisations pour sa simplicité. L’un des argu-
ments fort est que cette méthode est graphique, elle décrit comment représenter un
processus, avec quels symboles, mais laisse libre l’utilisateur d’utiliser sa propre
méthode pour gérer son projet. Cela correspond parfaitement à un des objectifs de
l’étude qui est de pouvoir représenter graphiquement des morceaux d’organisation.
3.2.2.1. Présentation
OSSAD est le résultat d’un projet de recherche qui a été réalisé dans le cadre du
programme Européen ESPRIT (European Strategic Program for Research in Infor-
mation Technology) pour améliorer l’organisation des processus tertiaires en Eu-
rope. Elle est appliquée depuis 1990 dans de nombreuses entreprises sous le nom
d’OSSAD ou sous d’autres noms car c’est une méthode ouverte et non - proprié-
taire. La maintenance évolutive est assurée par un comité international OSSAD qui
siège à Genève.
OSSAD est un outil de description de besoins mais surtout et avant tout un langage
commun, simplifié, visuel qui permet à l’ensemble des acteurs de s’approprier la
méthode très rapidement. Son objectif premier est de permettre de représenter gra-

phiquement des processus et de faire ressortir des problèmes organisationnels. Ef-
fectivement, son approche n’est pas informaticienne mais orientée utilisateur. Elle
est très visuelle et possède un dictionnaire limité. C’est un outil qui rend facilement
possible une participation et implication de l’utilisateur.
La base d’OSSAD est d’avoir une approche à travers différents modèles reliés entre
eux : les modèles abstraits, descriptifs et prescriptifs.
3.2.2.2. Le modèle abstrait
Le modèle abstrait est orienté stratégie, il permet de représenter les objectifs d’une
organisation. Ce modèle s’attache à représenter de façon conceptuelle les processus
du système étudié. Il ne doit représenter que les caractéristiques stables, on peut
parler de macro - schéma de processus. Ce modèle a
l’avantage de rester très simple et facilement interprétable.
Sur le Méta - modèle UML on constate l’existence de
deux classes dont une qui forme une agrégation (Proces-
sus) pouvant donner ainsi un ensemble de sous processus.
Il est à noter sur ce Méta modèle qu’une information ne
peut avoir qu’un seul processus comme émetteur, si tel
n’était pas le cas, cela signifierait que plusieurs processus
génèrent la même information, donc un problème
d’optimisation. En complément de ce modèle, il est possi-
ble d’utiliser des modèles descriptifs en réutilisant les pro-
cessus déjà nommés.
Figure. 25 - OSSAD – Méta Modèle abstrait (UML)
3.2.2.3. Les modèles descriptifs
Le modèle descriptif complète le premier modèle et inclus des procédures, opéra-
tions, ressources, rôles, et outils, …. Il permet une représentation transversale et
concrète des activités de l’entreprise. C’est ce modèle qui va nous permettre de re-
présenter l’organisation Réelle Existante à partir des organisations Ressenties. Ces
modèles vont permettre de représenter le « qui fait quoi » et le « comment » du sys-
tème étudié. Pour rappel notre démarche étant systémique, les représentations dé-
coulant de ces modèles n’auront comme détails que ce qui nous intéresse ; ce ne se-
ront que des photographies d’une partie de l’environnement dans lequel nous nous
trouvons. Pour décrire ces photographies, plusieurs modèles descriptifs existent et
concernent : les procédures, les rôles et les opérations.
Informations (Paquet)
Processus
-Génère
0..*
-Provient1
-Reçoit
1..*
-Sert1..*
-Estconstituée
0..1
-Constitué
0..*

3.2.2.3.4. Le modèle descriptif de procédures
Le modèle descriptif de procédure permet de représenter les procédures d’un pro-
cessus donné ainsi que les ressources utilisées. En restant dans la simplicité du mo-
dèle abstrait, on commence à représenter les éléments opérationnels du système ci-
ble.
Ressources
Procédure
-Génère
0..*
-Provient0..*
-Reçoit
0..*
-Envoit0..*
Figure. 26 - OSSAD – Méta Modèle descriptif de procédures (UML)
3.2.2.3.5. Le modèle descriptif de rôles
Le modèle descriptif des rôles permet
de voir apparaître l’ensemble des res-
sources du système, incluant les per-
sonnes qui la composent. Le lien entre
les différents éléments de ce modèle
est le rôle. Une représentation de ce
type permet de visualiser
l’organisation opérationnelle attachée
aux personnes elle - même rattaché à
une Unité. Afin d’apporter toute sa va-
leur, ce modèle peut être appliqué
après les autres, ceci afin d’arriver
progressivement à se détacher d’une
représentation d’usage qui est
l’organigramme d’entreprise.
Figure. 27 - OSSAD – Méta Modèle descriptif de rôles (UML)
Ressources
Rôle
-Génère
0..*
-Provient1..*
-Reçoit
1..*
-Envoit1..*
Acteur Unité
-Exerce
1..*
-Estjouépar1..*
-Herberge
1..*
-Esttenupar0..*
-Estdépendante0..*
-Dépend0..*

3.2.2.3.6. Le modèle descriptif d’opérations
Ce modèle est le plus riche car l’ensemble des composants opérationnels sont pré-
sents. On remarque deux ensembles : la partie opérations et la partie tâches.
Nous serons confrontés dans cette étude à la similarité des opérations avec les tâ-
ches ; en fait, au final, la tâche reste un travail, tout comme l’opération. La diffé-
rence est sémantique, l’opération est rattachée à un ensemble d’éléments analyti-
ques (appuyer sur un bouton, pointer un état oui/non, …), la tâche à un ensemble de
traitement moins mathématique, qui ressemble plus à un aspect systémique (vérifier
le bon déroulement, qualifier une liste, ..). Cette différenciation est intéressante car
elle permet de mieux comprendre les problématiques auxquelles nous pourrions être
confrontées au cours de l’étude : une tâche peut être comprise sans être décrite de
façon formelle, une opération peut être décrite sans pour autant être imaginée ou
mémorisée par un acteur car elle fait partie d’un savoir implicite.
-Sertà
1..*
-Estutilisépar0..*
-Reçoit0..*
-Produit
0..*
-Génère0..*
-Utilise
0..*
-Sedécomposeen
0..*
-Appartient
0..*
1..*
-Dépend1..*
-Estconstitue
1..*
-Estutiliséepar1..*
Figure. 28 - OSSAD – Méta Modèle descriptif d’opérations (UML)
3.2.2.4. Le modèle prescriptif
OSSAD stipule simplement que la partie prescription doit être traitée avec d’autres
outils adaptés à la situation du projet. Néanmoins des études sont effectuées afin
d’orienter une démarche vers la mise en œuvre d’automatismes dans l’application
des opérations et procédures des modèles descriptifs. L’application la plus logique
étant de faire une transition vers la mise en place d’un « WorkFlow » (automatisa-
tion d’un processus par l’usage d’un outil). Ce modèle est le « Comment » de la mé-
thode.
Afin de permettre un dialogue cohérent avec les acteurs d’un projet, une grammaire
fondée sur un dictionnaire permet de normaliser l’ensemble de ces modèles.

3.2.2.5. Le dictionnaire OSSAD
Un des objectifs de la méthode OSSAD fait qu’elle possède un dictionnaire très
simplifié, afin que les graphiques puissent être assimilables facilement et rapide-
ment. Dans les tableaux en annexe (1010 - Le dictionnaire OSSAD) nous vous pré-
senterons les détails d’OSSAD en nous appuyant sur le dictionnaire utilisé par le
logiciel OSSAD PROCESS DESIGN. A savoir que chacun peut, comme il le sou-
haite, adapter ce dictionnaire, l’important étant de rester homogène durant tout le
cycle projet de représentation.
3.2.2.6. Les principes OSSADIQUES
Cette méthode ne serait pas complète si elle n’était pas enrichie par une philoso-
phie : Les principes d’OSSAD :
Contingence : l’avantage d’OSSAD est d’être souple dans ses représentations
d’une organisation. La contingence est cette capacité à s’adapter à
l’environnement dans lequel l’étude est menée, à ne pas être forcément
nécessaire,
Participation : OSSAD est une méthode orientée organisation, cela signifie
qu’un projet OSSAD travaillera dans un environnement très humain. Or, dans
tout projet où la composante maître est la personne, il est primordial d’inclure
tous les acteurs impactés par le projet, ceci afin que l’ensemble des participants
puissent adopter et enrichir le projet,
Pragmatisme (Orientation du problème) : ne pas avoir d’à priori dans la
démarche et le « problème à résoudre », rester le plus neutre possible et garder
l’objectif en vue afin de ne pas s’égarer vers de multiples détails et/ou
problèmes inhérents au projet,
Expérimentation : OSSAD base l’expérimentation comme étant une étape de
définition réelle d’un besoin. L’expérimentation peut effectivement être un
prototype d’organisation permettant de valider des choix en termes de
concrétisation des besoins qualifiés durant le projet,
Itéractivité : la notion d’itéractivité pour OSSAD est très importante car
l’ensemble de la méthode se base sur des enrichissements progressifs au fur et à
mesure de l’évolution du projet. « Les tâtonnements et retours en arrière sont
la conséquence logique des choix faits pour la Participation, le Pragmatisme et
l’Expérimentation permanente. » [OSSAD, 1990]
Agrégation/décomposition : comme nous l’avons expliqué, la méthode
OSSAD est systémique, c'est - à - dire qu’elle base sa réflexion sur un système
complexe avec ses processus et ses flux. Dans un environnement de ce type, il
est primordial d’être capable de décomposer et/ou d’agréger les informations
qui sont construite au cours du projet. Présenté sous la notion de Zoom, ces
agrégations/décompositions permettent d’avoir la vue nécessaire à la meilleure
réflexion. D’autres méthodes restent sur une description soit trop détaillées soit
trop générales, occultant ainsi la possibilité de garder une vue macro du
système tout en ayant la possibilité de projeter une petite partie cible et ses
liens.

3.2.2.7. La notion de zoom
Une particularité d’OSSAD par rapport à d’autres méthodologies permettant de re-
présenter une organisation est de pouvoir adapter le niveau de détail en fonction des
besoins (devant des opérationnels ou devant des décideurs par exemple). C’est la
notion de Zoom, qui est plus un concept qu’un outil. Cela est extrêmement intéres-
sant car permet d’avoir :
Une approche généralisée (démarche générale)
Une approche mixte (complétée avec une approche plus spécifique)
Une approche spécifique
Chacune de ces approches, permet de « cascader » des informations (exemple : un
processus est composé de plusieurs sous - processus, que l’on peut voir si on le sou-
haite (par un zoom) ). L’intérêt de cette notion de zoom est de permettre de rester
sur un schéma ayant le niveau de détail nécessaire à sa bonne compréhension.
D’ailleurs, pour rappel, le fondement du processus ISO 9000 V2000 est d’être une
boite avec des entrées et des sorties et interconnectée avec d’autres boîtes. La possi-
bilité de voir l’ensemble des processus en pouvant zoomer facilement sur l’intérieur
du processus permet de ne pas avoir les deux extrêmes : trop ou trop peu
d’informations.
Organisation
réelle existante
Organisations
ressenties
Organisation
Souhaitée
Organisation
théorique
Différence b
Différence c
Alternatives
Alternatives
Alternatives
Alternatives
Modèle
Prescriptif
Modèle
Abstrait
Modèles
Descriptifs
Figure. 29 – Macro schéma des modèles OSSAD
La figure (Figure. 29 – Macro schéma des modèles OSSAD ) nous présente les mo-
dèles utilisés par OSSAD et leurs positionnements dans une progression. A partir
d’un ensemble d’organisation (Figure. 16 - Différences et relations entre organisa-
tions), il est possible de générer le modèle abstrait ainsi que les modèles descriptifs.
Après un certain nombre d’enrichissements ces modèles pourraient permettre de
créer des alternatives à l’organisation cible, et le choix de ces alternatives permettra
de définir le modèle prescriptif qui sera appliqué. Le triangle permet de représenter

la notion de Zoom, ainsi que la notion d’itéractivité qui est représenté par les flè-
ches entre le modèle abstrait et les modèles descriptifs.
OSSAD est une méthode fondée sur une grammaire et des modèles de représenta-
tion d’organisations opérationnelles (originalement OSSAD été prévue pour des or-
ganisations tertiaires, qui ont donc leur productivité associée à l’outil bureautique).
L’intérêt est de pouvoir représenter une organisation en étant maître du niveau de
détail, ce qui n’est pas le cas d’autres méthodes qui sont plus fondées sur un tout ou
rien. Son usage est excellent pour réaliser des études courtes et précises dans le ca-
dre d’un audit, de préparation à la conduite de changement ou simplement de ges-
tion de compétences. Dans notre cas OSSAD répond à notre besoin, pouvoir repré-
senter plusieurs aspects d’une organisation.
3.3. Outils employés pour la modélisation
3.3.1. OSSAD PROCESS DESIGN
OSSAD Process Design est un logiciel édité par la société C - Log International, qui
propose des solutions dans le domaine du Business Process Management. Cette so-
lution, sans équivalent sur le marché, permet de couvrir tout le cycle lié à la maîtrise
des processus de l’entreprise :
Modélisation des processus et procédures d'entreprise grâce au logiciel OSSAD
Process Design
Documentation, publication et diffusion des processus, par l’intermédiaire d’
OSSAD Process Portal
Automatisation des processus grâce au logiciel WORKEY.
OSSAD Process Design est utilisé dans cette étude pour toute la phase de cartogra-
phie du Pôle Mise en Place Pilote, ceci quelque soit l’organisation (théorique ou re-
présentable). Cet outil très ergonomique a l’avantage de respecter la méthode OS-
SAD. De par sa simplicité, il peut faire partie intégrante de la mise en œuvre d’une
cartographie d’organisation. La principale raison est qu’il permet de communiquer
par son intermédiaire avec n’importe lequel des niveaux hiérarchiques ou profil
d’acteur de la dite organisation. Ceci est très important afin de capitaliser sans blo-
cage ni mauvaise compréhension avec les équipes en place.
« L’atelier Ossad permet d’éditer tous les types de graphes Ossadiens, avec le
contrôle automatique de la syntaxe et des formes graphiques. Cette facilité permet
d’utiliser effectivement le langage graphique Ossadien de manière participative, car
le coût de mise à jour des graphes devient insignifiant et ne constitue pas un frein à
l’imagination. » [C - Log, 2003]

Figure. 30 - Écran de base d’OSSAD Process Design
Les différents graphes utilisables par cet atelier sont (Figure. 30 - Écran de base
d’OSSAD Process Design) :
Modèle Abstrait : qui permet de représenter une organisation de façon
macroscopique à l’aide de Systèmes pouvant être imbriqués ainsi que de paquets
représentant des échanges entre ces systèmes.
Figure. 31 - OSSAD Process Design – Modèle abstrait
Modèle descriptif de procédures : Représentant les procédures d’un processus
donné ainsi que les ressources utilisées.

Figure. 32 - OSSAD Process Design – Modèle descriptif de procédures
Graphe des rôles : Ce graphe permet de voir apparaître l’ensemble des
ressources du système, incluant les personnes qui la composent.
Figure. 33 - OSSAD Process Design – Graphe des rôles
Modèle descriptif des opérations : Fait apparaître les détails séquentiels que
compose une procédure.
Figure. 34 - OSSAD Process Design – Modèle descriptif des opérations

Matrice des processus et rôles : Cette matrice permet de visualiser, par
croisement, les rôles avec les processus.
Figure. 35 - OSSAD Process Design – Matrice des processus et rôles
Graphe des unités organisationnelles : Permet de représenter un organigramme
avec des acteurs et unités
Figure. 36 - OSSAD Process Design – Graphe des unités organisationnelles
OSSAD PROCESS DESIGN est un outil est très simple sans pour autant perdre de
richesse en termes de représentation. Sa prise en main est assez rapide, bien qu’il
soit nécessaire d’avoir une certaine rigueur pour éviter des erreurs.
Un grand avantage d’OSSAD Process Design est qu’il possède un certain nombre
de contrôles et d’outil de synthèse. Ce logiciel s’avère être un parfait outil qui peut
être utilisé rapidement et pour toute opération de qualification d’un fonctionnement
simple ou complexe.
De plus la Société C - Log, dans la continuité de cet outil, propose deux autres logi-
ciels permettant de globaliser l’ensemble de la démarche de cartographie de
d’organisation (et de processus) avec une publication interactive sur intranet (OS-
SAD PORTAL) et la mise en œuvre de WorkFlow évolué directement construit à
partir de la démarche effectuée avec OSSAD Process Design (WORKEY).
En plus d’un outil permettant de représenter nos organisations, il était important
d’avoir dans sa valise des outils méthodiques qui permettraient d’être organisé dans
notre démarche, le Quoi, Qui, Où, Quand, Comment, Combien, Pourquoi en est un.

3.3.2. QQOQCCP
QQOQCCP est un acronyme de Quoi, Qui, Où, Quand, Comment, Combien, Pour-
quoi. Cet outil n’a rien de particulier si ce n’est de se poser les bonnes questions.
Souvent utilisé dans le cas de résolution de problèmes, il permet de ne pas se perdre
dans un ensemble vaste de détails complexifiant une réflexion. Son objectif est de
parvenir à une vision claire d’une situation donnée.
Le QQOQCCP peut être utilisé de façon méthodique en se fondant sur des formu-
laires posant les questions (Quoi, Qui, …) permettant de renseigner des colonnes
associées « est, n’est pas, différences » .
Figure. 37 - QQOQCCP – Quelques questions
Cet outil définit qu’il est important de se poser les bonnes questions, et que le mieux
est pour cela de se les poser toutes. Ceci afin de s’appuyer sur le principe qu’une
question ou une réponse en apporte d’autres et surtout le fait de s’interroger sur un
point est déjà un enrichissement de compréhension de ce point !
Dans notre étude, nous utiliserons cet outil face à une situation difficilement com-
préhensible ou nécessitant d’être éclaircie.

3.4. Synthèse du mûrissement
Avant tout chose, il est important de noter qu’il y a deux manières d’aborder une
étape de mûrissement : verticalement, c'est-à-dire avec une volonté d’apprentissage
et de maîtrise détaillées des éléments étudiés, avec une démarche d’expertise. Ou
horizontalement, en cherchant alors à comprendre les intérêts, contraintes, logiques
des éléments étudiés, cela nous mets alors dans une attitude de généraliste, qui
cherche a avoir une vue d’ensemble d’un sujet donné. C’est en tant que généraliste
que nous avons abordé ce mûrissement.
L’ensemble des éléments présentés dans ce chapitre ont comme objectif d’alimenter
plusieurs aspects de cette étude :
Les sources d’inspiration permettant d’élargir une ouverture de réflexion, et de
comprendre l’environnement d’étude :
ISO 9000 V2000 : La notion de processus doit être maitrisée, c’est une
condition permettant de mieux appréhender ce projet.
Des méthodes de modélisation permettant de répondre au mieux au besoin
OSSAD : Est la méthode de représentation des processus d’organisation et de
leurs fonctionnements qui est utilisé dans cette étude.
Les outils utilisés dans le cadre de l’étude
QQOQCCP : Il est nécessaire de se poser des questions pour mieux
appréhender un fonctionnement. Cet outil est un bon entrainement à
l’acquisition d’un reflexe valorisant toute étude d’analyse.
ISHIKAWA : Surtout utilisé afin de reconstruire un ensemble de cas
particuliers. Dans le cas où un processus a plusieurs manières (plusieurs
procédures semblables) et qu’il faut retrouver le fonctionnement adapté, le
diagramme de causes à effet apporte une grande facilité de reformulation.
(Annexe 11.4 - Ishikawa.)
La Loi de Pareto : Il est important de considérer le détail comme étant un
objet d’enrichissement d’un objectif et non comme une nécessité. Dans une
étude systémique, le détail doit être considéré avec attention, au risque de
rendre des représentation/explications indigeste et inutilisable. (Annexe 11.5 -
La Loi de Pareto)
D’autres éléments ont été utilisés indirectement pour cette étude, ceci principale-
ment afin d’influencer une méthode de travail et de mûrir l’orientation qui devait
être prise. Ces méthodes/outils et concepts sont résumés en annexe, pour informa-
tion et renvoi éventuel.
Une fois tous les éléments regroupés pour construire l’étude, il est nécessaire de dé-
finir une démarche de base qui sera notre fil conducteur. Il est à noter qu’il est très
difficile de proposer une démarche précise car l’environnement, systémique, aura
une appréhension directement liée à la vision qu’en aura l’auteur des représenta-
tions. Il y a des grandes étapes à suivre, ensuite il faut s’adapter avec bon sens à son
environnement. Aucune organisation opérationnelle n’est semblable car très dépen-
dante de ses composants variables.

La première étape directement nécessaire à la construction des représentations est
le recueil des informations, qui se fait en traçant et mémorisant l’ensemble des li-
vrables, acteurs, rôles, activités, éventuellement un certain nombre d’opérations. Ce
recueil peut être fait seul, et nécessite d’être détaillé et arrangé en terme de famille
de regroupement.
L’objectif de cette étape est de dégrossir le contexte de l’étude et de s’enrichir de
80% du nécessaire.
La seconde étape concerne la partie construction ; à l’aide des éléments recueillis,
la construction s’opère en appliquant les différents modèles (Abstrait, descriptifs, .
.). L’ensemble des modèles doit permettre d’avoir une représentation cohérente du
périmètre étudié. Dans le cas d’une représentation de l’organisation théorique, il est
souhaitable de réaliser en premier les représentations abstraites. Ceci car
l’organisation théorique suit une stratégie, qui par définition est générale. Vouloir
représenter quelque chose de global de façon détaillée risque d’apporter une infinité
de combinaisons. Par contre, dans le cas des représentations des organisations exis-
tantes, l’application de modèles descriptifs sera plus appropriée car collant bien
avec les détails de la situation existante. Attention cependant à rester assez généri-
que pour ne pas se perdre dans une multitude de détails qui rendrait la lecture im-
possible.
La troisième étape est l’analyse ; beaucoup plus collégiale, elle nécessite d’affiner,
par des entretiens, l’ensemble des schémas et d’enrichir le recueil effectué au pré-
alable. Ces entretiens seront croisés avec plusieurs acteurs afin que l’organisation
réelle soit une représentation concrète convenant à la majorité des acteurs.
C’est naturellement à travers cette étape que l’on pourra voir apparaître les incohé-
rences et / ou le delta entre l’organisation « existante » et « théorique ».
Ces différences permettront de prendre conscience de certaines situations,
d’apporter d’éventuelles corrections et de définir l(es) ’organisation s) cible(s).

Réalisation
Etude
Entités
concernées
Présentation de
l’étude
Bases de
mûrissement
Compréhension de
l’organisation
théorique
Analyse de
l’organisation
existante
Projection des
organisations
souhaitées
Représentation
Organisation
Méthode
Figure. 38 - Organisation du document – Réalisation
Dans le cadre de notre réalisation, nous allons présenter trois organisations de notre service
et détailler un cas particulier qui est la gestion des signalisations. Notre objectif étant de
comprendre le nécessaire permettant d’apporter des critiques constructives. Il est important
de considérer que ces trois organisations sont les mêmes mais vues selon des angles diffé-
rents. Elle traite des mêmes processus, des mêmes rôles, peuvent avoir les mêmes problè-
mes, elles ne diffèrent que par leurs objectifs. Cette subtilité est la clef de la compréhen-
sion de cette partie.

4.L’ORGANISATION THEORIQUE – (AGATHONE)
4.1. Présentation
La méthodologie Agathone a été défini par France Télé-
com dans le cadre des programmes ARCHIMEDE (nor-
mes organisationnelles relatives à l’architecture fonc-
tionnelle) et ARISTODE (normes organisationnelles
relatives à l’architecture technique). Cette méthodologie
oriente un projet vers une réflexion mixte sur deux acti-
vités d’ingénierie transverse : l’analyse métier qui impli-
que une étude fonctionnelle et l’architecture techni-
que qui implique une étude technique
L’ensemble de ces études effectuées simultanément
donne l’enrichissement d’un cahier des charges qui sera
utilisé pour les phases de conceptions et réalisation.
Figure. 39 - Différences et re-
lations entre organisations
AGATHONE suit un cycle de vie et est organisée d’une part en processus de réali-
sation reprenant chacun des métiers du système d’information, et d’autre part en ja-
lon et phases. Le croisement de ces deux systèmes donne des activités nommées
modes opératoires.
4.1.1. Le cycle de vie Agathone
Le cycle de vie de projet décrit de façon statique les différentes phases nécessaires à
la réalisation d’un besoin. Dans le cas d’AGATHONE elles sont délimitées par des
jalons.
Organisation
réelle existante
Organisations
ressenties
Organisation
Souhaitée
Organisation
Nécessaire
(théorique)
Différence b
Différence c

Figure. 40 – AGATHONE - Le cycle en Y
Dans ce cycle, on aperçoit à travers les différentes étapes la forme du cycle en Y et
la fusion des analyses fonctionnelles et techniques pour aboutir à la conception.
Ce cycle ne prend pas en compte la notion de pilote et de généralisation, (mais ils
sont traités dans la méthodologie AGATHONE), il s’arrête au jalon J1a qui corres-
pond à la construction du logiciel. Les autres jalons (notamment celui de la MPP)
sont visibles sur le graphe des processus et phases AGATHONE.
Figure. 41 - AGATHONE – les processus et phases
AGATHONE est composé de 6 phases majeures :
Études : Première analyse du besoin, permettant d’avoir une réponse concrète à
une expression de la maîtrise d’ouvrage et incluant un chiffrage global du coût de
réalisation,
Mûrissement : L’étude ayant été acceptée il est nécessaire de définir au mieux
l’ensemble des éléments permettant d’initier une conception, le mûrissement est le
cadrage fonctionnel et technique du besoin,
Conception : Élaboration des livrables définissant précisément le produit à
fabriquer (spécifications techniques et fonctionnelles),
Fabrication : Élaboration des produits, qualification, tests et recettes, intégration
des produits, et Mise en Place d’un Pilote,
Généralisation : Déploiement sur l’ensemble du périmètre sélectionné pour le
projet. Transfert de compétence du projet aux équipes du service continu,
Utilisation : Usage du/des produit (s) en environnement de production. La phase
utilisation se termine avec la fin de vie de l’objet dont il est question (logiciels,
…),

Il est à noter que ces processus comprennent des sous - ensembles d’activités indé-
pendants non représentés sur le tableau ; ainsi un processus peut démarrer très tôt
dans le cycle de vie du projet afin, par exemple, de permettre à ses équipes de mon-
ter en compétence. Mais ce processus ne sera véritablement actif que bien plus tard.
C’est le cas de la mise en place pilote qui commence au J - 1 pour finir au J2a, soit
une longue période.
Ces phases sont parcourues par 10 processus AGATHONE qui sont orientés vers
les métiers des systèmes d’information. Nous détaillerons plus précisément le pro-
cessus de la Mise en Place Pilote par la suite.
Analyse Conception,
Construction du logiciel,
Qualification des logiciels,
Exploitabilité,
Management du projet,
Maintenance, soutien et amélioration des produits et services (MSAP),
Gestion de configuration,
Acquisition,
Mise en Place Pilote et Déploiement (MPP),
Instruction des demandes d’évolution du système d’information
4.1.2. La mise en place Pilote
Nous avons déjà commencé une présentation de la Mise en Place Pilote (en page
38). Cette partie va permettre de positionner ce processus dans la méthodologie
AGATHONE.
Figure. 42 - AGATHONE – les relations du processus MPP avec les autres processus

Il est intéressant de constater que le processus MPP touche presque tout le cycle
AGATHONE. Théoriquement, les phases non impactées sont la Généralisation et
l’Utilisation
Figure. 43 - AGATHONE – Les regroupements du processus MPP
La figure (Figure. 43 - AGATHONE – Les regroupements du processus MPP) re-
présente les modes opératoires du processus MPP ainsi que les livrables nécessaires
à sa bonne réalisation et qui sont :
1 Critère de sélection du site pilote : Afin de choisir au mieux les sites qui vont
héberger le pilote, il est nécessaire de connaître les critères de choix, qui sont dé-
pendants de la version du logiciel et de l’environnement (projet en cours, périodes
sensibles, …).
2 Scénario de MPP : Le scénario de MPP définit de l’organisation de la MPP,
ceci en terme d’acteurs mais aussi de livrables.
3 Plan de travail commun (PTC) : Le PTC liste l’ensemble des tâches à réaliser
durant la MPP, l’objectif est que ce document soit consultable par les autres mem-
bres de l’équipe afin d’être le référant du projet de MPP.
4 Planning MPP : Liste toutes les dates clefs de la MPP (réunions, jalon, instal-
lation, livraisons, …)
5 Reporting MPP : L’état d’avancement, la listes des contraintes rencontrées et
les actions en cours ou à venir.
6 Dossier MPP : Le dossier de MPP reprend l’ensemble de l’organisation, ainsi
que la description des grandes étapes, l’équipe qui est activée, les contraintes et ris-
ques, …. C’est un document qui doit résumer l’ensemble de la MPP.

7 Contrat MPP ; Le contrat est une version allégée du dossier de MPP. Il est en-
voyé au (x) site (s) retenus (directions régionales) pour signature de bon pour ac-
cord.
8 Support de communication : Les supports de communication présentent la
version ainsi que les modifications d’usages qu’elle apporte.
9 Comptes - rendus de réunion : Les comptes rendus de l’avancement de la
MPP, des signalisations, …
10 Produits de formation et supports associés : Dans le cas d’un grand change-
ment au niveau de la version, il peut être nécessaire de faire de la formation directe
aux utilisateurs. Dans ce cas les livrables seront des supports de cours, cd - rom
d’auto formation, …
11 Compte rendu de la réunion de « GoNoGo » : Avant de partir en MPP un état
des lieux est fait afin de savoir si tout est livré, qualifié, intégré et prêt à être instal-
lé. Si ce n’est pas le cas des réserves seront émises, réserves qui devront être levées
pour pouvoir partir en MPP.
12 Dossiers de contrôle : Les dossiers de contrôle présentent les évolutions et
corrections apportées par la version afin que les utilisateurs du site Pilote puissent
les suivre et vérifier le bon fonctionnement du logiciel.
13 Documents utilisateurs : Tous les modes opératoires à destination des utilisa-
teurs finaux. Cette documentation est enrichie et validée au fil de la MPP afin d’être
livrée durant la généralisation.
14 Comptes rendu des contrôles : Ces comptes rendus reprennent l’état
d’avancement du dossier de contrôle.
15 Synthèse des signalisations : Un tableau reprenant l’ensemble des signalisa-
tions (incidents, évènements particuliers, durant la MPP.
16 Bilan de la MPP : La synthèse du déroulement de la MPP ; tous les acteurs in-
cluant le (s) site (s) pilote (s) participent à ce bilan.
17 Compte rendu de réunion de démarrage de la généralisation : Synthèse de la
réunion de GoNoGo qui trace les grandes contraintes rencontrées, les points positifs
et négatifs ainsi que les actions de vigilance pour la généralisation.
En plus de ces regroupements (au nombre de 17, et avec 17 livrables) le processus
MPP est expliqué à travers 7 modes opératoires qui décrivent chacun une activité :
relations avec le site pilote, qualification utilisateur, formation métiers, qualification
MOE SI, installation, communication, et avancement et suivi. Ces modes opératoi-
res présentent des fiches procédures qui expliquent le travail à réaliser ainsi que les
livrables associés. Ces dernières sont, pour chaque mode opératoire, regroupées par
phases (phase de mûrissement MPP, phase recherche du site pilote, phase de prépa-
ration du déploiement, phase d’initialisation du site pilote, phase d’installation,
phase de suivi et bilan, phase de post - bilan).

4.2. Les processus
Pour représenter AGATHONE, il a été important de reprendre l’ensemble de la do-
cumentation existante et unitairement de reconstruire chacun des sous - processus.
La méthode du groupe France Telecom a comme plus petit niveau de processus ce-
lui de la MPP. Si nous entrons dans le contenu de ce processus alors AGATHONE
parle de Modes opératoires et de Phases. Les modes opératoires étant composés de
sous - modes opératoires qui sont des regroupements de tâches. Nous les appelle-
rons donc des procédures puisque cela suit la même définition qu’OSSAD.
Cette étape de représentation a été très difficile car AGATHONE, à travers sa do-
cumentation ne nous propose que des fiches de mode opératoire d’activité et des
macros schémas par processus projet et par activité, mais sans présenter les liens en-
tre les différents systèmes. Ne sont pas représentés, non plus, de façon directe, les
liens qu’il peut y avoir entre chacun des modes opératoires ni entre chacune des
phases. Il est nécessaire de reprendre chaque descriptif et faire apparaître les liens,
quand ils existent.
Pour avoir la meilleure visibilité, nous avons croisé l’ensemble des sous - processus
AGATHONE MPP par phase et par activité afin de reconstruire les paquets qui
lient chacune de ces briques. Cela donne deux modèles abstraits. L’un par phase et
l’autre par activité.
Pour rappel, (4.1.2 La mise en place Pilote) nous avons comme objet pour notre ré-
flexion :
Le processus AGATHONE MPP
Composé de 17 regroupements fonctionnels
Expliqué par 7 modes opératoires (pour 7 activités)
Composé de 7 regroupements temporels (appelé des phases)
La première étape a donc été de représenter des systèmes qui se rapprochent le plus
de ce qui est proposé par AGATHONE. C’est pourquoi nous nous sommes appuyés
sur la documentation qui est composé majoritairement par les modes opératoires des
activités de la MPP.
Nous avons ensuite projeté une représentation par phase, afin de nous rapprocher le
plus possible d’une méthode de travail naturelle : progresser étape par étape en sui-
vant le temps.
Afin de ne pas refaire une méthodologie déjà existante, nous n’avons pas détaillé
l’ensemble des schémas, mais avons juste présenté un résumé. L’intérêt de l’étude
étant de représenter différentes organisations pour en faire ressortir des points
d’attention, pas de les expliquer dans le détail (pour rappel, notre démarche est sys-
témique et non analytique).
Il est à noter que lors de la représentation OSSAD d’AGATHONE, il n’a pas été
possible d’imbriquer des processus les uns dans les autres de façon naturelle. Ceci
est dû principalement à la présentation très descriptive et segmenté de la méthodo-
logie en question. On peut dire que le processus MPP contient d’autre processus
comme par exemple : ORGANISATION et QUALIFICATION, le contenu de ces

derniers est trop hachuré pour pouvoir constituer des niveaux de profondeur. C’est à
dire qu’il manque trop d’informations en termes de lien entre les différents proces-
sus (quel est le commencement et quels sont les liens entre processus ?).
De même, concernant les phases que nous avons créées, pour avoir une représenta-
tion chronologique, il n’est pas possible d’avoir plusieurs niveaux de détails en ter-
mes de processus, ceci car ces phases utilisent des morceaux des précédents proces-
sus. Ces zooms seraient incohérents car composés de petits morceaux d’opérations,
le tout avec quelques rares liens entre eux.
Par soucis de lisibilité et afin de ne pas surcharger le corps de l’étude, l’ensemble
des schémas et détails associés se trouvent en annexe (13.1 Voir pour les descriptifs
l’annexe 13.1 - Descriptif des processus AGATHONE, et pour les schémas
l’annexe 113.2 - Représentation OSSAD des processus AGATHONE MPP).
Lors de l’aperçu que le lecteur pourra avoir de ces descriptifs et schémas, il
conviendra de noter que l’organisation théorique, dans le cas d’AGATHONE, est
très détaillé et organisée sous forme de procédure (notion d’activités). Dans la partie
schémas, il pourra être remarqué l’absence de liens entre les différents phases et ac-
tivités. Ces caractéristiques particulières rendent cette organisation difficilement
appréhendable de façon globale et linéaire (suivre son déroulement pas à pas), cet
aspect, entre autre, sera décrit dans le chapitre suivant.
4.3. Les phases18
AGATHONE base sa chronologie sur la notion de jalon19
, on parle de J0, J1, J2, …
La MPP, comme nous avons pu le voir sur le schéma : Figure. 43 - AGATHONE –
Les regroupements du processus MPP, s’étend du J - 1 au J2. Les phases que l’on
peut rencontrer dans les documentations AGATHONE et sur la partie qui nous inté-
resse sont : mûrissement, conception, fabrication. Ce sont des phases de dévelop-
pement des produits logiciels qui sont difficilement appropriées pour classer les
procédures de la MPP.
Par contre, en entrant dans les descriptifs des modes opératoires, sur les synoptiques
de description de l’organisation de ces derniers nous avons trouvé des intitulés de
phases appropriés et qui permettent d’ordonner au mieux les tâches de la MPP.
Ces phases sont : Mûrissement, recherche site pilote, préparation du déploiement,
initialisation du site pilote, installation, suivi et bilan, post bilan.
Au vue du grand nombre de schémas, le lecteur pourra trouver en annexe
l’ensemble des synoptiques qui ont été réalisés à partir des documents AGA-
THONE. Leur description détaillées apporte très peu d’éléments, seule leurs cons-
truction et la vue d’ensemble réalisée a permis de mûrir l’organisation théorique.
18
La phase est la principale composante de regroupement d’étapes sur le cycle de vie d’un projet, elle intègre une notion de
temps (un positionnement dans le temps).
19
Les jalons sont noté J0, J1, J2, … J pour jalon et le numéro pour une séquence

4.4. Les rôles
AGATHONE associe les acteurs aux rôles, cela signifie que le seul rôle qui
concerne directement la mise en place pilote est le pilote de la MPP. Ce pilote est
appuyé par d’autres acteurs (pilote de qualification, installateur, …) ; ces rôles se-
ront présentés dans le chapitre de l’organisation existante. Ils sont les mêmes que
l’organisation théorique.
4.5. Un exemple : La gestion des signalisations
Un aspect intéressant de la MPP est la gestion des incidents. Dans le cadre d’un pi-
lote, l’objectif majeur est de valider la mise en place d’une nouvelle version, de cor-
riger les dernieres « erreurs » et d’ajuster la version en fonction des remontées dé-
tectées.
Figure. 44 - AGATHONE – Les activités de suivi des signalisations
AGATHONE ne présente que quelques enchaînements concernant cette partie qui
se trouve dans la phase Organisation, avancement et suivi. Il est question
d’organiser la gestion des signalisations, de les gérer, et de les clôturer. Ce niveau
de détail est suffisant pour une méthodologie projet d’entreprise, par contre, elle né-
cessite un enrichissement de détail lorsque l’on est directement confronté à sa mise
en place et réalisation.
Nous verrons par la suite la nécessité de creuser ce processus, afin de détecter des
incohérences et donc de proposer des améliorations. A ce stade ce que nous pou-
vons dire est qu’Agathone dit qu’il est nécessaire de gérer les incidents et de les clô-
turer. Ceci sans aucun détail supplémentaire.
Nous verrons dans le chapitre suivant que l’organisation existante est fortement
semblable à l’organisation théorique. Nous essaierons de faire apparaître les élé-
ments qui ne sont pas semblable, ou qui le seraient peut être un peu trop.

5.L’ORGANISATION EXISTANTE
5.1. Présentation
L’organisation existante est beaucoup plus simple à
décrire que la précédente, ceci de par le fait :
qu’elle concerne une population travaillant dans un
unique domaine (études informatique),
n’intervenant que sur une partie du macro -
processus Agathone
et qu’elle a adaptée son organisation à un
fonctionnement plus simple que celui proposé par
Agathone20
.
Figure. 45 - Différences et re-
lations entre organisations
L’organisation existante ne représente que ce qui est réellement présent et utilisé.
Néanmoins, elle est la plus intéressante car celle qui nécessite d’être comprise pour
connaître le point de départ d’éventuelles améliorations. Appliquer des concepts ou
orienter des organisations vers des cibles théoriques, sans connaissance de l’existant
peut avoir des conséquences difficiles à gérer.
Afin d’arriver à une cible synthétique et lisible, notre démarche a été, dans un pre-
mier temps, de lister l’ensemble des éléments que nous pourrions avoir. Il a été en-
suite nécessaire d’organiser ces éléments de façon cohérente et exploitable pour
constituer un vivier d’informations attaché à la mise en place pilote : la liste de
composants21
.
20
Pour rappel l’organisation existante est tributaire d’un grand nombre de facteurs difficilement industrialisables. C’est, à
l’opposé de l’organisation théorique, qui est théorique et mathématique, une organisation malléable et adaptative aux com-
posants qui l’enrichissent, composants humains et complexes, … systémiques.
21
Voir : 12 - Complément : Recueil des composants
Organisation
existante
Organisation
Souhaitée
Organisation
théorique
Différence c

Acteurs
(pôles ou famille)
Réunions
Livrables Outils
Mise en place
Pilote
MOE CRISTAL
Contrat
Scénario
MOA
lancement signalisation
Excel 26D
WebDoc
Direction
de Service
TMA CRISTAL
Production
informatique
Chaîne
de soutien
Généralisation
Support
métier
Qualité
Les utilisateurs
(DR)
Plan de travail commun
Planning
Reporting
Plan de mobilisation
Annuaire
Dossier MPP
Ordre d’installation
Fil conducteur
MPP Metre
Bilan
Signalisation
Présentation
contributeurs
Présentation
utilisateurs
Fiches de test
Fiches croisière
Doc. utilisateur
Ouverture file mpp
Temps de réponse
Sonde Vantage
OGA
Genesis
lancement installation
lancement MOE
Présentation à la DR
Présentation
aux Contributeurs
tests sur
la version
suivi des signalisations
suivi de la MPP
validation Ordre
d’Installation
suivi de l’installation
présentation
fiches croisière
présentation
fiches de tests
présentation
organisation
Figure. 46 – Ensembles des composants de la MPP
Le diagramme de cause à effet22
de la Figure. 46 – Ensembles des composants de la
MPP, représente la synthèse de la démarche de recensement des différents compo-
sants de la MPP. Les 4 branches principales représentent chacune un ensemble dont
le contenu est nécessaire à la bonne réalisation de la MPP : acteurs, réunions, livra-
bles, et outils.
Au niveau processus, nous avons décidé d’effectuer des regroupements par phase,
ceci afin d’avoir une vue séquentielle de l’organisation, qui colle parfaitement avec
la réalité de vie du projet de MPP. Les phases se comportant dans ce cas comme des
processus, avec leurs entrées et sorties.
22
Voir : 11.4 - Ishikawa

5.2. Les phases et processus
Au sein de la MOE, on ne parle pas de phases de façon formelle, le projet évolue en
fonction de livrable ou d’étapes. Les intitulés donnés ici l’on été afin d’arriver à re-
grouper un ensemble d’actions pour arriver à livrer des représentations lisibles.
Dans l’organisation existante, la MPP se construit au fil de l’eau, sur la connais-
sance des personnes, en s’appuyant si besoin sur la référence AGATHONE, et plus
particulièrement sur des documents préformatés, et listant, de façon exhaustive les
tâches à ne pas oublier.
Les listes qui suivent présentent les différentes phases ainsi que les moments forts
de ces dernières. L’important est de noter que pour appréhender une organisation il
faut être capable de la visualiser par sous-système. Nous faisons donc des regrou-
pements de sous-système que nous appelons phase.
Dans cette partie, ainsi que la même partie des chapitres suivants, nous chercherons
à présenter ces phases dans leurs ensembles afin d’apporter une sensibilité sur la
nécessité de raisonner par ensemble et non par détails.
Préparation
Constitution de la version / Montée en puissance / Choix du site pilote
Rédaction du dossier, contrat, …
Constitution des packages logiciels, test d’installation, rédaction de l’ordre d’installation.
Figure. 47 – (Organisation existante) – Phase préparation

Installation
GoNoGo23
, ordre d’installation, plan de mobilisation24
,
Réunion de suivi de l’installation et d’utilisation, …
Figure. 48 – (Organisation existante) – Phase installation
Suivi et bilan
Suivi des signalisations et des correctifs, préparation du bilan
Bilan25
, clôture des signalisations, préparation du jalon « J2 »
23
GoNoGo est une expression souvent utilisée avant de lancer un projet ou une phase d’un projet, cela signifie « nous y
allons ou non », la réponse à cette question se fait après qu’un collège de décideurs ait passé en revue une liste de point et
ait statué s’il y avait présence de points bloquants ou non.
24
Le plan de mobilisation regroupe toutes les informations de support, d’intervention, d’astreinte pour les équipes néces-
saire à une opération en environnement de production (par exemple : installation d’un logiciel)
25
Le Bilan est la réunion qui termine une phase ou un projet. Le GoNoGo le commence, le Bilan le termine. En général, les
mêmes listes sont utilisées.

Figure. 49 – (Organisation existante) – Suivi et bilan
Pour rappel ce qui est intéressant à noter est que les personnes qui travaillent sur la
MPP ne se basent pas sur un fonctionnement par phase mais en fonction des jalons.
A la question où en est ce projet, la réponse sera au J1, J2, ... (La référence étant le
jalon d’AGATHONE). L’inconvénient est que ces jalons n’offre pas de niveau de
détails fort : être avant le J2 signifie être entre le tout début du projet dans son en-
semble (analyse des besoins, accord de budget, …), et au début de la généralisation,
c’est assez vaste.
Lorsque les acteurs de la MPP nécessitent donc de se positionner temporellement
sur le projet, à part les jalons, ce qui est utilisé est souvent la tâche à venir et plus
particulièrement la livraison de produits logiciels (ce qui sera mis en paquets et ins-
tallé sur les machines). C'est-à-dire à la question ; « où en sommes-nous du pro-
jet ? » la réponse est : « avant le J2 » (positionnement sur Jalon), ou alors : « avant
la livraison des produits livrables » (positionnement sur un évènement de type tâ-
che.
Cela ne pose pas de problèmes particuliers car les acteurs se positionnent chacun en
fonction de leur rôle. L’inconvénient est que chacun ayant ses repères, et ces der-
niers étant semblables (cas des produits livrables), les appréhensions de l’avancé du
projet divergent. Car chacun n’a pas forcément la même vue sur ce qu’il y a à faire.
Une bonne communication est nécessaire pour ajuster et uniformiser la vue et le po-
sitionnement sur le projet de chacun. Nous verrons que cela pourra être amélioré en
portant, entre autre, une attention particulière aux rôles.

5.3. Les rôles
Pour rappel, il est important de bien comprendre qu’un acteur a un ou plusieurs rô-
les attribués qui peuvent varier au fil du temps, et qu’un même rôle peut être partagé
par plusieurs acteurs.
Rôle
Acteur
Figure. 50 – (Organisation existante) – UML des rôles
Dans le cadre de l’organisation existante, les rôles sont ceux qui sont décrits dans
AGATHONE. Ce sont ces rôles que l’on retrouve regroupés dans l’organigramme
de la MOE de CRISTAL (Figure. 51 – Organisation et positionnement de la MOE
CRISTAL) et celui représentant les équipes de la MOE CRISTAL (Figure. 52 –
Equipes de la MPP). Ces rôles sont assez nombreux (certains interviennent réguliè-
rement et d’autres très rarement). Les principaux sont pour ceux qui sont les plus
impliqués : le pilote de la MPP, le chef de projet version, le chef de projet de la Di-
rection régionale, le pilote de qualification. Les autres rôles sont moins impliqués
mais nécessaires : Gestionnaire des environnements techniques, Responsable des
tests, Qualificateur du SI, Expert fonctionnel, Expert technique, Concepteur, Sup-
port Études, Accompagnateur métier (SPOT), la MOA, packageur logiciel (Kim-
meur) – Intégration, Pilote d’exploitabilité – Exploitation, Réalisateur développeur
(Sopra), Réalisateur développeur (Ordo_DR), …26
.
26
Les rôles les plus importants sont présentés en annexe (12 - Complément : Recueil des compo-
sants de la MPP)

Figure. 51 – Organisation et positionnement de la MOE CRISTAL
Avec une vue macro et au niveau de l’organisation globale des équipes de la MPP
et leurs positionnements dans l’organigramme de SIClient, on peut noter deux
grands aspects intéressants :
1) La transversalité entre le Direction du projet représentée par le chef de projet ver-
sion (figure ci-dessus),
2) L’association un à un entre les pôles et les rôles impactés par la MPP.
Concernant la transversalité, nous remarquons que le point d’accroche des deux
domaines de responsabilités est la DP Commande - Livraison, et qui situe les deux
chefs de projet au même niveau hiérarchique. On peut en déduire que ces rattache-
ments permettent de garder une organisation « administrative » orientée vers le ma-
nagement d’une équipe opérationnelle qui met à disposition d’un chef de projet,
pour un événement temporel, une partie de ses ressources.

Figure. 52 – Equipes de la MPP
Sur un périmètre élargi, hors MOE CRISTAL qui prend en compte la conception, le
pilotage du développement, la qualification, la gestion du référenciel, la MPP im-
pacte un grand nombre d’entités. De l’intégration pour valider la compatibilité tech-
nique des produits logiciels qui vont être insérés dans la production informatique, à
l’exploitation qui prend en compte le suivi de l’application modifiée, au support qui
soutient la période de mise en place et le récurrent une fois la MPP terminée. Cette
chaîne de soutien est une des composantes majeurs en terme d’organisation pour la
bonne maitrise de la mise en place pilote (dont l’objectif est de valider une nouvelle
version sur un périmètre défini).
L’organisation existante suit à l’identique l’organisation théorique. Les rôles sont
nombreux et bien définis. De même chaque acteur a un rôle, et on remarque qu’en
général, il y a unicité entre rôle et acteur.
5.4. Un exemple : La gestion des signalisations27
Dans le cadre de la mise en place d’une nouvelle version sur un pilote, la gestion
des signalisations est un processus clef car, une fois les opérations d’installation
terminées, il est le point focal du projet. La gestion des signalisations, dans le cadre
de l’organisation existante, est un processus qui est cantonné au suivi des incidents
remontés de la mise en place pilote.
27
Il est à noter que nous n’avons pas intégré 100% des possibilités dans les schémas de ce processus, mais uniquement ceux
qui nous paraissaient pertinents pour notre analyse.

Figure. 53 - Signalisations : Processus d’escalade simplifié
Nous avons vu au chapitre 2.3.3 - La gestion des signalisations, les différents types
d’évènements ainsi que leurs transformations. Il est important de noter que la mé-
thodologie AGATHONE ne parle que de signalisation d’incidents. C’est aussi ce
que nous constatons dans le cadre de la gestion des incidents de la MOE Cristal.
Dans l’organisation existante, la gestion des signalisations est telle que décrite dans
l’organisation théorique. Il n’y a pas de différences majeures.
Figure. 54 - AGATHONE – Les activités de suivi des signalisations
Ce qui est présenté de façon simple sous AGATHONE, donne, en réalité un chemi-
nement plus détaillé qui prend en compte deux étapes de qualification :
Déterminer si la signalisation entre dans le cadre de la MPP : Si ce n’est pas le
cas alors elle passe dans le périmètre de gestion AR (Actions récurrentes : qui
correspond au service continu, et donc hors projet).
Déterminer le type de signalisation : Avant d’être transformé en OGA, il est
nécessaire de reproduire et de qualifier le problème. Dans la majorité des cas, une
signalisation se transforme en OGA, mais il est possible qu’elle soit simplement
clôturée.

Figure. 55 – Processus existant de gestion des signalisations28
Dans le schéma ci - dessus, nous apercevons les étapes d’évolution d’un évènement,
qui ensuite devient signalisation puis OGA. Ce schéma présente trois grandes famil-
les de transformation, les signalisations, les OGA et les correctives.
Ensemble très cohérent sur papier, le fonctionnement l’est moins dans ses subtilités
et sur le terrain. Effectivement, que se passe - t - il si une signalisation n’est pas
vraiment un incident, si c’est un effet de bord d’une évolution qui modifie les usa-
ges des utilisateurs ? Cela doit il être corrigé dans la MPP (effet de bord) ou passée
en AR (ancien problème) ? Qu’en est - il des incidents non reproductibles qui peu-
vent être dus à une mauvaise manipulation ? Ou même qu’en est il d’une évolution
qui après pratique se révèle incomplète et nécessite de bénéficier d’une extension
d’évolution ?
En résumé, qu’en est - il des cas particuliers, officieux ou officiels ? La méthodolo-
gie AGATHONE ne parle que du suivi des signalisations. Ces dernières ne peuvent
28
(xxx) abcdef = xxx le type d’événement (SIGnalisation, OGA, CORrection, abcdef l’action. Exemple : (SIG) Transfor-
mation OGA = L’évènement signalisation est transformé en OGA.

être que des anomalies déclarées et prise en compte dans le circuit normalisé. Dans
la réalité il existe d’autres circuits pour d’autres types d’informations, mais ces der-
niers sont traités différemment, des fois avec des zones de flous qui se maitrisent
par des échanges croisés et informels entre acteurs.
On ressent, dans l’ensemble, une volonté de coller à AGATHONE, mais pour ce
dont AGATHONE traite. Pour le reste, il n’existe pas de formalisme, alors chacun
s’est adapté, souvent en utilisant la voix pour communiquer, ce qui offre une sou-
plesse mais aussi des risques de mauvaise compréhension, de perte d’information,
de bruits, …. .
Une règle d’or lorsque l’on travaille en mode projet est d’avoir un fonctionnement
complètement dissocié du service continu. (6.2 - Les phases et processus). Les limi-
tes entre les équipes MPP (Projet) et les équipes AR (fonctionnement service conti-
nu) sont assez floues ; ce qui présente un risque de complexification des occurren-
ces de cheminement d’évènement (mauvaise qualification ou qualification tardive,
effet ping - pong entre les deux services). Ici aussi il est généré un certain nombre
d’échanges afin de réaliser une qualification du moment, des fois en urgence.
Enfin pour finir, l’équipe MPP est chargé du pilotage de cette chaîne d’évènements,
elle s’appuie pour cela sur :
une équipe qui gère les signalisations en entrée (Niveau 1 : enregistrement de
l’incident, et niveau 2 : résolution évoluée d’un incident),
une équipe qui gère le suivi des OGA,
l’équipe du service continu qui gère les signalisations et OGA au fil de l’eau.
La grande difficulté de cet ensemble se joue sur l’aspect coordination, considérant
qu’excepté les niveaux 1 et 2 qui sont directement liés à la MPP ; le niveau 3 a un
fonctionnement complètement autonome, en tant que service continu et en mode
projet. Les limites entre ce qui touche la MPP, ce qui relève d’une future version
(les cycles de montée de version se chevauchent), et ce qui relève du support
d’ancienne version peuvent bouger et des fois se chevaucher ou ne plus se rejoindre.
Considérant qu’une information appartenant à la MPP peut voyager entre ces diffé-
rents niveaux, il faut être capable de la suivre et d’être sûr qu’elle sera prise en
compte tout le temps. Cela implique, parfois, une coordination sportive.
La qualification des signalisations se fait sur un périmètre géographique, il est donc
aisé de relever toutes les signalisations touchant l’application CRISTAL puis de les
qualifier. Pour le service continu (Gestion des signalisations et OGA AR) et le Pôle
qualification, cela est plus difficile car chacun a sa vie propre et chacun peut géné-
rer des évènements impactant la MPP et le suivi des signalisations en cours. Il
s’avère alors difficile de centraliser une information à 3 points d’entrée en n’en re-
gardant qu’un.

Figure. 56 – Vie d’une signalisation : visibilité de la MPP
La figure ci-dessus illustre la vue que peut avoir le pilote MPP dans la vie d’une si-
gnalisation. Ce qui est sur fond bleu (devant l’œil non barré) peut être suivi car le
point d’entrée est la signalisation, qui se transforme en OGA, …. Par contre l’OGA
a générée des effets de bord, c'est - à - dire que son analyse a fait apparaître d’autres
problèmes. Ces derniers provoquent la création d’une autre OGA qui va être corri-
gée puis installée lors d’une corrective, ceci dans le cadre de la MPP, et sans que le
pilote de la MPP puisse le savoir. Le problème est le même avec une autre OGA ef-
fet de bord, qui elle passera en AR. On peut aussi rencontrer cet aspect si une OGA
est créée sans signalisation, donc sans passer par le point d’entrée de la MPP. Ceci
se fait en usage normal durant la qualification.
L’importance de ce disfonctionnement apparemment anodin, est lié à la maitrise du
processus. Le fait de ne pas connaître une étape de la vie d’un incident n’empêche
en rien au projet de se dérouler. Par contre qu’en est-il lorsque qu’un incident grave
se produit ?, il est fort probable qu’il y ait une grande perte de temps pour retracer et
requalifier le problème.
Nous sommes là sur un raisonnement d’anticipation qui se résume à « il me faut
avoir tous les éléments en main afin de pouvoir anticiper sur un incident grave ». Ce
raisonnement est souvent assez difficile à comprendre car il ne concerne que la per-
sonne qui a besoin de cette visibilité complète. Il se trouve que ce n’est pas celui qui
a le contrôle complet sur le déroulement du flux.
Si l’ensemble des acteurs ne sont pas sensibilisés, alors l’information nécessitera un
coût conséquent en pilotage de « recherche d’information ».

6.PROJECTION DE L’ORGANISATION SOUHAITEE
6.1. Progression
Nous avons vue l’organisation apportée par AGA-
THONE ainsi qu’une des organisations que vit
l’équipe de la MOE CRISTAL à travers la mise en
place d’un pilote. Ce chapitre nous présentera une vue
sur l’organisation souhaitée. Cette organisation devra
intégrer des contraintes qui auront été exposées au
préalable, et apporter des solutions qui amélioreraient
l’organisation existante.
Figure. 57 – Différences et relations entre organisations
La première étape pour présenter une organisation cible a été d’enrichir le recueil
effectué lors de la représentation de l’existant. Ce nouveau recueil, figure ci-
dessous, a été réalisé dans le cadre d’un transfert de compétences vers un nouveau
Pilote MPP. Il est enrichi entre autre d’une brique phase et de quelques modifica-
tions relatives aux outils et aux documents projet.
Acteurs
(pôles ou famille)
Réunions
Livrables Outils
Mise en place
Pilote
MOE CRISTAL
Contrat
Dossier de scénario
PTC + Planning
+ annuaire + ...
MOA
lancement signalisation
Universalisation
du suivi des versions
(Excel 26D)
WebDoc
Phases
Direction
de Service
TMA CRISTAL
Production
informatique
Chaîne
de soutien
Généralisation
Support
métier
Qualité
Les utilisateurs
(DR)
Reporting
Dossier MPP
Fil conducteur
MPP Metre
Bilan
Signalisation
Présentation
contributeurs
Présentation
utilisateurs
Fiches de test
Fiches croisière
Doc. utilisateur
Ouverture file mpp
Temps de réponse
Sonde Vantage
OGA
Genesis
lancement installation
lancement MOE
Présentation à la DR
Présentation
aux Contributeurs
tests sur
la version
suivi des signalisations
suivi de la MPP
validation Ordre
d’Installation
suivi de l’installation
présentation
fiches croisière
présentation
fiches de tests
présentation
organisation
Préparation
Initialisation
Lancement
Réalisation
Terminaison Suivi des
signalisations
Figure. 58 – Ensembles des composants de la MPP
Organisation
réelle existante
Organisations
ressenties
Organisation
Souhaitée
Organisation
théorique
Différence b
Différence c

6.2. Les phases et processus
Au travers de l’analyse du regroupement des informations qui sont ressorties de ce
diagramme et de la réflexion que nous avons eu sur les organisations théorique et
existante, nous avons considéré qu’il pouvait y avoir 5 phases projet29
dans la MPP
et que ces phases avaient des comportements et des règles spécifiques :
Préparation : Prend en compte l’ensemble des étapes permettant de recueillir
les informations et d’initier les actions de base pour l’enrichissement du projet,
sans générer de contrainte de dates. Les actions faites à ce stade restent
informatives et intemporelles, le projet peut donc ne pas avoir de dates de
réalisation planifiées, mais cette phase peut inclure un rétro planning. Nous
sommes dans la phase majeure du projet, celle de sa construction en avance de
phase. Cette phase est unique.
Figure. 59 – (organisation souhaitée) - Phase préparation
Initialisation : Le projet est acté, les dates connues, il est donc nécessaire
d’initier toutes les tâches qui vont permettre sa réalisation effective. Cela va de
l’activation des ressources, à la communication, en passant par la réalisation
d’étapes préliminaires (développement spécifiques, …). Cette phase est unique.
29
Nous notons deux modes de fonctionnement : Le mode projet qui est volatile dans le temps et a une organisation spécifi-
que car liée à la durée du projet, et le mode service continu qui prend en compte les activités récurrentes sur un « projet »
donné (ce « projet » est une activité ou un ensemble d’activités. Il est d’usage de l’appeler aussi « projet », mais il ne suit
pas le même fonctionnement qu’un projet. Cet aspect est à prendre avec beaucoup d’attention car très souvent synonyme
d’incompréhensions entre équipes, de failles d’organisations (croisement / manques de responsabilités, désynchronisation
d’actions, …))

Figure. 60 – (organisation souhaitée) - Phase initialisation
Lancement : Le lancement est une étape qui peut être récurrente au sein même
du projet. C’est dans cette phase que sont regroupées les actions opérationnelles
d’une séquence du projet (la séquence pouvant être le projet en entier). Si une
installation a lieu sur un périmètre donné alors cela fera partie du lancement.
Figure. 61 – (organisation souhaitée) - Phase lancement

Réalisation : La réalisation intègre les opérations de déroulement du projet une
fois que celui ci a été initié et lancé. Des opérations de pilotage, suivi, contrôles,
rapports, de déploiement, de corrections, ….
Figure. 62 – (organisation souhaitée) - Phase réalisation
Terminaison : Une fois la fin de la réalisation actée, la phase de terminaison
permet de gérer l’ensemble des actions de fin de projet, et de transférer les
compétences et actions, objets restants aux équipes de service continus.
Figure. 63 – (organisation souhaitée) - Phase terminaison

La figure, ci dessous, reprend le séquencement des différentes phases présentées.
On aperçoit les notions de phase autonome, (pour ce qui peut être fait en avance de
phase, sans contrainte de délai) les phases séquentielles, qui s’enchaînent les unes
derrière les autres, et les phases récurrentes qui peuvent se réaliser en chevauche-
ment en suivant les mêmes processus de réalisation.
Figure. 64 – Les phases projet
Pour rappel, la mise en place pilote s’insère dans un processus informatique projet
possédant un début et une fin est donc fondée sur un axe temporel déterminant de
son évolution prévisible. Il nous a paru logique de segmenter l’ensemble des actions
dans des phases qui auraient 2 natures : unique, qui ne s’applique qu’une fois dans
le processus projet de la MPP ou récurrente qui peuvent se reproduire autant de fois
que nécessaire, avec le même contenu. C’est le cas de la phase de réalisation qui a
pour particularité de pouvoir se réappliquer sur autant de directions régionales qu’il
peut être nécessaire. (Figure. 64 – Les phases projet) L’intérêt de cette récurrence
est d’industrialiser autant que possible les actions à réaliser.
6.2.1. Les rôles
Fondée sur l’organisation théorique, l’organisation existante que nous avons décrite
garde une bonne répartition des rôles utiles à la MPP. La projection que nous pour-
rions faire pour l’organisation souhaitée serait la même que celle que nous ferions
pour l’organisation existante. Ceci tout simplement car nous n’avons pas détecté
d’incohérence dans les rôles en tant que tel, mais dans leurs interprétations et
contextes.
Un aspect qui nécessiterait une évolution serait l’interaction entre les différents rô-
les qui peuvent être liés (ou le sont faiblement). La constatation faite lors de
l’analyse de l’existant est que les acteurs ont un périmètre de travail qu’ils gardent
bien délimité, ce qui est tout à fait normal et évite des croisements de responsabilité.
Néanmoins si les rôles d’un acteur restent trop délimités, il existe un risque fort
d’avoir une interactivité nulle avec les autres acteurs. Cela peut être assez problé-
matique.
Concrètement, un rôle est composé d’un ensemble d’opérations de travail qui ont
pour objectif de participer au fonctionnement d’un processus. Si cet ensemble
d’opérations de travail ne s’interconnecte pas avec d’autres rôles d’autre acteur,

alors il peut y avoir un dysfonctionnement. Surtout si ces deux rôles nécessitent de
communiquer entre eux pour apporter une complémentarité à un processus ou une
opération.
Pour rappel, dans le cadre de l’organisation existante, qui reprend quasiment
l’organisation théorique, les rôles sont bien définis, les processus le sont aussi mais
l’engrenage ne tourne pas aussi bien qu’il serait souhaitable. Ceci tout simplement
car il n’existe pas ou peu de dimensions qui permettraient d’attacher ou
d’interconnecter des rôles entre eux.
Pour prendre un exemple extrême où il y a cloisonnement d’un rôle : le pilote MPP,
dans son rôle principal, nécessite de coordonner les applications de correctives du-
rant la période de MPP. Ces dernières sont composées de produits logiciels qui ont
un numéro de version. (1.2.2 - Composition de l’application) l’application Cristal
est composée de deux familles de composants : les composants applicatifs et les
composants référentiels. Ces deux familles de composants sont gérées le premier
par le pôle qualification, le second par le pôle référentiel. Le rythme d’évolution des
composants Cristal est de, maximum, 4 - 5 fois par an, celui du référentiel de 1 fois
par mois. Il existe le rôle de « Gestionnaire logiciel » qui a en charge de suivre les
versions des différents produits livrables. La personne tenant ce rôle est le respon-
sable du pôle référentiel. Les deux ensembles de versions sont suivis par
l’intermédiaire de deux outils.
Il se trouve que durant les MPP, il apparaissait régulièrement des difficultés à obte-
nir, de façon rapide et directe, les versions des composants référentiels.
Ceci tout simplement car le cycle de vie des composants du référentiel est plus ra-
pide que celui des composants applicatifs et suit un cycle de qualification différent.
Ce qui fait que le rôle de « gestionnaire logiciel » doit effectuer un ensemble
d’opérations pour suivre les versions des composants Cristal, et un autre pour le ré-
férentiel, ceci mémorisé à travers deux outils. Le moment où un rapprochement doit
être fait est celui où le pilote de la MPP sollicite les deux informations en même
temps. C’est à ce moment où le rôle « gestionnaire logiciel composant Cristal » et
celui de « gestionnaire logiciel composant référentiel », tenu par la même personne
devient un seul et même rôle. Du moins devrait devenir un seul rôle.
Cette incohérence, amusante avec recul, est complètement compréhensible car dé-
pendante d’un historique, de mutualisation de rôles et de responsabilités. Ce qui
était intéressant de montrer est que la définition d’un rôle est importante, et que les
interconnexions de ces rôles doivent tout autant être maitrisées.
Une solution dans cet exemple serait tout simplement d’adapter l’outil de suivi des
versions utilisé à l’origine pour les composants Cristal afin qu’il devienne la réfé-
rence aussi pour les composants référentiels. Cet outil deviendrait alors le liant qui
manquait.
Dans notre organisation souhaitée, il paraît nécessaire d’enrichir les liens entre les
rôles afin de fluidifier et de favoriser les échanges.

6.3. Un exemple : La gestion des signalisations
Figure. 65 – Processus cible gestion des signalisations
Pour rappel, concernant notre exemple, le problème majeur que nous avons ren-
contrés est la restriction d’information relative au suivi des incidents de la MPP,
complété par le cloisonnement des rôles (cas de la gestion du référenciel) de notre
dernier exemple.
Notre problème est donc une perte de lien entre les informations ainsi qu’une visibi-
lité réduite. Afin d’améliorer cette situation la logique nous suggère :
d’augmenter notre champs de vision sur les opérations liées aux signalisations,
ceci afin d’avoir le recul nécessaire pour maitriser toutes les informations,
d’étendre le processus de gestion des signalisations à l’ensemble des acteurs
impactés par la MPP. Cela correspondrait à une redéfinition des rôles en les
étendant à un périmètre plus grand.

Concernant l’aspect visibilité nous pouvons tout simplement appliquer une règle qui
serait : toute information nécessite d’être considérée et mémorisé. Une fois tracée, il
serait nécessaire de qualifier les différents types d’information et les suivre. La sub-
tilité étant bien sûr de savoir classer, ce qui n’est pas considérable, comme étant du
« bruit ». A ce sujet, les compétences et le bon sens des personnes concernées
prennent la relève.
Concrètement, le schéma Figure. 65 – Processus cible gestion des signalisations
présente le nouveau processus. On remarque entre autre qu’apparait
l’enrichissement de la transformation de l’évènement en OGA, en patch, en signali-
sation, ceci au niveau de la MPP ainsi qu’au niveau de la AR. En nous appuyant sur
le schéma théorique Figure. 66 - Signalisations : Les différents évènements et leurs
traitements nous faisons apparaître un ensemble de type d’information pouvant être
géré et transformé (voir 2.3.3 - La gestion des signalisations).
Evénement
Incident
Information
Evolution
Bruit
Patch
Correctif
Traité
Supprimé
Redirigé
Information
Tâche
Redirigé
Traité
Service continu
Figure. 66 - Signalisations : Les différents évènements et leurs traitements
Deux nouveaux éléments que nous faisons apparaître sont la notion « d’évolution »
ainsi que la notion de « correctif » .
Effectivement, il est nécessaire d’ouvrir ce processus vers la prise en compte d’un
nouvel aspect d’un événement ( « théoriquement non officielle » car devant entrer
dans le cadre d’un processus en amont de la MPP) : la gestion des évolutions.
L’objectif est de ne pas permettre de traiter en MPP (phase réalisation) des évolu-
tions de logiciels mais uniquement des évolutions de référenciel. Ceci est possible
de par le fait que la partie référenciel a un cycle très court (entre le besoin, l’étude,
le développement, la qualification, l’intégration et le passage en production). Cette

aspect froisserait les puristes du mode projet30
, à cela nous répondrons que des fois
il faut être capable d’assouplir certaines règles afin de répondre aux contraintes du
marché31
.
Au niveau des correctifs, leurs prises en compte permettent de suivre l’évènement
de sa création à sa disparition, par la mise en place des corrections. Ceci afin de
permettre le pilotage de l’ensemble des transformations et aussi la résolution effec-
tive de l’incident premier.
Comme nous pouvons le constater dans cet exemple, les modifications qui ont été
réalisées sont très simples et l’on été en donnant plus d’ouverture au processus.
Ainsi notre processus de gestion des signalisations s’est enrichi par la prise en
compte d’évolution, ainsi que la notion d’information et de bruit. L’objectif du tracé
des informations et bruits est de valoriser la nécessité de tout tracer sans pour autant
tout traiter. Mais avec comme objectif final de simplement savoir ce qui se passe.
30
On ne mélange pas une étape de conception avec une autre plus en aval de déploiement d’éléments déjà conçus. C’est un
mélange de phase projet qui peut mener à des incohérences de réalisation (c’est comme si on peignait une portière de voi-
ture en même temps que l’on (re)conçoit les serrures, opération hasardeuse.
31
Pour rappel le référenciel contient les offres et services. Et ce sont ces données qui sont amenées en ce moment à bouger
très rapidement pour suivre le marché qui, nous l’avons vu, est aussi très mouvant.

7.SYNTHESES
7.1. L’organisation théorique
AGATHONE est une méthodologie très avancée dans la description de l’ensemble
des actions à réaliser pour un projet et à un moment donné. L’avantage indéniable
est que l’ensemble du groupe a un référant unique en termes de Projet, et que cha-
que personne maîtrisant cette méthodologie est rapidement autonome quel que soit
son périmètre d’activité. La méthodologie est bien documentée et facilement acces-
sible. L’ensemble des détails peut être trouvé afin de comprendre les grandes lignes.
Cette vue macro permet à chaque équipe de posséder sa propre latitude d’évolution
quant à l’application dans le détail tout en parlant le même langage avec les autres
équipes.
Il existe plusieurs remarques importantes concernant cette méthodologie.
C’est une démarche bien adaptée à des projets de grande envergure. Elle est par
contre très coûteuse pour être utilisé dans des petites structures, car très lourde à
mettre en place.
Le fait qu’il existe un cadre de fonctionnement dans lequel il suffit simplement de
s’insérer, peut impliquer une dévaluation mémorielle du fonctionnement de chaque
équipe. Étant donné que tout le monde suit AGATHONE, alors il n’est pas néces-
saire de décrire ce qui se fait (puisque c’est la méthodologie de référence). Par
contre qu’en est - il de l’adaptation que chacun en a faite ? Elle reste souvent orale
et très rarement formalisé par écrit.
Figure. 67 - AGATHONE – Complexité de la méthodologie

La difficulté à former les équipes sur cette méthodologie qui pour être très généri-
que et adaptable par tous n’en est que plus compliqué, implique une difficulté
d’appréhension de ce qu’il faut faire et ce qu’il ne faut pas faire. Cette non - maî-
trise apporte une adaptation très personnelle de la méthode, qui peut impliquer des
dégradations de qualité. La figure (Figure. 67 - AGATHONE – Complexité de la
méthodologie), qui est un extrait « simplifié » des relations entre phases, montre
une certaine richesse dans la bonne compréhension des interrelations entre les diffé-
rentes activités et paquets d’information entre activités. Effectivement, il est très
difficile de bien appréhender la logique de cette méthode, si la vie des livrables
n’intègre pas plus de richesse (quand il est créé, à qui va-t-il servir, …).
Un troisième aspect concerne la notion de cloisonnement. AGATHONE, de par sa
complexité, est détaillée sous forme de processus, de phase et de mode opératoire,
et de livrables. Il existe des croisements entre les phases, avec des liens entre les
phases et processus, processus et mode opératoire, mode opératoire et livrable, mais
il n’existe pas de fil conducteur entre les processus. Il est en fait très difficile de ré-
pondre à la question « comment va se transformer, et par où va passer une informa-
tion entrée dans le premier processus de la première phase » . Cette discontinuité de
liens entre les différents processus montre que la méthodologie est très directive sur
les tâches à réaliser, et beaucoup plus souple sur l’imbrication entre ces tâches. Ceci
se voit par la présence de livrables qui servent à des phases antérieures à la phase
pendant laquelle ils sont construits, ou des disparitions de livrables, ….
Figure. 68 - AGATHONE – La notion de cycle de vie d’une information
Bien que suivant un axe temporaire, on ressent dans cette méthode une certaine sta-
tique, il n’existe pas de notion de vie des flux d’information (document, objets logi-
ciels, …) qui permettrait de suivre un cheminement dans le temps intégrant les
éventuelles transformations de l’information.

On remarque sur la figure (Figure. 68 - AGATHONE – La notion de cycle de vie
d’une information), représentant une partie du modèle abstrait inter - mode opéra-
toire, que le livrable « plan de travail commun » est utilisé pour plusieurs activités,
mais sans pouvoir avoir d’ordre chronologique.
L’ensemble de ces points nous fait penser que AGATHONE pourrait avoir été cons-
truit à partir de macro activités puis suivant une approche descendante (dite « top
down ») de plus en plus détaillé afin d’arriver à des modes opératoires set des livra-
bles.
L’image que nous pouvons en avoir est celui d’une construction en silo, c’est à dire
une représentation complète d’un ensemble d’opérations sur un périmètre détermi-
né. Périmètre fonctionnel qui dans notre cas serait la MPP. La particularité d’un silo
est qu’il englobe un grand nombre d’éléments du plus général au plus détaillé. Son
inconvénient est qu’il reste sur ce périmètre et il peut être difficile de trouver des
ponts entre différents silos.
Effectivement, un aspect intéressant concerne le nombre de rôles associés au nom-
bre d’acteurs, le rapport est proche de 1. Cela signifie que le travail des personnes
est fortement délimité sur un domaine unique. Phénomène d’industrialisation du
travail, afin de simplifier des tâches et augmenter la montée en compétence ainsi
que la productivité. L’inconvénient est qu’un fonctionnement mono domaine peut
entrainer une visibilité réduite et un cloisonnement à terme.
Quoiqu’il en soit, dans notre étude, cette méthodologie nous donne tous les élé-
ments permettant d’avoir une organisation théorique bien explicitée.
Résumé :
Agathone est une méthodologie très complète fondée sur un fonctionnement jalon-
née, prenant en compte toutes les étapes d’un projet. C’est pour nous l’organisation
théorique, c'est - à - dire qui représente la stratégie que doit suivre notre service
d’étude informatique. AGATHONE est très procédurale, elle décrit l’ensemble des
composants des processus par des modes opératoires et décrit des rôles et activités
de façon très précise. Les « défauts de ses qualités » sembleraient être la présence
de risque d’une interprétation trop rigoureuse de ce qu’il faut faire à travers ses ac-
tivités et rôles, ceci sans forcément pouvoir s’adapter à un existant. De même il est
difficile d’avoir une vue vivante des flux entre les différents processus. AGA-
THONE semble être une description complète mais statique dans sa circulation
d’information.

7.2. L’organisation existante
Certaines des contraintes qui ont été vues à travers des exemples (Gestion des si-
gnalisations, suivi du référenciel, . .) paraissent anodines et aisément gérables par un
bon pilotage et des équipes proches et communicantes. Néanmoins il faut prendre
en compte que CRISTAL est une application complexe et qui s’insère dans un sys-
tème d’information complexe, l’ensemble étant soumis à une stratégie qui casse
complètement la logique sectorisé de ce dernier32
.
Effectivement, la convergence pousse les applications à communiquer encore plus
entre elles et modifie les offres dans leurs caractéristiques propres. Nous ne parlons
plus d’une offre de service sur le fixe, mais d’une offre packagée incluant par
exemple le fixe et le radio mobile.
La particularité de l’organisation existante est qu’elle s’appuie énormément sur
AGATHONE sans prendre la liberté d’adapter cette méthodologie à un contexte
collégial particulier. Par contre, on sent que dans un périmètre de responsabilité uni-
taire, les équipes s’adaptent et s’affranchissent facilement des contraintes
d’AGATHONE. Cela est parfaitement normal, l’effort est moindre lorsque l’on peut
s’organiser de son propre chef. Un fonctionnement devient compliqué lorsqu’il
s’agit d’intégrer plusieurs équipes ayant chacun leur propre autorité.
L’effet de bord de ces observations est qu’il est très difficile d’avoir une bonne mai-
trise du processus de gestion des signalisations. Rien n’explique, n’impose, ou ne
conseille de la nécessité de suivre toutes les informations qui peuvent impacter la
MPP.
Les entités participants à ce processus ont une vue interne dans la gestion des signa-
lisations, ce qui fait que le pilote de la MPP est obligé de courir derrière
l’information, car cette information n’est pas prévue d’arriver jusqu’à lui.
L’organisation existante33
correspond dans l’ensemble à ce qui est induit par
l’organisation théorique. Néanmoins elle est perfectible sur tout ce qui peut permet-
tre d’élargir les champs d’actions des acteurs.
32
La téléphonie fixe a été, en France, un produit avec très peu d’évolution en termes de service. Forcément le système
d’information relatif à cette téléphonie avait le même faible rythme d’évolution d’où l’aspect statique et fermé sur un sec-
teur technique : la téléphonie sur le fil.
33
Pour rappel, nous nous sommes mis devant une organisation existante, il ne faut pas oublier qu’il y en a plusieurs, mais
en prendre une et la travailler est une manière de procéder par couche successives qui permet de la rendre meilleure.

Résumé :
L’organisation existante colle le plus parfaitement possible à l’organisation théori-
que. Les rôles et activités sont très semblables à ce que nécessite AGATHONE, les
acteurs s’appuient beaucoup sur ce qui doit être, l’évolution du projet est fondée sur
le référenciel de jalons. Cette volonté de vouloir respecter à l’identique
l’organisation théorique affaiblit le fonctionnement des équipes entre elles. La
communication est réduite à ce qu’il doit être fait au détriment de ce qu’il faudrait
réellement faire. Ceci est complété par une limitation induite principalement par la
définition trop précise des rôles d’un acteur à un périmètre donné, et à l’exécution
des opérations contenu dans son processus. Il existe une forte fréquence d’unicité
entre rôle et acteur, n’incitant pas une personne à ouvrir son travail vers d’autres.
Les personnes sont très ouvertes entre elles, les relations dans leurs échanges
d’informations sont plus restreintes. Des processus en silo, des rôles trop bien défi-
nis, des échanges de flux d’informations appauvris, cette organisation a besoin de
s’assouplir au niveau de ses échanges.

7.3. L’organisation souhaitée
Une des organisations souhaitées34
se résume par la nécessité d’étendre et d’enrichir
les champs d’action de certains processus, partant du principe qu’avec une réflexion
transverse, il est possible d’avoir un champ de vision suffisamment large pour dé-
tecter des processus silos et de les rendre plus étendus et plus complets.
Bien sûr, il est important de considérer que rendre complet ne doit pas rendre com-
pliqué, ce qui, forcément, rendrait l’application du processus inexploitable. Nous
restons toujours dans une logique systémique.
A travers des expériences, on apprend dans le monde projet qu’il existe un certains
nombre de règles basiques qui sont des conditions sine qua none de la bonne ou
mauvaise réussite d’un projet. Deux d’entre elles concernent les responsabilités :
Les croisements de responsabilités : lorsque deux acteurs ou deux rôles ont dans
leurs procédures les mêmes opérations ainsi que les mêmes responsabilités sur les
résultats de ces dernières, il y a risque de dysfonctionnement (et de conflit) car
cette responsabilité identique peut se balancer entre les deux au gré de la bonne ou
mauvaise volonté des acteurs ou porteurs des rôles.
Les vides de responsabilités : c’est le contraire, il existe entre deux
responsabilités qui se complètent (qui travaillent ensemble) un ensemble
d’opérations orphelines (personne ne les (re)connait). Ainsi lorsque l’une de ces
opérations est en échec (ce qui est forcément le cas), personne ne la prend en
compte pour résolution.
De notre contexte nous pouvons faire ressortir une nouvelle règle attachée aux res-
ponsabilités qui serait :
Les responsabilités en silo : la trop bonne protection des responsabilités de
chacun (par une application très théorique d’une méthode ou par protection d’un
périmètre donné (pour qualité, par affinité, par historique, …) ) implique une perte
de communication et d’information entre chaque acteur ou porteur de rôles
concerné.
Un exemple simple résumerait ceci : dans un circuit électrique, s’il est nécessaire
que le courant passe bien d’un point à un autre, il ne faut pas pour autant qu’il passe
partout, ni qu’il ne passe pas du tout, et surtout qu’il passe pour chaque élément le
nécessitant. Encore faut - il pour ce dernier point connaître les éléments qui en ont
besoin. D’où l’intérêt de connaitre le circuit actuel et sa composition.
De même, il nous parait, important de ne pas sous estimer les outils de liaison entre
les différents rôles et acteurs (contributeur du bon fonctionnement des processus).
Ces outils ne doivent pas être bloquants, juste structurants pour ce qui est néces-
saire. Ainsi dans le cadre de l’évolution du processus de gestion des incidents, la
34
Tout comme il existe une infinité d’organisation existante, il existe aussi une infinité d’organisation souhaité, nous som-
mes dans un raisonnement systémique donc global, qui n’est pas analytique et n’a donc pas une seule réponse mais une in-
finité.

mise en place d’un simple tableau Excel bien renseigné, et un suivi régulier sont
amplement suffisant au bon suivi de tous les évènements.
Ainsi notre organisation souhaitée serait plus ouverte au niveau de ses rôles. Elle
saurait s’affranchir d’une éventuelle rigidité naturellement imposée par
Résumé :
Dans notre organisation souhaitée, nous avons à palier les faiblesses de
l’organisation existante que nous avons décrite auparavant. Pour cela nous avons à
axer notre effort sur l’ouverture d’interprétation d’AGATHONE : cas de la gestion
des signalisations qui nécessitent de prendre en compte plus d’information que sim-
plement un incident. Il serait nécessaire d’ouvrir les descriptions des rôles afin de
permettre aux acteurs porteurs de s’interconnecter plus facilement avec leurs autres
contacts. Puis il faudrait transmettre une dynamique aux interconnexions de certains
processus afin de favoriser les échanges de flux.

7.4. Remarques
Comme nous l’avons évoqué dans notre cadrage, nous nous intéressons en particu-
lier au manager de cette organisation. Lui transmettre une réflexion afin de partici-
per à un mûrissement nécessaire pour modifier sa propre organisation (en fonction
de ses besoins).
Comparer trois organisations35
peut être difficile dans le cas où la stratégie
d’entreprise n’est pas connue, ou lorsqu’elle est connue, mais que rien ne précise
Dans le premier cas, malheureusement il n’y a pas grand - chose à faire que de
s’appuyer sur la bonne volonté des membres de l’organisation pour assumer le quo-
tidien de la façon la moins rébarbative possible. S’il n’y a pas de stratégie, il nous
parait difficile de savoir où aller, encore plus de comparer des organisations en
fonction d’une cible.
Néanmoins, il pourrait être intéressant de construire une organisation théorique fon-
dé sur des aspects de type qualité de travail, ou amélioration de la qualité. Cela re-
viendrait à laisser le manager définir sa propre stratégie, et adapter son organisation
pour y répondre. Vu du niveau global de l’entreprise, cela risque de donner des ré-
sultats assez aléatoires36
.
Dans le second cas il sera possible d’adopter une méthode « descendante » (dite
« top down ») pour définir l’organisation théorique. En fait cela revint à dire que
notre entreprise à une stratégie, qu’il faut convertir en organisation cible. Nous par-
lons là de l’aspect tactique de cette stratégie. Cette tactique va offrir une cible aux
équipes managériales pour orienter leurs organisations.
Pour traduire une stratégie en modèle tactique, il peut être utile d’adopter une cons-
truction visuelle qui offrira à la direction le moyen de représenter leurs pensées ain-
si que les manières de les réaliser. OSSAD est une méthode qui peut aider à cette
formalisation. Elle est suffisamment simple à appréhender pour pouvoir facilement
dessiner un schéma lisible à une étape où le détail n’est pas nécessaire. Elle peut en-
suite permettre d’entrer dans le détail.
35
Il pourrait être judicieux de comparer ce que nous venons de voir dans cette étude : comparaison de trois points de vue
d’une organisation, avec une méthode d’audit classique (COBIT, propriétaire, ..). Cela pourrait revenir à la comparaison
d’une analyse systémique à une analytique. Cela n’est pas l’objet de ce document, mais pourrait faire l’objet d’une autre
étude.
36
Si cette entreprise n’a pas de stratégie, il y aura de toutes les façons des résultats aléatoires à terme.

En plus d’être une méthode graphique laissant une grande liberté d’usage, cette mé-
thode permet beaucoup de souplesse lorsqu’il s’agit de représenter les grandes li-
gnes d’une organisation ainsi que les paquets d’information qui transitent entre dif-
férents processus. Cela est aussi très utile lorsque l’on souhaite entrer dans le détail,
par contre cela est assez couteux en temps et nécessite une attention particulière afin
d’obtenir une bonne représentation. Dans notre étude nous sommes plus dans une
optique de sensibilisation, nos représentations apportent leurs valeurs à partir du
modèle abstrait, car nous sommes sur un concept de raisonnement sur des vues
d’organisation. Nous avons utilisé le modèle descriptif pour notre exemple. Il aurait
été gigantesque de représenter tous les processus, et cela n’aurait apporté qu’une
minuscule valeur ajouté à notre démonstration et à l’enrichissement de
l’organisation souhaitée. Par contre OSSAD prendrait toute sa valeur dans le cas où
il serait nécessaire de décrire en détails un ou plusieurs processus en vue de la mise
en œuvre d’une automatisation de travail (en anglais : Work Flow)
L’intérêt d’OSSAD pour cette étude était d’être un outil permettant d’appuyer la ré-
flexion que nous souhaitions apporter sur les différentes vue d’une organisation. A
la fin de cette étude, nous pouvons affirmer que cet outil a bien tenu son rôle
d’outil, et a permis de représenter les organisations de façon à pouvoir les découvrir
avec une vue globale permettant des comparaisons ; ce qui était recherché.

Conclusion
Cette étude a comme objectif d’apporter une réflexion sur le thème de
l’organisation. Elle s’appuie sur deux concepts clefs que sont la systémique (2.1.2
Démarche de résolution envisagée) et la représentation, et sur un découpage en trois
vues : le théorique, l’existant, et le souhaité. Enfin comme notre orientation est de
cibler l’aspect opérationnel de l’organisation, nous avons fondé la substance de
l’étude sur la notion de processus.
Réflexion : « Tu es assis près d'un ruisseau et tu as soif. Même si tu es idiot, tu sais
que l'eau va te désaltérer. C'est ça comprendre... » [Barjavel, 1976]. Cette étude a
comme objectif d’apporter des éléments de réflexion aidant à comprendre, selon un
point de vue personnel, une organisation opérationnelle.
La démonstration sous - jacente à cette réflexion est qu’un service, composé de res-
sources, nécessite d’être organisé, que cette organisation est relative à son environ-
nement, et qu’il est nécessaire de la comprendre avant de vouloir la changer.
Organisation : Notre réflexion s’est fondée sur un service d’études informatiques.
Afin de comprendre et d’améliorer ce service, nous avons fondé notre réflexion sur
la possibilité de décrire trois vues de son organisation. Nécessaire (aspect théori-
que), existante (aspect concret), souhaitée (aspect cible). « Il est sans comparaison
plus facile de faire ce qu'on est, que d'imiter ce qu'on n'est pas. » [Louis XIV, 1712].
Pour que notre réflexion soit mûrie il nous fallait mettre en place des éléments de
comparaison, de ce qui devrait être, ce qui est et ce que l’on souhaiterait voir être.
Systémique : Afin de rester en phase avec une compréhension globale de nos diffé-
rentes organisations, il fallait trouver une approche qui n’amène pas la réflexion
vers des analyses de la situation détaillées.
Une approche systémique permet de garder la capacité de recul pour comprendre
une vue d’ensemble. Si cette étude doit pouvoir servir à un lecteur qui aura pu mûrir
une réflexion personnelle, il est nécessaire que cela soit par des influences et non
des équations.
Représentation : Il nous fallait un outil afin de pouvoir construire les éléments
permettant au manager d’enrichir sa propre réflexion. Il fallait que cet outil soit
simple et facilement assimilable.
Nous avons donc décidé d’enrichir cette étude par des représentations visuelles. Et
afin que cela ne soit pas anarchique, il était nécessaire de trouver ou de créer un ou-
til visuel orienté organisation. Cet outil existe et s’appelle OSSAD.

Processus : Une organisation est vaste, et touche un grand nombre de sujets : le tra-
vail, les compétences, la productivité, l’affectif, la finance, les conflits, …. Il est ab-
solument nécessaire de cadrer la réflexion que nous voulions avoir.
Étant dans une logique de système d’information nous avons choisi de construire
nos organisations sur la notion de processus.
Ainsi, à la lecture de cette étude, il sera nécessaire de comprendre que
l’organisation dans laquelle nous évoluons n’est pas et ne doit pas être une fatalité,
une construction aléatoire, ni même l’exactitude de ce qui est souhaitée. Elle est
multiple, elle provient d’une nécessité, elle existe et idéalement est souhaitée sous
d’autres formes.
« Les détails font la perfection, et la perfection n'est pas un détail. » [deVinci,
1518].
A partir d’une organisation théorique évoluée et détaillé (AGATHONE) il apparait
des imperfections liées à une définition trop précise et à un travail trop délimité.
Imperfections qui peuvent être corrigées par un réajustement élargi des rôles des ac-
teurs, par le décloisonnement des processus, et la volonté de dynamiser les échanges
entre ces derniers.
L’ensemble de ces améliorations proviennent d’une réflexion assez générale, gar-
dant une logique systémique, en ayant une vue multiple de ce qui doit être, de ce qui
est et de ce que l’on souhaite, alors en connaissance de causes et d’effets.

Apport personnel
Cette thèse a été réalisée avec à la base les objectifs d’enrichir le mastère par une réflexion
personnel orientée sur l’organisation.
L’idée était de trouver un moyen pour représenter des organisations opérationnelles de façon
simple et rapide afin de pouvoir faire ressortir des axes d’amélioration. Il fallait donc absorber
puis fusionner un maximum de méthodes qui permettraient d’obtenir une sorte de méta mo-
dèle de représentation orienté organisation.
Au cours de la phase de recherche et mûrissement, j’ai pu découvrir OSSAD qui suivait exac-
tement ce principe. Poussant plus loin ma recherche, j’ai ainsi pu m’imprégner de la notion de
réflexion par système.
Cela a été la plus grande richesse que j’ai pu retirer de cette thèse. A un niveau de raisonne-
ment professionnel, déjà la notion de processus m’attirait fortement. La volonté de vouloir as-
socier une réflexion sur une organisation, un aspect processus, ainsi que cette sensibilisation à
la notion de système m’a permis d’avoir une véritable plus value dans mon mûrissement. Ain-
si, de fil en aiguille, j’ai pu avoir une vue sur ce monde qu’est la systémique et la notion de
pensée complexe.
Il se trouve qu’un raisonnement systémique ressemble beaucoup à un raisonnement processus
à la seule différence que la notion de processus est souvent associée à une vision très fonc-
tionnelle au niveau des systèmes d’information. La vision systémique déborde sur des domai-
nes tels que la psychologie, la gestion des conflits, la formation, la politique, ... C’est une
chose assez nouvelle pour le monde assez technique dans lequel j’évolue professionnellement.
Avoir un raisonnement systémique me paraît aujourd’hui quelque chose de primordial car il
permet de mieux comprendre des situations comportementales que nous pouvons facilement
rencontrer dans notre vie professionnelle de tous les jours.
Aujourd’hui, à l’issu de cette thèse, la triple satisfaction que je peux avoir concerne :
L’acquisition d’une vision plus large et plus riche de la notion d’organisation, de
processus et de raisonnement systémique,
La réalisation d’une étude qui a complétée ce que j’ai acquis au cours du mastère
Une réflexion en complete adéquation avec l’apport que m’a apporté cette thèse.
Effectivement, ce Mastère Spécialisé Management de Systèmes d’Information Réparties en
partenariat avec l’ESSEC et Telecom Paris constituée d’un volume de cours principalement
académique sur un grands nombre de sujets. Cette thèse a été le coté découverte et enrichis-
sement personnel. Les deux étant pédagogiquement et intellectuellement nécessaires.

Annexe

8.BIBLIOGRAPHIE
SOURCES PRIMAIRES
[AFNOR, 2000] AFNOR X50 - 176, Management des processus, AFNOR, 2000.
[Barjavel, 1976] René Barjavel, Si j'étais Dieu..., p. 69, Garnier, 1976
[C - Log, 2003] C - Log International – Tutorial sur OSSAD,
2003
[deVinci, 1518] Léonard de Vinci – Extrait des carnets, 1478 - 1518
[Harrington, 1987] Harrington, H. James. The Improvement Process : How Amer-
ica's Leading Companies Improve Quality. New York : McGraw
- Hill, 1987.
[Le Moigne, 1984] J. L. Le Moigne, La théorie du système général - théorie de la
modélisation, 2ème édition, Presses Universitaires de France,
1984.
[Le Moigne, 1990] J. L. Le Moigne, La modélisation des systèmes complexes, Du-
nod, Paris, 1990.
[Le Moigne, 1994] J. L. Le Moigne, Le Constructivisme, T1, p 122 ESF, édition,
1994
[Louis XIV, 1712] Louis XIV, Mémoires - 1712
[Morin, 1990] Edgar Morin, "Introduction à la Pensée Complexe" ESF Éditeur,
1990.
[ORYX, 2003] ORYX Choix d’outils de modélisation des processus, http :
//www. oryxsi.com/telechargement /Choix_outils_modelisation.
pdf, 2003.
[OSSAD, 1990] Philippe Dumas, Gilles Charbonnel, La méthode OSSAD –
Tome I « Principes » - Les éditions Organisation, 1990.
[Pillet, 2003] M. . Pillet, Six Sigma : comment l'appliquer, Editions d'Organi-
sation, Paris, 2003.
[VON BERTALANFFY, 1973] Ludwig Von Bertalanffy, Théorie générale des systèmes, Dunod,
Paris, p 153, 1973.
SOURCES SECONDAIRES
[Authier et al., 1992] M. Authier, P. Levy, Les arbres de connaissances, La Décou-
verte, Paris, 1992.
[Beckhard, 1975] R. Beckard, Le développement des organisations : stratégies et
modèles, Editions Dalloz, 1975.
[Belot, 1918] E. Belot, Principes généraux de l’organisation systématique des
machines et de l’industrie, La Technique Moderne, 1918.
[Büyükozkan, 1999] G. Büyükozkan, Une approche de formalisation d'un processus
de benchmarking coopératif, Thèse de l'INPG, 1999.
[Cattan et al., 2001] M. Cattan, N. Idrissi, P. Knockaert, Maîtriser les processus de
l’entreprise, Editions d’organisation, 2001.

[De Nanteuil, 1998] M. De Nanteuil, La participation des salariés aux changements
du travail, Ed. Liaisons, Paris, 1998.
[Desreumaux, 1998] A. Desreumaux, Théorie des organisations, Ed. Management et
Société, 1998.
[Durand, 1979] D. Durand, La systémique, Presses Universitaires de France, Bi-
bliographie 141, 1979.
[Eckes, 2001] G. Eckes, Objectif Six Sigma, Ed. Village Mondial, Paris, 2001.
[Herniaux et al., 2001] G. Herniaux, D. Noyé, Organiser et améliorer les processus, IN-
SEP Editions, 2001.
[ISO 7144, 1986] ISO 7144 « Présentation des thèses et documents assimilés »,
Genève : ISO, 10p, 1986.
[Jacob, 1994] G. Jacob, Le reengineering de l’entreprise, l'entreprise reconfi-
gurée, Hermès, Paris, 1994.
[Levan, 1999] S. K. Levan, Le Projet Workflow : Concepts et outils au service
des organisations, Eyrolles, Paris, 1999.
[Rouveyran, 1999] ROUVEYRAN, Jean - Claude, « Le guide de la thèse, le guide
du mémoire. Du projet à la soutenance », Paris : Maisonneuve et
Larose, 249 p, 1999.
[Vas, 2002] A. Vas, Les processus de changement organisationnel à
l’épreuve des faits : une approche multi - pragmatique, Actes de
la 11ème Conférence Internationale de l’AIMS, Paris, 2002.

9.GLOSSAIRE
Action corrective : Action visant à éliminer la cause d'une non - conformité ou d'une
autre situation indésirable détectée. (ISO 9000)
AFNOR : Association française de normalisation (AFNOR). L'AFNOR est l'organisme
français de normalisation membre de l'ISO.
AGATHONE : Méthodologie de description et de gestion de projet informatique créée
et utilisée par le Groupe France Telecom
Assurance qualité : Assurance qu'une entité (entreprise ou administration) a adopté des
principes d’organisations telles que la qualité des produits ou services rendus sera effec-
tive par la mise en œuvre de ces principes.
Audit : examen méthodique et indépendant qui vise à mettre en évidence objectivement
les écarts par rapport à un référentiel.
Bénéficiaire : Personne ou entité (client, usager, service demandeur) au profit de la-
quelle est menée une activité.
Cartographie : Synonyme de recensement. La cartographie d'un processus consiste à
recenser et à décrire l'ensemble des tâches ou activités composant un processus.
Consultant : Personne ou organisme ayant un rôle de conseil en matière d'organisation
d'entreprises ou d'administrations. Le consultant souvent rémunéré pour ses services
possède l'autorité d'un partenaire compétent, extérieur à l'entité demandeuse de ses ser-
vices.
Corrective : Ensemble de composants logiciel qui contiennent des corrections à des
problèmes recensés d’une application. Le passage de cette corrective sur l’application
concernée permet de supprimer les problèmes.
Correctif : (Voir corrective)
Diagramme d'Ishikawa : Voir « Diagramme causes/effets »
Diagramme causes/effets : Diagramme (appelé aussi diagramme d'Ishikawa) élaboré à
l'issue d'un groupe de travail. Ce diagramme ayant la forme d'une arête de poisson sert à
analyser le rapport existant entre un problème et ses causes classées en 5 grandes famil-
les (les "5 M").
Diagramme de Pareto : Graphique faisant apparaître les causes les plus importantes qui
sont à l'origine du plus grand nombre d'effets, sachant que 20% des causes sont à l'ori-
gine de 80% des conséquences. Le diagramme de Pareto est un diagramme en colonnes,
exposant et classant, par ordre décroissant d'importance, les causes ou problèmes. La
hauteur des colonnes est alors proportionnelle à l'importance de chaque cause.
Diagramme phase - entité : Tableau synthétique de description d'un processus où les
entités (services, bureaux) sont présentées horizontalement et les différentes phases du
processus verticalement.
Efficacité : niveau de réalisation des activités planifiées et d'obtention des résultats es-
comptés. (ISO 9000)
Efficience : rapport entre le résultat obtenu et les ressources utilisées. (ISO 9000)
FT : France Telecom

Gestion des difficultés : Recensement et analyse des difficultés survenues lors de la ré-
alisation d'une tâche ou d'une procédure. Cette analyse doit déboucher sur une améliora-
tion du mode opératoire de la tâche ou de la procédure.
Gestion des signalisations : Recensement et analyse des incidents survenues lors de
l’usage de briques su système d’information (application, poste de travail, . .). Cette ana-
lyse doit déboucher sur une résolution du problème directement ou indirectement par la
prise en compte dans une corrective.
FD X50 - 550 (fascicule de documentation AFNOR) : Fascicule de documentation
AFNOR publié en octobre 2001, relatif à la démarche qualité EN recherche. Formulation
de recommandations pour mettre en place une démarche qualité cohérente dans les acti-
vités de recherche ainsi que dans le fonctionnement des entités dans lesquelles elles sont
menées que ce soit en recherche fondamentale ou en recherche appliquée.
ISO : Organisme international de normalisation.
ISO 9001 : Norme d'exigence de la "famille" des normes ISO 9000, servant de référen-
tiel de certification (responsabilité de la direction, management des ressources, réalisa-
tion du produit, mesure, analyse et amélioration).
Norme : Une norme est un document écrit définissant les caractéristiques techniques
d'un produit ou d'un service. Elle est de nature volontaire (non obligatoire) et homolo-
guée par un organisme reconnu par un état.
Normes IS0 9000 : Ensemble de normes internationales relatives à la gestion de la qua-
lité dans les organisations (entreprises, administrations). Cet ensemble, appelé parfois
"normes de la famille ISO 9000" regroupe 4 normes : ISO 9000, ISO 9001, ISO 9004 et
ISO 19011.
MPP : Mise en Place Pilote : processus projet de la méthodologie AGATHONE
Procédure : Description normative définissant la réalisation d'une activité ou une tâche.
Processus : Ensemble d'activités, corrélées ou enchainées qui à partir de matières pre-
mières délivrent des produits finis. Cette définition industrielle peut être adaptée à l'acti-
vité des services telles que les administrations (exemple : la demande d'aide en entrée
génère une décision d'aide en sortie).
QQOQCPC : Initiales des questions à se poser lorsque l'on aborde un problème : Quoi,
qui, où, quand, comment, pourquoi, combien ? C'est aussi un outil d'audit Qualité qui
permet de vérifier l'existence d'exigences et d'en vérifier l'application au travers des pro-
cédures Qualité.
Référentiel : disposition de référence, servant de guide pour la construction et la vérifi-
cation d'un système. Ce sont des modèles d'exigences.
Système : ensemble d'éléments corrélés ou interactifs. (ISO 9000)
Système Qualité (ou système de management de la Qualité) : système de manage-
ment qui fixe une politique et des objectifs permettant d'orienter et de contrôler un orga-
nisme en matière de Qualité. (ISO 9000)

10. COMPLEMENT : LE DICTIONNAIRE OSSAD
La liste de tableaux qui suit présente les éléments de base du dictionnaire OSSAD
permettant d’avoir des représentations uniformes. Nous avons enrichi ces tableaux
avec quelques commentaires afin de bien comprendre certaines différences impor-
tantes pour une bonne représentation.
Icône et concept Règle de création
Type
de modèle
Exemple
Substantif, éventuellement suivi
d’un complément d’objet
En majuscule
Abstrait
GESTION DES INCI-
DENTS - ADMINISTRA-
TION DU SERVICE
En majuscule
Abstrait
GESTION DES INCI-
DENTS - ADMINISTRA-
TION DU SERVICE
Les processus à l’origine appelés « fonction » dans la méthode d’origine, peuvent
être :
Processus : à savoir un système (ou sous système) suffisamment significatif
pour qu’il soit valorisé, ceci quelques soient les interactions qu’il peut avoir
avec d’autres systèmes. L'analyse peut se faire par la décomposition du système
global en sous - systèmes observables et d'une complexité abordable. [Mélèse -
AMS]. Il est important que le processus soit parlant pour l’ensemble des acteurs
et que sa complexité soit de même niveau que les autres processus.
Processus externe : Considéré comme étant nécessaire que pour information,
il peut être représenté afin de valoriser ou d’aider à comprendre un modèle. Par
exemple, l’acte d’achat d’un client peut être représenté comme un processus
externe.
Sous - processus : est l’imbriquement d’un autre processus ou sous -
processus. De par la possibilité de la méthode d’effectuer des zooms dans les
différents modèles, il est possible donc d’avoir des processus composés d’autres
processus. Nous parlerons alors de Macro - processus. Dans le cas de
représentation complexe, il est tout de même déconseillé de descendre trop
profondément au niveau du zoom, tout simplement pour garder une lisibilité de
l’ensemble. La meilleure solution est alors de travailler par périmètre
fonctionnel.
Il est à noter que plus on entre en profondeur dans la description des processus (par
la représentation de sous - processus) et plus on se rapproche du modèle descriptif
pour qui le processus devient une procédure (déroulement d’opérations). OSSAD
utilise le terme d’activité pour définir les sous - processus d’un niveau très détaillé.

d’un qualificatif
En minuscule
Abstrait
incident – contrat de main-
tenance – ordre de lance-
ment
Afin d’échanger des informations, les processus sont reliés par des paquets.
Les paquets d’information véhiculent le résultant d’un processus pour
l’apporter en entrée à un autre processus. Au niveau du modèle abstrait, cela
reste au niveau d’information générique, il n’y a rien de représentable
physiquement à ce stade. Bien sûr, les paquets n’existent que s’ils sont reliés à
des processus.
Infinitif, éventuellement suivi
En majuscule
Descriptif
SUIVRE UN INCIDENT
– COMMUNIQUER
AUX UTILISATEURS
Infinitif, éventuellement suivi
En minuscule
Descriptif
mémoriser l’incident –
qualifier l’incident – re-
produire l’incident
L’opération est l’action minimum ayant un intérêt pour le projet et qui peut
être effectuée par une personne (ou une machine). L’opération doit être
présentée et décrite afin d’alimenter la réflexion de l’étude, il est juste
nécessaire de la présenter de façon très simple (le contraire risque de rendre
illisible la représentation). Il est à noter que dans la méthode OSSAD, il est
question de tâches, qui sont des composants de l’opération. Etant donné la
similarité entre ces deux concepts, nous considérons que la notion de Tâche
pourra être fusionnée avec celle d’Opération, ceci afin de gagner en lisibilité.
Néanmoins, lorsque nous parlerons d’opérations, implicitement cela
comprendra un nombre de tâches (représentées ou non).
La procédure est un ensemble d’opérations permettant de réaliser un
Processus. C’est l’aspect descriptif de ce processus et c’est de plus une
représentation dynamique car elle regroupe un ensemble d’opérations qui ont
une durée de vie propre et un état qui peut changer dans le temps.
Rôle
Première lettre en majuscule
Descriptif
Animateur – Décideur - Pi-
lote – Responsable des in-
cidents
Unité
Descriptif
Production – Qualification
– Marketing - s
Le rôle est une notion très importante lorsque l’on se trouve dans un contexte
d’Organisation. Son utilisation est un atout conséquent de la méthode OSSAD,
car complètement détaché des unités organisationnelles, et des acteurs.
Un rôle est un ensemble de tâches ou de responsabilités qui regroupées
peuvent former une activité facilement nommable. Par exemple le rôle
d’administrer des données, d’être garant du référencement des versions, de

piloter l’avancement de la qualification de composants logiciels, …. L’
important est que le rôle soit indépendant des personnes, car une personne peut
avoir plusieurs rôles, et un rôle peut être pris en compte par plusieurs
personnes. Pour mieux comprendre cette aspect, imaginez que en tant que
manager, vous deviez faire en sorte que votre équipe soit opérationnelle
24h/24h, il faut donc, lors de l’absence d’une personne, que son travail soit pris
en compte par les autres. Vous pouvez le faire unitairement, en doublant tout ce
qu’elle fait ou par répartition de ses rôles. Autre aspect intéressant d’usage des
rôles, tout simplement afin de dépassionner un projet touchant à l’organisation,
on ne parle pas de personnes mais de rôles lissant ainsi une implication qui
pourrait être trop personnelle pour certains acteurs.
L’unité, est un regroupement de rôles fondée soit sur une notion de
responsabilités soit sur des besoins de coordination et de contrôles. L’Unité
permet de représenter la structure formelle de l’organisation.
ET ou alors OU
En majuscule
Descriptif ET – OU
Les opérateurs ET et OU permettent d’enrichir le modèle descriptif par
l’usage de conditions. Le ET signifie il faut que les conditions entrantes soient
toutes respectées. Le OU permet une alternative, soit cette condition soit cette
autre condition permettront de réaliser l’opération.
Descriptif
Fiche incident – Demande
de moyens – Orde
d’installation.
Etat = A valider – En cours
– A tester
Descriptif
Produit livrable – Bandes
de sauvegarde – Dossier
collaborateur
La Ressource pour OSSAD est un couple : Ensemble d’information et son
support. A la différence du modèle abstrait qui parle du Paquet comme étant un
ensemble d’information générique, la ressource inclus en plus son moyen de
stockage. Exemple : Une disquette, un paquet logiciel, un email, ….
Le document est une ressource ayant la possibilité de porter un état particulier
et pouvant évoluer dans le temps. Cet objet a été rajouté par la société C - LOG
International à son logiciel afin d’enrichir la méthode par une meilleure
appréhension de l’évolution des Ressources.
Outil
Descriptif
Tableau de suivi – Logiciel
de références – Business
Object
L’outil physique et/ou technologique est utilisé pour accomplir une opération.
Il est utile de bénéficier de cet objet afin de rendre plus lisible et
compréhensible une représentation. L’outil rattaché à une opération peut, en
fonction du contexte être soit une ressource soit un outil (Exemple : une base de
donnée est un outil si nous sommes sur un projet orienté Système de gestion de
données, mais peut être une ressource si notre projet s’intéresse aux données
stockées).

11. COMPLEMENT : METHODES ET OUTILS COMPLE-
MENTAIRES
Ce chapitre présente des méthodes et outils qui peuvent être nécessaires à un enri-
chissement ou une poursuite de l’étude. Merise est une méthode qui a beaucoup
inspiré OSSAD, c’est d’une part pourquoi il m’était nécessaire de la présenter, et
d’autre part car sa richesse m’a permis de mieux appréhender la notion de segmen-
tation d’un système. Quand à Six Sigma, l’approche permettait d’apporter une forte
sensibilisation à la raison de l’étude (la notion de satisfaction, de qualité). UML a
surtout été un outil pour représenter les macros modèles d’OSSAD. Il est à noter
que certain diagrammes peuvent être assez semblables à ceux d’OSSAD, sans
néanmoins être liés entre eux.
11.1. Six Sigma
Six Sigma a été mis en place aux Etats - Unis, chez Motorola, dans les années 1980.
A l’origine cette méthode était fondée sur l’analyse statistique de processus afin de
faire apparaître la notion de variabilité et de défaut. Cette méthode a été mise en
place dans un univers industriel afin de réduire de façon drastique les coûts de pro-
duction et améliorer la disponibilité des machines. Après mûrissement auprès de
nombreuses entreprises qui l’ont utilisé, Six Sigma s’est enrichi afin de prendre en
compte l’aspect stratégique et managérial (notamment chez Général Electric).
Toute la philosophie de cette méthode est fondée sur la notion de variable. Ce qui
fait la qualité pour un utilisateur/client final, c’est le delta entre le temps où est at-
tendu le produit ou service et le temps ou ce dernier est réellement livré. Ce delta,
représenté par une variable est dépendant de la variabilité des processus qui permet
au produit ou service d’être livré. Il est donc nécessaire de chercher et corriger les
causes de la présence de cette variabilité. Cette recherche peut se faire avec un outil
classique qui est le QQOQCCP, le diagramme d’Ishikwa. 37
, ...
Figure. 69 - Six Sigma - Coubre de satisfaction avant
37
Voir le chapitre outil/QQOQCCP

Sur cette figure, on constate à travers des statistiques, que la livraison d’un produit
ou service s’étale dans le temps autour d’une cible (plage de tolérance). Des spécifi-
cations donnent un cadre à la période pendant laquelle le produit ou service doit être
livré. Ce qui se trouve en dehors de cette plage peut provoquer de l’insatisfaction.
Figure. 70 - Six Sigma - Courbe de satisfaction après
A l’issu d’un projet Six Sigma, la cible devrait ressembler à cette figure. On cons-
tate que la courbe de livraison s’est fortement réduite dans ses extrémités afin de
rester entre les spécifications.
La méthode Six Sigma est très orientée vers la qualité de service livré à l’utilisateur
final ou client. Elle est fondée sur la mise en place d’indicateurs de performance, de
la mise en place d’une organisation des compétences et responsabilités des person-
nes et d’une méthode de résolution de problème.
Cette méthode s’applique à travers la mise en place d’un projet formel et la démar-
che de résolution de problème peut être décomposée en huit étapes (Reconnaître,
Définir, Mesurer, Analyser, Améliorer, Contrôler, Standardiser, Intégrer), les cinq
étapes de base sont appelé DMAIC. L’objectif final étant de réduire les occurrences
d’insatisfaction de par la présence de nombreuses variations, l’ensemble de la ré-
flexion est posée sur la notion de mesure : mesurer ce qui existe, ce que l’on veut,
comment on le suivra, ….
L’intérêt de Six Sigma dans notre étude est d’apporter une réflexion sur la nécessité
d’améliorer une organisation en considérant la notion de variabilité. Sur un compor-
tement non anticipatif, la relativité des choses fait qu’un environnement de qualité
est dépendant d’un ressenti des composants de cette organisation : si, de par des ha-
bitudes, il apparaît une satisfaction d’usage alors peut - on dire pour autant que les
livrables de cette organisation donnent pleine satisfaction à leurs utilisateurs ? Peut -
on dire qu’ils vont donner pleine satisfaction à court terme ? La réponse peut se
trouver dans la lecture d’indicateurs (un des éléments contraignant d’ISO 9000
V2000), mais s’il n’existe pas d’indicateurs, ou que ces derniers ne sont pas adaptés
alors une des rares solutions possibles, en dehors de l’escalade sur un problème blo-
quant, est la prise de conscience. Six Sigma apporte des arguments relatifs à
l’importance d’indicateurs et des spécifications pour une satisfaction finale. Dans
notre étude, notre objectif étant de de comprendre une organisation en la considé-
rant sous trois vue. La connaissance d’une méthode comme Six Sigma (entre autre)
permet d’aider à comprendre qu’il peut être nécessaire d’améliorer un existant.

11.2. MERISE
Merise est une méthode française qui a été mis en place par le Ministère de
l’Industrie en 1979 (recherche de 1974 à 1978). L’objectif était de mettre en place
une méthode systémique d’intérêt national. Cette méthode devant intégrer
l’approche par les données et une démarche garantissant une rigueur et une facilité
d’application sur le terrain. Pour MERISE, la description des données est primor-
diale.
Cette méthode est très complète et s’appuie sur 4 niveaux d’abstraction regroupé en
deux systèmes :
- Le système d’information Organisationnel (SIO) avec les niveaux :
Conceptuel : exprime les choix de gestion (recherche d’éléments stables
indépendamment des moyens à mettre en œuvre, de leurs contraintes et de leur
organisation).
Organisationnel : exprime les choix d'organisation de ressources humaines et
matérielles.
- Le système d’information Informatique (SII) avec les niveaux :
Logique : exprime les choix de moyens et de ressources informatiques, en
faisant abstraction de leurs caractéristiques techniques précises (aspect
logiciels).
Physique : traduit les choix techniques et la prise en compte de leurs
spécificités (aspect techniques).
Pour chacun de ces 4 niveaux, Merise définit des modèles de représentation :
Fort
(Niveaudedétails)
faible
Figure. 71 - MERISE – Les modèles de données et de traitements

Chacun de ces modèles permet de reproduire un système donné à travers l’usage
d’une grammaire visuelle et de règles précises de représentation. MERISE ne
s’arrête pas à une modélisation, un ensemble de livrables, des cycles de décision,
une méthodologie d’application, … apporte tous les éléments permettant de réaliser
un projet complexe.
Merise, est aussi une méthode systémique, très orientée vers de la modélisation pour
réalisation d’application (incluant une forte notion de base de données). Cela signi-
fie que la méthode touche l’aspect organisation et ses processus en vue de réaliser
un développement, pas forcément pour modeler les rôles et activités de
l’organisation, elle ne semble pas offrir de concepts forts permettant de représenter
la dimension humaine, tandis que la méthode OSSAD propose un diagramme, dé-
nommé "réseau de relations entre rôles" permettant de représenter à la fois les Inte-
ractions personnelles dans une Relation et ceci au sein d'une Unité organisation-
nelle. Un autre aspect important concerne la richesse de Merise qui rend cette
méthode plutôt difficile à appréhender pour un projet où le maître mot est simplici-
té. OSSAD possède cette simplicité qui permet de rapidement communiquer avec
les acteurs du projet et de se concentrer sur la substance du projet plutôt que sur sa
méthode. Enfin pour finir il est intéressant de prendre en compte que OSSAD s’est
beaucoup inspiré de MERISE, entres autres. .
11.3. UML
UML (Unified Modeling Language) est un langage de modélisation orienté objet
pour représenter, spécifier, construire et documenter des constituants logiciels. Il a
été développé et standardisé par Rational Software Corporation et Object Manage-
ment Group (OMG) à partir de 1997. L'OMG est un organisme professionnel re-
groupant à la fois des fournisseurs de solutions informatiques et des utilisateurs. Il
s'est donné (entre autres) comme mission de promouvoir et de faire évoluer UML.
Ce langage de modélisation est à la base très orienté pour le développement, ceci en
couvrant les principales étapes du cycle de vie d’une application (Analyse, concep-
tion et implémentation) par l’usage de trois familles de vue et de neuf types de dia-
grammes :
Les 3 familles de vues :
La vue fonctionnelle : les services offerts à l’utilisateur,
Le diagramme de cas d’utilisation : représente les comportements d’un
système du point de vue de l’utilisateur,
Le diagramme d’activités : décrit les flux entre activités au sein d’un
système. Cela permet de représenter le déroulement d’une procédure ou d’une
fonction,
Le diagramme de séquence : représente les objets et leurs interactions selon
une ligne temporelle,

La vue statique : La structure des données et des objets,
Le diagramme de classes : représente la structure statique d’un système sous
la forme de classes et de relations et ne contient pas d’informations temporelles.
Une classe est une représentation abstraite d’un ensemble d’éléments similaires,
Le diagramme d’objets : représente les objets et leurs relations, un objet
étant un élément particulier d’une classe,
Le diagramme de composants : montre l’implémentation physique d’un
système, en termes de composants logiciels,
Le diagramme de déploiement : décrit la configuration des éléments de
traitement à l’exécution et les composants qui leur sont rattachés,
La vue dynamique : Les flux d’information et les interrelations des données et
objets,
Le diagramme de collaboration : représente les objets, leurs liens et leurs
interactions de manière structurelle,
Le diagramme de transition d’états : exprime le comportement dynamique
d’un objet en termes d’états, d’activités, de transitions et d’événements.
Les diagrammes qui pourraient être utilisés pour représenter une organisation se-
raient ceux de la famille fonctionnelle enrichie du diagramme de collaboration.
Dans le cadre de notre étude, nous avons utilisé les diagrammes de classe qui nous
ont permis de documenter, entre autres, les vues OSSAD. C’est pourquoi nous
avons décrit les objets et leurs représentations utilisées dans le cadre d’un dia-
gramme de classes UML.
CLASSE :
Description générique ayant des caractéristiques propres pouvant représenter des
objets. Dans le cadre de notre étude nous utiliserons des objets de méta - modèle. Il
est à noter qu’une classe comporte des objets (occurrence d’une classe ayant un état
et un comportement), des attributs (type d’information qui constitue une classe), et
d’opérations (élément représentant un comportement (calculs, actions, . .), se trouvant dans
une classe). Ces éléments ne seront pas utilisés dans le cadre de cette étude.
Exemple : Les classes « processus «
Figure. 72 - UML – Une Classe
ASSOCIATION :
Une association est une relation continue et durable entre deux classes
Exemple : L’association « gère et utilise » entre « procédure » et « Ressources »
RessourcesProcédure
-Génère
0..*
-Provient
0..*
Figure. 73 - UML – Une association

MULTIPLICITE :
Figure aux 2 extrémités d’une relation et indique le nombre d’objets pouvant parti-
ciper à la relation dans chacun des sens (Classe 1 vers classe 2, et vice versa)
Exemple : « Procédure » génère aucune ou une infinité de « Ressources »
« Ressources » provient d’aucune ou d’une infinité de « procédures »
Figure. 74 - UML – Une multiplicité
AGREGATION :
Une agrégation est une relation (ASSOCIATION) particulière, unilatérale, de
contenance
Exemple : La classe « Procédure » est une agrégation de la classe « Tâche »
Figure. 75 - UML – Une Agrégation
La forte richesse d’UML nécessite une appréhension de tous les diagrammes et du
dictionnaire associé afin de maîtriser convenablement le langage. Le mélange entre
la notion de rôle et d’acteur est un manque dans la cartographie des processus
d’organisation. De plus UML ne permet pas de représenter la nature des informa-
tions qui circulent entre acteurs (données, documents, paroles, …). La notion de
système et de sous - système imbriqué est difficilement représentable. Cette mé-
thode est meilleure en définition de besoin orienté application que orienté organisa-
tion. Elle a un plus sur OSSAD qui concerne le diagramme de séquence d’UML
contenant la notion de chronologie.
11.4. Ishikawa.
Du nom de son auteur (professeur Ishikawa, Président de l’Institut de Musashi), ce
diagramme en forme d’arrête de poisson, permet de décrire des causes pour un effet
donné.
Sa représentation se fait à l’aide d’une flèche principale horizontale qui pointe vers
un résultat cible (la dorsale), elle représente l’Effet, le résultat recherché. D’autres
flèches pointent alors sur cette dorsale (les arrêtes), et sont les Causes. Ces arrêtes
peuvent être subdivisées autant de fois qu’il est nécessaire.
Afin d’aider au regroupement des causes la méthode conseille d’utiliser ce qui est
appelé aux États - Unis : les 5M :

Men : Les hommes
Matérial : La matière, ce qui est consommable
Méthods : La méthode, ce qui est une façon de faire
Milieu : L’environnement
Machines : Les machines, ce qui nécessite un investissement
La meilleure façon d’utiliser cet outil est de commencer par un « remue méninges
». Qui a comme objet de récupérer un maximum d’information, sans aucune
contrainte et sur un sujet donné.
Figure. 76 – Le modèle de diagramme de causes à effet
Ce diagramme de cause à effet est très judicieux car il permet de représenter un «
écoulement » des causes apportant un effet. L’intérêt premier étant d’organiser un
ensemble d’information et surtout de les lier entre elles, ce qui est souvent difficile
sans formalisation.
Ishikawa sera utilisé dans le cadre de notre étude de deux façons :
Pour déterminer une organisation cible sur une partie de nos représentations.
L’idée sera de partir d’un élément qui paraît perfectible pour remonter aux causes
qui pourraient être objet d’amélioration. Dans ce cas nous n’utiliserons pas les 5
M, mais d’autres familles, en fonction de notre recherche.
Pour représenter l’ensemble des informations (ordres, communication) ou objets
(mail, livrables, …) permettant d’activer une action. C’est en fait la description
des entrées d’un processus. Effectivement au cours de la MPP, un grand nombre
d’informations transite par un grand nombre de média. Ces informations, pour la
plupart ne sont pas formalisées et nécessitent d’être « mises à plat » afin d’être
maîtrisés.

11.5. La Loi de Pareto
« L'économiste italien Vilfredo Frédérico Damaso surnommé par ses étudiants :
"Marquis de Pareto" observa au début du XXème Siècle que 20% de la population
italienne possédait 80% des richesses nationale d'où le nom de la loi 80 - 20 ou 20 -
80. » [Wikipédia].
Aujourd’hui, plus communément, c'est un graphique (histogramme) qui représente
les données quantitatives relatives à un même sujet. Il est fondé sur le principe que
20 % des facteurs expliquent 80 % des résultats. En étant un moyen simple pour
classer des phénomènes par ordre d’importance, il permet de se concentrer sur les
causes majeures d’un fait (problème, résultats, . .).
La démarche consiste à : établir une liste de données (nommées : les facteurs), les
quantifier et les regrouper, faire un pourcentage pour chacune de ces valeurs, et
après les avoir triées, les représenter sur un graphique.
Exemple : 80% du chiffre d’affaire est généré par 20% des produits d’une entre-
prise.
Figure. 77 – Pareto ou le 80/20
Dans le tableau (Figure. 40 – Pareto ou le 80/20) on remarque que 80% des occur-
rences proviennent de 20% des éléments mesurés. Bien sûr les valeurs peuvent être

différentes du 80 ou du 20, l’important étant de se concentrer sur un périmètre ré-
duit mais très significatif.
La loi de Pareto (des 80/20) est à considérer comme étant une réflexion sur le fait
qu’une minorité de faits produit une majorité de résultats. En générale, la démons-
tration s’appuie sur des relevés numéraires permettant de faire des graphiques ex-
ploitables. Dans notre étude, nous utiliserons cette loi comme filtre qui nous per-
mettra de restreindre notre réflexion qu’aux actions majeures, dans un premier
temps. Par la suite un grand nombre de cas particuliers pourront ressortir (les 80%
restant), nous essaierons d’en lister quelques uns afin de démontrer que peut être il
serait nécessaire de gérer ces cas particuliers à part. Nous n’utiliserons donc pas
l’aspect numérique qui est souvent constaté dans l’usage de cet outil, mais plutôt la
notion des 80/20, notion assez subjective mais qui permettra, au cours d’entretiens,
d’aider à ne pas se focaliser sur des cas particuliers.

12. COMPLEMENT : RECUEIL DES COMPOSANTS DE LA MPP
L’ensemble de cette partie regroupe les informations nécessaires à la construction
des représentations. Ces informations, regroupées par familles et par type provien-
nent en premier lieu de la méthodologie AGATHONE, puis d’entretiens avec les
acteurs de la MPP, ainsi que de l’expérience acquise sur le poste de pilote MPP. El-
les ont été ensuite enrichies dans le cadre d’un transfert de compétence.
Les regroupements ont été fait de façon à être les plus exploitables par les graphi-
ques de représentation, ceci en faisant ressortir le plus possible :
Les rôles
Les activités
Les livrables
Les sources de regroupement d’information (réunions, outils, . .)
12.1. Les Pôles autour de Cristal
Nous appelons pôle un regroupement de rôles servant des objectifs communs au
sein d’une unité organisationnelle. Il peut être composé au minimum d’un rôle.
(Figure. 27 - OSSAD – Méta Modèle descriptif de rôles (UML))
Les pôles majeurs liés à la MPP sont :
Les utilisateurs de Cristal :
Les Directions Régionale
La MOE CRISTAL :
La qualification,
le référentiel,
les études,
la MPP.
La Direction de service :
Le support niveau 3.
La Tierce Maintenance Applicative CRISTAL :
La réalisation.
La production informatique :
L’exploitation,
l’intégration,
l’installation.
La chaîne de soutien :
Le support niveau 2,
le support niveau 1.
Autres :
La généralisation,
le support métier,
la Maîtrise d’ouvrage
la qualité (les tests et mesures).

12.2. Le Pôle MPP
12.2.1. Les livrables
Scénario de MPP
Plan de travail commun
Planning de MPP
Reporting MPP (CR réunions de suivi)
Annuaire de la MPP
Dossier de Mise en Place Pilote
Fil conducteur et compte rendu de réunion de GoNoGo
MPP Mètre
Contrat de Mise en Place Pilote
Bilan de MPP
Tableau de suivi des signalisations
Enquête de satisfaction
Présentation de la version aux contributeurs
Présentation de la version à la DR1
Fiches de test
Fiches croisière Lot Qs
Fiches croisière Évolution
Exercices sur les évolutions (cf présentation contributeurs)
Documentation utilisateur Lot QS (peut être la doc de SOPRA)
Fiche de demande d’ouverture de la file MPP (P10)
Scénario de retour arrière
Tableau des temps de réponse
Liens vers les modes opératoires métier
12.2.2. Les outils
WebDoc
Excel 26D
Sonde Vantage
OGA (PVCS)
Genesis
12.2.3. Les réunions
Réunion de lancement signalisation

Réunion de lancement installation
Réunion de lancement MOE
Réunion de lancement Présentation de la version à la DR
Réunion de lancement Présentation de la version aux Contributeurs
Réunion de tests sur la version pour contributeurs et utilisateurs
Réunion de suivi des signalisations (Récurrente)
Réunion de suivi de la MPP avec la DR (Récurrente)
Réunion de validation de l’Ordre d’Installation (Récurrente)
Réunion de suivi de l’installation (Récurrente)
Réunion de présentation des fiches croisière
Réunion de présentation des fiches de tests
Réunion de présentation de l’organisation MPP
12.2.4. Les rôles
Préparateur MPP
Recensement des pré - requis - post - requis
Recensement des évolutions
Recensement des fiches correctives (Lot QS+…)
Montée en compétence sur les évolutions de la version
Montée en compétence sur les correctifs (ou correctives) de la version
Choix des sites Pilote
Organisateur de la MPP
Définir le planning de la MPP
Définir le séquencement des actions de MPP
Constituer l’annuaire de la MPP
Réaliser le contrat
Réaliser le dossier de MPP
Préparer le GoNoGo
Préparer le Bilan
Définition de l’organisation de suivi des évènements
Animateur
Présentation « rapide » de la version aux contributeurs (large)
Présentation de la version aux contributeurs + utilisateurs
Création du document de présentation global
Création des documents d’exercices sur la version (DoFo)
Organisation de la journée
Sélection et invitation des invités (cf MOA)
Réservations, aménagement, impression, . .
Déroulement de la journée
Réalisation d’une synthèse
Présentation de la version à la DR
Adaptation du document de présentation global
Présentation des fiches de croisière à la DR
Adaptation du document de présentation (évolution)
Qualification du lot QS pour lisibilité et reproduction (lot QS)
Présentation des fiches de contrôle à la DR

Définition des fiches de test en fonction de la version
Présentation de l’organisation de suivi des évènements
Pilote
Demande de mise en place des sondes
Mettre à jour le référentiel des documents
Réaliser le reporting du suivi de la MPP
Installation
Détermination du périmètre à embarquer (référencement)
Constitution de l’Ordre d’Installation
Validation de l’Ordre d’Installation
Planning de mise en production MPP
Livraison des PL
Répétition d’installation
Définition du planning
Constitution des paquets (Kim)
Tests d’installation
Installation
Création du plan de mobilisation
Pré et Post requis
Lancer une demande de mesure des temps de réponses
Autres actions dépendantes de la version
Des événements
Demande d’ouverture de file MPP (P10)
Suivre l’ensemble des évènements MPP
Signalisation, interrogations, évolutions
Passage en revue, récurrent, des évènements
Mise à jour du tableau de suivi des événements
12.3. Les Pôles contributeurs directs
12.3.1. La qualification
12.3.1.1. Les rôles
Pilote de qualification
Défini le plan de qualification
Suit la réalisation du plan de qualification
Gestionnaire des environnements techniques
Administrer les environnements (plate - formes)
Responsable des tests
Qualifieur du SI
Rédige des dossiers de tests
Fait les test
Rédige des fiches de bug
Expert fonctionnel
Expert technique

12.3.1.2. Les outils
26C : Cartographie du SI en développement
26D : Cartographie du SI de référence
Référentiel JE : Base contenant les cas de tests (description du cas, mode
opératoire). Une copie de ce référentiel sera transmise à DFO à chaque évolution
majeure (prise en compte d’une nouvelle fonctionnalité, nouvelle interface) afin
de pouvoir réaliser les TI
Gestion de Campagnes : Association d’un cas de test (JE) à une sous - campagne
– Suivi de l’avancement d’une campagne et de ses sous - campagnes
FLEMIX : Lecture simplifiée des fiches 02Z et SNAT comparaison avec les
contrats d’interface rattachés
PVCS TRACKER : Gestion et suivi des fiches d’anomalies (en client léger ou
client lourd)
AppCreerCommande : invocation du service de création de commande à partir
d’un message LPA de création de commande codé dans un fichier texte,
récupération dans un fichier texte du retour de la méthode (qui mentionne le statut
SI de la commande). AppCreerCommande donne accessoirement la possibilité
d’appeler le service de création de commande avec des commandes LIA. Cette
possibilité est utilisée lors des phases de tests unitaires avec des commandes LIA.
InterPublication : interception des évènements opérationnels publiés par
SERVICES CRISTAL, et consignation de ces derniers dans un fichiers texte.
OrdoSCris : lancement manuel de la procédure de relance des commande en
attente, et de la procédure de publication des évènements opérationnels
(nécessaire en l’absence d’ordonnancement).
IHMTRAD : atelier de mise au point et de tests unitaires des règles de traduction
LPA – LIA.
12.3.2. Le référentiel
12.3.2.1. Les rôles et activités associées :
Gestionnaire des installations, versions et correctives
Vérifier les PL et la documentations associées
Suivre les patchs du référentiel
Gestionnaire de logiciel (Gestion de configuration.)
Référencer des PL Cristal
Référencer des versions catalogue
Référencer des versions Tables de références
Référencer des versions Règles de traduction
Contrôler les livrables à leurs réceptions
Producteur du catalogue
1 Réception fiche d’ordre (de Mise à jour, de création, de suppression)
2 Qualification de la fiche
3 Mise à jour du modèle de catalogue
4 Vérification des erreurs de saisies

12.3.2.2. Les livrables
(DGP/FAC)
Fiche OSI :
Complément fiche OSI :
CR Hebdo FCF :
Soutien
Fiche de signalisation :
Autre
Fiches produit (OCISI) :
PMP Catalogue :
MOP (Version SI) :
Planning d’installation :
Flash info :
Extrait du catalogue Cristal (OCISI) :
Catalogue Cristal Packagé :
PV de recette d’industrialisation technique :
Bilan de MPP :
12.3.2.3. Les outils
(A) Forms Oracle (Mise à jour du modèle de catalogue)
(B) Extraction (Création du Produit Livrable Data
12.3.3. Les études
12.3.3.1. Les rôles et activités associées :
Expert fonctionnel
Concepteur
Réceptionne une demande MOA/étude
Qualifie la demande de la MOA/étude = valide l’expression du besoin MOA
Propose une/des solutions (s)
Spécifie le besoin fonctionnel
Valide les spécifications détaillées
« Marchande » le chiffrage de l’évolution
Met à jour la documentation fonctionnelle
Valide les dossiers de tests de la qualification
Propose des études de faisabilité : nouveauté lié aux restrictions de budget =
prise en compte de la demande à SI constant ou 0 euro
Propose des solutions à certaines fiches de bug jugées comme évolution et non
bug
Présentation des évolutions au :
Soutien N2/N3
MPP
qualification

Support Études
Aide à la MPP : répondre aux questions
Aide à la MOA : idem
12.3.3.2. Les livrables
Accusé de réception de la demande :
Dossier de qualification de la demande :
Dossiers d ’étude de l ’existant :
Dossier d ’architecture fonctionnelle transverse :
Dossier d ’étude des scénarios :
Glossaire :
Synthèse d ’étude :
Dossier de synthèse des modifications apportées au SI
DAE (Dossier d’architecture) ? :
DM1 :
DM2 :
CR de revue du DM2 :
CI/DI :
DM3 :
DFG :
CR de revue du DFG :
Demande d’avis d’urbanisme
12.4. Les Pôles contributeurs indirects
12.4.1. Les rôles
Accompagnateur métier (SPOT)
La MOA
Chef de Projet Version
Faire le Macro Planning du projet
Chef de projet DR
Packageur logiciel (Kimmeur) - Intégration
Pilote d’exploitabilité – Exploitation
Réalisateur développeur (Sopra)
Réalisateur développeur (Ordo_DR)

12.4.2. Les livrables
Ordre d’installation (en entrée)
AppliOP
Documentation d’exploitation

13. COMPLEMENT : DOCUMENTATION DES ACTIVITES
AGATHONE MPP
Ces informations ont été reprise pour la plupart des fiches explicatives de la métho-
dologie AGATHONE, et adaptée afin de correspondre à l’environnement CRIS-
TAL. L’ensemble des descriptifs suit les représentations d’OSSAD (description in-
sérées dans OSSAD pour décrire les processus et activitées).
13.1. Descriptif des processus AGATHONE
13.1.1. (A) MO_ORGANISATION, AVANCEMENT ET SUIVI
Processus non décomposés Description
(A) CONSTITUER
L EQUIPE DE LA MPP
Composer une équipe pluridisciplinaire en correspondance avec les besoins du projet
. . Définir les compétences requises pour les différentes activités de la MPP :
. . les impacts métiers. . l'installation
. . les impacts clients. . l'exploitation
. . la communication. . le suivi de la MPP, le soutien
. . la formation. . les enquêtes utilisateurs
. . la gestion de la documentation
. . la gestion des signalisations et des livraisons
. .
. . Identifier les contributeurs de la MPP (en définissant la mission de chacun) et de-
mander la
nomination d un responsable (ou d un correspondant) par entité
. . Constituer l équipe de la MPP avec les ressources définies et nommer un leader
applicatif
ayant des compétences fonctionnelles et techniques si besoin
(A) CONSTITUER L'EQUIPE
LOCALE DE LA MPP
Avoir un correspondant du projet dans chaque entité impactée par la MPP
. . Faire construire au chef de projet site pilote l'équipe locale de la MPP en s'ap-
puyant sur :
. . les compétences de chacun
. . l'organisation nécessaire à la MPP
. . Mettre à jour le plan de mobilisation
(A) CONSTITUER LE REFEREN-
TIEL
ET CENTRALISER LES DOCU-
MENTS
Préparer la documentation pour sa diffusion
. . En attente de l organisation cible :
. . répertorier la documentation auprès de chaque projet
. . lorsque tous les documents sont répertoriés, alimenter le tableau » référentiel
documentaire » du projet
. . effectuer le ciblage par profil, en indiquant (dans le tableau » référentiel
documentaire » ) si le document est diffusé pour information ou pour action
. . centraliser la documentation pour la duplication et la diffusion selon les modalités
de
la procédure de gestion de la documentation
(A) CONSTITUER LES LOTS DO-
CUMENTAIRES,
DIFFUSER ET POINTER LEUR RE-
CEPTION
S assurer de la diffusion et de la prise en compte de la documentation
. . Vérifier que le format des documents centralisés correspond à l'attendu
. . Dupliquer la documentation (CDrom ou papier), ou assurer la mise en ligne des
documents
. . Constituer les lots à diffuser en s'appuyant sur le référentiel documentaire et sur
l'annuaire des
destinataires
. . Envoyer au chef de projet site pilote le référentiel documentaire, une lettre d'ac-
compagnement
décrivant le contenu des lots, et, si envoi papier, un accusé réception à retourner
. . Si envoi papier,
. . prévenir les destinataires de la diffusion des documents en envoyant une fiche »
avis
de diffusion » par fax ou mail 48h avant l envoi des lots
. . S'assurer que tous les acteurs ont bien reçu l'ensemble de la documentation (re-
tour des
accusé réception)
. . Faire un compte - rendu au Pilote et au MOE généralisation
(A) DEFINIR L ORGANISATION
POUR LA
DIFFUSION DES DOCUMENTS
Avoir un circuit de diffusion des documents fiable auprès des destinataires
. . Etablir les modalités de diffusion de la documentation adaptées au support défini
(papier ou en

ligne)
. . Identifier les acteurs pour :
. . la duplication (support papier ou CDrom), ou la mise en ligne des documents
. . la diffusion : si une mise en ligne est prévue prévoir les outils et les compétences
nécessaires
. . la réception par les destinataires finaux (rédiger l'annuaire des destinataires)
. . Pour chaque flux, arrêter les dates de livraisons et communiquer le rétro planning
aux équipes
projet
(A) DEFINIR POUR CHAQUE
ETAPE DE LA
MPP LES RESSOURCES A MOBI-
LISER
Prévoir les moyens nécessaires à la MPP
. . Identifier les acteurs locaux, leurs tâches (en terme de charge)
. . Le chef de projet site pilote
. . Les correspondants locaux
. . Le soutien niveau 1 (soutien applicatif, soutien technique)
. . Le responsable qualité des données
... . .
. . Définir les conditions de fonctionnement, les périodes de sollicitation et les enga-
gements pour
chacune des phases de la MPP (préparation, installation, suivi, bilan)
. . Décrire pour chaque acteur local et national, les périodes et les charges par tâche
dans le plan
de mobilisation
(A) DESIGNER UN CHEF
DE PROJET SITE PILOTE
Avoir la contribution d un responsable site qui mobilise les acteurs et coordonne les
actions de
préparation et de suivi
. . Faire identifier un responsable au niveau de chaque site pilote (chef de projet site
pilote) qui
soit le point d entrée unique pour le site (même pour les établissements qui ne sont
pas sous la
responsabilité de l entité signataire du contrat)
. . Faire nommer et établir la lettre de mission du chef de projet site pilote
. . Intégrer le chef de projet site pilote à l'équipe de la MPP
(A) ELABORER LE PLAN DE TRA-
VAIL COMMUN
Identifier l ensemble des tâches et les acteurs de la MPP
. . A partir du Plan de Travail Commun type, lister les tâches nécessaires à la MPP
. . Ajouter si nécessaire des tâches spécifiques au projet
. . Définir pour chaque tâche les dates, le responsable et les acteurs
. . Alimenter le Plan de Travail Commun (PTC) pour suivre l avancement de la prépa-
ration de la
MPP
(A) ELABORER LES
PRE - REQUIS DE LA MPP
Définir les conditions de Go/No Go MPP
. . Etablir la liste des pré - requis techniques amont à la MPP :
. . issus de l'intégration (PV de recette d'intégration, liste des anomalies résiduelles,
...)
. . issus des normes du déployeur technique et du pilote de l exploitabilité (recette
d'exploitabilité, métrologie, cahier de sécurité, . .)
. . remettre à jour cette liste en tenant compte de la recette d'exploitabilité provisoire
(feux rouges, feux oranges, feux verts)
. . Etablir la liste des pré - requis (organisationnels, techniques, métiers et applicatifs)
à vérifier sur
le site pilote, distinguer :
. . les pré - requis nécessaires pour le déploiement : les intégrer au phasage type
. . les pré - requis spécifiques à la MPP (outil de gestion des signalisations, ...)
. . Constituer la liste des pré - requis de Go/NoGo d'après la synthèse de ces listes
. . Vérifier que pour chaque pré - requis sont définis :
. . les dates de réalisation
. . le responsable et les acteurs
(A) FINALISER ET DIFFUSER
LE DOSSIER DE BILAN
Formaliser les éléments du bilan dans un document
. . Finaliser le dossier de bilan de la MPP qui comprendra les points suivants :
. . rappel des objectifs de la MPP
. . rappel du contexte de la MPP
. . évaluation des aspects techniques (installation, production)
. . évaluation des aspects fonctionnels
. . évaluation des conditions de la MPP
. . évaluation de l'appropriation des évolutions et des changements métiers par les
utilisateurs
. . bilan général du projet
. . annexes (référentiel logiciel, référentiel documentaire, synthèse des fiches de tâ-
ches de
contrôle, signalisations non closes, tableaux récapitulatifs des signalisations, courbes
des signalisations, bilans utilisateurs, bilan installation et production, CR de la réunion
de bilan)
. . Diffuser le dossier de bilan de la MPP
(A) NOMMER UN PILOTE ET
ETABLIR LE FONCTIONNEMENT
DE L EQUIPE
contributeurs
. . Nommer le pilote de la MPP
. . Etablir le planning des différentes phases de la MPP à partir des dates clés déter-
minées lors du
J0 (période de début, de fin, de généralisation) en identifiant les tâches principales et

incontournables
. . Réévaluer les charges et les ressources à partir de l évaluation faite pour le J0
. . Fixer les modalités de reporting interne à l équipe projet
(A) PARTICIPER A LA
PREPARATION DU J2
Mettre en relief les éléments tangibles de la MPP permettant d asseoir la décision du
J2
. . Faire la synthèse des bilans fonctionnels, métiers, techniques et financiers des si-
tes
. . Construire avec le MOA le plan d actions éventuel issu du bilan de MPP et nommer
les
acteurs chargés de réaliser les actions
(A) PREPARER LA REUNION DE
GO - NOGO
Evaluer la préparation de la MPP et la qualité du logiciel pour permettre de prendre
une décision
argumentée sur le Go/NoGo
. . Préparer la réunion de Go/NoGo en s'appuyant sur les plans d'actions fixés suite à
l'analyse des
résultats de la revue de qualité
. . Faire une revue de qualité sur l'état de la MPP
. . passer le MPPmètre
. . présenter le diagramme de Kiviat au chef de Projet SI
. . analyser les résultats et lancer des plans d'actions
(A) REDIGER ET FAIRE
SIGNER LE CONTRAT DE MPP
Obtenir l engagement des représentants locaux et nationaux de la MPP
. . Identifier les signataires du contrat de MPP
. . Rédiger le contrat de MPP (pas plus de 7 pages) :
. . Définir le cadre de fonctionnement de la MPP sur le site pilote
. . décrire : . . les objectifs et les enjeux du projet. . l organisation de la MPP
. . les dates clés du projet. . les acteurs concernés
. . faire référence au dossier de la MPP
. . Faire signer le contrat par le décideur local (exemple le Directeur Régional), par le
MOA
principal, par le responsable du centre de production et par :
. . Soit le directeur du SN MOE SI (si c'est un projet transverse sur plusieurs direc-
tions
opérationnelles)
. . soit le directeur de la Direction opérationnelle (ou le directeur de projet)
(A) REMETTRE A NIVEAU
LE SITE PILOTE
S assurer de la remise à niveau le site pilote pour que celui - ci soit conforme à tout
site mis en
place lors de la phase de généralisation
. . remettre à niveau la documentation utilisateur
. . donner les supports de formation émis pour la généralisation
. .
(A) REUNION DE
GO - NOGO DE LA MPP
Suite à l examen des pré requis, évaluer l'état de la préparation de la MPP et prendre
la décision
stratégique de Go/NoGo après consultation des décideurs nationaux, des représen-
tants des entités
contributrices, des décideurs des entités du site pilote.
. . Prendre la décision d'installer sur le site pilote à partir :
. . du bilan des tests fonctionnels
. . du rapport des résultats de la qualification ou des campagnes d'intégration de la
métrologie et de la volumétrie, de la recette d'exploitabilité
. . de l'existence de la check - list référentiel de la documentation
. . de la préparation et du basculement du site
(A) REUNIONS DE SUIVI D'AVAN-
CEMENT
DE LA PREPARATION DE LA MPP
S assurer de l avancement de toutes les tâches de préparation de MPP
. . Prévoir des réunions d avancement avec l équipe de la MPP et les contributeurs
afin de faire le
point (utiliser le Plan de Travail Commun)
. . Suivre la production des livrables
. . Suivre les vérifications des pré - requis
. . Tenir à jour le planning de l équipe
. . Alerter le chef de projet SI en cas de difficulté
. . Faire un reporting régulier au chef de projet SI
(A) SUIVRE LE DEROULEMENT DU
SITE
PILOTE ET ASSURER LE SOUTIEN
Organiser le suivi et le soutien afin de garantir un accompagnement efficace du site et
une
évaluation exhaustive de la qualité des logiciels, des impacts métiers, clients, utilisa-
teurs,
. . Assister le site au démarrage de l'exploitation
. . Animer des réunions périodiques de suivi pour faire l'évaluation de la MPP au fil de
l eau :
. . déroulement de l'exploitation
. . avancement des contrôles de croisière
. . point sur les signalisations
. . difficultés rencontrées
. . actions à venir et à entreprendre (campagne de mesures, installation d'un correctif)
. . Prévoir des ponts téléphoniques pour la résolution de problèmes spécifiques (hors
réunion de
suivi)
. . Rédiger le compte rendu de chaque réunion de suivi et le diffuser rapidement
. . Déclencher si nécessaire des réunions en comité de crise

13.1.2. (A) MO_QUALIFICATION MOE SI
(A) CLOTURER LES
SIGNALISATIONS
S assurer que toutes les signalisations émises ont reçu réponse pour se mettre en si-
tuation
de soutien de croisière
. . Produire une synthèse quantitative et qualitative de l'ensemble des signalisations
relatives au projet de manière globale et les répartir selon :
. . leur origine
. . leur type (incidents, questions, ...)
. . leur criticité (bloquant, gênant, mineur)
. . les réponses apportées, les palliatifs
. . Informer le MOE généralisation, le soutien niveau 2, les formateurs, le MOE mé-
tiers
et les sites pilotes sur les signalisations n'ayant pas fait l'objet de correctifs ou de
palliatifs
. . Informer l équipe chargée de reprendre l application (activités récurrentes, )
(A) CONSTITUER LES DOSSIERS
DE
CONTROLES D INSTALLATION ET
DE CROISIERE
Identifier les contrôles à effectuer
. . Lors de l installation du nouveau produit
. . Au cours de la MPP (croisière)
. . Rédiger un dossier de contrôles d installation après basculement pour vérifier sur le
site le
fonctionnement de la nouvelle version. Il comprend :
. . la liste récapitulative par item de l ensemble des tâches
. . des fiches de tâches précisant : les pré - requis, les acteurs, la durée, les actions,
le
résultat attendu
. . Rédiger un dossier de contrôles de croisière, pour tester les fonctionnalités lors de
la MPP,
comprenant :
. . la liste récapitulative par item de l ensemble des tâches
. . des fiches de tâches précisant : les pré - requis, les acteurs, la durée, le mode
opératoire, le but, le résultat attendu
(A) FAIRE DES REUNIONS DE
PREBILAN
(PAR THEME) ET DE BILAN
Obtenir les éléments factuels d évaluation pour la décision de généralisation (J2)
. . Faire, le plus tôt possible, des réunions de pré - bilan par thème (formation, instal-
lation,
métrologie, documentation...)
. . Envoyer les fiches bilans aux acteurs concernés 10 jours avant la réunion
. . Exploiter les fiches bilans retournées pour constituer les supports de la réunion
. . Initialiser ou mettre à jour le dossier bilan
. . Faire une réunion de préparation du bilan sur chaque site (en cas de sites multi-
ples)
. . Faire une réunion bilan physique tous sites pilotes confondus si les objectifs de la
MPP sont
les mêmes pour tous les sites.
. . Faire rédiger au chef de projet site pilote un avis motivé et signé des décideurs lo-
caux sur la
généralisation (favorable, défavorable, réserves)
(A) FIXER L ORGANISATION POUR
LA
GESTION DES SIGNALISATIONS
Garantir un suivi rigoureux et efficace des signalisations
. . Fixer le circuit de remontée en précisant
. . les engagements pour la traçabilité des signalisations
. . les engagements pour la résolution des problèmes bloquants
. . Fixer les modalités du suivi et la périodicité des réunions
. . Prévoir, si nécessaire, une formation pour les utilisateurs de l'outil de gestion des
signalisations
. . S assurer de la présence en nombre suffisant des soutiens locaux et nationaux et
de leur
disponibilité
Associer fortement le soutien niveau 2 dans l organisation du suivi des signalisations
(A) GERER LES
SIGNALISATIONS
Avoir un suivi rigoureux des signalisations émises par le site pilote
. . Mettre en oeuvre la gestion des signalisations prévue :
. . faire constater l'incident par le soutien niveau 1 et le faire initialiser dans l'outil de
gestion des signalisations : préciser le contexte d'apparition de l'incident, ses
conséquences, les messages d'erreur
. . faire attribuer les signalisations par le soutien niveau 1
. . analyser/traiter les signalisations
. . valider les corrections et clôturer les signalisations
. . Produire les tableaux de synthèse
. . Faire le point sur les signalisations lors des réunions de suivi de la MPP
[La "fiche de signalisation" et la "fiche de réponse" figurent dans la procédure de ges-

tion des
signalisations]
(A) ORGANISER ET EFFECTUER
LA
LIVRAISON DES CORRECTIFS
Avoir une procédure de livraison qui respecte les règles d installation et garantisse la
mise à
niveau du site pilote avec la version généralisée
. . Définir le contenu des livraisons avec le chef de Projet SI et le (s) projet (s) en rap-
prochement
avec les signalisations (leur nombre et leur gravité)
. . Planifier et confirmer les livraisons avec les différents acteurs, en rappelant et res-
pectant le
délai de préparation pour le déploiement
. . Mobiliser les équipes locales et nationales comme pour l'installation initiale (cf. :
MPP611,
MPP614),
. . Organiser les contrôles techniques et fonctionnels après l'installation des correctifs
en ayant
informé les utilisateurs sur les palliatifs à ne plus utiliser, les signalisations corrigées
. . Mettre à jour le dossier de MPP (base du dossier de déploiement)
. . Suivre les lots correctifs en configuration
13.1.3. (A) MO_INSTALLATION
(A) ADAPTER LES PRE REQUIS
AVEC LE SITE PILOTE
Garantir des conditions nominales pour le déploiement du projet sur le site pilote
. . Demander au site pilote une description précise de l'architecture technique, de l'en-
vironnement
fonctionnel et organisationnel (recenser les produits installés, ...)
. . A partir de cette description, adapter la liste des pré - requis nécessaires au dé-
ploiement sur le
site en faisant ressortir les points à surveiller (spécificités locales)
. . pré - requis organisationnels : utiliser des moyens techniques pour soulager un ser-
vice
(basculer les appels téléphoniques d'un service vers un autre pendant des forma-
tions), . .
. . pré - requis métier : préparer le planning éventuel d'intervention du MOE Métiers, ...
. . pré - requis technique
. . Planifier les horaires pour l'installation des applications
. . réactualiser le planning prévisionnel suite aux contraintes locales (le faire valider
par
les acteurs concernés)
(A) CONSTITUER LE REFEREN-
TIEL ET
LE PACKAGE DES LOGICIELS
Après qualification du produit à installer, identifier et avoir un produit référencé et
conforme aux
normes d installation
. . En fin d intégration :
. . finaliser le « référentiel des logiciels » à embarquer en MPP
. . produire la liste des anomalies résiduelles, les palliatifs et obtenir de l intégrateur le
PV de recette d intégration
. . demander au packageur l industrialisation finale des logiciels en s assurant de la
purge
des éléments obsolètes de l ancienne version
. . faire tester auprès de l intégrateur le bon fonctionnement du logiciel packagé
. . vérifier la conformité du package par rapport au logiciel intégré
. . déposer le logiciel packagé à l organisme de référencement
(A) CONSTRUIRE LE
SCENARIO DE MPP
Préparer dès la MPP un scénario proche des conditions de généralisation
. . Prendre en compte s'il y a lieu, la stratégie et les contraintes de généralisation
. . sur plusieurs types de sites
. . sur plusieurs types d environnements techniques (par exemple : serveurs exté-
rieurs)
(A) DECRIRE L ORGANISATION
POUR LA
DIFFUSION DES LIVRABLES LOGI-
CIELS
Avoir un circuit et des règles de diffusion fiables et efficients
. . Décrire les modalités de livraison (dépendantes de l environnement technique)
pour chaque
application du projet en identifiant l expéditeur et le destinataire final
. . pour la version initiale
. . pour les correctifs
. . Adapter le document réponse de contrôle de réception pour chaque circuit confor-
mément aux
procédures
. . Pour chaque flux, arrêter les dates de livraison et les communiquer aux équipes
projet et au
Chef de Projet Site Pilote
(A) DEFINIR LES CRITERES DE S assurer des caractéristiques nécessaires au site pilote pour répondre aux objectifs

SELECTION DE SITE du projet et
être représentatif de la généralisation
. . Définir la représentativité des sites par rapport aux exigences du projet :
. . l environnement fonctionnel (présence de toutes les applications interfacées, mise
en place
de tous les postes de travail en configuration et organisation cible)
. . le volume d activité, le nombre de postes de travail et leur répartition géographique,
. . l infrastructure technique, l environnement d exploitation et les conditions d installa-
tion,
. . les profils utilisateurs (niveau de compétence et besoins en formation), la motiva-
tion du site
(A) DESIGNER LES PERSONNES
D ASTREINTES POUR
L INSTALLATION
Organiser les astreintes pour garantir une installation sécurisée
. . Désigner les astreintes :
. . Nationales (MOE SI, pilote de l exploitabilité, déployeur technique, Réalisateurs,
Concepteurs, ...)
. . Locales (expert réseau, exploitant d'autres systèmes utilisés pour les contrôles
d'installation)
. . Prévoir les ponts téléphoniques (fonctionnels, techniques, ...)
. . Préciser les délais d'intervention et les compétences nécessaires
. . Distinguer les plages d'astreintes (physique/téléphonique)
Faire valider l'annuaire et les numéros des ponts téléphoniques par les intervenants
respectifs
(A) FAIRE UNE REPETITION
D INSTALLATION
Vérifier les procédures d installation et de retour arrière
. . cas de migration de base pour :
. . s'assurer du bon déroulement des opérations conformément au phasage d'installa-
tion
. . vérifier les points de synchronisation, les points de contrôle, la volumétrie
. . relever les temps de traitement pour faire une estimation fiable de l'opération réelle
. . Tester la procédure de retour arrière
Prendre les décisions nécessaires au bon déroulement de l'installation
(A) FAIRE UNE REUNION DE
PRESENTATION TECHNIQUE
DE L INSTALLATION
Informer et mobiliser les acteurs techniques sur les spécificités de l installation
. . Présenter le déroulement détaillé :
. . de l'installation
. . des contrôles d'installation
. . Présenter les tâches et les acteurs (connus du dossier de phasage)
. . Identifier les positions de travail et les périphériques nécessaires aux contrôles
d'installation
. . Vérifier les pré - requis d'installation et la mobilisation des acteurs
. . Dresser l'annuaire des intervenants
. . S'assurer que les administrateurs des tables applicatives sont en possession des
informations à
saisir
(A) INSTALLER ET METTRE A
JOUR
LES TABLES APPLICATIVES
Assurer la mise en place des tables applicatives
. . Installer les tables
. . Saisir les données dans les tables applicatives ou récupérer des tables télédiffu-
sées
. . Faire les tests d'installation technique : tester la lisibilité de la table au moins à tra-
vers un
applicatif
. . Faire remonter les signalisations éventuelles
(A) INSTALLER LES LOGICIELS Installer les logiciels en capitalisant pour la généralisation
. . Installer les logiciels
. . Noter la durée de chaque tâche
. . Signer le procès verbal de recette d'installation et rédiger le rapport d'intervention
. . Faire les tests d'installation technique
. . Mettre à jour le dossier de configuration locale du site (ou du centre de production)
. . Faire remonter les signalisations
. . Rédiger rapidement le bilan de l'installation pour enrichir le bilan final
(A) INSTALLER LES MATERIELS,
LES
RESEAUX, LE MOBILIER, . .
Préparer le site à l installation
. . Installer :
. . les matériels (machines, stations de travail, ...)
. . les réseaux (X25 ou IP)
. . l'environnement technique (énergie, climatisation)
. . le mobilier
... . .
. . Penser aux éléments logistiques (bâtiments, ...)
. . Faire mettre à jour la liste des pré - requis au pilote MPP
(A) LIVRER LES LOGICIELS, LES
TABLES ET POINTER LA RECEP-
TION
S assurer de la disponibilité des logiciels sur site pour l installation
. . S'assurer de la disponibilité du logiciel et des tables chez le diffuseur accompagnés
du
bordereau de livraison
. . Donner le feu vert au diffuseur pour la livraison au destinataire
. . S'assurer de la réception par le destinataire nommé
. . Pointer la livraison à l'aide du référentiel logiciel
(A) PRENDRE EN COMPTE LES
IMPACTS
SUR L ARCHITECTURE TECHNI-
Définir les adaptations techniques à réaliser sur le site pour les besoins du projet
. . Recenser les besoins en infrastructure et en ressources nécessaires à l exploita-
tion sur site

QUE, (matériels informatiques, réseaux, locaux, mobilier, ... .)
. . Rédiger si besoin les procédures d approvisionnement
. . Informer le fournisseur sur la prévision de commande
(A) REDIGER LE PHASAGE
D INSTALLATION ET LES
MODALITES DE RETOUR ARRIERE
Décrire l enchaînement des tâches qui garantit une installation opérationnelle et re-
productible
. . Rédiger le phasage d installation par type d'architecture technique en prenant en
compte
. . la métrologie rapportée au contexte terrain
. . les acteurs
. . les périodes de réalisation de chaque tâche
. . les points de synchronisation
. . des points de contrôle
. . les actions à mener après l installation du logiciel
. . Décrire le déroulement de retour arrière pour l ensemble des applicatifs
. . Identifier les contraintes utilisateurs liées à l installation des applications (par exem-
ple :
indisponibilité des applications)
. . Valider la durée et la période d installation avec le MOE généralisation
(A) VERIFIER QUE LES DOSSIERS
D INSTALLATION ET D EXPLOITA-
TION
SONT REDIGES
Constituer une documentation technique, conforme aux normes d installation et d ex-
ploitabilité
. . Récupérer les dossiers d installation et d exploitation par application initialisés par
les projets
. . Ajouter la liste des composants logiciels (ajouts, modification, suppression)
. . Regrouper ces dossiers par type d architecture technique (ATN, serveur UNIX, sys-
tèmes
nationaux, serveur DR hors UNIX, ...)
. . S'assurer de la conformité avec les normes d'installation et d'exploitabilité :
. . existence des procédures d installation et de désinstallation des logiciels
. . identification précise des « feux » (verts, oranges, rouges) de la recette
d exploitabilité provisoire
13.1.4. (A) MO_FORMATION METIERS
(A) APPROFONDIR LES IMPACTS
METIERS ET CLIENTS
Déterminer l importance des impacts métiers et clients du produit pour construire le
plus en amont
possible les actions liées au métier et à la communication client
. . Déterminer l'importance des impacts métiers à partir de la description du processus
métier.
Dans le cas d'impacts forts (nouvelle organisation, nouvelle position de travail, . .) pré-
voir un
accompagnement métier et l'implication des encadrants du site pilote, prendre contact
également avec les syndicats et les ressources humaines (une expérimentation pré-
alable à la
MPP est prévue dans ce cas).
. . Dans le cas d'impacts clients (modification des courriers, des contrats, de la fac-
ture...), associer
le service marketing de la Branche pour vérifier la prise en compte de ces impacts et
leur
évaluation dans le cadre de la MPP.
. . S assurer que toutes les positions de travail impactées sont bien recensées et s
assurer que les
compétences à développer sont bien définies.
(A) ASSURER LES FORMATIONS Former la population ciblée lors de la préparation de la MPP
. . Dispenser la formation technique
. . aux exploitants
. . aux installateurs
. . Dispenser la formation fonctionnelle
. . aux soutiens niveau 1
. . aux utilisateurs (formation assurée soit directement, soit par les soutiens
niveau 1)
. . Faire une évaluation à chaud de la formation
(A) CONCEVOIR LES DOCUMENTS
UTILISATEURS
Donner les moyens aux utilisateurs de s approprier les nouveautés fonctionnelles et
les processus
métier
. . Constituer un groupe pluridisciplinaire chargé de définir :
. . les documents à produire,
. . le support final (papier, mise en ligne, CDrom) en fonction du type de projet et des
lecteurs cibles,
. . le format intermédiaire (documents papier non reliés pour la reprographie, format
électronique adapté pour un CDrom ou une mise en ligne),

. . les réalisateurs et les valideurs des documents.
. . Rédiger :
. . les fiches évolutions par application : si les impacts métiers sont faibles, les fiches
évolutions peuvent être associées à la documentation utilisateur,
. . les modes opératoires éventuels,
. . la documentation utilisateur.
S assurer que tout a été vu en faisant une visite sur le terrain
(A) ELABORER LE PRODUIT
DE FORMATION
Répondre aux besoins en formation identifiés en fonction des évolutions
Avec un groupe pluridisciplinaire :
. . Analyser l'apport de l'application (delta pour les nouvelles versions, nouveaux utili-
sateurs,
nouvelles applications), déterminer s'il faut faire une simple information ou une forma-
tion
. . Cibler la population à former (soutien niveau 1, experts, utilisateurs, encadrants de
proximité,
exploitants, soutiens techniques, ...)
. . Etablir un cahier des charges, en évaluant bien les coûts, les délais (validation du
MOA)
. . Définir le produit de formation : le contenu, la durée des formations suivant le type
de
population à former
. . Choisir les outils, correspondant au produit de formation, adaptés aux contraintes
du projet
. . des VIF. . des bases écoles, des simulateurs interactifs
. . des formations physiques (pour ces produits, anticiper les formations)
. . Centre de Ressource Formation. . une cassette et un guide d accompagnement
. . Réaliser les produits de formation et les supports associés
(A) ORGANISATION DES
SESSIONS DE FORMATION
Assurer la mise en oeuvre de la formation en cohérence avec le planning de déploie-
ment et la
population à former
. . Fournir au site les modalités de formation définissant :
. . la durée, les moyens pédagogiques et les supports associés (base école, cassette,
guide
d'accompagnement, transparents, ...), la population à former, le lieu de la formation
(VIF, physique, ...), la période prévisionnelle de formation.
. . ordonnancer et planifier la formation
. . identifier et dénombrer les personnes concernées
. . constituer les groupes de formation
. . installer l'infrastructure nécessaire à la formation
. . vérifier la livraison des outils pour la formation (transparents, cassettes, ...)
13.1.5. (A) MO_COMMUNICATION
(A) ASSURER LA MONTEE EN
COMPETENCE DES
CONTRIBUTEURS NATIONAUX
Garantir la sécurité de la généralisation en préparant les acteurs du déploiement
. . Cibler les acteurs nationaux devant monter en compétence : soutien niveau 2 (ap-
plicatifs,
métiers, ...), le MOE généralisation, ...
. . Les faire participer à la recette pour leur permettre de comprendre le fonctionne-
ment de
l'application et les nouveautés.
. . Faire informer par la MOE métiers le soutien niveau 2 sur les changements et les
apports du
projet.
. . Faire former éventuellement par les formateurs le soutien niveau 2 à partir des pro-
duits de
formation préparés pour le site pilote.
(A) COLLECTER REGULIEREMENT
AUX
DIFFERENTS PARTENAIRES DE LA
MPP
AFIN DE RESTITUER
Tenir les responsables nationaux informés de l avancement du projet
. . Collecter auprès des différents contributeurs de la MPP les informations concer-
nant :
. . les impacts métiers
. . l'installation et la production
. . le soutien sur site
. . la documentation
. . le suivi de la MPP
. . les évaluations des formations
. . le traitement des incidents
. . Donner les informations au chef de projet SI pour qu il puisse faire le reporting du
projet en

s'appuyant sur les informations précédentes.
(A) COMMUNIQUER AUX UTILISA-
TEURS
SUR LA VIE DU PROJET
Maintenir les acteurs locaux informés des événements de la MPP
. . Rédiger un journal (fréquence à adapter selon les événements) présentant la vie
du projet et de
la MPP :
. . les éventuels dysfonctionnements
. . les palliatifs
. . le calendrier des correctifs
. . les informations plus générales d'avancement
. . Diffuser massivement le journal aux utilisateurs concernés par le projet
(A) FAIRE UNE PRESENTATION
AUX
EQUIPES PROJET ET AUX MOA
Assurer la communication aux équipes projet et à la MOA sur le contenu de la MPP
. . Présenter :
. . l équipe de MPP et son organisation
. . le planning prévisionnel
. . le scénario de MPP
. . les impacts métiers et clients
. . l avancement de la préparation de la MPP
. . les objectifs du projet
(A) FAIRE UNE REUNION DE
LANCEMENT DE LA MPP
. . présenter les nouveautés du projet aux acteurs locaux
. . les sensibiliser et les mobiliser sur la mise en oeuvre de son déploiement en site pi-
lote
. . Réunion de lancement de la MPP :
. . Présenter
. . l'objectif de la MPP et les nouveautés du projet
. . les pré - requis. . le calendrier prévisionnel
. . les rôles des différents intervenants. . le déroulement de la formation
. . l'organisation de la MPP. . les actions de communication
. . la charge des différents intervenants
. . Recueillir
. . les informations spécifiques au site (techniques, organisationnelles, ...)
. . les informations nécessaires pour compléter le contrat et le dossier de MPP
. . Faire une évaluation à chaud de la réunion (questionnaire d évaluation)
(A) PREPARER LE DOSSIER DE
MPP
Formaliser les conditions de mise en oeuvre de la MPP
. . Dans le Dossier de MPP, expliciter dans le détail le fonctionnement de la MPP sur
le site pilote
. . les objectifs du projet. . les nouveautés du projet
. . les acteurs. . le planning de la MPP
. . le déroulement de la formation. . le plan de communication
. . les besoins en ingénierie. . la gestion des signalisations
. . la préparation du bilan. . les besoins en matériel, en réseau
. . Préciser clairement les rôles et les responsabilités des différents acteurs
. . Joindre en annexe du dossier de MPP, le plan de communication, le plan de mobi-
lisation, la
procédure de gestion de la documentation, la procédure de gestion des signalisa-
tions, les
procédures de gestion des livraisons logicielles et de suivi des diffusions terrain.
(A) PREPARER LES ACTIONS DE
COMMUNICATION
Concevoir une communication efficace, ciblée selon le profil des destinataires
Définir les objectifs du plan de communication (information sur les évolutions et les
vecteurs de
communication, accompagnement du changement, identification et résolution des dif-
ficultés)
. . Elaborer le plan de communication du projet en différenciant la population qui doit
être
informée (les décideurs, le soutien, les utilisateurs, les encadrants, l'équipe technique,
...)
. . Prévoir des supports de communication adaptés à chaque type de population, an-
nexés des
commentaires, et préparer des questionnaires d évaluation pour les différentes ré-
unions
. . Prévoir les dates des différentes réunions
. . Prévoir si nécessaire une communication en interne (article dans journaux locaux,
VIF, ) et
s assurer que la communication éventuelle vers les clients de FT est prévue
. . Insister sur le rôle et les responsabilités du site pilote
. . Joindre le plan de communication au dossier de MPP
(A) PRESENTER LE CONTEXTE
DE LA MPP
AU CHEF DE PROJET SITE PILOTE
Préparer la construction du déploiement sur le site pilote avec le chef de projet site pi-
lote
. . Lors d une réunion d initialisation, présenter au Chef de Projet Site Pilote :
. . les nouveautés du projet
. . le planning prévisionnel de la MPP et les contraintes de déploiement (par
exemple, les besoins en matériels, en locaux)
. . les pré - requis nécessaires
. . l organisation de la MPP
. . les acteurs locaux et le plan de mobilisation
. . le questionnaire d évaluation de la démarche qualité MPP et son objectif
. . Initialiser, avec le Chef de Projet Site Pilote le PAQ site pilote (évaluation des ris-
ques de la

MPP, gestion des signalisations et de la documentation). Prendre en compte les critè-
res qualité
du site
. . Arrêter les dates adéquates d'installation
. . Arrêter les dates prévisionnelles des différentes réunions
(A) PRESENTER LE PROJET ET LA
MPP
AUX ENCADRANTS DU SITE PI-
LOTE
Sensibiliser l encadrement sur les apports et les contraintes du projet
. . Présenter le projet et la MPP aux encadrants du site pilote
. . insister sur les apports de l'applicatif (gain de productivité, gain de qualité du SI...).
. . Informer les décideurs
. . sur la formation prévue
. . sur les actions de communication
. . Rappeler les charges induites par la MPP pour les correspondants locaux et le
Chef de Projet
Site Pilote
13.1.6. (A) MO_RELATIONS AVEC LE SITE PILOTE
(A) EVALUER LE RESSENTI DES
UTILISATEURS
Evaluer la satisfaction des utilisateurs
. . Faire des visites sur le site pilote pour connaître le ressenti utilisateurs face :
. . aux nouveautés du projet
. . aux impacts métiers
. . aux temps de réponse
. . à la documentation
. . à la qualité du logiciel
. . à l accompagnement du changement
. . Utiliser le questionnaire d enquête utilisateur et analyser les réponses de satisfac-
tion
utilisateurs
(A) IDENTIFIER LES SITES
PILOTES POTENTIELS
Trouver des sites pilotes disponibles et correspondants aux critères identifiés
. . Etudier les sites sur l ensemble des dimensions suivantes :
. . Organisation
. . Configuration matérielle
. . disponibilité
. . exploitation
. . configuration logicielle
. . dimension (volumétrie)
. . Prendre en compte les déploiements prévus pendant la période de MPP
. . Contacter les DED des sites sélectionnés
. . Solliciter les responsables locaux
(A) OBTENIR L ACCORD DES
DECIDEURS LOCAUX ET LA
SIGNATURE D ENGAGEMENT
Faire confirmer aux décideurs leur accord et leur engagement dans la participation à
la réussite du
projet
. . Organiser une réunion de présentation aux décideurs :
. . s assurer de la présence des personnes concernées
. . Actualiser (si besoin) le planning prévisionnel suivant les contraintes du site
. . En cas d impacts sociaux importants, informer les organisations syndicales
. . Demander au site pilote une lettre d acceptation
(A) PREPARER L ENQUETE DE
SATISFACTION DES
UTILISATEURS
Construire une enquête satisfaction utilisateurs pour l évaluation en fin de MPP. Cette
enquête est
l un des éléments permettant de prendre la décision de généraliser
. . Préparer une enquête d évaluation du produit et du déroulement de la MPP
. . Cibler la population qui doit être sondée
. . Utilisateurs
. . Exploitants
. . Encadrants
. . Soutiens niveau 1... .
. . Définir les modalités d'accompagnement du questionnaire d enquête

13.1.7. (A) MO_QUALIFICATION UTILISATEURS
(A) EFFECTUER LES CONTROLES
D INSTALLATION
. . Effectuer les contrôles d'installation conformément au dossier de contrôle d'installa-
tion
. . Vérifier la conformité par rapport aux fiches de contrôle
. . Chronométrer la durée des contrôles
. . Faire part des résultats du passage des contrôles au chef de projet site pilote
(A) INFORMER LES UTILISATEURS
SUR
LA PERIODE D ARRET DU SI
. . Informer les utilisateurs sur :
... . la date et l'heure de l'arrêt du système
... . l'heure prévisionnelle de reprise du SI
. . les applications indisponibles durant l'installation
En cas de fermeture TP anticipée, formaliser la période d'arrêt avec le Chef de Projet
Site Pilote
(acceptation écrite)
(A) S ASSURER DE LA MESURE
DES TEMPS DE REPONSE
Avoir un référentiel temps de réponse fondé sur les informations données par un site
réel
(site pilote)
. . Préciser les conditions de mesures (nombre d utilisateurs connectés, nombre
d utilisateurs actifs).
. . Chronométrer les transactions demandées dans les fiches de tâches du référentiel
de
temps de réponse (temps machine).
. . Comparer les mesures faites au résultats attendus
. . Faire remonter les signalisations éventuelles
. . Valider le tableau de synthèse des mesures
(A) S ASSURER DU PASSAGE DES
CONTROLES DE CROISIERE
S assurer, à partir du dossier de contrôles de croisière, du bon fonctionnement du site
pilote
. . Compléter le dossier de contrôles avec les données résultantes du test (N° com-
mande, ND, ...)
. . Vérifier le fonctionnement dans un environnement opérationnel (d'après le dossier
de contrôles
de croisière)
. . Valider les contrôles dans des réunions de suivi

13.2. Représentation OSSAD des processus AGATHONE MPP
13.2.1. Les activités du processus AGATHONE MPP
Figure 78 – AGATHONE, Activité : Organisation, avancement et suivi.

Figure 79 – AGATHONE, Activité : Qualification MOE SI

Figure 80 – AGATHONE, Activité : Installation

Figure 81 – AGATHONE, Activité : Formation métiers

Figure 82 – AGATHONE, Activité : Communication

Figure 83 – AGATHONE, Activité : Relation avec le site pilote

Figure 84 – AGATHONE, Activité : Qualification utilisateurs

13.2.2. Les phases du processus AGATHONE MPP
Figure 85 – AGATHONE, Phase 1 MPP : Mûrissement

Figure 86 – AGATHONE, Phase 2 MPP : Recherche du site pilote

Figure 87 – AGATHONE, Phase 3 MPP : Préparation du déploiement (1/2)

Figure 88 – AGATHONE, Phase 3 MPP : Préparation du déploiement (2/2)

Figure 89 – AGATHONE, Phase 4 MPP : Initialisation du site pilote

Figure 90 – AGATHONE, Phase 5 MPP : Installation

Figure 91 – AGATHONE, Phase 6 MPP : Suivi et Bilan

Figure 92 – AGATHONE, Phase 7 MPP : Post Bilan

13.2.3. Les relations avec les autres processus
Figure 93 – Abstrait MA - Agathone MPP - Relation avec les autres processus

Figure 94 – Abstrait MA - Agathone MPP - synthese MO par Activité

Figure 95 – Abstrait MA - Agathone MPP - synthese MO par phase
Figure 96 – Abstrait MA - Agathone MPP - synthese MO par Activité

Figure 97 – Abstrait MA - Agathone MPP - synthese MO par phase

Représentations systémiques d’une organisation opérationnelle en s’appuyant sur la méthode graphique OSSAD (Full)

Contenu connexe

Tendances

Plus de Perrein Jean-Pascal

Représentations systémiques d’une organisation opérationnelle en s’appuyant sur la méthode graphique OSSAD (Full)