Projet master la voix du client - Marc Bonnemains

i
MMéémmooiirree pprrooffeessssiioonnnneell
ppoouurr llaa
vvaalliiddaattiioonn ddee ll’’eexxppéérriieennccee
VAE 2002
de
Marc Bonnemains
Dans le cadre d’un
Master 2 professionnel
Mention
Informatique
spécialité
Conduite de Projets Informatiques.

Master 2 professionnel « Gestion de projet informatique » ii
À tous ceux qui ont participé de près ou de
loin au projet relaté dans ce mémoire. Plus
particulièrement à l’équipe qui m’a accompagné
lors de cette réalisation.

Master 2 professionnel « Gestion de projet informatique » iii
Sommaire
SOMMAIRE III
LISTE DES FIGURES V
LISTE DES TABLEAUX IX
GLOSSAIRE X
I INTRODUCTION 1
I.1 Avertissement 1
I.2 Plan du mémoire 2
I.3 Le sujet et le but du mémoire 3
I.4 Le cadre théorique : les concepts 5
II L’HISTOIRE DE MON PROJET : « LA VOIX DU CLIENT » 27
II.1 Ma nomination : les dés sont jetés 27
II.2 La phase de préparation de la « voix du client » 29
II.3 L’étude de cadrage de la « voix du client » 34
II.4 La réalisation de la « voix du client » 44
II.5 La gestion du changement sur le projet « la voix du client » 69
II.6 La finalisation du projet « la voix du client » 72
III LESPOSTULATSINITIAUXDUPROJET«LAVOIXDUCLIENT»75
III.1 Le contexte du projet « la voix du client » au niveau stratégique 76
III.2 Le contexte du projet « la voix du client » :
« tout bâtir dans un délai très court ! » 78
III.3 Les contraintes du projet « la voix du client » : « le triangle d’or » 80
III.4 Le choix du progiciel de GRC « Siebel » : démarche et justification 89
III.5 Les spécificités du projet : innovations et dimension sociale 94

Master 2 professionnel « Gestion de projet informatique » iv
IV LE PROJET VU SOUS L’ANGLE MÉTHODOLOGIQUE 98
IV.1 La typologie du projet : un projet « complexe » 98
IV.2 Ma méthodologie de gestion de projet confronté à la théorie 107
IV.3 La gestion de mon projet 131
V CONCLUSION 190
LEXIQUES
197
BIBLIOGRAPHIE 200
TABLES DES MATIÈRES 230

Master 2 professionnel « Gestion de projet informatique »
v
Liste des figures
Figure 1 : Schéma de progiciel de gestion intégrée (PGI ou ERP). 19
Figure 2 : Proposition commerciale pour le projet de centre de contacts. 28
Figure 3 : Analyse succincte des risques du projet. 32
Figure 4 : Compte-rendu de la première revue d’enclenchement de
contrat. 35
Figure 5 : Périmètre fonctionnel initial du centre de contacts. 36
Figure 6 : Cartographie des systèmes d’information identifiés. 37
Figure 7 : Présentation de la future architecture technique. 38
Figure 8 : Tableau de synthèse de la configuration matérielle. 39
Figure 9 : Présentation technique de Siebel. 39
Figure 10 : Présentation du périmètre applicatif Siebel sur le projet. 40
Figure 11 : Les grandes phases de notre contrat. 40
Figure 12 : Les jalons importants du projet rectifié 41
Figure 13 : La place du progiciel de GRC Siebel dans le SI de l’entreprise.
43
Figure 14 : Compte-rendu de la deuxième revue d’enclenchement de
contrat. 46
Figure 15 : Courriel d’échange avec mon supérieur hiérarchique. 51
Figure 16 : Procès-verbal de recette client du lot 1. 60
Figure 17 : Procès-verbal de recette client du lot 2 & 3. 68

vi
Figure 18 : Procès-verbal de recette de la salle de formation. 70
Figure 19 : Document de formation technique des opérateurs. 71
Figure 20 : Manuel d’utilisation de la « voix du client ». 71
Figure 21 : Exemple de fiche de poste. 72
Figure 22 : Calendrier prévisionnel du plan de déploiement du centre de
contacts. 73
Figure 23 : Courriels de fin de projet. 74
Figure 24 : Objectifs à court terme du projet. 79
Figure 25 : Le triptyque « coûts, délais, qualité ». 82
Figure 26 : Résultat du Chaos Report 2009. 86
Figure 27 : Enjeux du projet « Voix du Client » sur le plan des
performances de l’entreprise. 93
Figure 28 : Vision fonctionnelle du progiciel Siebel version 7. 93
Figure 29 : La voix du client au cœur de l’entreprise. 95
Figure 30 : L’étroite collaboration du consultant et du chef de projet. 96
Figure 31 : Le modèle NTCP appliqué à mon projet. 106
Figure 32 : Méthode Delta décrit dans le guide méthodologique de mise en
œuvre et d’intégration de progiciels applicatifs. 111
Figure 33 : Les cinq volets d’activités de la méthode Delta. 111
Figure 34 : Place du projet de mise en oeuvre de progiciels applicatifs
dans le cycle de vie global. 113
Figure 35 : Représentation « matricielle » des tâches. 114
Figure 36 : Architecture technique. 115

vii
Figure 37 : Organisation type d'un projet informatique à base de progiciels
intégrés chez la société qui m’emploie. 115
Figure 38 : Comparaison du modèle de développement séquentiel vs
simultané. 118
Figure 39 : Le cycle en Y ou two track unified process (2TUP). 121
Figure 40 : La méthode de développement RAD vs méthodes
traditionnelles. 124
Figure 41 : Positionnement des méthodes selon les quatre critères agiles. 125
Figure 42 : Organigramme général des processus de gestion de projet.128
Figure 43 : Mémento du chef de projet de la société qui m’emploie. 129
Figure 44 : Cycle de vie du projet. 134
Figure 45 : Intranet sur le projet – La voix du client. 138
Figure 46 : Exemple de documents structurant sur le projet. 138
Figure 47 : Répertoires et documents du projet La voix du client. 139
Figure 48 : Exemple de documents organisationnels sur le projet. 140
Figure 49 : La part des erreurs des exigences par rapport au nombre total
d’erreurs 141
Figure 50 : Processus critiques de définition et de gestion des exigences
adaptées par Marc Bonnemains. 149
Figure 51 : Exemple d’un schéma de procédure. 150
Figure 52 : Exemple de processus du centre de contacts. 150
Figure 53 : Les 5 dimensions culturelles de Geert Hofstede entre la France
et la Roumanie. 155
Figure 54 : Composantes clés du dialogue avec les parties prenantes
(adapté par Marc Bonnemains). 161

viii
Figure 55 : Le Retour d’Expérience objet d’étude complexe. 178
Figure 56 : Retour d’Expérience (adapté par Marc Bonnemains). 179
Figure 57 : Bilan projet. 181
Figure 58 : Position du BA vue par IIBA France. 184
Figure 59 : Collaboration PM et BA durant le projet. 186
Figure 60 : Les limites du projet. 193
Figure 61 : Le problème des projets. 193
Figure 62 : Une approche idéale. 194

ix
Liste des tableaux
Tableau 1 : Historique de l’évolution des PGI ou ERP. 20
Tableau 2 : Taux d’échecs de l’implantation des outils de GRC. 24
Tableau 3 : Composition de l’équipe du projet 47
Tableau 4 : Composition de l’équipe du projet pour la fin du projet 74
Tableau 5 : Les données du « Chaos Report » consolidées (1994-2009). 87
Tableau 6 : Cause d’échecs d’un projet. 88
Tableau 7 : Panorama des solutions de CRM intégrées avec les champs
fonctionnels couverts. 90
Tableau 8 : Parts de marché 2002 des éditeurs de solutions de CRM dans
le monde. 91
Tableau 9 : Chiffre d'affaires issu des ventes de licences pour les
principaux éditeurs de solutions de CRM dans le monde. 91
Tableau 10 : Typologie des projets. 98
Tableau 11 : Synthèse de la revue de littérature sur la complexité en
gestion de projet. 103
Tableau 12 : Synthèse du cycle en Y ou Two track unified process. 123
Tableau 13 : Tableau des activités directes ou indirectes du chef de projet
sous forme de matrice. 130
Tableau 14 : Une nouvelle vision de l'expression des exigences. 146
Tableau 15 : Différentes définitions des parties prenantes 160
Tableau 16 : Répartition des rôles entre PM et BA sur le projet. 186

x
Glossaire
2TUP Two Track Unified Process - Le cycle en Y
AFITEP Association francophone de management de projet
AFNOR Association française de normalisation
AMOA Assistance à maîtrise d’ouvrage
CCPM Critical Chain Project Management
Gestion de projet selon la chaîne critique
CIF Congé individuel de formation
CRM Customers Relationship Management
CTI Couplage Téléphonie Informatique
DEA Diplôme d'étude approfondi
DOSI Direction de l'Organisation et des Systèmes d'information
EIP Enfant intellectuellement précoce
ERP Entreprise Resources Planning
FAE Fiche d'anomalie et d'évolution
FCS Facteurs clés de succès
GRC Gestion de la relation client
ICP Indicateurs clés de performance
IHM Interface homme-machine
IPMA Association internationale du management de projet
ISO Association internationale de normalisation
MOA Maîtrise d'ouvrage
MOE Maîtrise d'œuvre
NTCP Novelty, Technology, Complexity and Pace
La nouveauté, la technologie, la complexité et le rythme

xi
OGC Office du commerce britannique
OSSAD Office Support Systems Analysis and Design
PABX Private Automatic Branch eXchange
Autocommutateur téléphonique privé
PECO Pays d’Europe centrale et orientale
PGI Progiciel de gestion intégré
PMAJ Association japonaise du management de projet
PMI Institut de management de projet
QI Quotient intellectuel
RACI Responsible, Accountable, Consulted and Informed
Réaliser, approuver, consulter et informer
RAD Rapide Application Development
Méthode de développement rapide d’application
REX Retour d'EXpérience
RSE Responsabilité sociale des entreprises
SHT Stakeholder Theory - Théorie sur les parties prenantes
SI Système d'information
TAM Technical Assitant Managers
Assistant technique de Siebel
UML Unified Modeling Language
Langage de modélisation unifié
UP Unified Process - Processus unifié
USIC Unité de stratégie informatique de la Confédération helvétique

Master 2 professionnel « Gestion de projet informatique » 1
I Introduction
Ce travail de rédaction de mémoire est réalisé dans le cadre d’une
validation des acquis de l’expérience (VAE) pour l’obtention d’un mastère
2 professionnel, mention « Informatique » avec une spécialité en
« Conduite de Projets Informatiques » à l’université de Paris 8. Ce travail
fait suite à la rédaction d’une autobiographie raisonnée et l’établissement
d’un portefeuille de compétences pour prouver que je suis un chef de
projet accompli pouvant prétendre à la délivrance du diplôme ci-dessus
nommé. Pour ce faire, j’ai décidé de baser mon mémoire sur une mission
de chef de projet pour complaire aux exigences du diplôme visé. Tout au
long de mes activités professionnelles et personnelles, j’ai réalisé de la
gestion de projet sans même parfois en avoir pleinement conscience.
J’ai choisi de décrire ma mission de chef de projet réalisé au sein
d’une société de service et d’ingénierie en informatique en choisissant un
des projets dirigés durant ma période d’emploi de 1999 à 2002. Le projet
choisi est un des projets menés pour une filiale en Europe de l’Est d’un
constructeur automobile français de juin 2000 à janvier 2002. Par la
narration de ce projet, je vais essayer de démontrer au travers de
l’analyse de cette expérience, ma capacité à agir en tant que chef de
projet et montrer ma compréhension du sujet.
I.1 Avertissement
Aujourd’hui dans le cadre de ce mémoire, je développe et j’analyse
ma façon de travailler et de penser. Mais à l’époque du projet, j’ai mis en
œuvre des savoir-faire et des savoir-être non conscientisés que j’aurai eu
bien du mal à expliquer. Ma formation au sein du ministère de la Défense
où j’ai été entraîné à agir en milieu risqué, incertain et dangereux a été un

des éléments importants de mes prises de décision du moment, même si
j’étais incapable de l’expliquer. Mon long séjour en Europe de l’Est a aussi
renforcé mes réflexes de survie vis-à-vis de situations instables,
imprévues et changeantes.
Aujourd’hui ce travail plus académique de réflexion et d’explication
risque d’introduire un biais et quelques doutes dans la compréhension du
lecteur sur mes motivations et sur la manière d’agir. Je voudrais ajouter
que l'on ne peut pas juger les faits en dehors de leur contexte, car le
jugement porterait sur les apparences de l'acte et non pas sur son sens
profond.
I.2 Plan du mémoire
Après un avertissement sur le contenu de ce mémoire, je présente
le sujet et le but de ce mémoire. Je dresse une ébauche du cadre
théorique de mon approche en détaillant la méthodologie utilisée, ainsi
que les concepts utilisés dans ce mémoire. Je narre par écrit l’histoire de
mon projet « la voix du client » en expliquant les circonstances de ma
nomination, ainsi que le déroulement du projet jusqu’à sa clôture.
Je n’oublie pas d’expliquer les postulats initiaux concernant le
contexte du projet au niveau stratégique et au niveau du projet lui-même
où il faut tout bâtir dans un délai très court. Je n’oublie pas de souligner
les contraintes du projet ainsi que les circonstances du choix du progiciel1
ou logiciel standard utilisé. Après avoir décrit et expliqué le type de projet
que j’ai réalisé, je confronte ma méthodologie de management de projet à
la théorie. J’explique les divers points sur lesquelles j’ai focalisé mon
attention dans le cadre de mon action. J’insiste aussi sur la synergie créée
1
J’utiliserai dans ce mémoire le terme de « progiciel » terme consacré par le CXP
(Centre d’eXpertise des Progiciels) au lien de logiciel standard.

entre le chef de projet et le business analyste. Après l’ensemble de mes
explications, je présente la conclusion de ce mémoire.
I.3 Le sujet et le but du mémoire
Mon intervention s’est déroulée sur plus d’un an et demi dans le
cadre d’une gestion de projet qui a évolué en management de projet, puis
en gestion de programme sur une durée totale de 17 mois, avec un
périmètre débordant largement le périmètre initial, et une équipe allant
jusqu’à 20 personnes en management direct et indirect, comprenant
divers sous-traitants. Le périmètre de ce mémoire couvrira uniquement la
gestion du projet concernant la mise en place du logiciel de GRC pour un
centre de contacts.
I.3.1 Le sujet : la mise en place d’un logiciel de GRC
pour un centre de contacts
Le projet que j’ai choisi est la mise en place d’un système
d’information pour le futur centre de contacts d’une usine de fabrication
automobile, filiale d’un grand groupe français. En tant que chef de projet,
j’ai conçu et mis en place un outil de Gestion de la Relation Clients (GRC)
d’un centre de contacts nommé – La Voix du Client –2
. C’est un centre de
contacts entrants et sortants d’une centaine de positions. En Europe du
Sud-est, ce projet proprement dit a duré 10 mois, de septembre 2000 à
juin 2001, en dehors de la période de préparation de la mission et de
formation.
J’ai choisi ce projet en particulier, car je le considère comme l’un des
projets le plus complet et le plus représentatif dans le cadre de ma
mission de chef de projet. Ce projet, comme je le démontrerai plus tard,
peut être défini comme un projet complexe avec une approche innovante
2
Ou bien « Vocea Clientului » en Roumains.

dans un environnement mouvant et multiculturel. Ce projet est aussi
choisi pour son importance pour moi et pour ma capacité à valoriser cette
expérience particulière. Un autre élément important de mon choix est le
fait d’avoir pu disposer de données, d’informations, de documents
accessibles de façon significative sur ce projet-là.
I.3.2 Le but du mémoire : faire émerger un schéma
opératoire à partir d’une pratique empirique
Je démontrerai tout au long de la narration de ce projet qu’ayant
appris la gestion de projet « sur le tas » sans aucune formation théorique
et certification préalables, j’ai mis en place des solutions et œuvré en
dehors de toutes « normes », mais en recoupant largement ce que les
différentes méthodologies existantes préconisent. En relatant mon projet
comme une étude de cas, je vais analyser ce que j’ai fait, pourquoi et
comment je l’ai fait, et décrire quelles ont été mes motivations. Je vais
aussi passer mes actions au travers des principales méthodes de gestion
de projet connues (PMI, OCG, IPMA) ainsi que les méthodes internes aux
entreprises côtoyées pour analyser ma démarche. Je vais démontrer que
sans le savoir, j’ai réussi à créer ma propre méthode cohérente basée sur
une approche que nous pourrons qualifier de « multi méthodes ».
Ce projet essaye de souligner que le suivi d’une méthodologie
apprise au préalable n’est pas pour moi la seule garantie de réussite d’un
projet, mais peut sûrement y contribuer. Je vais chercher à démontrer au
travers de ce projet que des règles simples et strictes de mise en œuvre
au travers de mon savoir-être et d’une certaine « intelligence », allié à
mes savoir-faire (expérience) me permettent de mener à terme un projet
complexe en environnement multiculturel avec succès. D’autre part,
comme je vais le démontrer dans la suite de ce mémoire, la grande liberté
d’adaptation que j’ai su me donner dans un environnement complexe et
innovant a été un des facteurs supplémentaires de réussite du projet.

Au travers de ce mémoire, j’expose ma capacité à évoluer comme
chef de projet. Je cherche à faire émerger un schéma opératoire non
conscient qui va donner du sens à ma pratique. Je confronte cette
pratique à la théorie en management de projet afin de mieux l’asseoir
dans ces fondements. De plus j’aborde certains points importants de mon
expérience qui viennent mettre en perspective, au travers d’une
application pratique, les différentes méthodes et outils mis en œuvre dans
la réalisation de ma mission.
I.4 Le cadre théorique : les concepts
J’ai souhaité développer dans ce mémoire une approche en deux
volets, avec un premier volet théorique et un deuxième volet plus
empirique. Le volet théorique me permet de situer la réflexion et vient
donner un cadre rigoureux et itératif d’analyse. Cette approche théorique
va contribuer à informer et questionner le deuxième volet de ce mémoire,
le volet empirique. Ce volet sera traité au travers de l’utilisation d’une
méthode d’analyse qualitative permettant de gagner en profondeur dans
l'analyse de l'objet de mon étude. La méthode d’analyse qualitative
choisie repose sur une étude de cas pour son intérêt à favoriser « la
découverte plus que la confirmation »3
de nouveaux savoirs et à apporter
une compréhension riche des réalités étudiées.
Dans la tradition sociologique de l’école de Chicago, je tiendrai
compte de « l’interactionnisme symbolique »4
, reconnu par plusieurs
3
Merriam, Sharan B. Qualitative research and case study application in education.
2ème ed. San Francisco, CA: Jossey-Bass Publishers, 1998. p. 19.
4
Blumer, Herbert. Social psychology. Dans Schmidt, Emerson Peter (Ed.), Man
and society: a substantive introduction to the social sciences. New York, NY: Prentice-
Hall, 1937. Blumer, Herbert. Symbolic interactionism: perspective and method. Berkeley,
CA: University of California Press, 1986.

auteurs francophones5
, ce qui me permet de considérer les compétences
de l’acteur, moi-même, pour le sens qu’ils donnent à son vécu et la place
importante de la compréhension qu’il peut avoir de son agir6
. L’approche
portera sur les savoirs pratiques mis en œuvre, éclairé notamment par la
théorie de l'agir professionnel de Schön7
, car mes actes sont issus « d’un
jugement professionnel, d’une décision qui résultent d’une réflexion dans
l’action »8
.
I.4.1 L’étude de cas : des définitions
Selon un point de vue méthodologique, j’ai décidé de travailler sur
une étude de cas représentée par le projet choisi. Mon étude de cas va
s’inscrire dans un processus de formation, qui me permet de faire le lien
entre une situation que j’ai vécue et une prise de conscience des savoirs
que j’ai mobilisés. Elle me permet aussi de réaliser un questionnement sur
mes connaissances et par là même de réaliser un perfectionnement de
mes compétences9
.
L’étude de cas traditionnelle est une étude approfondie sur un cas
particulier ou un sujet spécifique, généralement utilisée dans une
5
Le Breton, David. L'interactionnisme symbolique. Paris: Presses Universitaires de
France, 2004. Le Breton, David. L'interactionnisme symbolique de Blumer à Goffman
Paris: Presses Universitaires de France, 2008. Pessin, Alain. Un sociologue en liberté.
Lecture de Howard S. Becker. Saint-Nicolas, QC: Presses de l'Université Laval, 2004.
6
Guignon, Sylvie. Des savoirs pratiques construits à partir de récits d'intervention
de coachs en entreprise [En ligne]. (Maître ès arts), Sciences de l'éducation de
l'Université Laval, 2006. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<www.theses.ulaval.ca/2006/23831/23831.pdf>.
7
Schön, Donald A. Le praticien réflexif : à la recherche du savoir caché dans l'agir
professionnel. Trans. The Reflexive Practitioner par Gagnon, Dolorès and Heynemand
Jacques. Montréal: Les éditions Logiques, 1993.
8
Perrenoud, Philippe. Mettre la pratique réflexive au centre du projet de formation
[En ligne]. Cahiers Pédagogiques, Janvier 2001, 2001, no. 390. [Cité le 23 janv. 2011].
Html. Disponible à partir de:
<http://www.unige.ch/fapse/SSE/teachers/perrenoud/php_2001/2001_02.html>.
9
Vergniory, Sonia (Cord.). La technique de l'étude de cas [En ligne]. Rennes:
Collège Régional d'Education pour la Santé de Bretagne, 2008. [Cité le 23 jan. 2011].
Pdf. Disponible à partir de: <Http://www.cresbretagne.fr/>.

approche de recherche qualitative pour démontrer ou établir une théorie.
L’étude de cas s’est aussi développée comme une méthode pédagogique
spécifique d’enseignement rendu célèbre par l’Université de Harvard10
.
Cette dernière est fondée essentiellement sur l’analyse de situations
vraies, utilisant des problèmes de la vie réelle pour entraîner les étudiants
à aborder des situations concrètes, illustrer un point ou faire ressortir un
élément important dans l’apprentissage11
. Cette méthode se justifie par
une approche de pédagogie active utilisée à l’université et dans la
formation continue.
L’étude de cas est un support de réflexion, qui permet de mettre en
évidence une situation d’apprentissage en tant qu’outil d’appropriation au
travers de la réflexion et de la confrontation d’un agir avec la théorie.
« C’est une méthode dynamique, qui stimule l’effort de l’apprenant en lui
donnant un rôle actif »12
. On a souvent recours à la méthode des études
de cas « - notamment dans le cas des évaluations - lorsque l’on veut
observer des effets ou vérifier des hypothèses »13
. Ainsi l’approche par
l’étude de cas dans mon contexte est très intéressante, car « l’on peut
ainsi acquérir des connaissances théoriques pertinentes sur l’objet
d’étude »14
tout en parlant d’une certaine représentativité théorique15
.
10
Juarrero, José Martin. Petite histoire de la méthode des cas... [En ligne]. Paris:
Centrale de Cas et de Médias Pédagogiques - Chambre de commerce et d'industrie de
Paris, p. 13. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<http://www.ccmp.fr/web5_bdc/MDC_ensavoirplus.fr>.
11
Kennedy, Mary M. Generalizing from Single Case Studies (Généralisation à
partir d'études de cas uniques). Evaluation Quarterly, November 1979 1979, vol. 3, no. 4
661-678. ; Stake, Robert E. Case Studies. Dans Denzin, Norman K. (Ed.), Strategies of
qualitative inquiry. 2ème ed. Thousand Oaks, CA: Sage Publications, Inc., 2003. 2 vols.
Vol. 2.
12
Cova, Bernard et de la Baume Charles. Cas et méthode des Cas : fondements,
concepts et universalité. Gestion 2000, Juin-juillet, 1991, no. 3.
13
Müller, Franziska, Bachmann Ruth, Spreyermann Christine, et al. Projets de
mentoring : Etudes de cas [En ligne]. Berne: Secrétariat d'Etat à l'éducation et à la
recherche SER, 2008. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<http://www.unifr.ch/f-mentoring/assets/files/Mentoring_Chancengleichheit_fr.pdf>.
14
Ibid. Projets de mentoring : Etudes de cas.

La conduite de mon étude de cas répondra à un double objectif. Un
objectif thématique et méthodologique. En effet, l’étude de cas compte
parmi les rares démarches de recherche en sciences sociales qui conjugue
l’observation directe et les différentes sources documentaires relatives aux
pratiques et aux discours pertinents à l’objet d’étude. J’utiliserai ainsi
cette étude de cas, comme une méthode d’analyse empirique qui vise à
analyser un phénomène dans son contexte. Cette méthode est
notamment employée quand les limites entre l’objet de l’analyse et le
contexte ne sont pas évidentes dès le départ16
. Pour moi, l’étude de cas
sera utilisée comme un élément d’analyse des processus « que les
individus utilisent pour mener à bien les différentes opérations qu’ils
accomplissent dans leur vie quotidienne »17
et dans mon cas précis, lié à
une pratique professionnelle. Dans une situation d’observateur a posteriori
à l’action menée, car au moment des faits j’étais acteur, je vais cibler un
savoir transférable pour passer du singulier au général. Les notions mises
en évidence dans cette étude pourront être utilisées à d’autres échelles et
dans d’autres contextes même si cette étude de cas n’est qu’un cas
singulier.
Généralement pour obtenir un résultat convenable, il est important
de choisir un terrain d’étude pertinente qui permet de valider la question
de recherche18
en faisant une sélection adéquate du cas étudié19
. J’ai donc
15
Hermanns, Harry. Die Auswertung narrativer Interviews. Ein Beispiel für
qualitative Verfahren [En ligne]. (L'analyse des entretiens narratifs. Un exemple de
méthodes qualitatives). Dans Hoffmeyer-Zlotnik, Jürgen H. P. (Hrsg.) (Ed.), Analyse
verbaler Daten. Über den Umgang mit qualitativen Daten. Opladen: Westdeutscher
Verlag GmbH, 1992Pdf. Disponible à partir de:
<http://www.hermanns.it/publication/hermanns_auswertung_narrativer_interviews.pdf>
.
16
Yin, Robert K. The case study method as a tool for doing evaluation (La
méthode des études de cas comme un outil pour réaliser l'évaluation). Current Sociology,
1992, vol. 40, no. 1.
17
Hlady Rispal, Martine La méthode des cas : Application à la recherche en
gestion. Bruxelles: De Boeck Université, 2002.
18
Patton, Michael Quinn. Qualitative evaluation methods. 3ème ed. Thousand
Oaks, CA: Sage Publications, Inc., 2002. ; Yin, Robert K. Case Study Research: design
and methods. 4ème ed. Thousand Oaks, CA: Sage Publications, Inc., 2009.

considéré comme critères de choix de mon étude de cas, l’importance du
projet réalisé et ma capacité à valoriser cette expérience. Cette étude de
cas est donc choisie et étudiée parce qu’elle représente par ses
caractéristiques propres et communes, un intérêt certain pour notre
étude20
. Néanmoins, je tiens à préciser que la généralisation de l’étude ne
pourra pas être utilisée de façon générale en dehors de l’objet d’étude :
moi-même.
I.4.2 Les concepts utilisés dans ce mémoire
« Nos sociétés modernes sont devenues des « sociétés à projets ». Les
projets concernent autant les institutions (projet scolaire, projet d'établissement
hospitalier, projet de loi, projet politique, projet de société...) que les individus, à
tous les stades de la vie (du projet éducatif au projet de retraite, en passant par
les projets professionnels, familiaux, existentiels...). Cette omniprésence du mode
projet dans tous les aspects de l'activité humaine renvoie à une vision idéalisée de
ce mode d'action. Le projet semble alors devenu un instrument qui donne l'espoir
à l'homme de ne plus seulement subir les événements, mais de pouvoir maîtriser
le cours de l'histoire et forger le futur à sa façon. »21
.
Dans ce chapitre je vais définir les concepts utilisés dans ce
mémoire. J’explique ce que l’on entend par la notion de « projet ».
Ensuite, j’explique la différence entre la gestion versus le management de
projet. Enfin j’explique ce que l’on qualifie par les progiciels de gestion
intégrée.
19
Miles, Matthew B. et Huberman A. Michael Analyse des données qualitatives.
Trans. Qualitative Data Analysis, An expanded sourcebook par Rispal, Martine Hlady
2ème ed. Bruxelles: De Boerk Université 2003. ; Stake, Robert E. Case Studies. Dans
Denzin, Norman K. (Ed.), Strategies of qualitative inquiry. 2ème ed. Thousand Oaks, CA:
Sage Publications, Inc., 2003. 2 vols. Vol. 2.
20
Stake, Robert E. Case Studies. Dans Denzin, Norman K. (Ed.), Strategies of
qualitative inquiry. 2ème ed. Thousand Oaks, CA: Sage Publications, Inc., 2003. 2 vols.
Vol. 2. p. 12.
21
Asquin, Alain, Falcoz Christophe et Picq Thierry. Ce que manager par projet
veut dire. Paris: Editions d'Organisation, 2005.

Dans le cadre de notre époque moderne avec la venue de la
révolution industrielle, ces dernières années il y a une volonté de mieux
gérer les ressources avec un besoin de retour sur investissement plus
rapide. L’informatisation de l’activité de l’entreprise encourage l’utilisation
d’outils et de méthodes pour répondre aux besoins de maîtrise et de
rigueur dans les affaires. Le métier de chef de projet n’a pas échappé à
cette règle, imposant rapidement la nécessité de l’utilisation de méthodes
et de normes communes. Cette nécessité s’est concrétisée par la mise en
place de projets. « Projet » est donc un mot souvent employé dans
différents environnements et qui peut recouvrir des réalités différentes.
Généralement, un projet est considéré, réalisé dans un milieu
inconnu, innovant, avec une organisation temporaire, dont les processus
sont historiques et les décisions irréversibles. Il y a une incertitude forte
avec des variables exogènes, non contrôlables, mais avec un certain degré
de liberté. D’autre part, le cash-flow est négatif, car il faut investir avant
d’avoir un retour sur investissement financier. De plus, la difficulté est de
générer un « saut dans l’inconnu » parfois complexe. Le projet a toujours
eu une place particulière dans l’entreprise et vient souvent en choc par
rapport à son fonctionnement qui est basé sur la productivité. Le projet
est donc en opposition à la notion de production, l’élément de base de
l’entreprise.
Depuis plus de trente ans, un certain nombre d’associations
professionnelles ont œuvré pour faire reconnaître le rôle et les
compétences particulières des chefs de projet, ainsi que pour définir des
méthodologies d’intervention. Plusieurs sources telles que l’association
internationale de normalisation (ISO), l’association française de
normalisation (AFNOR), l’association francophone de management de
projet (AFITEP), l’institut de management de projet (PMI), l’office du
commerce britannique (OGC), l’unité de stratégie informatique de la
Confédération helvétique (USIC), l’association internationale du

management de projet (IPMA) ou bien encore, l’association japonaise du
management de projet (PMAJ) ont une définition propre de ce qu’est un
projet. Depuis plus de 40 ans, la recherche en management de projet
s’interroge aussi sur la notion de projet22
. D’ailleurs plusieurs auteurs ont
essayé de définir le terme de « projet ». Par exemple Rodney Turner23
,
par l’utilisation d’une approche se basant sur la logique des
mathématiques, a établi une hypothèse sur la nature du projet. Il existe
donc des dizaines de méthodes de gestion de projet avec autant de
définitions du « projet » qui se recoupent souvent très largement.
I.4.2.1 Projet : des définitions
Les définitions normalisées du projet, selon les différentes sources,
peuvent revêtir plusieurs sens.
Selon la norme ISO10006 de 2003, un projet est un « processus
unique, qui consiste en un ensemble d’activités coordonnées et maîtrisées
comportant des dates de début et de fin, entrepris dans le but d’atteindre
un objectif conforme à des exigences spécifiques telles que les contraintes
22
Hanisch, Bastian et Wald Andreas. A Projet Management Research Framework
Integrating Multiple Theorical Perspectives and Influencing Factors (Un cadre de
recherche en gestion Projet qui intègrent les multiples perspectives théoriques et les
facteurs influants). Project Management Journal, 2011, vol. 42, no. 3. p. 4-22.
23
Turner, Rodney J. . Editorial: Towards a Theory of Project Management: The
Functions of Project Management (Editorial : A travers la théorie du management de
projet : Les fonctions du management de projet). International Journal of Project
Management, 2006a, vol. 24. Turner, Rodney J. . Editorial: Towards a Theory of Project
Management: The Nature of the Functions of Project Management (Editorial : A travers
la théorie du management de projet : La nature des fonctions du management de
projet). International Journal of Project Management, 2006b, vol. 24. Turner, Rodney J. .
Editorial: Towards a Theory of Project Management: The Nature of the Project (Editorial
: A travers la théorie du management de projet : La nature du management de projet).
International Journal of Project Management, 2006c, vol. 24. Turner, Rodney J. .
Editorial: Towards a Theory of Project Management: The Nature of the Project
Governance and Project Management (Editorial : A travers la théorie du management de
projet : La nature de la gouvernance de projet et du management de projet).
International Journal of Project Management, 2006d, vol. 24.

de délais, de coûts et de ressources »24
. Historiquement, un projet est
décrit par l’Afnor comme étant « une démarche spécifique, nouvelle, qui
structure méthodiquement et progressivement une réalité à venir pour
laquelle on n’a pas encore d’équivalent »25
. De même source selon
l’Afitep, une association d’origine française, « le projet est un ensemble
d’actions à réaliser pour satisfaire un objectif défini, dans le cadre d’une
mission précise et pour la réalisation desquelles on a identifié non
seulement un début, mais aussi une fin »26
. Selon le PMI, une association
internationale de gestion de projet d’origine nord-américaine, « un projet
est un effort temporaire dans le but de créer un produit, un service ou un
résultat unique. La nature temporaire des projets implique un
commencement et une fin déterminés »27
. Pour l’IPMA, une autre
association de management de projet international d’origine européenne,
« un projet est une intervention limitée par des contraintes temporelles et
financières dont le but est la production d’un ensemble de livrables
prédéfinis répondant à des exigences et à des standards de qualité »28
. Un
projet selon l’OGC, organisme gouvernemental anglais, est « une
organisation temporaire, créée en vue de livrer un ou plusieurs produits
d’entreprise conformément à un cas d’affaire convenu »29
. Pour le PMAJ,
24
___. Système de management de la qualité - Lignes directrices pour le
management de la qualité dans les projets [En ligne]. Genéve: Organisation International
de Normalisation, 2003b. (ISO 10006:2003). [Cité le 23 jnv. 2011]. Pdf. Disponible à
partir de: <http://marcelrzmut.comxa.com/2APII/ISO100062003.pdf>.
25
AFNOR. Le management de projet. Concept. Saint-Denis La Plaine: Association
Française de Normalisation, 1991. (FD X50-105).
26
Association Francophone de Management de Projet. Dictionnaire de
management de projet. 3ème ed. Paris: Association Française de Normalisation, 1996.
27
Project Management Institute. Corpus des connaissances en management de
projet (Guide PMBOK). 4ème ed. Newtown Square, PA: Project Management Institute,
Inc., 2008.
28
Caupin, Gilles, Knoepfel Hans, Koch Gerrit, et al. ICB - IPMA Competence
Baseline [En ligne]. (Référentiel international de compétences en management de
projet). 3ème ed. Nijkerk, Netherland: International Project Management Association,
2006. [Cité le 20 jan. 2011]. Pdf. Disponible à partir de:
<http://ipmadownloads.camako.com/Downloads/ICB3.pdf>.
29
Office of Government Commerce. Réussir le management de projet avec
PRINCE2. 5ème ed. Norwich, Royaume-Uni: The Stationery Office, 2009.

l’association de management de projet japonais, « un projet se réfère à
une entreprise de création de valeur fondée sur un thème particulier, qui
est réalisé dans un délai et des contraintes donnés ou convenus, en
incluant des ressources et des circonstances externes »30
. Pour Rodney
Tuner « un projet est une organisation temporaire à laquelle des
ressources sont allouées pour réaliser le travail d’apporter des
changements bénéfiques »31
tout en consommant « des ressources,
particulièrement financières »32
.
Mais au travers de toutes ces définitions, qu’est-ce qui définit au
fond un projet ? En recensant les multiples définitions ci-dessus, on peut
identifier plusieurs composantes principales du projet.
Un projet est unique, sujet à des contraintes temporelles
(comportant un début et une fin) et environnementales (parties
prenantes, changements divers). La réalisation d’un projet mobilise des
ressources diverses telles que des ressources financières, humaines et
matérielles. Le projet conduit à la production d’un extrant sous quelque
forme que ce soit. La réalisation d’un projet nécessite la mise en œuvre de
compétences particulières de savoir-faire et de savoir-être. De plus, selon
le type et la nature du projet, la démarche de réalisation peut varier en
30
Project Management Association of Japan. A Guidebook of Project & Program
Management for Entreprise Innovation "P2M" [En ligne]. (Guide du management de
projet et de programme pour l'entreprise de l'innovation "P2M"). 2ème ed. 2 vols. Vol. 1.
Japan: Project Management Association of Japan, 2006. [Cité le 23 jan. 2011]. Pdf.
Disponible à partir de:
<http://www.plaj.or.jp/ENG/P2M_Dowload/P2MGuidebookVolume1_060112.pdf>.
Traduction de Marc Bonnemains.
31
32

prenant une structure générale découpée en différentes grandes phases
telles que la préparation, la mise en œuvre et l’évaluation33
.
Nous pouvons aussi faire les remarques suivantes concernant le
projet. Alors que la méthodologie du PMI se concentre plus
particulièrement sur les processus de la gestion de projet, la méthodologie
Prince2 (Project IN Controlled Environment) de l’OGC se concentre plus
sur le produit à livrer, alors que le modèle ICB (IPMA Competence
Baseline) de l’IPMA se concentre plus sur les aptitudes du chef de projet.
La méthodologie P2M du PMJA, elle, se focalise sur la complexité et les
changements (social, économique, environnemental, technologique) du
projet.
Il serait tout aussi intéressant d’étudier la sémantique et les
interférences culturelles avec la définition d’un projet et la portée que cela
peut sous-entendre dans sa mise en pratique, entre le sens francophone,
le sens anglophone et le sens japonophone de ce dernier. Dans le sens
francophone, la notion de projet s’attache plus à l’aspect intentionnel des
choses et à l’objectif à atteindre qu’à la période du passage à l’acte et du
déroulement de celui-ci34
. Ils privilégient « le contenu (l’objet en train de
se construire) »35
. Alors que les Anglo-saxons, plus pragmatiques
s’attachent à définir la façon d’atteindre l’objectif. Ils insistent « sur le
processus et les moyens (l’organisation et la démarche pour le
33
Denoual, Gérard. Intégration du développement durable dans la gestion de
projets : l'exemple du transport (Maîtrise), Centre universitaire de formation en
environnement, Université de Sherbrooke, 2003. Champagne St-Arnaud, Valériane.
Conception d'une grille d'évaluation des changements comportemantaux en matière de
développement durable [En ligne]. (Maîtrise), Centre Universitaire de Formation en
Environnement, Université de Sherbrooke, 2009. [Cité le 23 jan. 2011]. Pdf. Disponible à
partir de:
<http://www.usherbrooke.ca/environnement/fileadmin/sites/environnement/documents/
Essais2009/Champagne_St-Arnaud_V_-_10-05-09.pdf>.
34
Joly, Michel et Muller Jean-Louis G. De la gestion de projet au management par
projet. Paris: Association Française de Normalisation, 1994.
35
Asquin, Alain, Falcoz Christophe et Picq Thierry. Ce que manager par projet
veut dire. Paris: Editions d'Organisation, 2005. p. 6.

construire) »36
. Les Japonais ont une approche plus systémique dans une
démarche ascendante intégrant la notion de collectivité et d’harmonie
pour faire émerger la force et la capacité du projet.
Il faudrait aussi prendre en compte les différents effets de mode et
de tendances dans la gestion de projet37
, ainsi que les différentes écoles
en management de projet38
.
N’étant pas là pour analyser les différentes méthodologies de projet,
je reviendrais donc à mon étude de cas avec une approche plus
pragmatique.
Maintenant que le projet est défini, je vais m’intéresser à la gestion
de projet et au management de projet. Quels en sont les attributs et
36
Ibid.
37
Giard, Vincent et Midler Christophe. Management et gestion de projet : une
étude des mutations en cours [En ligne]. Lettre trimestrielle, 1994, no. 1994-02. [Cité le
23 jan. 2011]. Pdf. Disponible à partir de:
<http://www.gregoriae.com/dmdocuments/1994-02.pdf>.
38
Bredillet, Christophe N. Exploring research in project management - Nine
schools of project management research (part 1) (Recherche d'exploration dans le
management de projet - Neuf écoles de recherche en management de projet (Part. 1)).
Project Management Journal, 2007a, vol. 38, no. 2. Bredillet, Christophe N. Exploring
research in project management - Nine schools of project management research (part 2)
(Recherche d'exploration dans le management de projet - Neuf écoles de recherche en
management de projet (Part. 2)). Project Management Journal, 2007b, vol. 38, no. 3.
Bredillet, Christophe N. Exploring research in project management - Nine schools of
project management research (part 3) (Recherche d'exploration dans le management de
projet - Neuf écoles de recherche en management de projet (Part. 3)). Project
Management Journal, 2007c, vol. 38, no. 4. Bredillet, Christophe N. Exploring research in
project management - Nine schools of project management research (part 4)
management de projet (Part. 4)). Project Management Journal, 2008a, vol. 39, no. 1.
Bredillet, Christophe N. Exploring research in project management - Nine schools of
project management research (part 5) (Recherche d'exploration dans le management de
projet - Neuf écoles de recherche en management de projet (Part. 5)). Project
Management Journal, 2008b, vol. 39, no. 2. Bredillet, Christophe N. Exploring research in
project management - Nine schools of project management research (part 6)
management de projet (Part. 6)). Project Management Journal, 2008c, vol. 39, no. 3.
Chritophe Bredillet a identifié neuf écoles en management de projet qui sont : the
Optimization school, the Modeling School, the Governance School, the Behavior School,
the Success School, the Decision School, the Process School, the Contingency School,
and the Marketing School.

qu’elle est la différence entre la gestion de projet versus le management
de projet ?
I.4.2.2 « Gestion » ou « management » de projet ?
Les termes de « gestion de projet » et de « management de
projets » recouvrent des dimensions différentes. La notion de
« management de projet » est considérée comme plus large que celle de
« gestion de projet »39
. La gestion de projet puise son origine depuis que
l’on réalise des projets pharaoniques. Beaucoup plus modélisé au 19e
siècle avec les premières réalisations de grands travaux en Amérique du
Nord et l’émergence de grands théoriciens du travail et de l’organisation
tels que Frédéric Wilson Taylor (1856-1915), Henry Laurence Gantt
(1861-1919), Henri Fayol (1841-1925) et bien d’autres… Une approche
plus classique et industrielle apparaît dans les années 50-60 pour de
grands projets (militaires, nucléaire, construction navale, aéronautique,
pétrolier, BTP…) où l’accent est mis sur les outils et les méthodes de
structuration du projet, avec une prise en compte de la planification, du
contrôle des ressources, des coûts et de la qualité, ainsi que de la maîtrise
des délais. En fait, la gestion de projet se limite à la gestion appliquée au
système qu'est le projet, tandis que la direction de projet intègre
l'ensemble des aspects stratégiques, politiques, organisationnels et
humains, ainsi que la définition des objectifs et des finalités. Le
management de projet est la synthèse de ces deux notions en incluant
tant la gestion du projet que la direction du projet. Cette définition est
confirmée par l’Afnor qui précise que le management de projet recouvre
deux niveaux de responsabilité ; la direction de projet sous-entendu
l’organisation et la gestion du projet représentée par les méthodes et les
39
AFNOR. Norme X50-115 - Management de projet - Presentation générale [En
ligne]. Décembre 2001 ed. Vol. Norme X50-115. Saint-Denis La Plaine: Association
Française de Normalisation, 2001c. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<http://membres.multimania.fr/vincentor/x50/X50-
115%20Management%20de%20projet.pdf>.

outils. Pour le PMI, « le management de projet est l’application de
connaissances, de compétences, d’outils et de techniques aux activités
d’un projet afin de satisfaire les exigences »40
. Par contre pour l’IPMA, « le
management de projet consiste à planifier, organiser, suivre et maîtriser
tous les aspects d'un projet, ainsi que la motivation de toutes les
personnes impliquées dans le projet (parties prenantes), de façon à
atteindre les objectifs de façon certaine et dans des critères définis de
coûts, de délais et de performances »41
.
Le management de projet intègre donc deux volets. Un volet
organisationnel pour définir le quoi et le comment et un volet de pilotage
pour analyser la situation, mesurer les écarts et les impacts, ainsi
qu’assurer la mise en place des actions à entreprendre. De toute façon, la
gestion du projet implique d’utiliser l’héritage de Henri Fayol pour
planifier, organiser, diriger et contrôler (PODC), mais aussi celui de Luther
Gulick avec le POSDCORB42
(planifier, organiser, recruter, diriger,
coordonner, rapporter, budgéter) énoncé plus tard dans un raffinement de
la notion43
.
Nous verrons tout au long de mon mémoire que si j’ai été en charge
de la gestion du projet, j’ai rapidement migré vers une direction de projet
pour réaliser en fin de compte du management de projet tel que défini ci-
dessus.
40
Project Management Institute. Corpus des connaissances en management de
projet (Guide PMBOK). 4ème ed. Newtown Square, PA: Project Management Institute,
Inc., 2008. p. 12.
41
Caupin, Gilles, Knoepfel Hans, Koch Gerrit, et al. ICB - IPMA Competence
Baseline [En ligne]. (Référentiel international de compétences en management de
projet). 3ème ed. Nijkerk, Netherland: International Project Management Association,
2006. [Cité le 20 jan. 2011]. Pdf. Disponible à partir de:
<http://ipmadownloads.camako.com/Downloads/ICB3.pdf>. p. 128. Traduction de Marc
Bonnemains.
42
POSDCORB est un anacronyme anglais pour planning, organizing, staffing,
directing, coordinating, reporting, budgeting.
43
Rouleau, Linda. Théorie des organisations : approches classiques,
contemporaines et de l'avant-garde. 2ème ed. Québec: Presses de l'Université du
Québec, 2007. p. 18.

I.4.2.3 Les outils de gestion intégrée : PGI et GRC
L’intervention qui sert de support à l’expérience développée dans ce
mémoire est un cas d’implantation d’un progiciel de gestion intégré (PGI
ou ERP en anglais pour Entreprise Resources Planning). Plus exactement,
l’intervention s’est focalisée sur l’implantation d’un outil de gestion de la
relation client (GRC ou aussi appelé en anglais, CRM pour Customers
Relationship Management) au profil d’un centre de contacts à créer.
I.4.2.3.1 Progiciel de gestion intégrée (PGI)
Depuis une dizaine d’années, la littérature, tant anglo-saxonne que
francophone, est devenue foisonnante sur le thème des PGI ou ERP. Pour
moi d’une façon générale, un PGI est une suite intégrée de logiciels
modulaires dont le but est de coordonner l’ensemble (ou une partie) des
processus de l’organisation d’une entreprise autour d’un même système
d’information. De manière plus académique, on peut définir un PGI
comme étant « une application informatique paramétrable, modulaire et
intégrée, qui visent à fédérer et optimiser les processus de gestion de
l’entreprise en proposant un référentiel unique et cohérent et en
s’appuyant sur des règles de gestion standard »44
.
L’outil fournit une structure centralisée composée de modules
fonctionnels généralement liés à une base centralisée de données avec
toutes les informations et les processus de l’entreprise. Il intègre toutes
les activités qui comprennent, la planification, le contrôle des stocks, la
fabrication, les ventes, le marketing, la finance, les services à la clientèle,
les ressources humaines, etc., d'une organisation afin d’améliorer son
efficacité opérationnelle. En un sens, c’est une convergence du personnel,
44
Pérotin, Pascal. Les Progiciels de Gestion Intégrés, instruments de l'intégration
organisationnelle ? - Etude d'un cas - [En ligne]. PhD (PhD), Economie et gestion,
Université de Montpellier II, 2004. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<http://halshs.archives-ouvertes.fr/docs/00/04/79/40/PDF/tel-00008966.pdf>.

du matériel et des logiciels dans un but de la réalisation d’une production
et de services de manière plus efficace afin de créer des profits pour
l’entreprise (figure 1). Les PGI ont évolué au fil du temps pour intégrer de
plus en plus la globalité de l’entreprise (tableau 1).
D’une manière générale, le choix d’un outil intégré permet à
l’entreprise de bénéficier de l’expertise et de l’expérience des acteurs du
domaine concerné, par la prise en compte des meilleures pratiques
d’affaires de leur métier. Normalement, il permet une mise en place
accélérée à l’inverse de la conception d’un système d’information
propriétaire, ainsi qu’une facilité de maintenance et de mise à jour des
fonctionnalités qui en découlent tout naturellement. Il présente aussi des
avantages importants, mais aussi des désavantages non négligeables.
L’évolution des PGI et des GRC a grandement impacté la gestion de
l’entreprise, son rapport à son système d’information, mais aussi la
gestion de projet elle-même.
Figure 1 : Schéma de progiciel de gestion intégrée (PGI ou ERP).

L’implantation d’un PGI, comme tout projet en système
d’information, n’est pas juste « l’installation d’un système informatique,
mais l’institutionnalisation de son utilisation dans le contexte en cours »45
de l’entreprise. Il suppose toujours une refonte de tout ou partie du
système d’information de l’entreprise. Il suppose aussi au sein de
l’organisation un changement dans les processus métiers de l’entreprise,
car il ne s’agit pas de simplement automatiser ce que l’on sait déjà faire,
mais de chercher à améliorer les méthodes et les pratiques existantes en
s’inspirant des meilleures pratiques du secteur. En général,
l’implémentation de tout progiciel de gestion intégrée (PGI) ou de GRC est
décrite comme une difficile et très coûteuse proposition, qui demande
d’énormes ressources et de disponibilité de la part de l’entreprise
concernée46
.
Tableau 1 : Historique de l’évolution des PGI ou ERP47
.
45
de Sutter, Jan. The power of IT: survival guide for the CIO. 2ème ed. North
Charleston, SC: BookSurge, LLC, 2004. p. 228. Traduction de Marc Bonnemains
46
Bhatti, T. R. Critical success factors for the implementation of entreprise
resource planning (ERP): empirical validation [En ligne]. (Facteurs critiques de succès
pour l'implémentation d'un progiciel de gestion intégré (PGI) : validation empirique).
Paper presented at the Second International Conference on Innovative in Information
Technology (IIT'05) on 26-28 sept. 2005. Dubai; UAE: MCB University Press. p. 10.
[cited 23 jan. 2011]. Pdf. Disponible à partir de:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.8236&rep=rep1&type=p
df>.
47
Hossain, Liaquat, Patrick Jon David et Rashid Mohammad A. Enterprise resource
planning: global opportunities and challenges (Progiciel de gestion intégré: opportunités
et challenges global). Hershey, PA: Idea Group Publishing, 2002. Pepin, Linda. Enterprise
Resource Planning [En ligne]. (Progiciel de gestion intégré). Montréal, QC: HEC Montréal,

L’implantation d’un PGI, comme d’un GRC nécessite une réingénierie
des processus d’affaires de l’entreprise. La réingénierie des processus
d’affaires est une « remise en cause fondamentale et une redéfinition
radicale des processus opérationnels existants, pour obtenir des gains
spectaculaires dans les performances - comme les coûts, la qualité, le
service, et la rapidité »48
. Mais, les PGI ou GRC peuvent être aussi vus
comme des instruments d’intégration de l’entreprise, car ils sont un
« véhicule du changement organisationnel »49
. Nous verrons que c’est
justement une des bases de justification du projet de GRC dans
l’entreprise cliente.
I.4.2.3.2 Gestion de la relation client (GRC)
Notre expérience s’est focalisée sur la mise en place d’un outil de
GRC, une fonction intégrée des PGI, mais pouvant être déployée
indépendamment. De façon basic, le CRM ou GRC est constitué de trois
éléments : client, relation et gestion50
. Un logiciel de GRC est « une
approche complète pour créer, maintenir et développer la relation avec le
client »51
. Pour Paul Greenberg la GRC peut être encore plus. Elle peut
2008. [Cité le 23 jan. 2011]. Disponible à partir de:
<http://zonecours.hec.ca/documents/H2008-1-
1575637.EnterpriseResourcePlanning(13).ppt>.
48
Hammer, Michael et Champy James. Reengineering the Corporation. A
Manifesto For Business Revolution (Réingénierie de l'entreprise : un manifeste pour la
révolution des affaires). New York, NY: HarperBusiness Essentials, 2003. Traduction de
Marc Bonnemains.
49
Hanseth, Ole et Braa Kristin Technology as Traitor: Emergent SAP
Infrastructure in a Global Organization [En ligne]. (La technologie comme traître :
Infrastructure SAP Emergente dans une organisation mondiale). Paper presented at the
Proceeding ICIS '98 Proceedings of the international conference on Information systems
on 13-16 déc. 1998. Helsinki: Association for Information Systems p. 9. [cited 23 jan.
2011]. Pdf. Disponible à partir de: <http://aisel.aisnet.org/icis1998/17>.
50
Gray, Paul et Byun Jangbok. Customer Relationship Management [En ligne].
(Gestion de la relation client). Irvine, CA: Center for Research on Information Technology
and Organiz - University of Califonia. August 2001, 2001. Pdf. Disponible à partir de:
<http://escholarship.org/uc/item/76n7d23r>.
51
Anderson, Kristin et Kerr Carol. Customer relationship management (Gestion
de la relation client). New York, NY: MacGraw-Hill Professional, 2002. Traduction de Marc
Bonnemains.

être vue comme « une philosophie et une stratégie d'entreprise, soutenue
par un système et une technologie, conçus pour améliorer les interactions
humaines dans un environnement d'affaires »52
. En fait, un outil de GRC
tente d'aboutir à une vue unique et intégrée de la clientèle (single
integrated view of customers) avec une approche centrée sur le client
(customer-centric approach)53
.
La recherche s’est penchée depuis plus d’une décennie sur la
définition de la GRC. La GRC peut être tour à tour définie comme un
ensemble de produits groupés de logiciels, de systèmes ou de
technologies54
. Mais aussi, elle peut être vue comme un stockage et une
analyse de données55
, tout comme une culture du changement dans
l’organisation concernée56
. Elle est aussi une pratique de management
focalisée sur la relation en opposition aux transactions57
tout comme une
52
Greenberg, Paul. Making CRM Whole-Brained [En ligne]. CRM Magazine, 2 fév.
2003, Fév. 2003. Medford, NJ: Information Today, Inc., 2003. Html. Disponible à partir
de: <http://www.destinationcrm.com/Articles/Columns-Departments/Reality-
Check/Making-CRM-Whole-Brained-48129.aspx>. Traduction de Marc Bonnemains.
53
Desmond, John P. It's the Customer, Stupid [En ligne]. (Est-ce que le client est
stupide ?). Software Magazine. Newton, MA: King Content Co, 2000. [Cité le 23 jan.
2011]. Html. Disponible à partir de: <http://www.softwaremag.com/focus-
areas/business-of-it/featured-articles/its-the-customer-stupid/>.
54
Gefen, David et Ridings Catherine M. Implementation Team Responsiveness and
User Evaluation of Customer Relationship Management: A Quasi-Experimental Design
Study of Social Exchange Theory [En ligne]. (Réactivité de l'équipe d'implémenatation et
évaluation des utilisateurs pour la gestion de la relation client: une étude de conception
quasi-expérimentale de la théorie des échanges). Journal of Management Information
Systems, 2002, vol. 19, no. 1. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<https://fp1.cc.lehigh.edu/cmr4/jmis.pdf>. Zikmund, William G., McLoad Raymond et
Gilbert Faye W. Customer relationship management: integrating marketing strategy and
information technology (Gestion de la relation client : intégration de la stratégie
marketing et des technologies de l'information). New York, NY: Wiley and Sons, 2003.
55
Hamilton, David P. E-Commerce (A Special Report): Openers-In Translation: A
Guide to the Baffling Jargon of Online Business-to-Business Commerce (E-Commerce
(Rapport spécial): Openers-In Translation : un guide sur le jargon déroutant du
commerce en ligne Business-to-Business). Wall Street Journal.
56
Anton, Jon et Petouhoff Natalie L. Customer Relationship Management: the
bottom line to optimizing Your ROI (Gestion de la relation client : la ligne du bas pour
optimiser votre ROI). 2ème ed. Upper Saddle River, NJ: Prentice-Hal, Inc., 2001.
57
Swift, Ronald S. Accelerating Customer Relationship (Accélérer la relation
client). Upper Saddle River, NJ: Prentice-Hall Inc., 2001. p. 15.

pratique demandée par le management58
. Enfin cela peut être comme une
stratégie qui focalise sur le client de l’entreprise59
.
Le Meta Group propose une définition de la GRC considérée comme
la plus spécifique et complète avec une orientation technologique60
. La
GRC (gestion de la relation client) est comme « l’automatisation des
processus d’affaires intégrées transversaux impliquant le front office avec
les points de contact avec le client (le management des contacts, la
configuration des produits), le marketing (la gestion des campagnes, le
marketing), et le service à la clientèle (centre d’appels, service sur le
terrain) - via de multiples canaux de distribution interconnectés
(téléphonie, courriel, Web, interaction directe). L’architecture de
l’application de GRC doit combiner les deux technologies opérationnelles
(orienté sur les transactions de gestion des processus d'affaires) ainsi
qu’analytiques (entrepôt de données centrées sur la gestion des
performances d’affaires) »61
.
L’implantation d’un outil de GRC « est un projet, puisqu’il demande
un travail spécifique, délimité dans le temps, avec une mission de mise en
place d’une nouvelle solution informatique pour supporter les fonctions de
gestion »62
. Or, si souvent ce type de projet est conduit à tort comme un
simple projet informatique, il couvre généralement une dimension
stratégique en changeant la manière de faire de l’entreprise et est
58
Bergeron, Bryan P. Essentials of CRM: A guide to Customer Relationship
Management (L'essentiel de la GRC : un guide de la gestion de la relation client). New
York, NY: Wiley & Sons, Inc., 2002.
59
Bodenberg, Thomas M. Customer Relationship Management: New Ways of
Keeping the Customer Satisfied (Gestion de la relation client : nouvelle voie pour
maintenir le client satisfait). New York, NY: The Conference Board. August 2001, 2001.
60
Baran, Roger Joseph, Galka Robert et Strunk Daniel P. Customer Relationship
Management (Gestion de la relation client). Mason, OH: Thomson South-Western, 2008.
61
Peel, Jeffrey. CRM: redefining customer relationship management (GRC :
redéfinir la gestion de la ralation client). Woburn, MA: Elsevier Science, 2002. Traduction
de Marc Bonnemains.
62
Darras, Franck. Proposition d'un cadre de référence pour la conception et
l'exploitation d'un progiciel de gestion intégré [En ligne]. Ph.D (Ph.D), Systèmes, Institut
National Polytechnique de Toulouse, 2004. [Cité le 11 nov. 2010]. Pdf. Disponible à partir
de: <http://www.univ-valenciennes.fr/GDR-MACS/these/These_f_darras.pdf>.

toujours porteur de promesses en termes de croissance du chiffre
d’affaires. Le projet de GRC mise, en plus du produit, sur un recentrage de
l’entreprise vers le client. Au départ, la mise en place d’un outil de GRC
est souvent juste un élément de la chaîne de la relation client de
l’entreprise. Cette décision d’implantation a été une décision stratégique
pour l’entreprise cliente, car ce projet va servir très vite à permettre de
repenser l’organisation et les relations avec les autres services de
l’entreprise. Cette approche expose souvent l’entreprise à des risques, car
l’organisation tend à devenir alors transversale, en n’étant plus seulement
découpée par grandes fonctions, mais par des macros processus qui
traversent les principales fonctions de l’entreprise63
.
Tableau 2 : Taux d’échecs de l’implantation des outils de GRC64
.
Mais, il faut souligner que depuis près d’une décennie, les
professionnels du secteur et plusieurs cabinets de consultance parlent
63
Davenport, Thomas H. et Short James E. The new industrial engineering:
information technology and business process redesign [En ligne]. (Le nouveau génie
industriel : les technologies de l'information et la refonte des processus d'affaires). Sloan
Management Review, Juin 1990, 1990, vol. 31, no. 4. [Cité le 23 jan. 2011]. Txt.
Disponible à partir de:
<http://www.archive.org/stream/newindustrialeng00dave/newindustrialeng00dave_djvu.
txt>. El Amrani, Redouane, Rowe Frantz, Bidan Marc, et al. Effets de la stratégie de
déploiement des PGI sur la vision transversale de l’entreprise [En ligne]. Revue française
de gestion, 20006/9, 2006, no. 168-169. [Cité le 23 janv. 2011]. Pdf. Disponible à partir
de: <http://s2.e-monsite.com/2010/04/04/11/RFG_168_0267.pdf>.
64
Krigsman, Michael. CRM failure rates: 2001-2009 [En ligne]. (GRC taux d'échecs
: 2001-2009). ZDNet - US Edition, 3 août 2009, 6:15 PDT. San Francisco, CA: CBS
Interactive Inc., 2009. [Cité le 23 jan. 2011]. Html. Disponible à partir de:
<http://www.zdnet.com/blog/projectfailures/crm-failure-rates-2001-2009/4967>.

d’un taux d’échecs particulièrement élevé lié aux types de projets
d’implantation de PGI et d’outils de GRC. Même si la définition d’échec est
subjective, depuis 2001 ils annoncent des taux avoisinant entre 18 % et
70 %65
(tableau 2).
I.4.2.3.3 Les facteurs clés de succès : des définitions
Ils se sont aussi penchés sur les facteurs qui sont les clés du succès
d’un projet de PGI et de GRC. Appelés généralement « facteurs clés de
succès » (FCS ou en anglais CSF pour critical success factor), ils peuvent
prendre diverses dénominations (facteurs critiques, clés du succès, enjeux
fondamentaux, etc.). Ils sont des paramètres importants dont la maîtrise
conditionne la bonne réalisation et la réussite du projet. Identifier ces
facteurs, au nombre restreint, permet de définir les points importants sur
lesquels le chef de projet doit se concentrer pour réussir l’implantation
d’un outil de GRC.
Les FCS ont été introduits dans les années 60 par D. Roland Daniel
(Daniel, 1961) de l’entreprise McKinsey & Company et raffinés par John F.
Rockart66
dans les années 80. Utilisés surtout dans les organisations dans
le cadre de la réflexion de leurs besoins fondamentaux et de leur marché,
ils tendent de plus en plus à être aussi utilisés dans la gestion de projet.
La détermination des FCS varie en fonction de la contingence des
projets, en fonction de l’environnement, mais aussi en fonction de la
vision de chaque chef de projet. Quels que soient les FCS définis, ils
permettent de focaliser les efforts de l’équipe du projet et d’avoir un point
65
Ibid.
66
Rockart, John F. et Bullen Christine V. A primer on critical success factors [EN
ligne]. (Un abécédaire sur les facteurs clès de succès). Center for Information Systems
Research, MIT, 1981. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<http://dspace.mit.edu/bitstream/handle/172.1/1998/SWP-1220-08368993-CISR-
069.pdf?sequence=1>.

de référence unique qui favorise la synergie du travail et de
communication avec les parties prenantes et le ou les sponsors. Ils ont
néanmoins quelques faiblesses potentielles, car ils ne sont pas des
stratégies, mais uniquement des termes qualitatifs mesurables (au travers
des indicateurs clés de performance – ICP ou key performance indicator –
KPI en anglais), appartenant à tous et à personne et pouvant changer
dans le temps67
.
Les FCS généralement définis pour l’implantation d’un projet de GRC
sont :
1. impliquer la direction de l’entreprise, car le projet doit
s’inscrire dans la stratégie de l’entreprise,
2. communiquer tout au long du projet,
3. impliquer les utilisateurs dès le début du projet,
4. tenir compte de la partie humaine du projet en
accompagnant avec une gestion du changement,
5. avoir une bonne définition des exigences et un bon niveau
d’expertise fonctionnelle,
6. impliquer dans le projet l’éditeur de la solution progicielle
choisie.
67
Kinaze, Ali. Les facteurs clès du succès (FCS) [En ligne]. Stratégies. s.l.:
WordPress, 2009. [Cité le 23 jan. 2011]. Html. Disponible à partir de:
<http://www.kinaze.org/facteurs-critiques-du-
succes/#Les+forces+des+facteurs+cl%C3%A9+de+succ%C3%A8s>.

II L’histoire de mon projet : « la voix du
client »
L’imprévisibilité est source de complexité.68
En juin 2000, au sein du département « Intégration de Système »
dans l’agence « Système d’Informatiques de Gestion » (SIG), l’on me
demanda de prendre en charge un projet de mise en place d’un outil de
Gestion de la Relation Clients (GRC) pour un centre de contacts de 100
positions au profit d’une usine automobile en Europe de l’Est, nouvelle
filiale d’un groupe constructeur automobile français. La prestation chez le
client avait été prévue initialement pour une durée de 8 mois, de
septembre 2000 à avril 2001 avec une équipe globale de 7 personnes
pour un coût total de quelques millions de francs. Mais rapidement, le
projet initial a été étendu dans son contenu (scope) et dans sa durée (3
mois de plus) à la demande du client pour se terminer à la fin du mois de
juin 2001.
II.1 Ma nomination : les dés sont jetés
Normalement, je n’étais pas pressenti pour cette mission en Europe
de l’Est. Mon supérieur hiérarchique et patron du département
« intégration de système » ne voulait pas que j’intervienne sur ce type de
mission pour des raisons qui lui étaient propres. Je l’avais apprise au
travers d’une de ses réflexions qu’il m’avait « lâchées » dans un couloir de
l’entreprise et que je n’avais pas relevées sur l’instant. De plus à l’époque,
je n’étais pas au courant de ce projet et de sa négociation en cours. À ma
grande surprise, un jour de juin 2000 un directeur de projet d’une de nos
68
Le Moigne, Jean-Louis. La Modélisation des systèmes complexes. Paris: Dunod,
1999.

filiales69
est venu me demander de participer au projet de création d’un
centre de contacts dans un des pays d’Europe centrale et orientale (PECO)
au profit de la nouvelle filiale d’une entreprise française. Cette demande
m’a été faite directement sans l’accord préalable de ma hiérarchie et sans
attendre mon refus, comme un fait évident d’acceptation de ma part et de
la hiérarchie de l’entreprise. J’ai appris par la suite que ce directeur de
projet, Éric, avait imposé à notre hiérarchie que j’intervienne comme chef
de projet pour cette mission. Il m’avait vu opérer sur un de mes projets
précédents d’implantation d’outils de GRC et savait que j’avais passé
plusieurs années dans les pays de l’Est de l’Europe.
Figure 2 : Proposition commerciale pour le projet de centre de
contacts70
.
Rapidement, Éric me présenta la mission (figure 2) et me demanda
d’initialiser et d’organiser le projet pour une intervention qui devrait faire
suite à l’étude de cadrage réalisée par deux de ses consultants, Mathieu et
François, dans le cadre de la définition des processus métiers et du
périmètre du futur centre de contacts. Sur une de nos réflexions, ce projet
prendra rapidement le nom de code de « la voix du client » ou en roumain
69
Un cabinet d’experts, focalisé sur l’amelioration de la performance des
entreprises, intervenant au niveau stratégique et opérationnel par une approche
combinée des processus métiers, des systèmes d’information et du management des
organisations.
70
Société qui m'emploie. Projet Centre d'appels. Proposition de services. Saint-
Quentin en Yvelines: Société qui m'emploie, 2000e.

« Vocea clientului », et restera le nom officiel du centre de contacts
jusqu’à ce jour.
Le projet a été découpé en plusieurs phases : la phase de
préparation du projet, l’étude de cadrage, la réalisation du projet avec une
phase de déploiement et une phase de gestion du changement à gérer en
parallèle, puis la clôture du projet.
II.2 La phase de préparation de la « voix du
client »
Dès la réception de l’accord officiel de ma hiérarchie contrainte et
forcée, j’entrepris d’organiser le projet. Avec les premières informations
que m’avait communiquées le directeur de projet Éric, j’ai travaillé de fin
juin à début septembre à initialiser le projet avec toutes les informations
connues sur le moment, en prenant en compte une certaine extrapolation
personnelle sur les besoins futurs pressentis, mais bien loin de ce qui allait
réellement arriver ! J’ai donc initialisé le projet en élaborant le contour et
le périmètre provisoire du projet, mais aussi le squelette du plan de
découpage du projet d’après la proposition commerciale, le planning
prévisionnel du projet avec l’équipe de consultant (début, fin, gros jalons,
etc.). J’ai travaillé aussi les coûts prévisionnels du projet, la préparation
du référentiel documentaire, l’étude des clés de succès et la définition
provisoire des indicateurs de performances. Je me chargeai du
recrutement et de la formation de l’équipe du projet, de la diffusion de
l’information autour du projet, de l’identification des risques connus du
projet, et enfin de la prise en charge de la logistique du projet et de la
planification des approvisionnements.
Ce projet d’intégration de système était rattaché à mon agence
d’emploi et suivi personnellement par le directeur, mon supérieur

hiérarchique. Il avait deux exigences : l’informer régulièrement sur
l’avancement du projet et ne pas perdre d’argent. Compte tenu de la
distance et des enjeux du projet, mais surtout de ma connaissance des
pays de l’Est, j’ai expliqué et négocié avec le directeur du projet une totale
liberté de manœuvre sur mon périmètre d’intervention avec un
engagement de ma part sur les résultats, mais pas nécessairement sur les
moyens, qui me seraient propres. Ainsi, je me suis laissé une grande
liberté de manœuvre pour la réalisation de la mission. Néanmoins mon
supérieur, qui avait hérité du rattachement administratif et financier du
projet, était moins enthousiaste à cette idée ! J’ai donc su faire jouer dans
cette étape de préparation du projet des jeux de pouvoir en ma faveur,
afin d’avoir les coudées plus franches.
Dans le cadre de la préparation du projet, je me suis beaucoup
documenté sur le pays d’intervention, sur le client et renseigné sur tous
les aspects importants du projet. J’ai identifié les risques apparents du
projet (figure 3) et passé du temps sur l’étude de la réduction de ces
risques, portant sur les dimensions humaines, technologiques, financières,
commerciales et temporelles.
II.2.1 La dimension humaine
Sur la dimension humaine71
, j’ai identifié des risques possibles de
crise au sein de notre équipe, inhérents à un environnement de vie et à
des conditions matérielles difficiles. Il m’était venu à l’idée de la démission
possible d’un collaborateur qui pénaliserait le projet. J’ai aussi identifié un
risque de manque d’expertise sur certains périmètres techniques du
projet. J’ai donc porté une attention particulière au recrutement des futurs
71
La dimension humaine du projet est développée plus en détail dans le chapitre
des « ressources humaines ».

collaborateurs72
en privilégiant le savoir-être et la formation sur les
aspects techniques du projet. J’ai beaucoup travaillé sur le recrutement en
identifiant les collaborateurs susceptibles de participer au projet d’un point
de vue technique et humain, mais aussi sur leur formation y compris pour
moi-même concernant les aspects techniques du projet (Oracle, Siebel,
etc.) avant le départ en mission.
II.2.2 La dimension technologique
Sur la dimension technologique, j’ai identifié un manque d’expertise
des membres de notre équipe qui ne connaissait pas le progiciel et tous
les logiciels à mettre en œuvre. De plus, je devais faire travailler mon
équipe sur une nouvelle version du progiciel pressenti (Siebel
eAutomotive) qui ne devrait sortir officiellement qu’au début de notre
projet. Pour pallier à ce risque, j’ai envoyé toute l’équipe en formation. J’ai
aussi sensibilisé le fournisseur du progiciel à son implication dans le projet
et demandé à bénéficier d’une expertise particulière et de conseil pour la
mise en œuvre de la version automotive du progiciel. J’ai aussi négocié
une version d’évaluation dans le cadre de la future commande de notre
client, afin de pouvoir familiariser l’équipe avec les modules automotive du
logiciel de GRC. J’ai aussi pris en compte l’éventuelle déficience du client
dans la mise à disposition des moyens techniques nécessaires au projet.
J’ai donc organisé le projet afin d’avoir une totale autonomie vis-à-vis de
notre entreprise et vis-à-vis du client, en cas de déficience des différentes
parties sur les points techniques importants du projet.
72
On utilisera dans le mémoire le masculin pour une facilité de rédaction.

Figure 3 : Analyse succincte des risques du projet73
.
II.2.3 La dimension financière
Sur la dimension financière, j’ai pris en compte la réflexion de mon
patron sur la profitabilité prévisionnelle compromise du projet. Dès le
début, j’ai essayé de ne pas perdre de l’argent et de gérer les budgets au
plus juste. Compte tenu de la situation locale, pour moi le risque de
dérapage sur le projet était plus que probable et aura une forte incidence
par une possible perte financière importante. Sur ce point-là, un respect
des délais était très important et nécessitait des jalons définis et fixes. J’ai
tout de suite pensé que le point important à prendre en compte serait le
respect des jalons coûte que coûte et la réception des différents lots dans
73
Bonnemains, Marc. Compte-rendu de revue d'enclenchement de contrat. Saint-
Quentin en Yvelines: Société qui m'emploie, 2000d.

les délais. J’ai aussi tenu compte qu’une gestion financière dynamique du
projet qui nous permettrait de faire des économies non négligeables.
II.2.4 La dimension commerciale
Sur la dimension commerciale, je savais que le contrat, à l’habitude
du client, ne serait signé qu’après le démarrage du projet et qu’il n’y avait
aucune représentation commerciale chez le client pour une négociation
tripartie - notre entreprise, le client (sa filiale) et le commanditaire de la
maison mère -. D’autre part, je savais que l’entreprise ne payait ses
fournisseurs qu’après un long délai, par habitude, mais aussi imposé par
des procédures administratives longues et fastidieuses dans le pays
d’intervention. Je savais aussi que ce contrat commercial était important
pour notre entreprise et que sa réalisation aurait des implications
importantes sur d’autres projets en cours de négociation auprès de
l’entreprise française. Je savais également que le sponsor chez notre client
était très exigeant et quelque peu versatile. Nous avions aussi le risque
que la mission s’arrête, à la demande du client, après la phase d’étude et
de réflexion.
II.2.5 La dimension temporelle
Sur la dimension temporelle du projet, j’ai bien saisi que tous les
problèmes notamment sur les délais et la logistique auraient une
répercussion importante sur le projet en termes de délais et de coûts. J’ai
beaucoup travaillé sur ce que je pouvais prévoir et contrôler. J’ai travaillé
sur la partie logistique (ordinateurs portables, logiciel, hébergement,
transports, documentations, approvisionnement, etc.), car je ne concevais
pas de faire des allers-retours dans le cas d’un besoin non identifié ou non
réalisé avant le départ de notre équipe. Afin d’avoir une meilleure maîtrise
des délais et compte tenu de l’enjeu représenté par le projet, j’ai négocié

auprès des différents services de l’entreprise (Achat, comptabilité, service
technique, etc.) de ne pas suivre la procédure normale d’engagement
d’achat et de commandes, que je considérais assez lourde et inadaptée
pour ce genre de projet offshore, mais plutôt d’avoir une totale autonomie
financière dans le cadre de règles d’engagements claires sur un budget
donné. J’ai fait de même sur la partie technique (ordinateurs portables,
logiciel, connexions, etc.) pour m’astreindre des limitations et des
procédures techniques imposées par l’entreprise, mais inadaptées au
projet. D’autre part, en demandant à participer à la phase d’étude et de
réflexion sur le projet, je m’assurais de gagner du temps dans la mise en
œuvre du projet avec une montée en charge progressive. Je m’assurais
autant que possible que la partie technique couvrirait au mieux les besoins
du client.
Dans cette phase de préparation, je me suis beaucoup investi sur la
partie logistique du projet et sur la partie humaine en identifiant et
sélectionnant les futurs concepteurs et développeurs du projet. Je n’ai pas
eu de liberté de manœuvre concernant la sélection des consultants
métiers issus d’une de nos filiales et qui intervenaient avec le directeur de
projet. Je n’ai pas eu beaucoup de contact avec eux avant le départ sur le
projet.
II.3 L’étude de cadrage de la « voix du client »
Après une revue d’enclenchement de contrat (figure 4) que j’ai
initialisé, j’ai commencé en septembre 2000 le projet avec l’équipe de
consultants constituée de Mathieu et François et du directeur de projet,
Éric. J’ai donc pu participer, à ma demande, à la phase d’étude et de
réflexion du périmètre fonctionnel du centre de contacts, et au scénario de
mise en œuvre du projet. J’ai traduit les exigences en terme
technologique et réalisé l’étude des aspects techniques du projet. L’équipe

avait commencé à initialiser sous mon initiative une étroite collaboration
entre la partie technique (intégration de système) et la partie métier
(processus)74
.
Figure 4 : Compte-rendu de la première revue d’enclenchement de
contrat75
.
La participation à cette étape d’étude de cadrage76
m’a permis de
participer avec l’apport de mes connaissances techniques à la construction
du « business case » et de la définition du contenu (scope) du projet.
Cette étape a été importante dans mon projet, car elle nous a permis
d’aligner l’organisation et les processus du centre de contact à la stratégie
74
Ce sujet est développé plus en aval dans ce mémoire dans le paragraphe
« association entre le CP et le BA ».
75
Quentin en Yvelines: Société qui m'emploie, 2000f.
76
J’approfondi la notion de l’ingénierie des exigences dans le chapitre concernant
« la définitions des exigences ».

de l’entreprise77
. J’ai aussi permis de valider avec le fournisseur de l’outil
de GRC la disponibilité de leur nouvelle version de progiciel adaptée à
notre secteur d’activité : l’automotive. Il s’est avéré nécessaire de vérifier
l’adéquation du choix réalisé de l’outil par rapport aux exigences
fonctionnelles de notre client. J’ai aussi pu participer à la définition des
processus métiers du client (partie métier) (figure 5) sur le périmètre
technique du centre de contacts.
Figure 5 : Périmètre fonctionnel initial du centre de contacts78
.
J’ai profité de cette étape pour avancer sur l’étude de certains
éléments du périmètre du projet, nous permettant de mieux réaliser notre
cahier des charges pour le développement. J’ai ainsi pu réaliser une
cartographie des systèmes d’information (figure 6) avec une analyse par
77
Briol, Patrice. Ingénierie des processus métiers, de l'élaboration à l'exploitation
[En ligne]. s.l.: Lulu.com, 2008. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<http://zonecours.hec.ca/documents/3070608_247330CC-0645-4BCC-8895-
4E1703AD4647.INGE_PROC_V0_US_img_v3_ISBN.pdf>.
78
Société qui m'emploie. Analyse des processus et synthèse. Saint-Quentin en
Yvelines: Société qui m'emploie, 2000a.

rapport au référentiel des « données clients » manipulées par l’entreprise.
J’ai réalisé une étude de la future architecture technique du projet (figure
7) sur les parties matériel, réseau et logiciel. J’ai détaillé les différentes
plateformes techniques (développement, formation, production) (figure 8)
et les configurations nécessaires à la réalisation du projet. J’ai réalisé une
présentation technique détaillée sur l’outil de GRC (figure 9) Siebel à
destination du client et identifié les différents modules de l’outil de GRC
(figure 10) à mettre en œuvre par rapport à nos besoins.
Figure 6 : Cartographie des systèmes d’information identifiés79
.
La participation à cette phase m’a permis, outre de prendre en
compte la dimension stratégique du commanditaire chez le client - la
Direction de l’Organisation et des Systèmes Informatiques (DOSI) -,
d’avoir une meilleure connaissance de ses enjeux de refonte et de
transformation de son système d’information. Cela m’a permis de faire
valider le périmètre fonctionnel par le client afin que je puisse rédiger la
79
Bonnemains, Marc. Cartographie des systèmes d'informations identifiés.
Référenciel de données. Saint-Quentin en Yvelines: Société qui m'emploie, 2000a.

charte définitive du projet, mais aussi d’avancer sur le périmètre
technique du projet.
Figure 7 : Présentation de la future architecture technique80
.
Après un « go » du client et de notre hiérarchie, le projet de centre
de contacts « la Voix du Client » a débuté avec une deuxième revue
d’enclenchement de contrat comprenant un ensemble de données et de
documents d’évaluation du projet dont, sous ma responsabilité de chef de
projet, une analyse plus fine des risques du projet, ainsi que la validation
de la composition définitive de l’équipe du projet. Cette étude de cadrage
m’a permis aussi de vérifier que bien que de bonne foi, le client avait du
mal à tenir ces engagements de délais en termes de mise à disposition
des ressources matérielles et humaines promises, combien utiles au projet
(locaux, bureaux, ordinateurs, réseaux, interlocuteur, etc.).
80
Société qui m'emploie. Présentation au comité exécutif du client. Saint-Quentin
en Yvelines: Société qui m'emploie, 2000c.

Figure 8 : Tableau de synthèse de la configuration matérielle81
.
Figure 9 : Présentation technique de Siebel82
.
81
Bonnemains, Marc. Etude de l'environnement technique et technologique. Saint-
Quentin en Yvelines: Société qui m'emploie, 2000h.
82
Bonnemains, Marc. Présentation Siebel technique. Saint-Quentin en Yvelines:
Société qui m'emploie, 2000p.

Figure 10 : Présentation du périmètre applicatif Siebel sur le projet83
.
Figure 11 : Les grandes phases de notre contrat84
.
83
Bonnemains, Marc. Etude de l'environnement technique et technologique. Saint-
Quentin en Yvelines: Société qui m'emploie, 2000h.
84
Bonnemains, Marc. Note d'organisation de projet - La voix du client. Saint-
Quentin en Yvelines: Groupe Euriware, SA, 2000l. p. 4.

Dans le cadre de notre étude de réalisation, le projet initialement
défini est la création d’un centre de contacts de 100 positions avec un
premier périmètre de 35 positions pour lequel nous nous occupons au
forfait de la réalisation de la partie technique du système d’information, de
la gestion du changement et de la formation des opérateurs à l’utilisation
de l’outil de GRC. Le client doit lui s’occuper de la construction et de
l’installation technique du centre de contacts, mais aussi du recrutement
et de la formation de ses futurs collaborateurs au métier de centre de
contacts. Le projet est donc un projet au forfait initialement découpé en
plusieurs phases avec la possibilité de s’arrêter à la demande du client
après chaque phase. La phase d’étude et de réflexion s’est déroulée du 18
septembre 2000 au 20 octobre 2000. La phase de réalisation devait se
dérouler du 16 octobre au 31 mars 2001 avec une phase de déploiement
et d’une phase de gestion du changement à gérer en parallèle (figure 11).
La phase de réalisation devait permettre de réaliser 3 lots avec des
dates de livraisons échelonnées dans le temps. Le projet est donc
initialement prévu pour nous avec la livraison d’un premier lot (Lot 1) en
décembre 2000 et un deuxième et troisième lot (Lot 2 & 3) à fin mars
2001. Le démarrage du centre de contacts est initialement prévu vers le
début de mois de décembre 2000 après la livraison du premier lot. En
raison de certaines difficultés techniques et managériales du côté client, le
centre de contacts ne sera opérationnel qu’en juin 2001 (figure 12).
Figure 12 : Les jalons importants du projet rectifié

Il faut que je rappelle la place importante du centre de contacts au
cœur de l’entreprise et l’interface de l’outil de GRC dans le schéma
directeur du système d’information de notre client. C’est une contrainte
importante que j’ai identifiée et que j’ai dû intégrer dans la gestion du
projet et la réalisation des interfaces de l’outil de GRC choisies avec les
autres logiciels et progiciels actuels ou futurs de l’entreprise cliente (figure
13).
Cette phase d’étude et de réflexion a permis d’ajuster ma
compréhension du fonctionnement des consultants métiers, Mathieu et
François (Business Analyst ou analyste d’entreprise). Nous avions pu
développer durant cette courte période, tant bien que mal, un sentiment
d’appartenance à un même groupe soudé et solidaire. Un des consultants,
François, a été obligé de nous quitter à cette étape du projet85
, et je dois
dire qu’après avoir pris du recul, cette situation s’est révélée être une
chance. Cette nouvelle situation a amélioré le ratio du projet par des
dépenses de personnel en moins. Compte tenu de l’évolution du projet, sa
charge de travail a pu être absorbée en maintenant tout au long du projet
notre consultant, Mathieu. Il a pu intervenir sans discontinuer au sein de
notre équipe sur la partie métier, et dans les relations avec les utilisateurs
et les parties prenantes.
85
Les raisons de ce départ sont résumées dans le paragraphe de la gestion des
ressources humaines.

Figure 13 : La place du progiciel de GRC Siebel dans le SI de
l’entreprise86
.
Cette phase d’étude et de réflexion, appelée aussi « étude de
cadrage », est normalement menée par la maîtrise d’ouvrage (MOA)87
.
Néanmoins cette étude a été sous-traitée à notre entreprise (partie
métier) dans le cadre d’une assistance à maîtrise d’ouvrage (AMOA). Nous
verrons dans la suite du projet qu’en fait sur le terrain il n’y a pas eu de
MOA, mais uniquement un sponsor88
. Une partie de notre équipe a donc
pris en charge la MOA dans les limites de certaines responsabilités en tant
86
Société qui m'emploie. Présentation au comité exécutif du client. Saint-Quentin
en Yvelines: Société qui m'emploie, 2000c.
87
MINEFI. Guide sur l'assistance à la maîtrise d'ouvrage en informatique [En
ligne]. Paris: Ministère de l'Economie, des Finances et de l'Industrie, 2004. [Cité le 23 jan
2011]. Pdf. Available from:
<http://www.minifi.gouv.fr/fonds_documentaire/daj/guide/gpem/amo/amo.pdf>.
88
Lorsque la fonction de maîtrise d’ouvrage est moins impliquée ou bien sous-
traite la totalité de ses compétences dans le projet, on parle plutôt de « sponsor » ou
commanditaire. le sponsor entérine les décisions, arbitrages et options pris.
Normalement, il supervise aussi le travail des experts métiers.

qu’AMOA89
, durant et à la suite de l’étude de cadrage en créant une
situation atypique pour le projet que nous menions. Cette étroite
collaboration amorçait une collaboration plus longue entre la partie métier
et la partie technique tout au long du projet, jusqu’à la gestion du
changement et le déploiement du progiciel. Ce type de collaboration
atypique sur l’ensemble du projet était relativement nouvelle et innovante
à cette date dans notre sphère d’activité et présageait déjà une future
évolution dans le management de projet. Ce type de collaboration
initialisé dès le début du projet amorçait un projet géré en « ingénierie
simultanée » qui allait impliquer les personnels respectifs du client, notre
équipe et nos fournisseurs avec certains des rôles redéfinis tout au long
du projet. J’ai aussi conseillé le directeur de projet de maintenir et faire
intervenir notre consultant tout au long du projet sur la partie métier en
soutien à ma mission de chef de projet.
II.4 La réalisation de la « voix du client »
Si tout s’est relativement bien passé lors de la phase amont de
préparation, le projet dans sa phase de réalisation n’a pas été « un long
fleuve tranquille », mais a nécessité une adaptation constante à une
situation environnementale complexe et mouvante. Dès le début du
projet, j’ai été obligé de m’adapter et de négocier en permanence avec les
parties prenantes, la partie métier ainsi que d’aider mon équipe à
s’adapter à la situation de travail parfois difficile.
Après la signature de la deuxième revue d’enclenchement de contrat
pour la partie de réalisation, la phase de déploiement et de gestion du
changement (figure 14), l’équipe du projet pour notre société était
définitivement fixée avec le directeur de projet Éric, notre consultant
89
MINEFI. Guide sur l'assistance à la maîtrise d'ouvrage en informatique [En
ligne]. Paris: Ministère de l'Economie, des Finances et de l'Industrie, 2004. [Cité le 23 jan
2011]. Pdf. Available from:
<http://www.minifi.gouv.fr/fonds_documentaire/daj/guide/gpem/amo/amo.pdf>. p. 4.

métier Mathieu, un chef de projet, moi-même, et trois analystes-
développeurs : Andra, Jérôme et Pierre (tableau 3). Cette phase de
réalisation a été composée de deux parties : le premier lot (Lot 1) du 13
octobre au 22 décembre 2000, le deuxième et troisième lot (Lot 2 et 3) du
8 janvier au 31 mars 2001.
Tout au long du projet, j’ai entrepris une gestion du projet en
m’appuyant sur certains éléments de base de l’entreprise (le guide
méthodologie Delta, le système qualité de la société) dans laquelle je
travaillais. J’ai continué à mettre en place le référentiel documentaire sur
le projet en l’adaptant à nos besoins, et ce dans les règles de l’art défini
dans les différents documents du référentiel de l’entreprise90
. J’ai aussi
graduellement, mis en place un intranet d’accès aux informations et aux
documents sur le projet de la « voix du client », afin de faciliter le suivi, le
stockage et l’accès aux informations du projet en toute transparence au
sein de l’équipe et avec nos partenaires91
. Dans notre démarche intuitive
d’ingénierie simultanée, cet intranet nous a aidés à communiquer et à
générer un flot d’information entre les différentes parties. Car « ce flot
d’information concerne (…) les données relatives au produit, les données
relatives aux processus (aussi bien) les communications entre les
personnes que les points de vue des experts »92
.
90
La gestion documentaire est développée dans ce document au chapitre de la
« gestion documentaire ».
91
Idem.
92
Dartigues, Christel. État de l’art sur l’Ingénierie Concourante [En ligne]. Lyon:
Université Claude Bernard - Lyon 1, Modélisation, Laboratoire d'Informatique Graphique -
Image et, 2001. [Cité le 23 jan. 2011]. Pdf. Disponible à partir de:
<http://www.i3s.unice.fr/~dartigue/?download=EDAIngenierieConcourante.pdf>.

Figure 14 : Compte-rendu de la deuxième revue d’enclenchement
de contrat93
.
Sur le projet, j’ai dû faire face à différents problèmes plus ou moins
importants pour assurer la réussite de notre mission. Je me suis heurté à
des problèmes de communication avec la hiérarchie de notre entreprise.
J’ai été confronté à des difficultés de management d’équipe et de plusieurs
démissions. J’ai rencontré des problèmes avec le client dans le cadre du
non-respect de ses engagements contractuels en termes de ressources et
de délais, ainsi que des demandes intempestives en dehors du périmètre
d’intervention. J’ai affronté des problèmes avec les utilisateurs dans le
cadre de la réalisation de l’interface homme-machine (IHM) du progiciel.
J’ai aussi eu des soucis avec les sous-traitants par rapport à la qualité et
les délais de livraison des ressources. Et pour finir, j’ai eu un véritable
challenge sur le projet, car la situation ne me permettait pas de maîtriser
les délais et les données de la prestation de réalisation du système
d’information du centre de contacts.
93
Quentin en Yvelines: Société qui m'emploie, 2000f.

Tableau 3 : Composition de l’équipe du projet94
II.4.1 Le premier lot : les bases du centre de contacts
Dès l’arrivée de mon équipe sur le projet (Andra, Jérôme et Pierre),
j’ai réparti le travail en fonction de l’expérience acquise de chacun sur les
projets antérieurs réalisés. En effet, la formation Siebel n’étant pas
suffisante pour maîtriser l’outil, l’équipe projet est arrivée sur la mission
avec un bagage de connaissances non pas faibles, mais insuffisantes.
L’objectif de cette mission était donc non seulement de remplir les clauses
du contrat client/fournisseur dans les plus brefs délais (délais imposés par
le client), mais aussi de permettre à chaque membre de l’équipe d’utiliser
un maximum de potentiel personnel acquis tout en développant les
connaissances sur le progiciel Siebel.
Pierre, expert technique et le plus expérimenté en gestion de
système, était chargé de l’installation, de l’exploitation, du système de
sauvegarde (back-up) et de l’initialisation de l’outil de GRC Siebel. Les
94
Ibid.

Projet master la voix du client - Marc Bonnemains

Projet master la voix du client - Marc Bonnemains

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Projet master la voix du client - Marc Bonnemains

Similaire à Projet master la voix du client - Marc Bonnemains (20)

Plus de Marc Bonnemains

Plus de Marc Bonnemains (13)

Projet master la voix du client - Marc Bonnemains