Vous êtes sur la page 1sur 241

Les m

ethodes agiles de management de projets


informatiques : une analyse par la pratique
Carine Khalil

To cite this version:


Carine Khalil. Les methodes agiles de management de projets informatiques : une analyse
par la pratique. Gestion et management. Telecom ParisTech, 2011. Francais. <pastel00683828>

HAL Id: pastel-00683828


https://pastel.archives-ouvertes.fr/pastel-00683828
Submitted on 30 Mar 2012

HAL is a multi-disciplinary open access


archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

Larchive ouverte pluridisciplinaire HAL, est


destinee au depot et `a la diffusion de documents
scientifiques de niveau recherche, publies ou non,
emanant des etablissements denseignement et de
recherche francais ou etrangers, des laboratoires
publics ou prives.

N: 2009 ENAM XXXX

Doctorat ParisTech
THSE
pour obtenir le grade de docteur dlivr par

Tlcom ParisTech
Spcialit Sciences de Gestion
prsente et soutenue publiquement par

Carine KHALIL
06 Dcembre 2011

Les mthodes agiles de management de projets informatiques : une


analyse par la pratique

Directeur de thse : Valrie FERNANDEZ


Co-encadrement de la thse : Jrme DENIS

Jury
Mme Bndicte GEFFROY, Professeur, Sciences de Gestion, cole des Mines de Nantes
M. Marc BIDAN, Professeur, Sciences de Gestion, Universit de Nantes
Mme Carine DOMINGUEZ-PERY, Professeur, Sciences de Gestion, Universit Pierre Mendes France
M. Jrme DENIS, Matre de confrences, Sociologie, Tlcom ParisTech, LTCI
Mme Valrie FERNANDEZ, Professeur, Sciences de Gestion, Tlcom ParisTech, LTCI

Rapporteur
Rapporteur
Examinatrice
Co-directeur
Directrice.

T
H

S
E

Tlcom ParisTech
Grande cole de lInstitut Tlcom membre fondateur de ParisTech
46, rue Barrault 75634 Paris Cedex 13 Tl. + 33 (0)1 45 81 77 77 www.telecom-paristech.fr

Les mthodes agiles de management de projets informatiques : une


analyse par la pratique
RSUM :
Jusqu la fin des annes 90, les approches dominantes de dveloppement de projets
informatiques taient bases sur la planification et le dcoupage extensifs du projet en lots
squentiels. Face aux besoins dadaptabilit et de ractivit imposs par un march
technologique de plus en plus concurrentiel, les mthodes classiques ont t remises en
cause par de nouvelles mthodes qualifies d agile . Ces dernires sont gnralement
dcrites comme tant itratives, incrmentales, encourageant lauto-organisation et sadaptant
au changement. La philosophie des mthodes agiles sinscrit dans lcole japonaise du
lean dvelopp dans les annes 1980. Elle pose de faon centrale la question du sens
collectif, et ce dans une perspective interactionniste (Koenig, 2003) o la cration de sens se
fait de manire processuelle par lintermdiaire de la communication entre les intervenants.
Participant dune philosophie dorganizing (Weick, 1995), les mthodes agiles ont souvent t
analyses dans des configurations organisationnelles simples o des modes de
coordination de type adhocratique (Mintzberg, 1984) peuvent facilement tre mis en place.
Quen est-il pour des structures de management de projet plus complexes ? Plus gnralement,
comment ce type dinnovation managriale peut-il tre mis en uvre dans une dmarche
structure de management pour constituer un dispositif formalis favorisant lorganizing ?
Les mthodes agiles de management de projet posent ainsi la question du degr de
faisabilit du substrat technique qui y est associ, de la plus ou moins grande pertinence de la
philosophie gestionnaire quelles sous-tendent, soit, de leur contextualisation interne (David,
1996). Lobjet de cette thse de doctorat est daborder ces questions en articulant une analyse
critique de la littrature consacre aux mthodes agiles, et une tude de cas instrumentale
mene dans la perspective de lapproche par la pratique (Gherardi, 2000, 2001 ;
Whittington, 2003 ; Antonacopoulou, 2006 ; Jarzabkowski, 2004), dune dure de 17 mois,
ralise dans une entit appartenant un large groupe franais de tlcommunication ayant
dcid de mettre en uvre une dmarche managriale base sur des pratiques agiles .
Nos rsultats permettent denvisager la dmarche agile comme un construit social
continu, guid non pas par lapplication mcanique de mthodes stabilises, mais par des
problmatiques de plausibilit, didentit organisationnelle et par les prsuppositions avances
par des acteurs nactant leur ralit organisationnelle. Nous montrons quen construisant le
sens des mthodes quils cherchent mettre en place, les acteurs identifient non seulement
des dysfonctionnements spcifiques la dmarche (des gaspillages), mais aussi des facteurs
de contingence (nature de la structure organisationnelle, profil du chef de projet, mode de
management existant) qui constituent des conditions essentielles, mais peu explores de la
mise en uvre des mthodes agiles .

Mots cls : Mthodes Agiles, Innovations Managriales, Management de Projet, Structure


Matricielle, Sensemaking.

Tlcom ParisTech nentend donner aucune approbation


ni improbation aux opinions mises dans cette thse. Ces
opinions doivent tre considres comme propres
lauteur.

A ceux qui ont rendu cette thse possible

Remerciements

Jexprime ma gratitude et ma considration les plus sincres toutes les personnes qui
mont de prs ou de loin, aide et soutenue durant la ralisation de ce travail et sans qui, il
naurait pas vu le jour. Mes remerciements sadressent particulirement :
Valrie Fernandez, professeur Tlcom ParisTech, ma directrice de thse. Je tiens la
remercier, de mavoir donn la chance de compter parmi ses doctorants. Je lui suis
reconnaissante pour la confiance et le temps quelle ma accords, pour ses directives, ses
encouragements et pour son soutien le long de cette aventure.
Jrme Denis, matre de confrences en sociologie Tlcom ParisTech, mon co-directeur de
thse. Je souhaite lui exprimer ma gratitude et le remercier pour sa grande disponibilit et ses
conseils stimulants tout au long de ces trois annes.
Les membres du Jury davoir accept dvaluer ce travail de thse. Jen suis trs honore. Mes
premiers remerciements iront Madame Bndicte Geffroy et Monsieur Marc Bidan, les
rapporteurs de ce travail de thse. Je remercie galement Madame Carine Dominguez-Pery
davoir accept dexaminer ce travail.
Thomas Houy, matre de confrences Tlcom ParisTech, qui a contribu par ses
nombreuses remarques et suggestions amliorer la qualit de ce travail de thse. Je lui en
suis trs reconnaissante.
M. Thierry Fraize, responsable qualit la direction Nextv chez Orange. Je souhaite le
remercier de mavoir accueillie au sein de son quipe et davoir rpondu toutes mes
questions.

Le corps professoral du Cercle Doctoral Europen de Gestion. Je remercie en particulier M. le


professeur Albert David pour ses prcieux conseils. Je tiens le remercier galement davoir
valu mon travail mi-parcours.
Je remercie chaudement ma chre famille qui ma soutenue depuis mon arrive en France et
qui ma permis de faire cette thse dans des bonnes conditions. Aujourd'hui je lui offre ce
travail.
Je remercie mes amis et en particulier Amlie Mauler, ma colocataire, pour son soutien et sa
patience mon gard.

Table des matires

Table des matires --------------------------------------------------------------------------------------------- 8


Liste des figures ---------------------------------------------------------------------------------------------- 10
Liste des tableaux -------------------------------------------------------------------------------------------- 11
Introduction gnrale --------------------------------------------------------------------------------------- 12
Premire partie : De la question des mthodes agiles comme innovations managriales 20
Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion ---------- 21
1.

Des mthodes classiques de management de projet aux mthodes agiles ---------------------- 22


1.1
Les mthodes classiques : une dmarche lourde de conduite de projet --------------- 22
1.2
Les mthodes agiles : une nouvelle tendance managriale -------------------------------- 24
1.3
Les sources dinspiration des mthodes agiles ---------------------------------------------- 28
2. Prsentation des mthodes agiles ------------------------------------------------------------------ 35
2.1
La mthode scrum ----------------------------------------------------------------------------- 36
2.2
La mthode Extreme Programming ---------------------------------------------------------- 41
2.3
Le lean dveloppement---------------------------------------------------------------------------- 48
2.4
Scrum , xp et le dveloppement lean : diffrences et complmentarit ----------- 58
Chapitre II : Analyse de la mise en pratique des innovations managriales -------------------- 63
1.

Les pratiques agiles les plus rfrences : avantages et limites --------------------------------- 64


1.1
Les pratiques dingnierie ------------------------------------------------------------------------- 65
1.2
Les pratiques de collaboration et de coordination----------------------------------------------- 66
1.3
Les outils de support au management ------------------------------------------------------------ 70
2. Les mthodes agiles v/s mthodes classiques : quelles mthodes privilgier ? ------------ 71
3. Lapplication des pratiques agiles dans un environnement godistribu ----------------------- 75
3.1
Les principaux dfis du dveloppement agile distribu ------------------------------------ 76
3.2
Les recommandations des praticiens face aux dfis remonts --------------------------------- 78
3.3
Regard complmentaires des experts sur le dveloppement agile globalis-------------- 82
Chapitre III : Stratgie de recherche : une approche par la pratique --------------------------- 86
1.

La fabrique de la stratgie : champ de recherche mergent en sciences sociales -------------- 91


1.1
Le strategizing : lintersection des pratiques, praxis et praticiens :-------------------------- 92
1.2
Qui sont les stratgistes et que font-ils ? --------------------------------------------------------- 94
2. Le modle du sensemaking ----------------------------------------------------------------------------- 97
2.1
Les proprits du sensemaking ------------------------------------------------------------------ 101
2.2
Lorganisation apprhende comme un processus dorganizing ----------------------------- 103

Deuxime partie : De la fabrique d'une innovation managriale : la construction d'une


dmarche agile ------------------------------------------------------------------------------------------ 107
Chapitre IV : Conduire une approche par la pratique ------------------------------------------- 108
Prsentation plat du cas dentreprise tudi ---------------------------------------------------- 109
1.1
Description du contexte dtude ----------------------------------------------------------------- 109
1.2
Mise en place de la dmarche lean ---------------------------------------------------------- 115
2. Dmarche dinvestigation ------------------------------------------------------------------------------ 119
2.1
Choix dune tude longitudinale----------------------------------------------------------------- 119
2.2
Procds de collecte de donnes----------------------------------------------------------------- 120
2.3
Choix dune mthode danalyse thmatique---------------------------------------------------- 127
2.4
Triangulation des donnes et des chercheurs --------------------------------------------------- 133
1.

Chapitre V : Variables de cration de sens ------------------------------------------------------------- 136


1.

Le gaspillage dans les projets pilots par Nextv ----------------------------------------------------- 137


1.1
Analyse et classification des dysfonctionnements par type de gaspillage ------------------- 138
1.2
Dmarche plausible de rsolution des dysfonctionnements ----------------------------------- 146
2. Facteurs dinfluence de la dmarche lean -------------------------------------------------------- 149
2.1
La taille et la distribution des quipes----------------------------------------------------------- 149
2.2
La structure organisationnelle ------------------------------------------------------------------- 153
2.3
Mode de management de projet ----------------------------------------------------------------- 156
2.4
Les ressources mobilises ------------------------------------------------------------------------ 159
2.5
Les parties prenantes du projet lean --------------------------------------------------------- 162
Chapitre VI : Discussion ----------------------------------------------------------------------------------- 169
Conclusion gnrale ---------------------------------------------------------------------------------------- 189
1. Rsum des principaux rsultats de recherche ------------------------------------------------------- 189
2. Les apports de ce travail de recherche ---------------------------------------------------------------- 197
3. Limites et pistes futures -------------------------------------------------------------------------------- 198
Bibliographie ------------------------------------------------------------------------------------------------ 201
Annexes------------------------------------------------------------------------------------------------------- 215

Liste des figures

Figure I:

Processus de dveloppement scrum ........................................................................ 41

Figure II :

Processus de dveloppement XP ............................................................................. 48

Figure III:

Jonglage entre trois taches de dlai d'une semaine chacune ................................... 57

Figure IV:

Parties constitutives de la fabrique de la stratgie ................................................... 94

Figure V :

Processus du sensemaking dans une organisation (Weick, 1995)................................. 104

Figure VI : Grille danalyse du sensemaking.................................................................................. 105


Figure VII : Structure macro-organisationnelle de lentit Nextv ................................................... 110
Figure VIII : Cycle de vie des projets DPS ..................................................................................... 111
Figure IX : Structure de type lightweight ................................................................................ 114
Figure X :

Droulement du projet lean .................................................................................. 119

Figure XI : Etude longitudinale ..................................................................................................... 120

10

Liste des tableaux

Tableau 1:

Comparaison des concepts de l'agile manufacturing v/s mthodes agiles ............... 31

Tableau 2:

Les pratiques XP ..................................................................................................... 42

Tableau 3:

Les sept sources de gaspillage (Poppendieck, 2003; 2006)............................................ 54

Tableau 4 : Diffrences entre XP et scrum ........................................................................... 58


Tableau 5:

lments structurant des approches : scrum , xp et lean .............................. 61

Tableau 6 : Dfis majeurs du dveloppement agile dans un environnement globalis .............. 78


Tableau 7 : Recommandations face aux dfis rencontrs dans un environnement globalis ........... 81
Tableau 8 : Les tudes bases sur la pratique ........................................................................... 91
Tableau 9:

Intervention des acteurs mtiers dans le cycle de vie du projet .................................. 113

Tableau 10: Profil des membres de l'quipe lean ..................................................................... 115


Tableau 11: Principes et pratiques adopts ................................................................................... 116
Tableau 12: Projets pilotes retenus ............................................................................................... 117
Tableau 13: Plans d'actions valids par le Codir ............................................................................. 118
Tableau 14 : Tableau descriptif des runions ralises .................................................................... 122
Tableau 15 : Ateliers organiss par lquipe lean ........................................................................ 124
Tableau 16 : Recension des entretiens raliss ............................................................................... 125
Tableau 17: Les causes de la surproduction ................................................................................... 139
Tableau 18: Les causes des temps dattente .................................................................................. 140
Tableau 19: Les causes des transports inutiles............................................................................... 141
Tableau 20: Les causes du travail supplmentaire ......................................................................... 142
Tableau 21: Les causes de linventaire ........................................................................................... 143
Tableau 22: Les causes des mouvements inutiles .......................................................................... 144
Tableau 23: Les causes des dfauts ............................................................................................... 145
Tableau 24 : PDCA mobilis par lquipe lean ........................................................................... 149

11

Introduction gnrale

Introduction gnrale

Nombre de modles1 de dveloppement de logiciels et de standards de management de


projets a t labor au cours de ces quatre dernires dcennies. De srieux problmes de
qualit et de productivit ont t rencontrs par les socits informatiques les amenant au fil
du temps repenser leurs modes de dveloppement et de gestion de projets informatiques2.
Jusqu la fin des annes 1990, les mthodes3 dominantes en dveloppement de logiciels
taient celles bases sur le dcoupage en lots squentiels. chaque phase, correspond un
ensemble dactivits ou de tches raliser et piloter, ainsi que des dcisions prendre. Le
livrable est produit la fin du processus. Ce processus de dveloppement a t symbolis par
la course de relais o les diffrents services fonctionnels se relaient tour tour (Takeushi &
Nonaka, 1986 ; Midler, 1993b). Lapproche la plus reprsentative de ce type de
dveloppement est le modle de la cascade . Universellement connu et utilis, il se base sur
lanticipation des demandes des clients, la dfinition complte du produit et la documentation
exhaustive. Toutefois, depuis quelques annes, les principes de dcoupages linaires et de
management de projets informatiques ports par les mthodes classiques sont de plus en
plus remis en cause. Les socits informatiques se trouvent aujourdhui confrontes de
fortes pression et concurrence sur un march caractris par une diversit des offres
technologiques, une instabilit des demandes et une rduction des dlais de mise sur le
march. Le changement permanent des fonctionnalits dvelopper et leffet tunnel caus
Nous dsignons par modle de dveloppement le dcoupage dun projet ou le modle de cycle de vie dun
projet.
2
Un systme informatique est un ensemble organis dobjets techniques-matriels, logiciels, applications- dont
la mise en uvre ralise linfrastructure dun systme dinformation (Morley, 2006, p. 15). Dans cette thse,
nous traitons des projets de dveloppement de systmes informatiques.
3
Pour dfinir le terme mthode nous nous rfrons la dfinition du Larousse : un ensemble ordonn de
manire logique de principes, de rgles, d'tapes, qui constitue un moyen pour parvenir un rsultat .
1

12

Introduction gnrale

par les projets en cascade ont amen les praticiens remettre en question ce modle de
dveloppement et se focaliser sur les volutions rapides et constantes du march
technologique. Comme la planification et lorganisation ex ante du processus de
dveloppement savrent, de nos jours, difficiles raliser, de nouvelles approches, plus
flexibles , dnommes agiles 4 , ont t dveloppes ; elles se sont progressivement
diffuses au niveau des industries de logiciels.
A quoi le terme agilit renvoie-t-il prcisment ? A quelle(s) forme(s) dagilit ? Sur quels
principes gestionnaires les mthodes agiles de dveloppement et de management de projet
se basent-elles ? Comment sont-elles appliques au sein des industries de logiciels ? Existe-til un rfrentiel permettant de structurer la conduite dun projet agile ?
En trs peu dannes, la notion d agilit a connu un succs considrable au niveau des
industries de dveloppement de logiciels. Comme en tmoignent les multiples colloques et
publications consacrs cette thmatique, de nombreuses socits informatiques aspirent
aujourdhui rompre avec les mthodes classiques et devenir agile . Une enqute
internationale 5, mene en 2008 auprs de 642 professionnels du dveloppement dapplications
informatiques et en management de projets, a montr que 69 % des participants utilisent, au
cours de leur projet, une ou plusieurs technique(s) relevant des mthodes agiles .
Ces mthodes sont gnralement dcrites comme tant itratives, incrmentales, encourageant
lauto-organisation et sadaptant au changement. Contrairement aux approches classiques ,
elles nexigent quun formalisme lger et renvoient une reprsentation souple des
pratiques de dveloppement et de management favorisant le bricolage et lajustement
continu au contexte des projets.
En effet, ces formes innovantes de dveloppement de logiciels reposent sur un ensemble de
pratiques dingnierie et de gestion de projet bien dfinies ainsi que sur une philosophie
gestionnaire qui visent, dune part, amliorer ladaptabilit et la ractivit des quipes de
dveloppement et dautre part, rduire, voire liminer les divers types de gaspillages (les
Littralement, le terme agile implique lhabilit bouger de faon lgre et gracieuse et de sadapter
rapidement (http://www.merriam-webster.com/). Nous reviendrons sur cette notion, de faon plus dtaille,
dans le chapitre (I) de cette thse.
5
http://www.ambysoft.com/surveys/agileFebruary2008.html.
4

13

Introduction gnrale

fonctionnalits inutiles, les anomalies tardivement identifies, le retravail , les temps


dattente, dus au chevauchement entre les phases dun projet, etc.) souvent rencontrs dans les
projets informatiques. Comme nous le verrons dans le cadre de cette thse6, cette notion de
gaspillage se trouve au cur des proccupations des agilistes et en particulier des
partisans de lapproche lean7.
Malgr la littrature foisonnante sur le concept dagilit, la transition vers une organisation
agile constitue un rel dfi. A lheure actuelle, le contexte dutilisation des outils
agiles demeure flou. Lanalyse de la littrature parue sur le sujet souligne des positions
contradictoires des praticiens vis--vis de lapplicabilit des pratiques et instruments de
gestion ports par ces approches de dveloppement et de management de projet. Les
mthodes agiles articulent de nouveaux concepts et dispositifs managriaux sans
participer toutefois dun modle unifi de gestion. Elles ne semblent pas sappuyer sur une
dmarche structure de management de projet. Elles posent ainsi la question du degr de
faisabilit du substrat technique8 qui y est associ, de la plus ou moins grande pertinence de la
philosophie gestionnaire 9 quelles sous-tendent soit, de leur contextualisation 10 interne (David,
1996).
Le caractre souple des outils agiles leur confre la capacit de sadapter facilement
aux modes de fonctionnement des quipes, essentiellement, de taille rduite (moins de 10
personnes). En effet, ces mthodes renvoient implicitement des configurations

(Chapitre I, section 2)
Littralement, lean signifie mince . A lheure actuelle, il nexiste pas de consensus qui diffrencie
clairement, en dveloppement informatique, lapproche lean des mthodes agiles . Daucuns confondent ces
deux concepts, dautres considrent que le lean renvoie un ensemble de principes concernant lorganisation au
sens global du terme dpassant ainsi les activits de dveloppement. Pour cette raison, nous avons dcid
daborder, tout au long de cette thse, lagilit comme un concept parapluie regroupant les principes et les
pratiques issus des mthodes agiles et de lapproche lean. Nous reviendrons sur la distinction entre ces deux
notions la fin du chapitre (I).
8
Le substrat technique est labstraction qui permet un outil de gestion de fonctionner (David, 1996, p.7). Il
sagit de la dimension concrte de linnovation (les runions de planification de litration, le plan de litration,
le tableau blanc, les post-it, les tests unitaires, etc.).
9
Une philosophie managriale correspond la signification gestionnaire de linnovation managriale, ses
aspects logiques et rationnels (la conformit du produit par rapport aux demandes des clients, la cration dun
environnement collaboratif, la rduction de la complexit du systme, etc.).
10
Par contextualisation, lauteur entend un tat ou un processus particulier de transformation rciproque de
l'innovation par les acteurs et des acteurs par l'innovation. Le degr de contextualisation interne peut tre dfini
comme la distance qui existe, un moment donn de l'histoire d'une innovation dans une organisation, entre
cette innovation et cette organisation . (David, 1996, p.12).
7

14

Introduction gnrale

organisationnelles simples o des modes de coordination de type adhocratique


(Mintzberg, 1984) peuvent facilement tre mis en place. Elles semblent participer dune
philosophie dorganizing o les acteurs sont impliqus dans des processus dajustement,
dexprimentation,

dapprentissage

et

damlioration

continus.

Linstabilit

de

lenvironnement pousse les quipes agiles sinterroger rgulirement sur la faon


damliorer leurs comportements par rapport aux situations rencontres. La mise en uvre
des outils agiles relve particulirement des comptences des individus, de leurs changes
et collaboration continus et de leur aptitude sadapter rapidement de nouvelles situations.
Si lapplication de ces mthodes a reu des chos trs positifs au niveau des quipes de taille
rduite, les rsultats ont t moins parlants quant leur application dans des structures
organisationnelles complexes o les modes de communication et de collaboration ne sont pas
toujours faciles raliser. Parmi les tudes empiriques ayant trait de la mise en pratique de
ces innovations managriales , rares sont celles qui se sont focalises sur leur application
dans des structures organisationnelles complexes11 . Nous constatons par consquent, une
vritable lacune dans la littrature consacre ce sujet. Dautant plus, quaujourdhui, la
majorit des organisations, sinscrivant dans des structures complexes, peine implmenter,
au sein de leurs quipes, ce type de pratiques de dveloppement et de management de projet.
La philosophie des mthodes agiles semble ainsi poser de faon centrale la question du
sens collectif, et ce dans une perspective interactionniste (Koenig, 2003) o la cration de
sens se fait de manire processuelle par lintermdiaire de la communication entre les
intervenants. Dans cette optique, les dynamiques dorganizing auxquelles ces mthodes
renvoient peuvent tre apprhendes comme des squences continues dinteractions entre les
acteurs dun projet. Cela nous amne nous interroger sur la manire dont ce type
dinnovation managriale (David, 1996) peut tre mis en uvre dans une dmarche
structure de management pour constituer un dispositif formalis dorganizing.
Lobjet de cette thse de doctorat en sciences de gestion est de rpondre cette problmatique
de recherche en articulant une analyse critique de la littrature consacre aux mthodes
agiles et une tude de cas (David, 2000) mene dans la perspective de lapproche par la
11

Par complexe nous dsignons une structure organisationnelle matricielle, de grande taille dans laquelle les
projets mens impliquent des acteurs mtiers transverses et godistribus.

15

Introduction gnrale

pratique (Gherardi, 2000, 2001 ; Whittington, 2003 ; 2007 ; Jarzabkowski, 2004 ;


Antonacopoulou, 2006 ; Jarzabkowski & Kaplan, 2008). Cette dernire met en avant laction
humaine pour comprendre le fonctionnement des groupes et les liens quils entretiennent avec
lorganisation et la socit (Rouleau, Allard-Poesi & Warnier, 2007).
Le choix de privilgier une approche par la pratique sexplique dune part, par le manque
de connaissances sur la manire dont les mthodes agiles sont appliques dans des
configurations organisationnelles complexes et dautre part, par notre volont de voir ce que
font concrtement les acteurs impliqus dans la fabrication et la mise en uvre de ces
mthodes mergentes de management de projet. A cette fin, lapproche par la pratique se
prsente comme un angle de recherche pertinent pour examiner de prs la construction
dune dmarche agile par les responsables de sa mise en uvre. Lattention est, ds lors,
centre sur les conversations des managers, leurs interprtations et leurs interactions par le
biais desquelles ils parviennent faire sens des mthodes agiles prsentes dans la
littrature acadmique et professionnelle et de lenvironnement dans lequel elles sont
implmentes.
Afin dinterroger le plus finement possible la manire dont les mthodes agiles sont
interprtes et appliques dans un contexte particulier, nous avons suivi, pendant 17 mois, la
mise en uvre dune dmarche managriale base sur des pratiques agiles 12 dans une
entit, appartenant un groupe franais de tlcommunication, responsable du pilotage et de
la livraison des produits de tlvision numrique par cble, satellite et sur le rseau IP. Les
raisons ayant amen la direction de lentit observe faire voluer ses mthodes de gestion
projet en empruntant la voie de lagilit sexpliquent principalement par le dpassement des
cots et des dlais de ses projets et la non-conformit des produits livrs aux attentes des
clients.
Cette tude de cas, qui constitue le cur empirique de notre travail de recherche, nous a
permis dexaminer en profondeur la manire dont ces mthodes peuvent tre dveloppes et

Dans ce travail, lagilit est apprhende comme un concept parapluie regroupant les principes et les
pratiques relevant de lensemble des mthodes agiles inclus lapproche du dveloppement lean issue du
monde industriel.
12

16

Introduction gnrale

mises en uvre, par un groupe de managers13, au sein dun contexte organisationnel


caractris par des conditions physiques, techniques et structurelles spcifiques.
Les observations ralises ont eu notamment pour objectif danalyser la dmarche de
fabrication dune stratgie agile et de sa mise en uvre dans une organisation
caractrise par des quipes instables, rattaches plusieurs projets et disperses
gographiquement.
La structure de la thse
Ce travail comprend deux parties :
La premire partie de cette thse est fonde sur une revue de la littrature sur les mthodes de
management de projet de type agile en tant qu innovations managriales . Elle est
compose de trois chapitres. Le chapitre (I) prsente et analyse les mthodes agiles du
point de vue des substrats techniques et de la philosophie gestionnaire quelles sousentendent. Le chapitre (II), met en perspective nombre de travaux rendant compte de
limplmentation de ces mthodes mergentes de management de projet au sein dentreprises.
A la lumire de ces deux volets danalyse, le chapitre (III) prsente la stratgie de recherche
que nous avons retenue : cerner la question de la contextualisation interne de ces
innovations managriales au travers dune approche par la pratique .
La seconde partie est consacre lanalyse de la construction dune dmarche agile de
management de projet : le cas dune fabrique de stratgie agile . Elle se subdivise
galement en trois chapitres : le chapitre (IV) prsente lorganisation dans laquelle sest
droul notre travail de terrain et prcise notre appareillage analytique. Le chapitre (V) rend
compte de nos observations et analyses de ltude de cas ralise durant 17 mois. Enfin le
chapitre (VI), est centr sur la mise en discussion de celles-ci.

13

Nous prcisons que la dmarche managriale lance par la direction gnrale a t prsente comme une
dmarche lean. Par consquent, le groupe dacteurs dsigns responsables de la mise en place de cette dmarche
sest attribu lappellation dquipe lean. Nanmoins cette dmarche repose sur des outils issus des mthodes
agiles de dveloppement informatique et du lean management.

17

Introduction gnrale

La conclusion est loccasion de revenir sur les principaux rsultats obtenus, de prsenter les
limites de cette thse et de proposer dventuelles pistes de recherche futures.

18

19

PARTIE I : DE LA QUESTION DES METHODES


AGILES COMME INNOVATIONS
MANAGERIALES

La premire partie de cette thse expose les lments des mthodes de management de projet
de type agile en tant qu innovations managriales .
Le chapitre (I) prsente les mthodes agiles . Trois mthodes agiles ont t retenues : la
mthode scrum, la mthode extreme programming et le lean development.
Le chapitre (II), met en perspective nombre de travaux rendant compte de limplmentation
de ces mthodes mergentes de management de projet au sein des entreprises.
Le chapitre (III) prsente la stratgie de recherche qui vise cerner la question de la
contextualisation interne de ces innovations managriales au travers dune approche
danalyse par la pratique .

20

Chapitre I : Prsentation des mthodes agiles :


principes et instruments de gestion

Ce chapitre est consacr la prsentation des mthodes agiles du point de vue des
substrats techniques et de la philosophie gestionnaire quelles sous-entendent. Il se divise en
deux sections.
Dans la premire section, nous dfinissons la notion dagilit, nous prsentons les causes de
lintrt actuel pour ces nouvelles approches de dveloppement et de management de projet
informatique et leurs principales sources dinspiration.
Dans la seconde section, nous prsentons trois approches agiles (la mthode scrum, la
mthode extreme programming et le development lean) ayant fait lobjet de nombreux
travaux empiriques. Nous dcrirons les pratiques et instruments de gestion ports par chacune
delles. A la fin de cette section, nous montrons comment ces trois approches offrent un bon
panorama du mouvement agile .

21

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Lagilit est avant tout une rponse llargissement et au durcissement des


environnements concurrentiels qui permet dinsuffler lorganisation ractivit et
performance14 . Applique au monde des logiciels, la notion dagilit renvoie la capacit
dadaptation des socits informatiques aux demandes volutives des clients, arrivant le plus
souvent en cours de projet et une meilleure matrise du triptyque cot/qualit/primtre
fonctionnel . Ces mthodes constituent une nouvelle logique de dveloppement de projets
informatiques, dcrites comme tant itratives, incrmentales, encourageant lautoorganisation et ladaptation au changement.
Avant dapprofondir davantage cette notion dagilit et ses principales sources dinspiration,
nous souhaitons revenir sur les limites des mthodes classiques de management de projet
qui semblent avoir particip lmergence du mouvement agile .
1. Des mthodes classiques de management de projet aux mthodes agiles
1.1 Les mthodes classiques : une dmarche lourde de conduite de projet
Les approches classiques de management de projet saccordent sur lhypothse selon
laquelle les dpenses augmentent dramatiquement lorsque des rectifications sont effectues
durant la phase dimplmentation. Dans cette perspective, les changements survenant aprs le
passage de la phase prliminaire du projet sont limits en vue de tenir les dlais et respecter
les cots pralablement fixs (Highsmith & Cockburn, 2001). Des contrats rigides sont
labors avec le client, prcisant, de manire trs fixe, le primtre et le cot de la solution
(Paetsch, Eberlein & Maurer, 2003). Laccent est donc mis sur la phase de planification
durant laquelle se fait la dfinition de lensemble des besoins implmenter. Le plan dtaill
constitue le fil conducteur, indispensable au projet. Beaucoup de temps et defforts sont ainsi
consacrs pour prvoir la totalit des demandes et rduire les changements ventuels (Sillitti,
14

Jean Pierre Vickoff (http://www.rad.fr)

22

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Ceschi, Russo & Succi, 2005 ; Hilkka, Tuure & Matti, 2005). On estime que le client est
capable de dterminer, ds la phase initiale, lensemble de ses attentes lgard de la solution.
La documentation, quant elle, occupe une place essentielle dans le dveloppement
classique de logiciels. Elle comprend la mmoire de toutes les micros-dcisions
oprationnalises (documentation conceptuelle, documentation du marketing, documentation
du codage, les codes, les documents dinstallation, etc.), matrialise lavancement des travaux
et constitue un support de communication entre les diffrents intervenants.
Cependant, les principes soutenus par ces modles renvoient des problmes varis. Une part
non ngligeable de lenveloppe budgtaire est consacre aux tapes danalyse et de prvision
des besoins. Dans cette logique, la planification extensive et les dcisions prises en amont
prennent le pas sur lintgration progressive des changements. Or, la lecture des travaux sur
les limites des approches classiques , un rsultat semble tre partag par la majorit des
spcialistes en informatique : lanticipation complte des besoins est difficile raliser car
dun ct, le client, lui mme, ne sait pas ce quil veut et dun autre, lenvironnement, dans
lequel se trouvent les industries de logiciels, volue constamment (Highsmith & Cockburn,
2001 ; Morien, 2005 ; Poppendieck, 2006 ; Petersen & Wohlin, 2009). Il est donc difficile
pour un manager de planifier et dorganiser en amont lensemble du processus de
dveloppement (Sillitti, Ceschi, Russo & Succi, 2005 ; Morien, 2005). Selon plusieurs tudes,
de nombreux projets logiciels sont abandonns avant dtre mis en production entranant des
pertes de plusieurs milliards de dollars (Standish group, 1995). Les principaux facteurs
dchec de ces projets sont lis une attitude prdictive inadapte (mauvaises estimations de
la productivit des quipes, des dlais et des cots), lvolution constante des besoins et
une faible implication des utilisateurs.
Dautres difficults renvoyant la rigidit de ces modles classiques concernent le
traitement des changements et la conformit aux demandes exprimes. Tout dabord,
lintgration et le traitement des modifications sont longs et coteux. Ils impliquent des
retours en arrire des mtiers qui sont dj passs dautres tches (Garel, 2003). Ensuite, la
sparation entre les acteurs de lamont (les concepteurs, le marketing) et ceux de laval
(dveloppeurs) gnre des barrires de communication et conduit des dsaccords dans la
dfinition et le recueil des besoins (Al Rawas & Easterbrook, 1996 ; Garel, 2003). En outre,
lintervention successive de diffrents acteurs mtiers (analystes, concepteurs, dveloppeurs,
23

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

etc.) engendrent des pertes dinformations importantes. De fait, les principes de gestion de
projet informatique et de dveloppement valoriss par les mthodes classiques ont t
remis en question.
1.2 Les mthodes agiles : une nouvelle tendance managriale
Le secteur informatique participe dune volution gnrale quont connue les industries de
logiciels, dans les vingt dernires annes. Cette volution se trouve lorigine de la rapidit et
de la complexit des projets informatiques : instabilit et obsolescence des demandes, fortes
exigences des clients, acclration du march technologique, diversification des offres, etc.
Comme nous lavons dj prcis, lanticipation des besoins des clients et la dfinition
complte de lensemble des demandes sont devenues trs risques. Dans un tel contexte, les
soucis de ractivit, de rduction des dlais de mise sur le march et dadaptabilit se sont
progressivement imposs.
Comment transformer les pratiques dingnierie et les modes de management pour produire
plus rapidement les applications informatiques? Comment concilier la qualit des produits et
les dlais de livraison ? Comment rendre les logiciels conformes aux attentes volutives des
clients ? Comment concilier la dialectique entre le niveau de connaissances acquis et les
capacits dactions dans un projet ? Cest en rpondant cet ensemble de questions quun
groupe de professionnels et dexperts en matire de dveloppement informatique a mis en
uvre, la fin des annes 1990, un ensemble de mthodes classes sous le qualificatif
agile .
1.2.1 Vers un consensus autour de la dfinition de lagilit
Depuis la fin des annes 1990, un nombre croissant de professionnels du dveloppement de
logiciels se sont intresss au concept dagilit et ont tent, travers divers articles et
ouvrages, dy apporter une dfinition. Pour Erickson et ses collgues (Erickson, Lyytinen &
Siau, 2005), l agilit permet de semparer de la rigidit des mthodes de dveloppement
traditionnelles et incite rpondre, de manire trs rapide, aux changements de
lenvironnement et aux contraintes imposes par les dlais, toujours plus courts, de livraison
de projets. Dans une mme optique, dautres auteurs ont apparent le dveloppement agile
aux notions de flexibilit, de rtroaction et dadaptation au changement rapide et continu.
24

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Pour ces personnes, les mthodes agiles ont t mises en place dans le but dintgrer le
changement plutt que de le freiner ou de le dtourner. Elles constituent un moyen pour les
socits de dveloppement de survivre dans un environnement instable (Abrahamsson, Salo &
Ronkainen, 2002 ; Williams & Cockburn; 2003 ; Beck & Andres, 2004). Dautres dfinitions
ont, quant elles, mis laccent sur laspect humain. Du point de vue de leurs auteurs,
limprvisibilit de lenvironnement est surmonte travers les individus et leur crativit
(Dyba, 2000 ; Beck, 2004). Si lensemble de ces dfinitions saccordent sur les principes
dadaptabilit et de flexibilit, elles ne permettent pas davoir une vision prcise de ce que
reprsente concrtement le concept dagilit en matire de dveloppement et de management
de projets informatiques.
1.2.1.1 Le manifeste agile
Les mthodes agiles aspirent amliorer la ractivit et ladaptabilit des socits de
logiciels aux fluctuations environnementales. En 2001, le mouvement agile a fait lobjet
dun accord entre dix-sept experts du dveloppement de logiciels dfendant une organisation
de projets informatiques moins structure et plus lgre que les mthodologies en vigueur, sur
un ensemble de valeurs et principes consigns dans un manifeste agile 15 .
Les rflexions et les retours dexpriences des professionnels de linformatique les ont
amens valoriser :
-

Les individus et les interactions plutt que les processus et les outils ;
Lapplication fonctionnelle plutt que la documentation comprhensive ;
La collaboration avec le client plutt que la ngociation des contrats ;
La rponse au changement plutt que le suivi dun plan.

Si les mthodes agiles privilgient les changes frquents entre les membres dun projet,
elles ne rejettent pas toutefois les outils mthodologiques en loccurrence, la planification.
Dans cette optique, les agilistes reconnaissent lutilit des plans mais ne sy conforment
pas aveuglement . Ces derniers sont sujets aux changements et doivent tre dfinis de

15

La dfinition officielle du dveloppement agile a t retenue dans un manifeste signe par 17


mthodologistes en dveloppement de logiciels : Kent Beck, James Grenning, Robert Martin, Mike Beedle, Jim
Highsmith, Steve Mellor, Arie van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries,
Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler et Brian Marick.

25

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

manire itrative. La planification fait donc lobjet dchanges informels et dajustements


mutuels entre les acteurs projets.
En ce qui concerne le processus de dveloppement, il ne renvoie pas un contrat fixe
entre le client et les acteurs projets. Il sappuie, en revanche, sur un ensemble dactivits
(runion de planification du livrable, runion de planification des itrations, etc.) et dartefacts
flexibles (product backlog 16, sprint backlog17, user-stories18) prcisant les engagements des
deux parties. Nous reviendrons un peu plus bas sur les instruments de gestion ports par ces
mthodes mergentes.
Conformment aux valeurs soutenues par les fondateurs du mouvement agile , la
documentation comprhensive est perue comme une source majeure de gaspillage.
Nanmoins, elle ne peut tre entirement limine et par consquent, elle doit tre repense
diffremment. A cet effet, la documentation ne constitue plus une activit part, ncessitant
un investissement en termes de temps et de ressources mais rsulte des activits de
dveloppement menes : story-cards19 , les tests, les codes, product-backlog , etc.
Aprs avoir prsent les valeurs fondamentales du mouvement agile il apparat utile de
dresser la liste des principes qui en dcoulent : la livraison rapide de logiciels utiles et de
qualit ; ladaptation aux changements et aux demandes tardives des clients ; la collaboration
et les interactions continues entre les parties prenantes du projet ; la construction dun projet
autour dindividus bien motivs ; la production dune application fonctionnelle permettant de
mesurer progressivement lavancement du projet ; la qualit de la conception et lexcellence
technique; lauto-organisation des quipes; lamlioration continue de lefficacit de lquipe
et la simplicit. Lannexe (I) reprend les principes agiles tels quils sont mentionns dans
le manifeste.
Divers questionnements mritent toutefois dtre traits : pourquoi faut-il impliquer le client
dans le processus de dveloppement ? Quel est lintrt de livrer rapidement des solutions
Cest un document danalyse dtaill qui liste lensemble des fonctionnalits implmenter. Les items nots
sur le product-backlog peuvent contenir les critres, les fonctionnalits, la fixation des bugs, les dfauts, etc.
17
Cest le point de dpart de chaque sprint ou itration. Le sprint-backlog contient la liste des tches raliser
dans la prochaine itration afin de convertir les items du product-backlog en un incrment livrable.
18
Il sagit des demandes fonctionnelles et des besoins des utilisateurs qui sont gnralement crits par les
utilisateurs.
19
Ils reprsentent des cartes sur lesquelles sont marqus les scnarios ou les histoires des utilisateurs .
16

26

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

fonctionnelles capables dintgrer les changements continus ? Quels sont les avantages dun
dveloppement itratif et incrmental ? Les travaux ayant trait de ces questions seront
prsents dans le chapitre (II).
1.2.2 Les enjeux du dveloppement agile de logiciels
Lattention actuelle accorde au dveloppement agile procde dune double explication :
les enjeux de ractivit et les avantages du dveloppement rapide. Ces enjeux ont dj t
lorigine dautres modles dorganisation et de management de projets en gnral, titre
dexemple, le modle dingnierie concourante, que nous prsenterons brivement.
La saturation des marchs, lhtrognit des demandes et les difficults danticipation des
besoins ont transform les systmes de production des industries manufacturires. Le modle
de lconomie ractive sest ainsi impos au niveau de ces industries remettant en cause les
modles de la standardisation 20 et de varit 21. Dans une conomie de concurrence, les
entreprises modifient leur systme productif pour rduire les dlais de mise sur le march et
gagner en ractivit 22. A cet effet, de nouvelles stratgies ont t adoptes par les
organisations la recherche dun avantage comptitif durable: la stratgie de niche pour
capter les demandes les plus exiges et la stratgie dobsolescence (Garel, 2003). On postule
que les demandes sont volatiles et se transforment rapidement.
Bien que cette hypothse soit galement soutenue par les agilistes , les stratgies de
rponse adoptes par ces derniers savrent diffrentes. Si lingnierie concourante repose sur
une logique doffre proactive, les mthodes agiles , quand elles, mettent laccent sur
ladaptation aux besoins mergents des clients. Le processus de dveloppement relve dune
collaboration forte entre le client et lquipe de dveloppement.
Par ailleurs, le dveloppement rapide de produits, valoris tant par lingnierie concourante
que par les approches agiles , prsente des avantages : dune part, le client a peu de chance
de changer son avis si le produit lui est livr rapidement et dautre part, les cots et les
20

Ce modle renvoie la production de masse des biens ayant de longs cycles de vie. En priode de croissance
stable ce modle savre efficace (Garel, 2003). Lobjectif de lentreprise est de rpondre, sans souci premier de
dlai ni de qualit, une forte demande du march en proposant des produits standardiss bas prix.
21
Ce modle renvoie la diversification des offres pour rpondre aux besoins varis des clients. Ce modle
prsuppose que les demandes sont facilement identifiables et prvisibles.
22
La ractivit signifie la capacit reconfigurer rapidement ses ressources de production et la capacit
rpondre rapidement aux exigences des consommateurs (Cohendet & al, 1992 dans Garel, 2003, p.39).

27

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

dpenses supplmentaires lis la dcouverte tardive de dfaillances sont limits. Les cycles
de dveloppement courts procurent une vision concrte et progressive par rapport la partie
dveloppe rduisant ainsi les risques de non-conformit aux attentes (Poppendieck, 2006).
Les enjeux ayant conduit les industries manufacturires changer de modle de production
sapparentent ceux des modles mergents de dveloppement informatique. A ce titre, il est
utile de revenir sur les approches managriales qui ont inspir les fondateurs des mthodes
agiles .
1.3 Les sources dinspiration des mthodes agiles
1.3.1 Transposition du modle Toyota au dveloppement de logiciels
Les annes 1980 et 1990 tmoignent de la transformation des systmes dorganisation
largement inspirs du taylorisme et du fordisme. Lexpansion des principes de gestion issus
du modle japonais, connu aujourdhui sous le systme de production Toyota (TPS), semble
tre lorigine dun tel changement. Les concepts cls dont relve ce systme renvoient
principalement lautonomation et la production juste temps. Lautonomation regroupe un
ensemble doutils (landon qui consiste arrter automatiquement la production en cas de
problme) et de mthodes (pareto des causes, la mthode des 5 Pourquoi) dont le but est
dinciter lensemble des employs dune entreprise amliorer ex ante la qualit des produits
et des services vendus plutt que dliminer ex post les rebus. Le principe de juste--temps,
quant lui, consiste organiser son entreprise de telle sorte quelle puisse livrer exactement et
au bon moment la quantit de biens souhaits par ses clients. La production est tire par la
demande. En dautres termes elle est dclenche par les demandes des clients (Houy, 2009).
Aprs le succs spectaculaire du Systme de Production Toyota traduit sous le terme de lean
management23, de nombreux constructeurs de vhicules ont tent de reproduire, au sein de
leur organisation, lensemble des principes et pratiques relevant de cette approche
managriale dans le but damliorer la performance et la productivit de leur systme de
production. La russite commerciale affiche par les industries lean et leur forte mdiatisation
23

Littralement lean signifie maigre . Le lean management qualifie un ensemble de pratiques managriales
inspires du Toyota Production System (TPS). Brivement, on peut reprsenter le lean management comme un
ensemble de principes et de procdures qui consistent grer au plus juste les processus de production (
produire la quantit exacte au bon moment) et liminer tout ce qui ne cre pas de valeur. Cette approche de
dveloppement est prsente dans la section suivante (II).

28

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

nont fait qulargir lexpansion de ce systme diffrents secteurs, dpassant ainsi son
domaine dapplication initial, celui de la production industrielle. Il nest donc pas surprenant
que le lean finisse par intresser le march des industries de logiciels en pleine mutation et
croissance. Lindustrie japonaise, capable de livrer trs rapidement des produits de haute
qualit, va constituer une base empirique et thorique pour le management des projets
informatiques. Divers facteurs de vitesse de dveloppement de projet ont t exposs par
Imaii et alii en 1985 (Imaii & alii en 1985 dans Garel, 2003) dont certains ont t repris par
les agilistes : lauto-organisation des quipes, le multi-apprentissage, lajustement mutuel,
le partage dinformations dans un environnement de travail ouvert et le regroupement des
acteurs dans un mme espace physique.
1.3.2 Lagile manufacturing
L agile manufacturing a t cr dans les annes 1990 par des chercheurs amricains, de
Lehigh University, chargs damliorer la performance des industries amricaines. Les
dfaillances du systme de production de masse et les menaces des pays industrialiss dAsie
ont pouss les firmes amricaines changer leur mode de production et emprunter la voie de
l agilit . Un rapport, publi par les chercheurs de linstitut Iacocca, intitul 21st
Century Manufacturing Enterprise Strategy (Nagel, Dove, Goldman & Preiss, 1991),
prsente les caractristiques de lagile manufacturing. Bien que divers chercheurs ont tent de
dfinir lagile manufacturing, il nexiste pas lheure actuelle une dfinition universelle. A
cet effet, nous prsentons trois dfinitions de lagilit organisationnelle qui relvent de
diffrentes dates de publications.
Lagile manufacturing a tout dabord t dfini comme une entreprise robuste, adaptative
avec une capacit de reconfiguration rapide pour rpondre aux opportunits du march. Une
telle entreprise est fonde sur des processus et des structures appropris ainsi que sur un
systme coordonn de personnes, dorganisation et de technologies permettant dacqurir une
performance comptitive suprieure celle des pratiques existantes.
An agile corporation is a fast moving, adaptable and robust business enterprise capable of
rapid reconfiguration in response to market opportunities. Such a corporation is founded on
appropriate processes and structures and the integration of technology, organization and
people into a coordinated system in order to achieve a quantum leap forward in competitive

29

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

performance by delivering capabilities that surpass those obtained from current enterprise
practices (Kidd, 1995, p.3).
Dans une mme perspective, Gunasekaran (1998) dcrit lagile manufacturing comme la
capacit de survivre et de prosprer dans un environnement comptitif et instable. Les
entreprises agiles sont capables de ragir rapidement aux changements des marchs qui
eux sont rgis par les demandes des clients.
capability to survive and prosper in a competitive environment of continuous and
unpredictable change by reacting quickly and effectively to changing markets, driven by
customer-designed products and services (Gunasekaran, 1998 dans Kettunen, 2009).
Une autre dfinition plus rcente identifie lagile manufacturing comme la capacit de
rpondre un march turbulent soumis aux exigences des clients en termes de rduction de
cots et de dlais.
Ability to respond to, and create new windows of opportunity in a turbulent market
environment driven by individual customer requirements cost effectively and rapidly
(Ismail, Snowden, Poolton, Reid & Arokiam, 2006 dans Kettunen, 2009).
Ces dfinitions partagent toutes une caractristique commune : elles mettent laccent sur les
concepts de ractivit 24 et dadaptabilit 25 de lindustrie manufacturire. En ce sens, lagilit
renvoie la capacit dune organisation mettre en uvre des ajustements rapides et
efficaces pour rpondre lvolution des demandes des clients de plus en plus exigeants.
Il nous parat ainsi judicieux de comparer les concepts de lagile manufacturing ceux des
mthodes agiles (tableau 1)26.

24

Cf. page 27.


Ladaptabilit est la capacit du systme de production dune entreprise rajuster ou modifier les cots de
performance en fonction de la demande (Katayama & Bennett, 1999).
26
Ce tableau comparatif se base sur une tude ralise par Kettunen (Kettunen, 2009).
25

30

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Tableau 1: Comparaison des concepts de l'agile manufacturing v/s mthodes agiles


Concepts

Agile manufacturing

Mthode agiles

Rponse rapide
aux changements

Capacit de lentreprise transformer


rapidement les informations collectes en
dcisions actionnables (Gunasekaran, Yusuf,
2002).

Capacit de sadapter aux


changements travers de courts
cycles de dveloppement.

Cycles de
dveloppement
rapides

Dveloppement rapide bas sur de courts


cycles concept-to-cash (Goldman, Nagel &
Preiss, 2005 dans Kettunen, 2009).

Cycles courts ne dpassant pas les


quelques semaines. Les itrations
sont fixes dans le temps.

Reconfiguration

Capacit dune entreprise reconfigurer sa


structure organisationnelle et ses processus
et rorienter sa production ainsi que ses
ressources afin de mieux rpondre aux
changements
(Gunasekaran, Yusuf, 2002).

Reconfiguration au niveau du
produit et du projet (restructuration
des codes, modification du design).

Pro-activit

Saisir les nouvelles opportunits ou


provoquer des ruptures par le biais de
linnovation
(Yusuf, Sarhadi & Gunasekaran, 1999)

Adaptation aux besoins mergents


des clients et rduction des activits
danticipation.

Qualit

La qualit renvoie la valeur ajoute perue


par le client. Il nexiste pas de compromis
prcis sur la qualit
(Liker, 2004 dans Kettunen, 2009).

La qualit est considre comme


une norme. Recours des pratiques
dingnierie pour amliorer la
qualit (tests unitaires, intgration
continue).

Stratgie des
processus
industriels

Les capacits industrielles sont dtermines


en fonction des objectifs stratgiques. Les
industries agiles sont du type make-to-order
27

(Narasimhan, Swink & Kim, 2006)

Leadership

Le management scientifique est remplac


par le principe dempowerment. Les
personnes disposent dune autonomie,
accorde par leur hirarchie, pour organiser
leur travail.
(Gunasekaran, Yusuf, 2002).

Les mthodes de dveloppement


agiles sont de nature engineering to
order 28 : les fonctionnalits sont
redfinies et stabilises durant la
conception du produit.

Renforcement et auto-organisation
des quipes.

27

La production se fait suite une demande bien prcise.


Il sagit dune mthode de dveloppement dans laquelle la conception de lensemble ou dune partie du produit
se fait selon lordre du client.
28

31

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Entreprise guide
par les
connaissances

Les connaissances collectives constituent un


avantage comptitif pour lorganisation
(Yusuf, Sarhadi & Gunasekaran, 1999).

La circulation libre de linformation


et les connaissances tacites sont
valorises.

Prises de
dcisions

Lautorit est distribue, les prises de risque


et le partage de connaissances sont
encourags.
(Shafer, 1997 dans Kettunen, 2009).

La responsabilit est partage entre


les membres dune quipe de
dveloppement agile. la
collaboration et la communication
frquente sont encourages.

Ce tableau permet de comprendre les fondements de la notion dagilit qui se trouvent


lorigine des transformations des industries manufacturires et des industries de logiciels.
Malgr le rapprochement que nous avons pu constater entre les deux approches dagilit,
certaines diffrenciations subtiles mritent dtre soulignes.
Tout dabord, les stratgies adoptes pour matriser et rpondre aux changements sont
diffrentes : les fondateurs de lagile manufacturing valorisent non seulement la ractivit
lgard des changements mais aussi la proaction qui est dailleurs encourage par
lingnierie concourante. En revanche, le dveloppement agile cherche sadapter aux
besoins mergents du client en favorisant la collaboration troite avec celui-ci ; lanticipation
des vnements futurs ntant pas privilgie.
Ensuite, les stratgies des processus industriels diffrent dun modle un autre. Si lagile
manufacturing exige une dfinition prcise de la demande avant le lancement de la
production, le dveloppement agile , quand lui, se base sur une dfinition vague des
fonctionnalits implmenter qui seront dtailles puis dveloppes, en fonction de leur
priorit, au fur et mesure de lavancement du projet.
En outre lagile manufacturing ne semble pas sappuyer sur des pratiques spcifiques
destines amliorer la qualit. Cette dernire renvoie la valeur ajoute perue par le client.
Quant aux mthodes agiles , en particulier la mthode extreme programming , elle
repose sur des pratiques dingnierie (le dveloppement conduit par les tests, lintgration
continue, le nettoyage quotidien des codes) qui cherchent anticiper les dfauts et les
bugs et amliorer la lisibilit des codes et sa maintenabilit.

32

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

1.3.3 Le dveloppement itratif et incrmental


Dautres sources, plus rarement cites, semblent galement avoir inspir les auteurs du
courant agile : le dveloppement itratif et limplication des utilisateurs.
Le dveloppement itratif et incrmental remonte aux travaux de Walter Shewhart29 en 1930.
Lavion hypersonic X-15 fut une premire tape dans lapplication du principe de
dveloppement itratif et incrmental. Ce type de dveloppement a t peru comme une
contribution majeure au succs du X-15. Ce principe fut ensuite appliqu, en 1960, au
dveloppement de logiciel autour du projet Mercure. Un article a t publi en 1975 dcrivant
ce type dapproche.
The basic idea behind iterative enhancement is to develop a software system incrementally,
allowing the developer to take advantage of what was being learned during the development
of earlier, incremental, deliverable versions of the system. Learning comes from both the
development and use of the system, where possible (Basili & Turner, 1975).
Dautres rapports ont tent de montrer les avantages lis ce type de dveloppement. Les
courtes itrations permettent davoir un feedback sur les parties dveloppes limitant les
risques de l effet tunnel (longueur des projets) et les problmes de qualit.
A complex system will be most successful if it is implemented in small steps and if each step
has a clear measure of successful achievement as well as a retreat possibility to a previous
successful step upon failure. You have the opportunity of receiving some feedback from the
real world before throwing in all resources intended for a system, and you can correct
possible design errors
(Rapport de Gilb, software metrics, 1978 dans Larman & Basili, 2003).
Quant au principe dimplication des utilisateurs, celui-ci a galement fait lobjet de rapports
antrieurs.
Software development should be done incrementally, in stages with continuous user
participation and replanning and with design-to-cost programming within each stage
(Rapport de Mills, IBM, 1976 dans Larman & Basili, 2003).
Ces sources dinspiration montrent bien que contrairement ce que de nombreux travaux
sous-entendent de nos jours, la notion dagilit nest pas rcente. Beaucoup de professionnels
29

Expert Bell-Labs, Walter Shewhart proposa, dans les annes 1930, les courts cycles plan-do-study-act
(PDSA) damlioration de la qualit repris par Edward Deming travers le PDCA (plan-do-check-act).

33

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

de linformatique ont dj eu recours des pratiques que nous qualifions aujourdhui


d agile . A ce titre, il serait intressant de montrer la place quaccordent, actuellement, les
industries de logiciels ces mthodes.
1.3.4 Lintrt actuel des entreprises pour le dveloppement agile
En trs peu de temps, la notion d agilit a connu un grand succs au niveau des industries
de dveloppement de logiciels. Plusieurs tudes ont dj t ralises pour valuer le taux
dadoption de ces approches mergentes.
Une enqute internationale 30, conduite en 2008 auprs de 642 professionnels du
dveloppement dapplications informatiques et en management de projets, a montr que 69 %
des participants utilisent, au cours de leur projet, une ou plusieurs technique(s) relevant des
mthodes agiles . Durant la mme anne, une seconde tude internationale31 a t ralise
auprs de 3061 employs utilisant ce type de pratiques. Les principaux rsultats montrent
que 49% des quipes agiles mobilisent la mthode scrum , et 22% combinent les
mthodes scrum et extreme programming . En effet, 26% des entreprises utilisent les
mthodes agiles depuis deux ans et 7% depuis plus de 5 ans.
Selon un autre rapport dtude32, publi en 2009, concernant 123 praticiens agiles , 65%
des participants dclarent recourir lintgration continue, 47% aux runions quotidiennes et
au dveloppement bas sur les tests et 45 % au dveloppement itratif. Ces diffrentes
pratiques seront prsentes en dtails dans la section suivante.
Une autre enqute internationale 33 laquelle nous nous sommes intresss, a t conduite, en
2010, auprs de 4770 participants dont la majorit savre des managers de projets. Les
rsultats montrent que 40% des organisations utilisent des pratiques agiles depuis environ
deux ans et que dans 32% des cas, ces pratiques sont adoptes par de larges organisations
(>250 salaris). Toutefois 65% des personnes interroges affirment avoir travaill avec des
quipes agiles gographiquement distribues. Les mthodes agiles mobilises sont la
mthode scrum (58%), la combinaison scrum et extreme programming (17%), le
dveloppement lean (2%). Les participants estiment trs important le fait que ces
30

http://www.ambysoft.com/surveys/agileFebruary2008.html
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
32
http://www.ambysoft.com/surveys/practices2009.html
33
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
31

34

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

mthodes amliorent les dlais de mise sur le march (37%), les capacits de gestion du
changement des priorits (36%), la qualit des logiciels (24%), la visibilit du projet (17%),
etc. En revanche, il apparat que lchec des projets agiles est d principalement au
manque dexprience des quipes en dveloppement agile (14%), la culture dentreprise
(11%), aux pratiques traditionnelles dj existantes (10%) et au manque de support du
management (8%). Les obstacles auxquels font face les organisations relvent essentiellement
du changement de la culture organisationnelle (51%), de la rsistance au changement (40%),
du support du management (34%), de la complexit et de la taille des projets (31%).
Au regard de ces chiffres, nous constatons queffectivement la mise en place de ces mthodes
relve dun phnomne rcent auquel sintressent les organisations, indpendamment de leur
taille. Il apparat, qu ce jour, les professionnels de dveloppement de logiciels demeurent
moyennement familiers avec ces pratiques de dveloppement mergentes. Si les mthodes
agiles peuvent amliorer les dlais de mise sur le march et la productivit des quipes,
elles ncessitent un investissement en termes de dveloppement des quipes, de
sensibilisation au changement organisationnel, dinitiation lauto-organisation, aux changes
et aux suivis rguliers. A la lumire des rsultats remonts, divers facteurs semblent entraver
ladoption de ces mthodes : le manque dexprience des quipes en dveloppement agile ,
les difficults associes aux transitions culturelles, la rsistance au changement
organisationnel, la complexit et la taille des projets, etc.
2. Prsentation des mthodes agiles
Les premires publications sur les mthodes agiles apparaissent en 1991 avec le
dveloppement de la mthode RAD34 par James Martin. Dautres mthodes ont ensuite vu le
jour telles que la mthode DSDM35, la famille des mthodologies Cristal36, le dveloppement

34

Rapid Application Development. Cette mthode conjugue le modle linaire, structur en cinq phases
(initialisation, expression des besoins, conception, construction et mise en uvre) et le modle itratif propre la
phase de dveloppement. Si cette mthode met en avant limplication des utilisateurs et le dveloppement
itratif, elle privilgie nanmoins la documentation extensive (Annexe III).
35
Dynamic System Development Methodology. Elle a t mise au point en 1994 dans le but de combler certaines
lacunes de la mthode RAD. Le cycle de vie du projet repose sur cinq phases : tude de faisabilit, tude du
mtier, modlisation fonctionnelle, conception-construction et mise en uvre. Les deux premires phases sont
ralises de manire squentielle alors que les trois suivantes seffectuent de manire itrative facilitant
ladaptation aux changements des fonctionnalits et des aspects techniques de la solution. Compare la
mthode RAD, le modle DSDM met davantage laccent sur le caractre itratif des cycles de modlisation
fonctionnelle et de dveloppement. La participation du client est galement plus accentue (Annexe III).

35

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

conduit par les tests37 , etc. Si lensemble des mthodes agiles sappuient sur des
principes et des valeurs communes, elles se dmarquent, toutefois, par rapport aux pratiques
et instrumentations de gestion quelles mobilisent.
Dans le cadre de ce travail, nous retiendrons principalement trois mthodes qui font lobjet
dune littrature foisonnante et qui constitueront le cur de notre revue de la littrature sur le
sujet : l extreme programming , le scrum et le lean dveloppement . Ces mthodes
sont largement diffuses dans les milieux acadmiques et professionnels ; par ailleurs chacune
dentre elles reprsente une forme dagilit diffrente mais complmentaire dans la conduite
des projets informatiques. Lensemble de ces trois approches donne une certaine compltude
la prsentation du courant agile .
Dans cette section, nous nous attachons dcrire le contenu de chacune de ces trois mthodes.
Pour ce faire, nous nous appuyons sur les ouvrages de base des auteurs de ces mthodes afin
de comprendre clairement leurs fondements et objectifs respectifs.
2.1 La mthode scrum
2.1.1 Principes, pratiques et instrumentations de gestion
Si le terme scrum fut popularis aprs la publication de louvrage de Ken Schwaber
agile software development with scrum , en 2001, celui-ci avait dj fait lobjet dun article
de Takeuchi et Nonaka en 1986 intitul the new new product development game . Dans cet
article, les auteurs se rfrent au concept scrum pour souligner une approche de
dveloppement permettant damliorer la cohsion de lquipe et la rapidit du processus de
dveloppement a rugby approach where a team tries to go to the distance as a unit, passing
the ball back and forth-may better serves todays competitive requirements (Nonaka &
36

Cre par Alistair Cockburn en 1995, la famille de mthodologie Crystal estime amliorer la communication
entre les membres des quipes de dveloppement et acclrer la rapidit de livraison des solutions
technologiques (Highsmith & Cockburn, 2001). Son nom renvoie la variabilit de couleurs refltes par un
cristal. Plusieurs varits sont ainsi regroupes dans cette famille : la mthode Crystal Clear , Crystal
Orange , Crystal Red. Le choix dune mthode dpend du contexte dapplication de celle-ci. A titre
dexemple, la mthode Crystal Clear base sur la communication frquente, la colocalisation des membres de
lquipe, les livraisons incrmentales (tous les 2 ou 3 mois) et la collaboration troite avec le client convient pour
des petites structures (quipes inferieures 6 personnes) (Highsmith & Cockburn, 2001). La mthode Crystal
Red , privilgiant les processus et la documentation, savre plus adapte des projets de grande taille
(Cockburn, 2002b).
37
Test driven development ou le dveloppement conduit par les tests est une mthode de dveloppement de
logiciels qui prconise dcrire les tests unitaires avant dcrire les codes du logiciel.

36

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Takeushi, 1986, p.2-3). Au sens initial du terme, scrum renvoie une pratique
gnralement connue au rugby signifiant la mle 38 . Cette mthode qualifie un ensemble
de rles, dinstruments de gestion et de pratiques managriales favorisant un environnement
base sur la transparence39, linspection, le suivi40 et ladaptation41.
2.1.1.1 Les rles dans la mthode scrum
Les membres dune quipe scrum nont pas de rles prdfinis. Ils sont pluridisciplinaires
et sont capables de raliser des activits varies (architecture, conception, dveloppement,
test, etc.). Par ailleurs, les responsabilits managriales sont rparties sur trois rles: le
scrum-master , le product-owner et lquipe scrum .
Le scrum-master : il fait le relais entre le product-owner et lquipe scrum . Il ne gre
pas son quipe, qui est autonome mais laide affronter les problmes quelle rencontre et
raliser les objectifs fixs. Son rle consiste guider lquipe dans la mise en uvre de la
mthode scrum et sassurer quelle adhre aux valeurs, aux rgles et pratiques soutenues
par la mthode.
Le product-owner : il est responsable de lidentification des demandes implmenter et de
loptimisation du retour sur investissement. Il communique la vision du produit lquipe de
dveloppement et dtermine les fonctionnalits dvelopper en fixant la date de lancement du
projet. Il est charg de la maintenance et de la dfinition des items dans le productbacklog ainsi que de leur priorisation. Il convient ici de prciser quun product-owner ne
peut jamais tre un scrum-master .
Lquipe scrum : elle est constitue de quatre dix personnes au maximum. Elle a pour rle
de convertir les items du product-backlog en fonctionnalits utilisables la fin de chaque
itration. Bien que les membres de ces quipes sont polyvalents chacun est nanmoins
spcialis dans une activit prcise : programmation, contrle de la qualit, interface des

38

Le principe de base tant d'tre toujours prt rorienter le projet au fil de son avancement.
Le principe de transparence consiste sassurer que les divers aspects du processus, affectant les rsultats du
projet, sont visibles aux personnes charges de la gestion des rsultats.
40
Les principes dinspection et de suivi mettent laccent sur linspection frquente du processus de
dveloppement afin de dceler tout cart dans les rsultats attendus.
41
Ladaptation implique que les ajustements doivent tre effectus le plutt possible pour minimiser les risque de
dviation.
39

37

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

utilisateurs, architecture, etc. En outre, lquipe sauto-organise pour atteindre les objectifs
fixs.
2.1.1.2 Les artefacts scrum
La mthode scrum repose sur trois principaux artefacts: le carnet du produit productbacklog , le carnet de litration sprint-backlog et le graphique de progression
burndown chart .
Le product-backlog : cet outil reprsente un document listant les fonctionnalits du projet ou
du produit dvelopper. Les items renseigns dans celui-ci peuvent renvoyer des
fonctionnalits, des fixations de bugs, des dfauts, des tests, etc. Dans tout productbacklog , les items sont dcrits, estims et prioriss. Par ailleurs, le product-backlog
volue avec le produit et peut tre modifi en fonction des besoins. Seul le product-owner
est responsable du contenu de cet outil (Annexe IV).
Le sprint-backlog : il constitue le point de dpart de chaque itration. Cet outil contient la
liste des tches raliser dans la prochaine itration. Les tches sont slectionnes par
lquipe scrum lors de la planification de litration laquelle participent le scrummaster et le product-owner . Toutefois, seuls les membres de lquipe peuvent modifier
le sprint-backlog durant litration. Une fois les tches slectionnes sont acheves, une
nouvelle itration commence (Annexe IV).
Le burndown chart : cest un graphe permettant de visualiser lavancement des tches au fil
du temps. Au cours dune itration, cet outil permet de mettre en vidence la corrlation entre
la quantit de travail restante un moment donn et lavancement de lquipe projet (Annexe
IV).
Un autre outil intangible qui semble amliorer la communication entre les membres dune
quipe scrum mrite dtre prsent: la notion done ou ralis . En effet, lobjectif
de lquipe scrum est de livrer, la fin de chaque itration, un sous-ensemble du produit
final. Par consquent, chaque sous-ensemble doit tre signal comme ralis avant quil
soit rajout lincrment prcdent. Des tests sont galement effectus en vue de vrifier la
cohrence et le fonctionnement des incrments rassembls. Or, la terminologie done nest
pas comprise de la mme faon par toutes les personnes impliques dans un projet. A titre
38

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

dexemple, si pour certains dveloppeurs, la notion done implique que le code est propre,
correctement remani, compil et test, pour dautres personnes ce mme terme peut signifier
uniquement compil. Dans cette perspective, les fondateurs de la mthode scrum insistent
sur la clarification des connotations des termes pour viter les incomprhensions et les
conflits ventuels au sein de lquipe.
Par ailleurs, la mthode scrum repose galement sur un ensemble de pratiques
managriales visant la planification du projet et lorganisation des quipes : la runion presprint , la planification de litration sprint planning meeting , les runions quotidiennes
daily scrum , la revue de litration sprint review meeting et la rtrospective de
litration sprint rtrospective .
2.1.1.3 Les pratiques managriales de la mthode scrum
Pre-sprint : cest une runion de planification de livrable permettant de discuter et rpartir les
items du product-backlog sur les prochaines itrations. Durant cette runion, laquelle
participent les parties prenantes du projet, les cots, le budget et la date de livraison du
produit sont estims.
Sprint planning meeting : cest une runion, double phase, organise par le scrummaster . Dans un premier temps, lquipe scrum dcide avec le product-owner , de
lobjectif de litration et des scnarios raliser. Dans un deuxime temps, le scrummaster et lquipe scrum se runissent pour se focaliser sur la manire dont lincrment
sera implment: les diffrentes tches raliser sont ainsi identifies, estimes et priorises.
La granularit d'une tche doit tre d'environ un deux jours de travail.
Daily scrum : la mle est une runion quotidienne de quinze minutes o lquipe
scrum se runit, souvent, au mme endroit et au mme moment. Durant cette runion, le
scrum-master pose trois questions chaque membre de lquipe : qu'est-ce que tu as fait
hier ? Qu'est-ce que tu vas faire aujourd'hui ? Et quelles difficults as-tu rencontres ?
Lobjectif est de suivre de prs le progrs de lquipe et de rsoudre rapidement les problmes
lors de leur apparition. Les quipes utilisent des minuteurs pour ne pas dpasser les quinze
minutes de la runion. Si un membre de lquipe a besoin de discuter dun sujet qui ne peut
pas tre couvert dans ces quinze minutes, il est recommand quil participe une autre
runion nomme side-bar qui suit le daily scrum .
39

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Post-sprint meeting : la fin de chaque itration, le travail de lquipe est prsent devant le
product-owner . Cette runion permet destimer le progrs du projet et sa conformit aux
critres dacceptation dfinis par le product-owner .
Rtrospective-meeting : aprs la runion post-sprint , lquipe scrum et le scrummaster se runissent pour valuer rtrospectivement le droulement de litration : lquipe
voque ce qui sest bien pass et ce qui sest mal pass et avec le scrum-master , ils
identifient les amliorations faire dans les prochaines itrations. Durant cette runion,
lquipe est amene voquer les points de succs et dchecs du projet. Cette runion est
aussi une occasion pour le scrum-master dobserver les obstacles rcurrents qui
influencent le fonctionnement de lquipe.
2.1.1.4 Le modle de dveloppement scrum
Le processus de dveloppement dbute par une dfinition du systme dvelopper. On
postule que la vision de la solution volue avec lavancement du projet. Dans cette phase
davant jeu pre-game , les demandes fonctionnelles et non fonctionnelles sont dfinies et
rpertories dans le product-backlog . Ces demandes sont labores par le client, le
marketing ou le dveloppeur reprsent par le product-owner . A ce stade le nombre de
scnarios, la date et les cots de livraison ainsi que le contrle de risques sont revus par
lquipe de dveloppement. Au cours de cette phase, larchitecture du systme est planifie
par lquipe scrum partir des lments du product-backlog .
Ensuite, litration dont la dure oscille entre une et quatre semaines est initie par un sprint
planning meeting au cours duquel le product-owner et lquipe vont ngocier des
scnarios implmenter. Cette runion ne peut excder les huit heures. Elle comporte
deux volets de quatre heures chacun : le premier est consacr la slection des items du
product-backlog et le second consiste dfinir et estimer les tches raliser.
Lestimation relve de la vlocit 42 de lquipe de dveloppement et de ses expriences
passes. Si le choix et la priorisation des fonctionnalits implmenter reviennent au
product-owner ils peuvent toutefois tre modifis par lquipe scrum .

La vlocit renvoie au nombre de scnarios que lquipe estime tre capable de raliser durant une itration.
Elle peut tre dtermine partir de lexprience de lquipe sur le sujet, des projets antrieurs, etc.
42

40

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Dans la phase de jeu game , une runion quotidienne daily scrum , dune dure de
quinze minutes, a lieu entre les membres de lquipe scrum . A la fin de litration, une
revue de litration, dune dure de quatre heures se fait entre lquipe scrum et le
product-owner . Lquipe prsente au product-owner le produit partiel pour avoir son
retour sur les fonctionnalits dveloppes. Aprs cette runion, la rtrospective de litration
se droule entre lquipe et le scrum-master o chaque membre est invit sexprimer sur
litration passe. Ces diverses runions (daily scrum, sprint planning meeting et sprint
review) relvent ainsi des pratiques dinspection et dadaptation de la mthode scrum .
Enfin, la phase daprs-jeu post-game qui consiste clturer le projet et livrer le produit
complet et document.
La figure (I) illustre le cycle de vie de la mthode scrum .

Daily scrum

Primtre du
produit

Primtre de
litration

24 heures

2 4
semaines

Itration

Produit
partiel

Figure I: Processus de dveloppement scrum


2.2 La mthode Extreme Programming
2.2.1 Principes, pratiques et instrumentations de gestion
Contrairement la mthode scrum qui ne couvre aucune technique dingnierie, la
mthode XP , paru en 1999, dans un ouvrage intitul Extreme Programming Explained:
Embrace Change qualifie un ensemble doutils de coordination et de pratiques dingnierie
favorisant lapprentissage, lamlioration continue et ladaptabilit des projets informatiques.
Cette mthode, itrative et incrmentale, revendique son nom au fait que les pratiques de
dveloppement sont pousses lextrme. A titre dexemple, la revue des codes est faite de
41

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

faon continue, la conception est remanie tout au long du projet et lintgration est ralise
plusieurs fois par jour.
La communication occupe une place centrale dans le processus de dveloppement XP .
Elle est mdiatise par un ensemble dartefacts ( story-cards , story-board , etc.) et de
pratiques (programmation en paire, runions quotidiennes, client sur le site, etc.). Les auteurs
de cette mthode estiment que les problmes majeurs rencontrs dans un projet de
dveloppement sont souvent dus un manque de communication au niveau de lquipe. De ce
fait, ils privilgient les rencontres frquentes entre les membres de lquipe et avec le client en
vue de favoriser les feedback et les ajustements continus. Par ailleurs, la simplicit des codes
et du design est ncessaire pour amliorer la flexibilit et ladaptabilit du systme et rduire
les cots. En outre, les membres des quipes XP sont amens changer de rle et de
vision du produit, admettre leurs propres faiblesses et erreurs et se respecter entre eux
(Beck & Andres, 2004).
2.2.1.1 Les pratiques de la mthode XP
La mthode extreme programming revoie un ensemble de principes et de pratiques
allant de la programmation la collaboration en passant par lorganisation des quipes. Nous
prsentons, dans la partie qui suit, les pratiques et principes tels quils sont dcrits dans
louvrage de Kent Beck (Beck & Andres, 2004). Par souci de clart, nous classerons ces
pratiques en fonction de leur vise : gestion de projet, programmation et collaboration
(tableau 2).
Tableau 2: Les pratiques XP
Gestion de projet

Programmation

Collaboration

-Planification itrative (cycle de planification hebdomadaire,


runion hebdomadaire ou planning game et runion
quotidienne ou stand-up meeting )
-La livraison itrative et incrmentale.
-La conception simple, incrmentale
-Les tests unitaires et fonctionnels
-La construction rapide
-Le dploiement quotidien
-Le remaniement des codes
-Lintgration continue
-La mtaphore
-La programmation en paire
-Lappropriation collective du code
-Les rgles de codage
-Le client sur le site
42

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Planning game : cest la runion effectue au dbut de chaque itration entre le client et
lquipe de dveloppement. Au cours de cette runion, les demandes fonctionnelles sont
dtermines par le client et sont matrialises travers des scnarios dutilisateurs ou de
user-stories 43 nots sur des story-cards44 . A ce stade, lquipe value la charge de travail
relative chaque scnario en termes de points (le nombre de points est attribu en fonction de
la difficult du scnario) et communique au client une estimation de sa vlocit 45. Ensuite,
conjointement avec le client, lquipe dcide des scnarios implmenter dans la prochaine
itration (Beck & Andres, 2004, p.45).
Cycle hebdomadaire : le cycle de planification hebdomadaire consiste valuer
lavancement du projet par rapport aux attentes des parties prenantes; identifier les
stories implmenter dans le prochain cycle et dcomposer celles-ci en tches
attribuables aux membres de lquipe.
Livraisons itratives et incrmentales : le projet est dcompos en plusieurs itrations o
chacune regroupe un ensemble limit de fonctionnalits. La version produite est rajoute la
version prcdente minimisant ainsi les cots de dploiement big deployment have a high
risk and high human and economic costs (Beck & Andres, 2004, p.63).
Stand-up meeting : cest une runion quotidienne de quinze minutes, se droulant, en
principe, dans un espace ouvert (de type plateau) occup par les dveloppeurs. Durant ces
runions, les dveloppeurs sont amens partager leurs expriences concernant la journe
prcdente et dcider collectivement des tches futures raliser. Les sances de travail en
binmes (le pair programming ) sont galement planifies au cours de cette runion.
Conception simple incrmental : la conception est ralise de faon simple et incrmentale.
Les duplications doivent tre limines afin de simplifier le travail de conception. Le design
est refix pour correspondre aux besoins des codes designs without duplication tend to be
easy to change. You dont find yourself in the situation where you have to change the code in
several places to add one feature (Beck & Andres, 2004, p.54).

Les user-stories reprsentent les besoins fonctionnels. En gnral, les utilisateurs de lapplication finale
crivent les user stories en utilisant leur propre terminologie.
44
Les story-cards reprsentent les cartes sur lesquelles est marqu le scnario implmenter avec une courte
description de celui ci. Ces cartes sont ensuite affiches sur un tableau visible toute lquipe (Annexe V).
45
Cf. page 40.
43

43

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Tests unitaires et fonctionnels : les tests unitaires concernent chaque classe ou portion de
codes. Ils sont crits avant la codification et raliss chaque intgration. Bien que ces tests
relve dune vision micro de lapplication, ils permettent de vrifier si cette dernire se
comporte comme prvu (Beck, 2004). Ces tests sont automatiss et continuellement excuts
(Beck & Andres, 2004, p. 51). Des modles de tests unitaires, dits xUnit , ont t
dvelopps pour certains langages de programmation46 (JUnit pour le langage Java, cppUnit
pour le langage C++, Pyunit pour Phyton, etc.). Chacun de ces est propre un langage de
programmation donn. Par ailleurs, quant aux tests fonctionnels, ils relvent de la tche des
clients. Ils sont rdigs et appliqus chaque itration. Ces tests spcifient ce que
lapplication est cense faire du point de vue du client. La fin dune itration a lieu lorsque
tous les tests sont excuts.
Construction rapide (en 10 minutes) : les dveloppements rapides, bass sur des tests
automatiques, permettent davoir un retour immdiat sur les codes dvelopps a build that
takes longer than ten minutes will be used much less often, missing the opportunity for
feedback (Beck & Andres, 2004, p.49).
Dploiement quotidien : les codes dvelopps doivent tre quotidiennement mis en
production. La mise en production du logiciel permet davoir des retours dinformations sur la
version produite any gap between what is on a programmers desk and what is in
production is a risk (Beck & Andres, 2004, p.68).
Intgration continue : si certaines socits informatiques insistent ce que lintgration
quotidienne soit un minimum, les fondateurs de la mthode XP exigent que celle-ci soit
un maximum integrate and test changes after no more than a couple of hours (Beck &
Andres, 2004, p.49). Cette pratique consiste intgrer, de faon continue, les nouveaux codes
aux codes existants the more you wait to integrate, the more it costs and the more
unpredictable the cost becomes (Beck & Andres, 2004, p.50).
Remaniement du code : le remaniement des codes ou le refactoring consiste amliorer
rgulirement la qualit du code sans en modifier le comportement. On retravaille le code
pour repartir sur de meilleures bases tout en gardant les mmes fonctionnalits. Autrement dit,
A notre connaissance, il nexiste pas de langage spcifique au dveloppement agile . Les mthodes
agiles , en particulier, scrum et XP sont techno-agnostiques (Antoine Contal, coach scrum et
XP ).
46

44

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

il sagit du nettoyage quotidien du code (limination des duplications et amlioration de sa


lisibilit).
Mtaphore : cest une histoire simple qui dcrit le projet et ses fonctionnalits. Elle relve de
larchitecture, du fonctionnement du systme, etc. Une mtaphore guide le processus de
dveloppement et aide lquipe avoir une comprhension commune des lments essentiels
du projet.
Programmation en paire : la production de codes se fait en binme partir de deux
personnes travaillant ensemble sur une seule machine, un clavier et une souris. La rotation des
paires se fait de manire quotidienne pair programming is a dialog between two people
simultaneously programming (and analyzing, and designing and testing) and trying to
program better (Beck & Andres, 2004, p.42).
Appropriation collective des codes : les codes dvelopps ne relvent pas de la
responsabilit dune personne prcise. Ils sont partags par toute lquipe. Chacun des
dveloppeurs peut apporter des modifications nimporte quelle occasion. Cette pratique
responsabilise lquipe lgard de lensemble des codes dvelopps I have heard that if no
one person is responsible for a piece of code, then everyone will act irresponsibly. They will
make expedient changes, leaving a mess for the next person who has to touch the code
(Beck & Andres, 2004, p.66).
Client sur le site : le client est impliqu dans le projet de dveloppement et fait partie de
lquipe. Son rle consiste rpondre aux questions de celle-ci, excuter les tests
dacceptation et sassurer de la conformit des versions dveloppes. A cet effet, il participe
aux runions hebdomadaires organises par lquipe XP (Beck & Andres, 2004, p.61).
Rgles de codage : les versions multiples de sources de codes gnrent du gaspillage. De ce
fait, il est important davoir une base unique de codes qui permet de rduire leur complexit
rather than add more code bases, fix the underlying design problem that is preventing you
from running from a single code base (Beck & Andres, 2004, p.68).
Par ailleurs, dautres pratiques ont t souligns par les auteurs de la mthode XP . Elles
relvent des outils du lean management : le recours lanalyse des causes racines qui permet
de dtecter les causes profondes des erreurs dans un systme et dy remdier rapidement. A
45

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

cet effet, la mthode des cinq pourquoi (5 whys) constitue un moyen pour cerner les causes
racines dun problme (Beck & Andres, 2004). Un principe complmentaire fut galement
mobilis, celui du Poka Yoke47 ou dtrompeur . En effet, lcriture des tests unitaires
avant la programmation permet dalerter les dveloppeurs en cas derreurs dans lapplication
the goal is not just that this one defect wont ever recur, but that the team will never make
the same kind of mistake again (Beck & Andres, p. 64). Les tests unitaires constituent ainsi
des dtrompeurs selon la terminologie utilise dans le lean.
2.2.1.2 Les rles dans la mthode XP
Contrairement la mthode scrum plusieurs rles sont attribus aux membres dune
quipe de dveloppement XP .
Le programmeur : son rle est dcrire les tests unitaires et de dvelopper les codes en
respectant le principe simple design . Le programmeur est amen communiquer et
collaborer constamment avec les designers, le client, etc.
Le designer : il est responsable de la dfinition de larchitecture de lapplication. Il aide
galement le client crire et clarifier les scnarios user-stories . En outre, il analyse
lusage actuel du systme et dcide des besoins futurs de celui-ci. Il spcifie, en amont,
linterface utilisateur et il se charge de son amlioration.
Le client : il est charg dexprimer ses besoins sous forme de scnarios et dcrire les tests
fonctionnels. La priorisation des demandes implmenter relve aussi de sa responsabilit
Le testeur : son rle consiste dune part, assister les clients dans lcriture et lexcution des
tests fonctionnels et dautre part, coacher les dveloppeurs dans les techniques de tests
unitaires.
Le tracker : il donne son feedback sur lavancement du projet. Il souligne les estimations
effectues par lquipe (en termes defforts par exemple) et donne son avis sur la pertinence
de celles-ci dans le but damliorer les estimations futures. Il trace galement la progression
de chaque itration et value les possibilits de raliser les objectifs fixs en prenant en
compte le temps et les ressources disponibles.
Il sagit de petits systmes pratiques qui permettent didentifier immdiatement que l'on fait de la non-qualit
ou que l'on ne suit pas le standard de travail (lean.enst.fr).
47

46

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Le coach : il a un rle de soutien technique pour les membres XP lors des premires
itrations de livraison. Il guide galement lquipe dans lapplication des pratiques et
principes XP .
Le manager : son rle correspond celui dun chef de projet. Il assiste son quipe pour
affronter les difficults rencontres au cours de litration. Il doit rendre des comptes au client
sur la base des informations fournies par le tracker. Le modle de dveloppement XP
2.2.1.3 Le modle de dveloppement XP
La mthode XP , focalise sur la partie programmation du projet, propose un modle de
dveloppement itratif avec une structure deux niveaux : dabord des itrations de livraison
puis des itrations de dveloppement. Les premires consistent livrer des fonctionnalits
compltes au client tandis que les secondes portent sur les scnarios qui contribuent la
dfinition dune fonctionnalit (Morley, 2006).
Le processus est dclench par une phase dexploration des besoins durant laquelle le client
labore les scnarios quil souhaite intgrer dans la premire livraison. En parallle, lquipe
se familiarise avec les outils et les pratiques qui seront utiliss au cours du projet. Une phase
de planification (de quelques jours) est organise entre lquipe de dveloppement et le client
pour identifier les scnarios implmenter dans la premire itration de livraison (ne doit pas
excder les 2 mois). Litration de livraison est ensuite dcoupe en plusieurs itrations de
dveloppement de courte dure (1 4 semaines).
La premire itration consiste laborer larchitecture du systme gnral en se basant sur les
scnarios capables de renforcer la structure globale du systme. Le client dcide des scnarios
implmenter dans chaque itration. Suite cela, les tests unitaires sont crits et automatiss
et les codes sont dvelopps. Par ailleurs, les tests fonctionnels crits par le client sont
excuts la fin de chaque itration de dveloppement. Litration de livraison prend fin
lorsque tous les scnarios retenus sont dvelopps (figure II). La documentation est rdige en
phase finale lorsquaucune modification nest accepte. Toutefois, il convient de prciser
quau cours du projet, les scnarios, les estimations et les tests crits sur les story-cards
constituent lunique source de documentation.

47

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Phase
dexploration

Phase de
planification

Des itrations la phase de


livraison

Mise en
production

Maintenance

Phase
finale

Priorits

Mis jour
rguliers

Scnarios
pour la
prochaine
itration

Programmation en paire

Analyse

Design

Scnarios

Plan des
tests

Test

Efforts
estims
Feedback

Intgration
continue

Tests
Base de
donnes
collective

Livraison
(1)

Livraison
mise jour

Livraison
finale

Figure II : Processus de dveloppement XP


2.3 Le dveloppement lean
Le modle lean provient du best seller des annes 1990 nomm The machine that changed
the world: the story of lean production (Womack & Jones, 1990 dans Poppendieck, 2003).
Inspir du Toyota Production System48, le lean qualifie un ensemble de pratiques
managriales bases sur deux piliers fondamentaux : la production juste temps et
l autonomation (Houy, 2008).
Le Toyota Production System est dsign comme un systme de management qui vise
llimination radicale du gaspillage The Toyota production system is a management system
Le Toyota Production System tait largement ignor mme au Japon jusqu la crise de lhuile en 1973 parce
jusququ ce jour, les entreprises se dveloppaient rapidement et pouvaient vendre tout ce quelles produisaient.
Mais la baisse conomique due la crise dhuile a dtruit un grand nombre dentreprises. Toutefois Toyota a
russi sen sortir rapidement grce son systme de production juste temps et lintrt accord
llimination des gaspillages.
48

48

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

for the absolute elimination of wasteAll we are doing is looking at the timeline from the
moment a customer gives us an order to the point when we collect the cash (Ohno, 1988
dans Poppendieck, 2006). Fond par Tachi Ohno dans les annes 1970, les objectifs
essentiels sur lesquels repose ce systme est la rduction des cots de production et
lamlioration de la satisfaction des clients. Deux principes sont ds lors mis en avant :
llimination du gaspillage ou tout ce qui dpasse la quantit minimale requise en termes de
matriels, dquipements, despace et de temps et par consquent ne cre pas de la valeur ; et
la valorisation des employs travers leurs responsabilisation et leur dveloppement continu
(Sugimori, Kusunoki, Cho & Uchikawa, 1977).
Aprs limmense succs qua connu le systme de production Toyota dans les industries
automobiles, traduit, plus tard, sous lapproche du lean management, les principes lean ont t
exports au-del de lindustrie automobile et se sont progressivement tendus dautres
services et secteurs dactivits. Aujourdhui, lapplication des principes du lean management
au dveloppement informatique est en pleine expansion (Enqute Scrum Alliance 49, 2009).
Mary et Tom Poppendieck se sont beaucoup intresss la question dapplication des
principes du lean management au dveloppement de logiciels. Dans leur ouvrage
Implementing lean software development: from concept to cash , paru en 2006, ils
dcrivent les diffrents principes qui constituent le lean thinking . Avant de procder la
prsentation de ces principes, il apparat judicieux de prciser que le lean development ne
renvoie pas une mthodologie de dveloppement et de management de projet analogue aux
mthodes agiles . En revanche, le lean souligne une philosophie, une manire de pense,
base sur des principes managriaux issus du monde industriel et appliqus au dveloppement
de logiciels. Nous reviendrons sur cette distinction la fin de ce chapitre.
2.3.1 Les principes du dveloppement lean
Llimination du gaspillage : les sources de gaspillage renvoie tout ce qui ne cre pas de la
valeur au client. Une socit de dveloppement qui se veut lean est, tout dabord, amene

49

http://www.frenchsug.org/download/attachments/591296/Enqu%C3%AAte_m%C3%A9thodes_agiles_2009_F
renchSUG.pdf?version=2

49

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

dterminer les gaspillages de faon rduire le time line ou le lead time 50 entre le
moment o le client a effectu sa demande et le moment o le produit lui a t livr.
En effet, en industrie automobile, linventaire est considr comme une vraie source de
gaspillage ncessitant un entretien, un transfert, un stockage, des recherches. Les stocks
rajoutent de la complexit au processus de production car ils risquent de devenir obsoltes, de
cacher des problmes de qualit et de se perdre. Do lintrt de rduire au maximum la
prsence de stocks inutiles. Appliqu au dveloppement de logiciels, le dveloppement de
fonctionnalits inutiles, la documentation exhaustive constituent des sources majeures de
gaspillage (Poppendieck, 2006). En effet, les codes inutiles engagent des tests, une
documentation et une maintenance inutiles gnrant des surcots. Il est donc important de
mettre en place un processus o 20% des codes dvelopps livrent 80% de la valeur just as
Taiichi Ohno called overproduction the worst waste in manufacturing, unused features are
the worst kind of waste in software development. Unused code still requires unnecessary
testing, documentation, and support (Ohno, 1977 dans Poppendieck, 2006). Dautres types
de gaspillages ont t identifis en dveloppement de logiciels (Poppendieck, 2003, 2006).
La qualit intrinsque : dun point de vue lean, les codes dvelopps doivent tre, ds le
dpart, de bonne qualit. En ce sens, lorganisation est amene anticiper les problmes ou
analyser les causes profondes de ceux-ci au moment de leur apparition. Dans cette optique,
Shigeo Shingo, expert en Toyota Production System, souligne deux types dinspection pour
amliorer la qualit des produits: linspection visant la prvention des dfauts et linspection
au moment o les dfauts apparaissent (Shigeo Shingo, 1981 dans Poppendieck, 2006). Il est,
primordial de contrler les conditions de production afin dviter loccurrence des dfauts.
Mais lorsque cette possibilit ne se prsente pas, il devient indispensable dinspecter le
produit chaque tape du processus pour dtecter rapidement les dfaillances et par
consquent viter que ceux-ci affectent toute la ligne de production If you really want
quality, you dont inspect after the fact, you control conditions so as not to allow defects in
the first place. If this is not possible, then you inspect the product after each small step, so
that defects are caught immediately after they occur (Shigeo Shingo dans Poppendieck,
2006). A cet effet, un ensemble de pratiques et doutils a t mis en place par les industries

50

All we are doing is looking at a timeline from the moment the customer gives us an order to the point when
we collect the cash. We are reducing that timeline by removing the non-value-added wastes (Ohno, 1977 dans
Poppendieck, 2006).

50

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

lean : lAndon51, la culture stop-the-line52, la mthode des 5P53, le pareto des causes54, lA3
problem solving55.
Les mthodes agiles ont elles aussi mis laccent sur le principe danticipation et danalyse
des processus dfaillants. Le dveloppement conduit par les tests, par exemple, permet de
rduire les risques derreurs dans les applications dveloppes Following the adoption of
TDD the number of defects reported dropped to less than three per thousand lines of code.
Even this 70 percent reduction in defects understates the improvement because the team
didnt track whether a reported defect was caused by code written before or after TDD
(Mike Cohn dans Poppendieck, 2006). Cependant, la vrification des codes demeure une
activit indispensable. Les tests fonctionnels, lintgration continue, le remaniement des codes
ou encore la revue de litration constituent des moyens pour identifier, au plutt, les erreurs
produits et amliorer la qualit du produit final.
Amplifier lapprentissage : dun point de vue lean, le dveloppement de logiciels relve
dun processus continu de cration et dacquisition de connaissances. Si au dpart dun projet,
larchitecture de lapplication est globalement conue, elle ne se prcise quaprs le
dveloppement des codes. Dans cette perspective, il apparat judicieux de raliser la
conception dtaille en parallle avec lactivit de programmation. Par ailleurs, divers
pratiques et outils ont t mis en uvre en vue de favoriser lapprentissage : les ateliers
kaizen56 qui permettent la rsolution collective des problmes et lamlioration continue, le
dveloppement itratif et les runions quotidiennes qui favorisent les feedback continus, lA3
problem solving qui consiste capturer les connaissances critiques et les stocker dans une
base de donnes accessible tout le monde.
Corde dalerte, situe gnralement au-dessus de chaque oprateur, qui permet denvoyer un signal visuel et/ou
sonore son superviseur pour lavertir de la prsence dun problme sur la chane de production. L Andon se
trouve au cur de la dmarche de rsolution de problmes (Houy, 2009).
52
Stop-the-line implique larrt de la chane de production au moment o une dfaillance dans le systme ou
un problme apparait. La production est reprise aprs la rsolution collective du problme.
53
La mthode de base de rsolution de problmes du lean. Ohno insiste souvent sur la ncessit de se poser cinq
fois la question "pourquoi?" pour aller au-del des causes symptomatiques et trouver les causes fondamentales
(lean.enst.fr).
54
Outil visuel permettant de visualiser les causes des problmes et de trouver, en fonction de leur frquence
dapparition, celles traiter en priorit. Cet outil obit la loi 20/80 o 20% des causes produisent 80% des
effets.
55
Document bas sur un format A3 o sont captures les informations relatives aux problmes apparus
(Conditions actuelles, objectifs attendus, analyse des causes, contre-mesure, confirmation des rsultats, suivi des
actions).
56
Organisation des discussions en quipe pour stimuler l'amlioration continue. L'objectif du kaizen est
l'limination du gaspillage sous toutes ses formes. Il s'agit de rendre les tches plus simples et plus faciles
effectuer (lean.enst.fr).
51

51

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

MacCormack (cit dans Poppendieck, 2006) identifie quatre lments cls qui conduisent au
succs dun projet de dveloppement : (1) les livraisons rapides et minimales de
fonctionnalits testes par le client; (2) les constructions quotidiennes et le feedback rapide
que lon obtient suite aux tests dintgration, (3) une quipe ou un chef dquipe bien
expriment capable de prendre les bonnes dcisions au bon moment et (4) une architecture
modulaire permettant lintgration facile de nouvelles fonctionnalits. Nous retrouvons
toutefois ces principes dans les mthodes de dveloppement agiles prsentes plus haut :
scrum , extreme programming .
Dcider le plus tard possible : une entreprise lean estime que, dans un projet de
dveloppement informatique, les dcisions doivent tre reportes jusqu la collecte maximale
dinformations. Elles doivent tre rversibles et facilement modifiables. Dans cette
perspective, le dveloppement itratif port par le courant agile consiste surmonter les
phases danalyse et danticipation paralysantes pour sappuyer sur des solutions concrtes
amliorant ainsi les prises dcisions (Poppendieck, 2006). Dans un processus de
dveloppement instable et complexe il est indispensable que lquipe dispose dun ensemble
doptions lui permettant de retarder les prises de dcisions irrversibles. Pour Taiichi Ohno,
les plans labors au dpart dun projet sont facilement modifiables et souvent, les activits
qui en dcoulent, changent de direction pour rpondre aux circonstances et conditions de
lenvironnement. De ce fait les entreprises qui se basent sur des plans trs dtaills encourent,
de nos jours, le risque dtre dpasses Toyota realizes that sticking to a detailed plan is not
healthy, and measuring process capability against one ability to do is measuring the wrong
thing (Ohno, 1988 dans Poppendieck, 2006).
Livrer rapidement : la rduction des dlais de livraison permet aux entreprises damliorer
leur comptitivit sur le march technologique. Dans cette optique, le style de dveloppement
itratif et incrmental permet, outre la vrification rapide de la version fonctionnelle
dveloppe, de rpondre assez rapidement aux demandes des clients quils nont pas le temps
de changer davis We need to figure out how to deliver software so fast that our customers
dont have time to change their minds (Poppendieck, 2006, p.34). Souvent les socits de
dveloppement informatique ont du mal conjuguer la rapidit et la qualit des produits
dvelopps. Il est donc important, dun point de vue lean, de dvelopper les personnes afin
quelles soient capables de prendre les bonnes dcisions, de rpondre rapidement aux
changements et damliorer, de faon continue, la qualit des livrables If you want to go
52

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

fast, you need engaged, thinking people who can be trusted to make good decisions and help
each other out (Poppendieck, 2006, p.35). A cet effet, un sixime principe est mis en avant :
le respect des personnes.
Le respect des personnes : lune des caractristiques cls du systme de production Toyota
est lintrt port aux personnes et en particulier aux oprationnels uvrant au bas de
lchelle . Une organisation lean incite respecter les gens et les valoriser en les rendant
plus autonomes, les dveloppant et les faisant participer aux dcisions. En effet, ce principe
fut galement soulign par les partisans de la mthode scrum et XP qui encouragent
lauto-organisation des quipes de dveloppement. Dans cette optique, le management
scientifique taylorien the one best way est remis en cause et remplac par une
organisation contribuant au dveloppement de ses salaris. Dans une perspective
dorganisation lean, les acteurs sont amens mobiliser leurs connaissances et leurs
expriences passes pour ragir plutt que de se limiter aux consignes standardises. Pour les
Poppendieck (2006), le one best way nexiste pas dans la mesure o chaque processus
ncessite continuellement des amliorations There is no such thing as one best way
(Poppendieck, 2006, p.38).
Un dernier principe majeur du lean management renvoie loptimisation de lensemble de
la chane de valeur 57 A lean organization optimizes the whole value stream, from the time it
receives an order to address a customer need until software development is deployed and the
need is addresses (Poppendieck, 2006, p.36). Par consquent lide doptimiser de manire
spare les diffrents silos dune chane de valeur ne gnre pas forcment des rsultats
satisfaisants.
Aprs la prsentation des fondements du lean thinking dans le dveloppement
informatique, il nous parat utile de revenir sur le principe dlimination de gaspillage qui
constitue lun des piliers fondamentaux du modle lean. Les checs rptitifs dans les projets
informatiques ont conduit les praticiens sintresser de prs leurs causes et consquences.
Sept types de gaspillage ont ds lors t identifis. Signalons que ces sources ont tout dabord
t rpertories en industrie automobile par Shigeo Shingo pour ensuite tre appliques aux
industries de logiciels (Poppendieck, 2006).

57

La chane de valeur est l'ensemble des activits indispensables pour la ralisation d'un produit.

53

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

2.3.2 Les sept sources de gaspillage


En ce qui concerne les sources de gaspillages identifies en usine, nous retrouvons: la
production excessive, les attentes, les transports inutiles, les processus supplmentaires, le
travail partiellement effectu, les mouvements inutiles et les productions dfectueuses. Le
tableau (3) illustre les sept sources de gaspillage identifies en industrie automobile et
appliques au dveloppement de logiciels.
Tableau 3: Les sept sources de gaspillage (Poppendieck, 2003; 2006)
Gaspillage en industrie automobile

Gaspillage dans le dveloppement

Production excessive
(Overproduction)
Attente
(Waiting)

Trop de fonctionnalits
(Extra features)
Retards
(Delays)

Transports inutiles
(Transportation)
Processus supplmentaires
(Extra processing)
Inventaire, stock
(In-process inventory)
Mouvements inutiles
(Motion)
Production dfectueuse
(Defects)

Transfert
(Handoffs)
Rapprentissage, reprogrammation
(Relearning)
Travail partiellement fait
(Partially done work)
Dplacement, changement de tches
(Task switching)
Dfauts non dtects par les tests
(Defects)

En dveloppement de logiciels, la production excessive se manifeste par le dveloppement


de fonctionnalits supplmentaires et de documents inutiles. Comme en industrie automobile,
la surproduction constitue la pire forme de gaspillage induisant des augmentations des cots
et des complications techniques au niveau du systme dvelopp: tests supplmentaires,
maintenance, obsolescence des codes, etc. Ladoption dun style de dveloppement itratif et
la mise en place dun systme pull58 limitent la surproduction de fonctionnalits
(Poppendieck, 2006, p.73).
Lattente constitue une deuxime forme de gaspillage se traduisant par des retards dans le
dveloppement et la livraison des produits. Dans une usine, les attentes concernent surtout les
pices, les outils, les instructions, etc. En revanche, dans une socit de dveloppement
informatique, les attentes relvent de la disponibilit des personnes, des informations
58

Ce systme initialement adopt chez Toyota consiste tirer la production par la demande.

54

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

recherches, etc. En effet, un projet de grande taille, une mauvaise synchronisation entre les
quipes et/ou une structure hirarchique rigide peuvent gnrer des temps dattente dans
les prises de dcision et des goulots dtranglement sur certaines phases du projet. Dans cette
optique, le style de dveloppement itratif et incrmental permet de rduire lcart entre les
diffrentes phases du processus et de livrer, rapidement, une version fonctionnelle du produit
(Beck, 1999 dans Poppendieck, 2003).
Les transports inutiles dans lindustrie illustrs par les dplacements physiques de pices
engendrent des interruptions ou ralentissements dans la chane de production, des pertes de
pices et des goulots d'tranglement (Godefroy & Chabiron, 2006). En dveloppement
informatique, les dplacements inutiles concernent surtout les allers-retours des mails, les
changes de documents entre les membres dune quipe entranant une perte considrable
dinformations et de connaissances tacites documents leave virtually all tacit Knowledge
behind. Replace them with face to face discussion, direct observation, prototypes and
simulations (Poppendieck, 2006, p.77). De ce point de vue, les pratiques de collaboration
telles que les runions quotidiennes de courte dure, la programmation en paire, le partage
collectif de codes, limplication du client, le management visuel (matrialis par des tableaux
de bord partag, des post-it, des graphes, etc.) et les ateliers kaizen peuvent amliorer la
coordination entre les membres dune quipe, favoriser le transfert de connaissances tacites
(Poppendieck, 2006), diminuer le temps de recherche des informations et crer une vision
commune du projet.
Les tapes supplmentaires dans un processus de dveloppement sont dues aux arrts et
reprises dun mme travail, aux activits redondantes, un manque de standardisation et une
documentation inutile (Poppendieck, 2003). Le rapprentissage et le retravail, entravent le
planning et induisent des retards et une baisse de productivit de lquipe. A cet effet, la
capitalisation sur les connaissances (A3 problem solving, standardisation et amlioration
continue des bonnes pratiques), les courts cycles de dveloppement, le remaniement des
codes, lintgration continue et les feedback semblent rduire le retravail et le rapprentissage.
En outre, limplication du client dans le processus de dveloppement diminue galement le
retravail et les modifications au niveau des codes implments (Middleton, F laxel &
Cookson, 2005).

55

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Les stocks inutiles ncessitent de lespace et engendre des cots supplmentaires en industrie
automobile. Quant au dveloppement de logiciels, linventaire reprsente le travail
partiellement effectu, la documentation excessive non utilise et les codes non tests ou
dploys. Ces formes varies de gaspillage requirent des investissements financiers, humains
et techniques et encourent le risque dobsolescence. A cette fin, il semble utile de rduire les
demandes prises en compte, le nombre de codes dvelopps (Middleton, Flaxel & Cookson,
2005) en adoptant de courts cycles de dveloppement (Poppendieck, 2006). En outre, la
communication permanente entre les membres de lquipe et la cration dun environnement
informatif permettent dune part, de rduire la documentation et dune autre, de clarifier les
besoins rels du client. Toutefois, certaines entreprises exigent une traabilit des
spcifications et des codes, autrement dit, la documentation de ceux-ci. Il est donc
recommand, dans de telles situations, de convertir les spcifications requises en des tests
excutables et de recourir des outils (framework for integrated tests59) permettant de
procurer une traabilit des codes tests (Poppendieck, 2006).
La multiplication des runions, lexcs de procdures, les dplacements physiques, la
ralisation de diverses tches simultanes, constituent une autre forme de gaspillage : les
mouvements inutiles ou motion. En effet, la prise en charge de tches varies empchent les
acteurs concerns raliser rapidement leur travail when Knowledge workers have three or
four tasks o do they will often spend more time resetting their minds as they switch to each
new task than they spend actually working on it (Poppendieck, 2006, p.76). Ce propos a t
illustr par un autre exemple (figure III) dcrit dans louvrage des Poppendieck (2006) :
imaginons quune personne dcide de raliser simultanment trois tches diffrentes o
chacune est fixe une dure dune semaine. Dans le cas idal, aucune de ces trois tches ne
sera ralise dans les dlais. Outre le temps perdu en jonglant entre les tches, la valeur
potentielle cre est galement anantie.
Si la polyvalence des membres dune quipe est valorise par certaines mthodes agiles ,
scrum par exemple, il semble tre important de rduire, au cours dune itration, la
rotation des individus sur des activits diffrentes. En outre, les pratiques comme le client
sur le site , les runions quotidiennes et le partage virtuel des tableaux de bords, permettent

Il sagit dun outil open source qui automatise les tests fonctionnels des clients. Il intgre le travail des
analystes, des clients, des testeurs et des dveloppeurs.
59

56

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

de rduire les runions de longue dure et les dplacements physiques en assurant un suivi
rgulier du projet (Poppendieck, 2006).
Tache A
Tache B
Tacj

Semaine 1

Semaine 2

Tache C

Semaine 3

Semaine 4

Figure III: Jonglage entre trois taches de dlai d'une semaine chacune
Et enfin, un dernier type de gaspillage commun au dveloppement informatique concerne les
dfauts non reprs dans les codes, retardant ainsi la livraison de la solution informatique et
augmentant les cots de dveloppement. A cet effet, les tests unitaires crits avant le codage
constituent ce quon appelle en industrie automobile les dtrompeurs ou mistakeproofing (Poppendieck, 2006). Ces tests dmontrent si les codes fonctionnent comme prvu.
Bien que le test-driven development permette de rduire les dfauts dans le systme, il
nempche pas compltement la survenue de ces derniers. Toutefois, la dtection rapide dun
dfaut critique aprs le codage est plus tolre quun dfaut minime dcouvert plus tard dans
le processus de dveloppement (Poppendieck, 2006). Par consquent, les tests frquents et
lintgration continue des codes permettent de dceler rapidement les erreurs et de vrifier
continuellement le fonctionnement de lensemble des codes dvelopps et intgrs.
Les types de gaspillages reformuls par les Poppendieck sapparentent aux problmes
auxquels les mthodes agiles , en particulier scrum et extreme programming ont
tent de remdier. De fait, nous constatons que les pratiques et outils agiles peuvent mettre
en pratique les principes lean et rpondre aux diverses formes de muda60 remonts en
dveloppement informatique. Lensemble de ces trois approches offre un bon panorama du
courant agile .

60

Terme japonais signifiant gaspillage

57

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Toutefois, nous constatons que le lean development reprsente une approche plus globale que
les mthodes XP et scrum . Avant de justifier notre propos, il nous parat opportun de
comparer les mthodes XP et scrum .
2.4 Scrum , xp et le dveloppement lean : diffrences et complmentarit
Au del des pratiques dingnierie non couvertes par la mthode scrum , des diffrences
subtiles existent entre les mthodes scrum et XP . Le tableau (4) souligne ces
principales dissimilitudes.
Tableau 4 : Diffrences entre XP et scrum
Mthode XP

Mthode scrum

Dure de litration (1 2 semaines)

Dure de litration (2 4 semaines)

Les changements des fonctionnalits durant


litration ne sont pas accepts

Possibilits de changements des scnarios ou des


fonctionnalits implmenter au cours de
litration

Diffrents rles sont attribus aux membres de


lquipe XP (programmeur, testeur, coach,
manageur, etc.)

Les membres de lquipe sont pluridisciplinaires


et seuls trois rles sont dfinis ( scrummaster , product-owner et lquipe)

Pratiques managriales, pratiques dingnierie


et outils de collaboration et de support au
management

Pratiques managriales et outils de collaboration


et de support au management

En revanche, ces deux mthodes valorisent la transparence, linspection et ladaptabilit des


projets informatiques. Elles privilgient le travail dquipe, les feedback continus et les
ajustements rapides aux changements. Elles concernent particulirement les quipes de taille
rduite (4 10 personnes) o la communication et la coordination, entre les membres dun
projet, sont faciles raliser. Le client se trouve au cur de ces deux approches. Il participe
la dfinition et la priorisation des fonctionnalits. Si la mthode scrum attribue un statut
au reprsentant du client product owner , la mthode XP , quant elle, se contente de
mettre laccent sur le rle quil occupe.
Le couplage scrum et XP semble amliorer trs sensiblement la qualit des logiciels
livrs et crer une culture renforant le sentiment de partage dobjectifs communs. Ces deux
mthodes savrent complmentaires selon certains praticiens (Schwaber & Beedle, 2002 ;
58

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Fitzgerald, Hartnett & Conboy, 2006a). Si la mthode XP constitue un support pour les
pratiques dingnierie et les aspects techniques du logiciel, la mthode scrum , quant ses
pratiques, renforce la planification et lvolution du projet.
Para ailleurs, en ce qui concerne le dveloppement lean, celui-ci sinscrit dans une perspective
plus globale valorisant essentiellement la dtection et lanticipation des problmes ainsi que la
rduction des diffrentes formes de gaspillages.
La dmarcation entre lapproche lean et les mthodes agiles demeure, lheure actuelle,
floue. Alors que pour certains praticiens, le dveloppement lean fait partie des pratiques
agiles (Jalali & Wohlin, 2010), pour dautres, ces deux approches se situent diffrents
niveaux : le lean renvoie une philosophie et un ensemble de principes tandis que les
mthodes agiles se caractrisent par leur pragmatisme (Morien, 2005 ; Poppendieck,
2003 ; 2006). A ce titre, le lean regroupe un ensemble de principes qui guident le
dveloppement agile de logiciels et contrairement aux pratiques valorises par les
mthodes agiles , les principes quil sous-entend sont invariables (Poppendieck, 2006). Il
lean est, ds lors, apprhend comme un outil indispensable pour guider et adapter les
pratiques agiles diffrents contextes.
Pour dautres praticiens en dveloppement de logiciels, ce sont les vises et les primtres qui
diffrencient les approches lean et agiles (Highsmith, 2002 ; Smits, 2007 ; Serignese,
2011). Selon eux, les mthodes scrum et XP concernent particulirement les pratiques
dingnierie et de management de projet relatives au dveloppement de logiciels tandis que le
lean, relve dune approche globale et holistique, sintressant lorganisation dans son
ensemble et allant au-del des activits de dveloppement informatique. Dans cette optique, le
dveloppement lean est peru comme le prcurseur des mthodes agiles (Serignese,
2001). Les principes soutenus par ce premier concernent les diffrents niveaux dune
organisation sans toutefois se limiter un service bien prcis. A cet gard, la mise en place
des pratiques agiles peut tre gouverne par les principes lean (Ambler, 2009 ; Ambler &
Kroll, 2009 ; Wang, 2011). La gouvernance lean semble faciliter la scalabilit des pratiques
agiles et par consquent leur intgration dans une entreprise (Smits, 2007).
Ainsi, le development lean renvoie un mode de pense quune organisation va
progressivement intgrer dans sa culture organisationnelle et managriale. Les principes
valoriss par cette approche managriale peuvent tre dclins sous diffrentes manires en
59

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

fonction des contextes. Bien que le lean sappuie sur diffrents outils exports de lindustrie
automobile (kanban61, andon, A3 problem solving, pareto des causes), son importation dans le
secteur informatique repose en grande majorit sur les outils et pratiques des mthodes
agiles en particulier scrum et XP .
La description de ces trois approches souligne clairement les fondements lorigine du
courant agile . Le tableau (5) illustre de faon globale les lments structurants de chacune
des trois approches retenues.
Si de nombreuses socits informatiques ambitionnent de mettre en place une dmarche de
dveloppement lean, beaucoup dentre elles ne rencontrent pas les rsultats attendus. A
linstar de lindustrie automobile, la dclinaison des principes lean sur des systmes
rigides et traditionnels peut engendrer beaucoup de problmes et de disruptions au
niveau du systme de dveloppement (Womack & Jones, 1990 dans Poppendieck, 2003 ;
Qumer & Henderson-Sellers, 2008).
Afin de clarifier notre comprhension de ces nouvelles formes de dveloppement et de
management de projet informatique, nous proposons dexaminer les rsultats des travaux
empiriques qui ont t consacrs ce sujet.

Des systmes dtiquettes ayant pour objectif denvoyer une indication aux units de production en amont de la
chane de production pour leur signaler la consommation de leurs produits (Houy, 2009).
61

60

Chapitre I : Prsentation des mthodes agiles : principes et instruments de gestion

Tableau 5: lments structurant des approches : scrum , xp et lean


Scrum (Schwaber, 2004)

Principes
Transparence, suivi et
adaptation

Pratiques managriales
Runions quotidiennes,
runions de planification de
litration, revue de
litration et rtrospective de
litration.

Artefacts
Product-backlog, sprintbacklog, burndown charts.

XP (Beck, 2004)

Lean (Poppendieck, 2006)

Principes
Communication, simplicit,
feedback, respect et courage.

Principes
limination du gaspillage,
livraison rapide, qualit
intrinsque, gestion des
comptences, responsabilit des
personnes et optimisation de
lensemble.

Pratiques dingnierie
Conception simple
Tests unitaires et fonctionnels
Remaniement des codes
Dploiement quotidien
Intgration continue.

Pratiques de collaboration
Planning game, stand-up
meeting, programmation en
paire, appropriation collective
des codes, client sur le site.
Artefacts
Story-cards, story-board, userstories.

Pratiques issues des mthodes


agiles et du lean
management
Systme pull, dveloppement
pilot par les tests,
dveloppement itratif, sessions
kaizen.

Artefacts
Landon, value stream mapping,
pareto des causes, 5 Pourquoi,
A3 problem solving.

61

62

Chapitre II : Analyse de la mise en pratique des


innovations managriales

Ce chapitre met en perspective nombre de travaux rendant compte de limplmentation des


mthodes agiles . Il comprend trois sections.
Dans la premire, nous prsentons les principaux rsultats de la mise en pratique des
mthodes agiles . Nous recensons les rsultats concernant les pratiques et outils agiles
les plus tudis et analyss.
Dans la deuxime section, nous examinons les recherches menes auprs dun chantillon
dentreprises de type agile et traditionnel . Les rsultats comparent les principaux
problmes rencontrs par chacune des quipes agiles et classiques .
Dans la troisime session, nous passons en revue les recherches concernant lapplication des
mthodes agiles sur des quipes godistribues. Nous remontons les principaux dfis
rencontrs par ces dernires et les solutions respectives proposes par les experts en
dveloppement de logiciels.

63

Chapitre II : Analyse de la mise en pratique des innovations managriales

Si les recherches menes sur les mthodes agiles se sont fortement multiplies ces
dernires annes, elles n'ont pas toutes la mme porte et ne prsentent pas la mme qualit.
Certains articles descriptifs se sont attachs dcrire lenvironnement dans lequel uvrent les
quipes agiles et analyser les effets dusage de ces mthodes sur la productivit des
quipes et sur lorganisation en gnral. Des crits, davantage prescriptifs, ont pos les rgles
dapplication des pratiques et outils agiles . Dautres tudes comparatives se sont attaches
valuer les divers aspects des projets agiles et classiques . Des travaux empiriques
rcents se sont intresss, quant eux, limplmentation des mthodes agiles au sein
dquipes de dveloppement distribues gographiquement.
Les diffrentes sources retenues pour cette revue de la littrature proviennent, en grande
majorit, des revues anglo-saxonnes (Information and Software Technology, IEEE Computer
Society, Information and Management, The Journal of Systems and Software, etc.) et dactes
de confrences (Proceedings of Agile Development Conference, Proceedings of International
Conference and Workshops on the Engineering of Computer-Based Systems, Proceedings of
International Conference on Software Engineering, etc.).
Dans ce chapitre, nous synthtisons les rsultats dun grand nombre dtudes ayant trait de la
mise en pratique des mthodes agiles .
1. Les pratiques agiles les plus rfrences : avantages et limites
Trois lments structurant des mthodes agiles ont fait lobjet de notre analyse
bibliographique. Les pratiques dingnierie (le dveloppement pilot par les tests et
lintgration continue) ; les pratiques de collaboration et de coordination (le dveloppement
itratif, la programmation en paire, le client sur le site et les runions quotidiennes) et enfin
les outils de collaboration et de support au management ( story-board , le productbacklog et les outils danalyse collective des causes racines).

64

Chapitre II : Analyse de la mise en pratique des innovations managriales

1.1 Les pratiques dingnierie


1.1.1 Le dveloppement pilot par les tests et lintgration continue
Deux pratiques dingnierie, valorises par la mthode XP , ont fait lobjet de nombreux
crits : les tests unitaires et lintgration continue. Les tests unitaires sont des tests crits pour
chaque classe ou portion de codes et sont raliss chaque intgration ; quand lintgration
continue, elle vise ce que le systme, dans son intgralit, soit rgulirement et
frquemment, assembl puis test. Selon certains experts en dveloppement de logiciels, ces
deux pratiques savrent indispensables pour garantir la qualit des codes et augmenter les
chances de russite du projet (Poppendieck, 2006 ; 2009).
En effet, le dveloppement pilot par les tests semble amliorer la transparence et la qualit
des codes produits (Tessem, 2003 ; Karlstrm & Runeson, 2005; Lejeune, 2006 ; Petersen &
Wohlin, 2009 ; Poppendieck, 2006, 2009 ; Beavers, 2007 ; Middleton & Joyce, 2010),
procurer un feedback rapide sur les codes dvelopps (Berczuk, 2007 ; Paasivaara &
Lassenius, 2004) et simplifier la base de codes complexity calcifies our code and causes it
to turn brittle and break (Poppendieck, 2006, p.67). Ainsi, les tests unitaires permettent de
rduire les cots lis la dcouverte tardive des anomalies (Poppendieck, 2009). Quant
lintgration continue, elle permet de rsoudre les erreurs ds leurs apparitions et dviter les
problmes rsultant des intgrations ralises la fin du projet (Simons, 2002). En outre, ces
deux pratiques savrent des mcanismes de communication essentiels pour les quipes
distribues (Berczuk, 2007).
Toutefois, les tests unitaires et lintgration continue prsentent des limites : dune part,
lcriture des tests unitaires nest pas une tche facile raliser pour les dveloppeurs peu
expriments (Melnik & Maurer, 2002), et dautre part, la cration dun environnement de
tests intgrs ncessite beaucoup defforts techniques (Svensson & Host, 2005) spcialement
lorsque les quipes sont distribues et utilisent des outils de programmation diffrents
(Paasivaara & Lassenius, 2004).
Ces deux pratiques rappellent deux outils visuels de signalement de problmes dploys en
industrie automobile chez Toyota : le Poka-Yoke et l Andon . Si ces pratiques
dingnierie se trouvent au cur de la dmarche de rsolution des problmes chez les
agilistes , leur efficacit nest pas toujours garantie. Leur mise en place demeure en effet
65

Chapitre II : Analyse de la mise en pratique des innovations managriales

insuffisamment tudie, en particulier, dans des structures larges o plusieurs quipes,


rattaches diffrentes directions, sont amenes travailler ensemble sur un mme projet.
Le dveloppement conduit par les tests exige que les dveloppeurs aient une vision trs
prcise des spcifications dvelopper. Or, souvent, dans une structure complexe, les
personnes charges de la dfinition des spcifications sont loignes des quipes de
dveloppement faisant accrotre le risque dune mauvaise comprhension des exigences.
1.2 Les pratiques de collaboration et de coordination
1.2.1 Le dveloppement itratif
Une autre pratique bien rfrence, encourageant la gestion du projet et la collaboration entre
une quipe et ses clients (Highsmith & Cockburn, 2001, Svensson & Host, 2005) est le
dveloppement itratif et incrmental. Cette pratique, base sur des cycles courts de livraison,
procure un feedback rapide sur les versions dveloppes (Jokela & Abrahamsson, 2004 ;
Kosh, 2004 ; Karlstrm & Runeson, 2005), facilite le suivi du projet (Begel & Nagappan,
2007), constitue une opportunit dapprentissage organisationnel (Middleton, Flaxel &
Cookson, 2005 ; Bahli & Zeid, 2005 ; Karlstrm & Runeson , 2005 ) et permet de rpondre
aux demandes volutives des clients (Sutherland J., 2001 ; Melnik & Maurer, 2002 ;
Middleton, Flaxel & Cookson, 2005) requirements are not fully understood before the
project begins. The users know what they want only after seeing an initial version of the
software (Sutherland, 2001, p.7). Elle permet galement de traiter rapidement les problmes
(Simons, 2002; Svensson & Host, 2005), de rduire les cots de rsolution (Smits, 2007) et la
volatilit des demandes dans un projet (Petersen & Wohlin, 2009).
Pour certains praticiens, les itrations frquentes, combines la voix du client, contribuent
dexcellents rsultats au niveau du dveloppement (Middleton, Flaxel & Cookson, 2005). En
effet, limplmentation dun ensemble minimum de fonctionnalits permet de rduire la
complexit et le cot de la base de codes (Poppendieck, 2006). Dans cette mme optique, le
recours la conception incrmentale rduit le nombre des dcisions prises en amont (Beck,
2004) et par la suite la quantit de fonctionnalits implmenter every line of code costs
money to write and more money to support, its better for the developers to be surfing than
writing code that wont be needed (Sutherland dans Poppendieck, 2006, p.71).

66

Chapitre II : Analyse de la mise en pratique des innovations managriales

En contrepartie, la coordination des diffrentes itrations menes en parallle, sur diffrents


sites gographiques, est difficile grer (Karlstrm & Runeson, 2005 ; Sutherland, Viktorov,
Blount & Puntikov, 2007).
1.2.2 La programmation en paire
La programmation en paire constitue lune des pratiques agiles les plus tudies.
Comme nous lavons dj indiqu dans le chapitre prcdent, elle consiste ce que la
production de codes se fasse en binme partir de deux personnes travaillant ensemble sur
une seule machine, un clavier et une souris. Pour certains, cette pratique savre un moyen
utile de dveloppement surtout lorsquune base unique de code est mise en place et respecte
par les membres de lquipe (Ilieva, Ivanov & Stefanova, 2004). Elle facilite lapprentissage
interindividuel (Tessem, 2003), amliore le partage de connaissances tacites (Williams,
Kessler, Cunningham & Jeffries, 2000) ainsi que la rapidit et la qualit des codes produits
(Melnik & Maurer, 2002). Cette pratique renforce galement la confiance au niveau des
membres dune quipe (Melnik & Maurer, 2002) et permet de rduire les cots de
dveloppement (Cockburn & Williams, 2003) et les besoins en formation (Lindvall, Melis,
Marchesi, Basili, Boehm, Costa, Dangle, Shull, Tesoriero, Williams & Zelkowitz, 2002).
Dans une tude mene, en 2005, auprs de 122 personnes utilisant la programmation en paire
(Mannaro, Melis & Marchesi, 2005), 72 % estiment que cette pratique acclre le processus
de dveloppement.
En revanche, le travail en binme est peru comme une pratique fatigante pour les
dveloppeurs (Tessem, 2003 ; Ilieva, Ivanov & Stefanova, 2004), diminuant la productivit de
lquipe lorsque lcart au niveau des comptences des personnes travaillant en paire est
grand (Melnik & Maurer, 2002, Svensson & Host, 2005 ; Wellington, Briggs & Girard,
2005).
1.2.3 Les runions quotidiennes
Pour ce qui est des pratiques de coordination et de collaboration, les runions quotidiennes
semblent renforcer la communication et le travail collaboratif (Svensson & Host, 2005 ;
Chong, 2005), le partage dinformations (Melnik & Maurer, 2002) et la rsolution collective
des problmes (Robinson & Sharp, 2004, Sharp & Robinson, 2007). Selon certains praticiens,
ce type de runions permet davoir des clarifications rapides sur lavancement du projet et
67

Chapitre II : Analyse de la mise en pratique des innovations managriales

assure un meilleur contrle du projet en temps rel (Paasivaara, Durasiewicz & Lassenius,
2009). En effet, la communication en face face occupe une place centrale dans le processus
de dveloppement. Les changes frquents entre les membres dune quipe semblent faciliter
et acclrer le transfert des ides et des informations. Dans cette perspective, les quipes de
taille rduite sont privilgies car elles constituent un cadre idal pour communiquer en
directe (Svensson & Host, 2005 ; Petersen & Wohlin, 2009) rduisant ainsi la documentation
inutile (Petersen & Wohlin, 2009). Certains auteurs ont prcis que les dveloppeurs
sappuient fortement sur la communication directe, informelle pour corriger les erreurs et les
mauvaises prvisions (Herbsleb & Grinter, 1999).
Dans cette perspective, diffrents facteurs ont t identifis affectant la communication au
sein dune quipe agile (Ambler, 2002b): la proximit physique (les personnes travaillant
ensemble dans un mme endroit peuvent communiquer plus facilement), la proximit
temporelle (les dcalages horaires peuvent entraver la communication), le moral de lquipe
(la communication et le partage dinformation sont plus efficaces lorsque le moral des
membres dune quipe de dveloppement est lev), les outils technologiques compliqus
pouvant compliquer la communication et enfin lanxit (certaines personnes prfrent
communiquer par tlphone ou en face--face pendant que dautres privilgient la
communication par ml).
Nanmoins, certains praticiens ont soulign la rigueur et la discipline quexigent les runions
quotidiennes : respect des horaires de la runion, disponibilit des personnes (Begel &
Nagappan, 2007). De mme, ces runions sont difficiles implmenter au sein des quipes de
grande taille (Cockburn & Highsmith, 2001 ; Begel & Nagappan, 2007) et godistribues
(Kircher, Jain, Corsaro & Levine, 2001 ; Yap, 2005). Une forte synchronisation au niveau des
quipes savre indispensable (Yap, 2005 ; Kircher, Jain, Corsaro & Levine, 2001) ainsi
quune infrastructure technologique de qualit, favorisant la communication et les changes
distance, est fort recommande (Jensen & Zilmer, 2003 ; Braithwaite & Joyce, 2005 ; Yap,
2005 ; Fowler, 2006).
1.2.4 Le client sur le site
Une dernire pratique qui a t apprhende dans de nombreux travaux de recherche sur les
mthodes agiles est limplication du client sur le site. La collaboration avec le client se
trouve au cur du manifeste agile (Abrahamsson, Salo & Ronkainen, 2002). Ce principe a
68

Chapitre II : Analyse de la mise en pratique des innovations managriales

cependant t dclin sous des pratiques ou rle propre une mthode agile : Joint
Application Development (RAD), on-site customer (XP), product-owner (scrum),
etc. Cette pratique favorise les feedback continus (Karlstrm & Runeson, 2005), perfectionne
la qualit du produit (Rising & Janoff, 2000) en rduisant le nombre de fonctionnalits
inutiles et non acceptables (Hilkka, Tuure & Matti, 2005) et amliore la satisfaction des
clients par rapport au produit dvelopp (Mann & Maurer, 2005 ; Sillitti Ceschi, Russo &
Succi, 2005). Les feedback frquents acclrent lapprentissage organisationnel et facilite la
rduction des variations dans les processus et les produits. En outre, les clients semblent
apprcier leur participation active aux projets (Ilieva, Ivanov & Stefanova, 2004). Du point de
vue des dveloppeurs, cette pratique est galement perue comme utile, car leur offrant la
possibilit de consulter le client nimporte quel moment (Koskela & Abrahamsson, 2004 ;
Svensson & Host, 2005 ; Mann & Maurer, 2005, Karlstrm & Runeson, 2005) et rduisant les
conflits potentiels (Melnik & Maurer, 2002). Les dveloppeurs estiment important davoir
une personne exprimente prte accompagner les clients dans le processus agile de telle
manire les prparer et les aider dans la dfinition des demandes (Mann & Maurer 2005).
Nanmoins, dans un environnement distribu, la proximit entre le client et lquipe de
dveloppement nest pas faisable. Certains praticiens ont voqu le terme de client virtuel,
jouant le rle du client sur le site et accompagnant lquipe de dveloppement virtuellement
(Simons, 2002 ; Sutherland, Viktorov, Blount & Puntikov, 2007). Des difficults ont
galement t reportes relevant de lindisponibilit du client (Laymann, Williams, Damia &
Bure, 2006 ; Middleton & Joyce, 2010), du stress auquel il est soumis (Martin, Biddle &
Noble, 2004 ; Koskela & Abrahamsson, 2004) et des comptences techniques que celui-ci
doit possder pour dun ct, prendre les bonnes dcisions dans le choix et la priorisation des
fonctionnalits et dun autre ct, raliser lcriture des tests fonctionnels (Tessem, 2003).
Pour Beck (2004), un client virtuel ou proxy peut constituer un gaspillage lorsque les
fonctionnalits dveloppes ne sont pas utilises ou si les tests spcifis ne respectent pas les
critres dacceptation. En outre, certains praticiens ont remis en cause la ncessit dune
prsence permanente du client sur le site de dveloppement. Selon certaines tudes, seuls 21
% des efforts des clients sont ncessaires pour assister lquipe de dveloppement (Koskela &
Abrahamsson, 2004). Il semble galement difficile quun client puisse reprsenter lensemble
des utilisateurs dune application donne (Stephen & Rosenberg dans Koskela &
Abrahamsson, 2004).
69

Chapitre II : Analyse de la mise en pratique des innovations managriales

Nous remarquons que malgr les avantages que prsente chacune de ces pratiques de
collaboration, leur mise en place, dans un environnement godistribu, reste difficile. Face
ce constat, certains questionnements mritent dtre approfondis : comment aligner le mode
collaboratif dune quipe de dveloppement agile au mode de fonctionnement dautres
quipes impliques dans un mme projet ? Comment raliser des runions quotidiennes dans
une quipe dont les membres sont engags dans diffrents projets ? Sur quel critre faut-il se
baser pour choisir les participants ces runions lorsque les quipes savrent de grande
taille ?
Le concept dune quipe agile consiste en ce que les personnes occupant diffrents postes
(architectes, dveloppeurs, testeurs, etc.) communiquent rgulirement entre elles, sautoorganisent et sajustent mutuellement en fonction de lavancement du projet. Or, lorsque les
quipes recourent des prestataires externes et des acteurs mtiers intervenant
temporairement sur les projets, le principe de collaboration vis par les agilistes perd de
son efficacit.
Si certaines solutions ont t proposes par les experts en ces mthodes de dveloppement
informatique (dcoupage du projet par module, rduction de la taille des quipes, etc.), leur
mise en place dans des organisations complexes restent nanmoins imprcises et peu
structures.
1.3 Les outils de support au management
Les travaux de recherches publis sur le systme de production Toyota ont accord beaucoup
dimportance aux outils visuels de communication capables damliorer la transparence au
niveau des systmes de production : dtection des dfauts grce au systme alerte landon ,
identification de la quantit des pices produire en recourant aux tiquettes kanban , etc.
Dans le domaine du dveloppement agile de logiciels, ces outils visuels renvoient aux
story-cards et story-board . Leur fonction est dassurer un environnement informatif en
reprsentant le flux du travail et en rendant visible et accessible, tous les membres dune
quipe, lavancement du projet. Diffrentes informations sont habituellement renseignes
correspondant aux tapes faire , en cours , relire et termin . Sur chaque tape
sont affichs les story-cards sous forme de post-it . (Annexe V)

70

Chapitre II : Analyse de la mise en pratique des innovations managriales

Le story-board sur lequel sont affichs les story-cards ainsi que le product-backlog
semblent crer un environnement informatif amliorant la visibilit du projet (Cockburn,
2002; Robinson & Sharp, 2004 ; Sharp & Robinson, 2007, 2008, Petersen & Wohlin, 2009,
Middleton & Joyce, 2010) et assurer le suivi de lavancement des projets. Ces outils
permettent davoir une vision partage des demandes (Martin, Biddle & Noble, 2004) et
favorisent galement la communication et la coordination du travail des quipes (Martin,
Biddle & Noble, 2004 ; Sharp & Robinson, 2007 ; Sharp, Robinson & Petre, 2009).
En outre, dautres instruments de gestion ont t tudis comme les outils didentification et
danalyse des causes racines des problmes. Ces derniers semblent, leur tour, liminer le
travail de correction et amliorer la qualit des fonctionnalits produites (Middleton, Flaxel &
Cookson, 2005).
Toutefois, le partage de ces outils savre difficile entre les membres dune quipe distribue.
Le remplacement dartefacts physiques par des artefacts lectroniques ncessite des mises
jour rgulires ainsi quune infrastructure technologique de qualit favorisant les changes
distance (Kircher, Jain, Corsaro & Levine, 2001 ; Danait, 2005, Berczuk, 2007, Paasivaara,
Durasiewicz & Lassenius, 2008, 2009).
Ainsi leur implmentation semble tre efficace dans une organisation de type plateau o
les acteurs peuvent facilement suivre au quotidien lvolution du projet et communiquer avec
leurs paires. Quen est-il des structures complexes, larges et godistribues ? Comment crer
un environnement informatif lorsque les membres dune quipe sont engags dans plusieurs
projets, rattachs diffrents services fonctionnels et ne travaillent pas au mme endroit ?
Quels types dinformations partager virtuellement ? Comment sassurer que le story-board
est mis jour rgulirement et parcouru par les acteurs projets ?
Bien que ces outils puissent tre partags distance, leur contrle est dur raliser dans un
environnement virtuel. Bien au contraire, ils peuvent constituer des risques de mauvaises
diffusions de linformation au cas o ils ne sont pas mis jour correctement et rgulirement.
2. Les mthodes agiles v/s mthodes classiques : quelles mthodes privilgier ?
Aprs la publication des premiers ouvrages sur les mthodes agiles , de nombreux experts
en matire de dveloppement ont tent de comprendre les rapports qui existent entre ces
mthodes mergentes et les anciennes approches de dveloppement. Plusieurs hypothses ont
71

Chapitre II : Analyse de la mise en pratique des innovations managriales

t avances. Si pour certains, les mthodes agiles constituent une alternative aux
approches centres sur les processus ou sur la planification (Murru & Deias & Mugheddu,
2003), elles savrent pour dautres complmentaires (Turner, 2002 ; Boehm & Turner, 2003 ;
2005 ; Khknen & Abrahamsson, 2004). Cest dans cette perspective quun modle
multidimensionnel a t propos aux industriels afin quils aient la possibilit de slectionner
lapproche de dveloppement en fonction de leur type de projets (Cockburn, 2002b ; Boehm
& Turner, 2003).
La tendance des chercheurs exposer les approches agiles comme un moyen permettant
aux quipes de dveloppement daccrotre leur productivit (Agerfalk & Fitzgerald, 2006) et
de sadapter rapidement aux changements (Highsmith & Cockburn, 2002 ; Chong, 2005) ne
va pas dans le mme sens que les rsultats observs avec les mthodes classiques qui,
quant elles, dfendent lide dun environnement stable o lintgration des changements
constitue des cots supplmentaires.
Comme nous lavons prcis dans notre introduction, les approches classiques ont fait
lobjet de nombreuses critiques : mauvaise dfinition et comprhension des besoins, livraisons
tardives causes par le dveloppement squentiel, obsolescence des plans et de la
documentation, etc. De fait, les mthodes itratives et incrmentales constituent un moyen
pour rpondre ces problmes et rduire les risques associs aux activits de dfinition, en
amont, de lensemble du systme. Selon certaines tudes, les entreprises recourant aux
mthodes agiles jouissent dune relation plus satisfaisante avec leurs clients contrairement
aux mthodes classiques (Sillitti, Ceschi, Russo & Succi, 2005). Ceci sexplique par le fait
que le client fait partie intgrante de lquipe de dveloppement. Par consquent, sa
communication avec celle-ci et sa participation dans le processus de dveloppement amliore
la qualit du systme (Hikka, Tuure & Matti, 2005).
Dans cette section, nous examinons les rsultats denqutes menes auprs dun chantillon
dentreprises de type agile et traditionnel . Ces enqutes se donnent pour objectif de
comparer ces deux approches managriales sur le plan organisationnel et managria l et de
mettre en avant les principaux problmes rencontrs par chacune des quipes agiles et
classiques .

72

Chapitre II : Analyse de la mise en pratique des innovations managriales

Dans une enqute mene auprs de seize entreprises dont huit agiles et huit
traditionnelles , 88% des managers classiques62 interrogs contre 13% de managers
agiles , affirment que la variabilit des demandes, qui arrivent en cours du processus de
dveloppement, constitue une vraie source de problmes (Sillitti Ceschi, Russo & Succi,
2005). En outre, les organisations de type document-driven estiment avoir dpens
beaucoup plus de ressources en termes defforts et de temps pour prvoir lensemble des
demandes sachant que dans 50% des cas, les fonctionnalits taient mal comprises. Cette
mme enqute a montr que 75% des entreprises document-driven recourent des
contrats rigides bass sur une rgulation spcifique limitant ainsi les modifications des
demandes. Dans ce type dorganisation, les interactions avec le client se limitent la premire
phase du projet durant laquelle les besoins sont identifis. A cet effet, un contrat fixe est
labor pour stabiliser les demandes (Sillitti Ceschi, Russo & Succi, 2005). Or, les
connaissances limites du client et son incertitude par rapport ses besoins constituent un
problme majeur dans la dfinition et la clarification des demandes.
En effet, 75 % des entreprises agiles et 100 % des entreprises traditionnelles considrent
que la spcification des besoins par le client est insatisfaisante. Les principaux problmes sont
dus au manque de clart des objectifs, linformation partielle, aux barrires de langue et aux
problmes de communication. Conscientes de ces dysfonctionnements, les entreprises
agiles adoptent une attitude diffrente vis--vis de leur client et du changement. Par
consquent, elles recourent au dveloppement itratif permettant au client de mieux spcifier
ses besoins au niveau de chaque itration. Do les rsultats qui montrent que les entreprises
agiles ont une meilleure relation avec leur client par rapport aux socits
traditionnelles .
Une autre tude comparant une entreprise agile et une entreprise centre sur la
planification (Ceschi, Ceschi, Russo & Succi, 2005) a montr que les mthodes agiles
permettent damliorer les processus de management et de dveloppement ainsi que les
relations avec le client.
Dans cette mme logique, deux tudes se sont attaches valuer la productivit de deux
projets similaires, l'un bas sur une mthode de dveloppement classique et l'autre sur la
mthode XP . La premire tude a affich 42% de gain de productivit pour les quipes
62

Les managers classiques sont ceux qui appartiennent des entreprises centres sur la documentation
document-driven .

73

Chapitre II : Analyse de la mise en pratique des innovations managriales

agiles (Ilieva, Ivanov & Stefanova, 2005) et la seconde 46 % de gain pour les livrables
agiles (Layman, Williams & Cunningham, 2005).
En outre, certains praticiens (Dalcher, Benediktsson & Thorbergsson, 2005) ont conduit une
tude exprimentale sur quinze quipes utilisant quatre approches diffrentes (le cycle en
V , la mthode volutionnaire, la mthode incrmentale et la mthode XP ) pour le
dveloppement dun mme logiciel. Les diffrences significatives relvent surtout des quipes
utilisant le modle en V et celles recourant la mthode XP : 337% de gains de
productivit ont t affichs pour les quipes agiles . Selon cette tude, les dveloppeurs
agiles produisent 3.5 fois plus de lignes de codes que les dveloppeurs utilisant la
mthode en "V". En revanche, certains chercheurs (Wellington, Briggs & Girard, 2005) ont
not 44% de perte de productivit pour les quipes XP par rapport aux quipes
traditionnelles . Cette divergence au niveau des rsultats peut toutefois sexpliquer par
plusieurs facteurs : la manire dont les pratiques XP ont t adoptes, le niveau
d'exprience des quipes utilisant cette mthode, leur degr d'acceptation, etc.
Malgr les points de vue partags sur lefficacit de ces deux approches de dveloppement,
nous constatons que les mthodes classiques se heurtent divers problmes sur lesquels
beaucoup dexperts en dveloppement semblent saccorder. Les entreprises qui se considrent
capables de contourner les changements ont des difficults survivre dans notre
environnement actuel. Nanmoins, peu danalyses empiriques tmoignent aujourdhui de la
scalabilit 63 des mthodes agiles . Les principes de communication, de suivi et de
contrle rguliers des projets au sens des agilistes sont difficiles dcliner sur des
structures dquipes de grande taille, godistribues.
A ce titre, un ensemble rcent darticles a mis en lumire plusieurs retours dexpriences sur
lapplication des mthodes agiles dans un environnement global caractris par des
quipes de dveloppement distribues gographiquement. La section suivante est consacre
la prsentation des rsultats de ces crits.

63

La scalabilit des mthodes agiles renvoie leur applicabilit sur des projets et des quipes de grande taille
(http://www.aubryconseil.com/post/Les-echelles de-l-agilit).

74

Chapitre II : Analyse de la mise en pratique des innovations managriales

3. Lapplication des pratiques agiles dans un environnement godistribu


Lenvironnement de dveloppement de logiciels est en pleine volution. La tendance des
socits informatiques sinstaller sur de nouveaux marchs de dveloppement moins
coteux, en loccurrence la Chine, lInde, le Brsil et les pays de lest saccrot. Cette stratgie
de globalisation prsente un grand nombre davantages : rduction des cots de main
duvre, diversit des profils et des comptences des dveloppeurs, optimisation du cycle de
travail en travaillant sur diffrents fuseaux horaires, dcomposition du travail en modules
transversaux et indpendants, etc. (Agerfalk & Fitzgerald, 2006). Si la distance gographique
constitue donc une opportunit conomique et organisationnelle, elle se heurte de nombreux
dfis : distance temporelle, socioculturelle, technologique, etc.
A cet gard, un ensemble de praticiens a cherch comprendre comment les principes
agiles pouvaient tre dclins sur des quipes distribues. Bien que de nombreux experts
en dveloppement considrent que ces pratiques correspondent des quipes de taille rduite
et colocalises (Rising & Janoff, 2001 ; Cockburn & Highsmith, 2001 ; Cohen, Lindvall &
Costa, 2004), des recherches ont montr que les mthodes agiles et en particulier
scrum et XP pouvaient tre appliques avec succs sur des quipes larges (Farmer,
2004 ; Paasivaara, Durasiewicz & Lassenius, 2009) et godistribues (Kircher, Durasiewicz,
Lassenius, Jain, Corsaro & Levine, 2001 ; Braithwaite & Joyce, 2005 ; Danait, 2005 ;
Berczuk, 2007; Sutherland, Viktorov, Blount & Puntikov, 2007). En outre, de rcentes
enqutes64 menes sur ladoption des pratiques agiles ont montr que celles ci taient
majoritairement adoptes par de larges organisations. Cependant, les quipes agiles
godistribues rencontrent des problmes spcifiques.
La communication est considre comme un facteur critique pour le succs des projets
agiles (Hersleb & Grinter, 1999; Yap, 2005 ; Agerfalk & Fitzgerald, 2006). Lorsque le
dveloppement est effectu sur diffrents sites, impliquant de larges quipes, les interactions
deviennent plus difficiles raliser compliquant ainsi les activits de coordination (Kircher,
Jane, Corsaro & Levine, 2001 ; Simons, 2002 ; Layman, Williams, Damia & Bures, 2006 ;
Berczuk, 2007 ; Sutherland, Viktorov, Blount & Puntikov, 2007). Plusieurs tudes empiriques
ont t conduites pour identifier les dfis majeurs dont relve le dveloppement agile dans
un environnement globalis.
64

Ambler, agile adoption rate survey, 2008 ; Ambler, Agile practice and principles survey, 2008

75

Chapitre II : Analyse de la mise en pratique des innovations managriales

Nous nous attarderons ici prsenter, dune part, les obstacles majeurs rencontrs lors de
lapplication des mthodes agiles dans un environnement godistribu et, dautre part, les
solutions respectives proposes par les experts en dveloppement de logiciels. Pour ce faire,
nous nous sommes appuys sur une revue systmatique (Hossain, 2009) qui nous a permis
didentifier lensemble des travaux explorer et analyser sur ce sujet.
3.1 Les principaux dfis du dveloppement agile distribu
Le manque dinteractions a t report comme un obstacle majeur auquel sont confrontes les
quipes agiles distribues (Kircher, Jane, Corsaro & Levine, 2001 ; Braithwaite & Joyce,
2005, Danait, 2005 ; Yap, 2005 ; Layman, Williams, Damia & Bures 2006 ; Sutherland,
Viktorov, Blount & Puntikov, 2007 ; Paasivaara, Durasiewicz & Lassenius, 2008). Outre la
distance physique, divers facteurs contextuels semblent entraver la communication et les
changes frquents entre les membres des quipes agiles godistribues : barrires de
langue (Yap, 2005 ; Layman, Williams, Damia & Bures, 2006), indisponibilit des quipes,
diffrents horaires de travail (Kircher, Jane, Corsaro & Levine, 2001, Yap, 2005), etc.
Dans cette section, nous regrouperons les causes des dfis auxquels font face les membres des
quipes agiles distribues. Le tableau (6) synthtise les dfis majeurs reports.
3.1.1 Lenvironnement technique
Linfrastructure technologique dont dispose une organisation semble fortement influencer les
activits de communication et de coordination entre les membres dune quipe (Kircher, Jane,
Corsaro & Levine, 2001). A ce propos, de nombreux praticiens ont insist sur la mise en place
dune infrastructure technologique de qualit pour amliorer la communication distance
(Kircher, Jane, Corsaro & Levine, 2001 ; Berczuk, 2007 Danait, 2005 ; Paasivaara,
Durasiewicz & Lassenius 2008 ; Jensen & Zilmer, 2003) et le partage des documents (product
backlog, les story-cards, les graphes, etc.) (Smits & Pshigoda, 2007 ; Berczuk, 2007 ;
Paasivaara, Durasiewicz & Lassenius, 2008). Nous reviendrons plus loin sur les
recommandations des experts en dveloppement de logiciels.

76

Chapitre II : Analyse de la mise en pratique des innovations managriales

3.1.2 Les diffrences culturelles


Une autre difficult reporte dans la littrature relve des divergences culturelles entre les
quipes travaillant sur des sites gographiques diffrents. Ces diffrences peuvent tre
significatives et entraner des incomprhensions et des conflits entre les acteurs. Ces
problmes relvent principalement des barrires de langue, des normes culturelles, des rgles
et des modes de fonctionnement des quipes (Hersleb & Grinter, 1999 ; Herbsleb & Moitra,
2001 ; Poole, 2004 ; Yap, 2005 ; Sutherland, Blount & Puntikov, 2007 ; Paasivaara,
Durasiewicz & Lassenius, 2008 ; Cristal, Wild & Prikladnicki, 2008).
3.1.3 Le rle du client
La participation du client un projet de dveloppement global nest pas vidente. Si les
mthodes agiles valorisent la collaboration troite avec le client, celle-ci nest pas facile
raliser lorsque les quipes sont spares physiquement. Les runions en face face et les
changes rguliers deviennent difficiles (Paasivaara, Durasiewicz & Lassenius, 2008)
conduisant de mauvaises dfinitions des demandes et des besoins (Simons, 2002 ;
Paasivaara, Durasiewicz & Lassenius, 2008).
3.1.4 Le management de projet
Les interdpendances au niveau des diffrentes quipes distribues peuvent avoir pour
consquence des problmes de synchronisation entre elles (Sutherland, Blount & Puntikov,
2007). Pour cela, le contrle managrial des diffrents groupes devient une activit difficile
grer (Simons, 2002 ; Sutherland, Blount & Puntikov, 2007 ; Paasivaara Durasiewicz &
Lassenius, 2008, 2009). La volatilit des demandes, les changements au niveau des
spcifications et du design ncessitent ds lors des efforts de coordination supplmentaires et
des stratgies managriales (Herbsleb & Moitra, 2001). La division du travail en modules
indpendants comme le proposent certains praticiens se heurte toutefois des problmes
techniques lis lintgration (Herbsleb & Grinter, 1999 ; Mockus & Herbsleb, 2001). Cette
dernire ncessite une mise en place de rgles de dveloppement spcifiques et des outils
technologiques performants permettant une cohrence entre les diverses sources de codes
intgrs.

77

Chapitre II : Analyse de la mise en pratique des innovations managriales

Tableau 6 : Dfis majeurs du dveloppement agile dans un environnement globalis


Problmes majeurs

Rfrences

Diffrents fuseaux horaires


-Asynchronisation des quipes

Hersleb & Grinter, 1999 ; Kircher, Jane, Corsaro & Levine, 2001 ;
Yap, 2005 ; Smits, 2007)

Infrastructure technique
-Faible changes de donnes,
service de rseau limit

(Jensen et Zilmer, 2003 ; Danait, 2005 ; Yap, 2005)

-Manque doutils collaboratifs


virtuels

(Kircher, Jane, Corsaro & Levine, 2001; Paasivaara, Durasiewicz &


Lassenius, 2008)

Diffrences culturelles
-Barrire de langue

(Poole, 2004; Yap, 2005, Layman, Williams, Damia & Bures, 2006)

-Vision non partage

(Herbsleb & Moitra, 2001; Yap, 2005)

-Valeurs culturelles

(Sutherland, Blount & Puntikov, 2007 ; Paasivaara, Durasiewicz &


Lassenius, 2008 ; Cristal, Wildt & Prikladnicki, 2008)

Client virtuel
-Manque de communication en
face face

(Kircher, Jane, Corsaro & Levine, 2001 ; Simons, 2002 ; Jensen &
Zilmer, 2003 ; Yap, 2005)

Management de projet
-Manque de contrle
managrial
-Difficults de synchronisation
entre les diffrents sites

(Kircher, Jane, Corsaro & Levine, 2001)


(Hersleb & Grinter, 1999 ; Sutherland, Blount & Puntikov ,2007)

Aprs avoir identifi les obstacles majeurs, les praticiens ont tent dy rpondre en proposant
un ensemble de solutions.
3.2 Les recommandations des praticiens face aux dfis remonts
3.2.1 Modes de communication multiples
Comme nous lavons dj prcis, la communication directe et informelle occupe une place
centrale au niveau des quipes de dveloppement. Il est donc indispensable de disposer dune
infrastructure technologique de qualit permettant les changes virtuels rapides (Yap,
2005 ; Braithwaite & Joyce, 2005 ; Agerfalk & Fitzgerald, 2006). Diverses technologies
78

Chapitre II : Analyse de la mise en pratique des innovations managriales

dinformation et de communication ont t suggres pour faciliter la communication directe,


le partage de documents et les changes de connaissances tacites (Kirch, Jane, Corsaro &
Levine, 2001 ; Jensen & Zilmer, 2003 ; Fowler ; Braithwaite & Joyce, 2005 ; Yap, 2005) :
connexion rapide dinternet, vidoconfrences, whiteboard65, Twikis66, Instant Messenger67,
XPplanner68, Jira69, etc. Ces outils collaboratifs qui soutiennent les runions frquentes entre
les quipes distribues (Simons, 2002 ; Braithwaite & Joyce, 2005 ; Danait, 2005; Berczuk,
2007 ; Paasivaara, Durasiewicz & Lassenius, 2009) savrent utiles pour contrler ce qui se
passe sur le site. (Paasivaara, Durasiewicz & Lassenius, 2009). Le partage en ligne dun
product-backlog ou des user-stories , par exemple, permet de rduire les
incomprhensions et daccrotre la visibilit du projet.
Les visites rcurrentes sont galement ncessaires, surtout durant les phases critiques du
projet : planification, tests, etc. Les dplacements physiques permettent de renforcer la
confiance et la collaboration entre les membres des quipes projets (Kircher, Jane, Corsaro &
Levine, 2001 ; Fowler, 2006). Bien que les technologies dinformation et de communication
permettent damliorer la communication inter-quipes, elles ne remplacent pas la
conversation en face face. Selon certains praticiens, les mls, bien quindispensables pour
les changes, se heurtent certaines difficults. A titre dexemple, le temps de rponse aux
mls peut tre long en raison du dcalage horaire et de lindisponibilit du destinataire. Il
convient alors dajuster les horaires de travail en rduisant au maximum le dcalage surtout en
phase critique du projet (Simons, 2002 ; Yap, 2005) ou mme, de recourir des rgles (le
temps de rponse un mail ne doit pas excder les 12 heures par exemple) qui pourraient
viter les retards (Vax & Michaud, 2008).
3.2.2 Le client virtuel
Les praticiens mettent laccent sur le besoin davoir un client virtuel qui travaille et
communique constamment avec lquipe de dveloppement. Il doit tre reprsent par une
65

Logiciel permettant aux utilisateurs distribus de collaborer en temps rel et de partager leurs fichiers, graphes,
etc.
66
Une plateforme de travail collaboratif permettant de stocker les informations sous forme de pages web et de
pices jointes. Localis dans lintranet, cet outil est scurisant et efficace pour communiquer les diffrents
aspects du projet (use-cases, daily program status, burndown charts, etc.).
67
La messagerie instantane ou le dialogue en ligne permet lchange instantan de messages textuels entre
plusieurs ordinateurs connects.
68
LXPplanner est un outil de planification et de traabilit pour les quipes XP .
69
Le Jira est un outil collaboratif permettant dassurer le suivi et la gestion du tableau des tches, des bugs, des
demandes dvolution, etc. Les demandes peuvent tre affiches sous forme de cartes virtuelles.

79

Chapitre II : Analyse de la mise en pratique des innovations managriales

personne facile daccs prouvant un grand intrt pour le projet (Simons, 2002 ; Layman,
Williams, Damia & Bures, 2006). De plus, un bon client virtuel doit disposer de
connaissances techniques relatives aux besoins du march et au produit dvelopp afin de
mieux communiquer avec lquipe de dveloppement (Simons, 2002) et de prendre les
bonnes dcisions relatives aux besoins du systme dvelopp (Layman, Williams, Damia &
Bures, 2006). Si pour certains, le rle du client virtuel semble indispensable, il prsente
certaines limites : un client virtuel ne peut identifier les changements dans les demandes aussi
rapidement quun client prsent physiquement avec lquipe (Simons, 2002). Il peut
galement constituer un cot supplmentaire, sil ne possde pas les connaissances suffisantes
pour prendre les bonnes dcisions (Beck, 2004).
3.2.3 Frquentes visites inter-sites
Les diffrences culturelles entre les quipes globalement distribues peuvent tre rduites
travers des rencontres et des changes frquents. Lchange culturel peut tre ralis par
lorganisation de voyages inter-sites et les changes inter-quipes contribuant ainsi la
cration dune comprhension commune du projet (Poole, 2004 ; Sutherland, Blount &
Puntikov, 2007).
3.2.4 Les outils de support au management de projet
Des outils de support au management ont t proposs en vue de contrler et de suivre au
quotidien ltat davancement des projets distribus : la dcomposition du projet en modules
indpendants (Herbsleb & Grinter, 1999), la division des quipes en sous-quipes, de taille
rduite, faciles grer (Layman, Williams, Damia & Bures, 2006 ; Sutherland, Blount &
Puntikov, 2007 ; Beavers, 2007 ; Paasivaara, Durasiewicz & Lassenius, 2008). La
dcomposition en sous-quipes, responsables dun ensemble limit de fonctionnalits
indpendantes semblent faciliter les activits managriales. Des mini-scrums peuvent
galement tre organiss un niveau local et des scrums of scrum entre les reprsentants
des chacun des sites (Sutherland, 2001 ; Berczuk, 2007 ; Summers, 2008).
Par ailleurs, il est important davoir une quipe quilibre en termes de taille, de comptences
techniques et dautorit dans chacune des rgions concernes par le projet (Yap, 2005). Cela
permet dacclrer les processus de prises de dcisions et de rsoudre rapidement les conflits
mergeant.
80

Chapitre II : Analyse de la mise en pratique des innovations managriales

La majorit des tudes publies sur lapplication des pratiques agiles dans un
environnement global se sont focalises sur les mthodes XP et scrum . Ces crits ont
mis laccent sur les dfis majeurs rencontrs par les quipes agiles globalement distribues
et ont report les retours dexpriences qui ressortent de lapplicabilit de ces mthodes dans
de tels environnements. Outre les dfis majeurs et les solutions proposes, ces tudes ne
posent pas, de faon concrte, la manire dont les quipes ont procd pour implmenter les
pratiques agiles au sein de leur contexte. En outre, ces tudes se sont uniquement
focalises sur des quipes de dveloppement. Lorganisation au sens global du terme na pas
t prise en compte. Bien que cette revue de la littrature fournisse un ensemble de solutions
aux problmes potentiels que les quipes de dveloppement agiles distribues peuvent
rencontrer, elle noffre pas de modle de gestion unifi pouvant tre appliqu facilement par
des quipes uvrant dans des conditions similaires. Le tableau (7) synthtise ces diverses
recommandations.
Tableau 7 : Recommandations face aux dfis rencontrs dans un environnement globalis
Recommandations
Multiples modes de communication

Rfrences

-Vido confrences, wikis, Instant


Messenger, Jira, XPplanner

(Simons, 2002 ; Braithwaite & Joyce, 2005 ; Yap, 2005 ;


Berczuk, 2007)

-Runions en directe

(Kircher, Jane, Corsaro & Levine, 2001 ; Fowler ;


Paasivaara, Durasiewicz & Lassenius, 2009)

-Client virtuel

(Simons 2002 ; Layman, Williams, Damia & Bures,


2006 ; Sutherland, Blount & Puntikov, 2007)

-Synchronisation des horaires de travail

(Simons, 2002 ; Yap, 2005, Vax & Michaud, 2008)

-Frquentes visites inter-sites

(Poole, 2004 ; Sutherland, Blount & Puntikov, 2007)

Management de projet
-Dcomposition du projet en modules
indpendants
-Dcomposition des quipes en quipes
de taille rduite

(Herbsleb & Grinter, 1999)


(Sutherland, Blount & Puntikov, 2007 ; Paasivaara
Durasiewicz & Lassenius, 2008)

-Organisation de runions scrums of


scrum

(Berczuk, 2007 ; Summers, 2008)

-Adhsion aux valeurs agiles

(Sutherland Blount & Puntikov, 2007 ; Paasivaara,


Durasiewicz & Lassenius, 2009)

-Sites quilibrs

(Yap, 2005)
81

Chapitre II : Analyse de la mise en pratique des innovations managriales

Afin de complter notre analyse de la littrature, nous souhaitons faire part de la manire dont
certains experts en mthodes de dveloppement peroivent lapplicabilit de ces mthodes
dans des environnements complexes et godistribus.
3.3 Regard complmentaires des experts sur le dveloppement agile globalis
Nous conclurons cette section par la transcription de trois entretiens par mens Agerfalk et
Fitzgerald (2006), auprs de spcialistes en mthodes dveloppement : David Parnas, Barry
Boehm et Matthew Simons.
Du point de vue de David Parnas
De nombreux industriels ont tent de rpondre aux difficults majeures rencontres dans un
environnement de dveloppement globalis. Pour David Parnas, les problmes de
dveloppement de logiciels relvent gnralement dun dficit de communication entre les
membres des quipes de dveloppement (programmeurs, architectes, etc.) et avec les
utilisateurs. Or face ce problme, deux coles de penses ont merg: lune insiste sur le
dveloppement standardis et reposant sur la planification et la documentation extensive et
lautre considre que le code est la seule source de documentation ncessaire the first
developed process standards requiring huge amounts of wordy documentation, the second
said : code is a document and all the documentation we need (David Parnas dans Agerfalk
& Fitzgerald, 2006). David Parnas dfend lide selon laquelle une quipe de dveloppement
ne peut uniquement se limiter la communication orale. Il explique que celle-ci est incapable
de garantir le transfert des informations dtailles ncessaires la production dun logiciel de
qualit. Selon lui, il est important de recourir des moyens permettant de produire une
documentation utile sans que celle-ci soit ncessairement abondante the real challenge is
not to find ways to avoid documenting but to find ways to produce useful documentsdocuments that take time but save more time (David Parnas dans Agerfalk & Fitzgerald,
2006).
Afin davoir une vision plus large de ce sujet, les auteurs (Agerfalk & Fitzgerald, 2006) ont
dcid dinterroger Barry Boehm, fondateur de la mthode en spirale base sur le pilotage
par les risques.

82

Chapitre II : Analyse de la mise en pratique des innovations managriales

Du point de vue de Barry Boehm


Si Barry Boehm confirme le fait que le dveloppement distribu ne relve pas dun
phnomne rcent, il affirme en revanche, quavec le dveloppement radical des outils
technologiques, la communication distance ne constitue plus un problme majeur aux
quipes de dveloppement distribues.
Pour Boehm, les stratgies danticipation des demandes de changement font preuve de peu
defficacit surtout lorsque les contextes savrent comptitifs et incertains. A cet effet, les
pratiques agiles ont t mises en place pour mieux rpondre aux besoins volutifs du
march. Limplication du client, les runions rgulires, la programmation en paire et
lappropriation collective des codes semblent favoriser les changes de connaissances tacites
contrairement aux activits de documentation. Si Boehm met en valeur les pratiques
soutenues par les mthodes agiles , il ne renonce pas aux activits de documentation des
approches traditionnelles . Il dfend le principe selon lequel un projet de dveloppement ne
doit pas se limiter une seule approche. Selon lui, il est important de se baser sur les risques
encourus dans un projet afin de dterminer lapproche de developpement la plus approprie
the best way i have been able to find is to use risk as a way to determine where to go agile
and where to go document-Driven (Barry Boehm dans Agerfalk & Fitzgerald, 2006).
Un troisime entretien auquel nous nous sommes intresss concerne Matthew Simons, le
directeur responsable de thoughtwork en Inde.
Du point de vue de Matthew Simons
Conformment la vision de David Parnas, Simons estime que le risque dchec dun projet
de dveloppement offshore est fortement li une communication inefficace. Bien que les
pratiques agiles soutiennent fortement les processus de communication, elles doivent
encore tre compltes par une documentation brve et lgre. Cest pourquoi Simons
prconise que la documentation doit comporter les dtails cls du projet sans toutefois
excder les deux pages : description textuelle des fonctionnalits, du contexte, une srie de
test-cases , etc.
Les points de vue de ces spcialistes sont cohrents avec les rsultats mitigs de la revue de la
littrature. Les positions contradictoires dfendues par les praticiens remettent en cause la
83

Chapitre II : Analyse de la mise en pratique des innovations managriales

gnricit de ces approches mergentes. Il nous parat donc htif de tirer des conclusions sur
la porte relle de ces mthodes et leur applicabilit dautant plus que les recherches les plus
avances dans ce domaine concernent les quipes de taille rduite. Les mthodes agiles
semblent ainsi difficiles implmenter dans des contextes complexes, caractriss par de
larges quipes, godistribues.

84

85

Chapitre III : Stratgie de recherche : une approche par


la pratique

Ce chapitre est consacr la prsentation de notre stratgie de recherche qui vise cerner la
question de la contextualisation interne des mthodes agiles en tant qu innovations
managriales travers une tude de cas mene dans la perspective de lapproche par la
pratique . Nous dcomposons ce chapitre en deux sections.
Nous prsentons, dans une premire section, la perspective de la pratique en nous
focalisant sur lapproche de la fabrique de la stratgie qui se prsente comme un angle de
recherche pertinent pour examiner les activits des acteurs impliqus dans la fabrication
et la mise en uvre dune dmarche managriale de type agile .
Nous exposons, dans une seconde section, le modle de sensemaking qui nous servira de
grille danalyse pour mieux saisir la manire dont les acteurs font sens de ces mthodes et de
leur contexte dapplication.

86

Chapitre III : Stratgie de recherche : une approche par la pratique

Bien que plusieurs ouvrages 70 et retours dexpriences attestent de lapplicabilit des


mthodes agiles sur des structures dquipes de grande taille et godistribues, la
gnricit des modles dapplication des ces pratiques reste peu investigue et dmontre.
Les tudes de cas menes sur ces nouvelles pratiques de dveloppement rassemblent des
positionnements contradictoires. Ces mthodes ne sappuient pas sur une base thorique
stabilise de management de projet informatique. Le corps de connaissances sur la mise en
uvre de ces approches mergentes demeure particulirement flou.
Aujourdhui, les organisations ne disposent daucun modle de gestion de projet agile
formalis quelles peuvent facilement adapter quelque soit leur contexte. Les mthodes
agiles invitent un mode dorganisation qui relve dune dynamique dorganizing. A ce
stade, une question principale nous parat lgitime :
Comment ce type dinnovation managriale peut-il tre mis en uvre dans une dmarche
structure de management pour constituer un dispositif formalis favorisant lorganizing ?
Ce questionnement nous amne dfinir une stratgie de recherche . Celle-ci renvoie
une approche danalyse par la pratique et une tude de cas instrumentale.
Notre projet de recherche vise comprendre les modes de construction dune dmarche
agile . La perspective de la pratique peut tre considre comme un angle de
recherche pertinent pour examiner, de faon approfondie, les activits des acteurs impliqus
dans la fabrication de ces mthodes de management de projet et leurs interactions
continues avec lenvironnement dans lequel ils se trouvent.
Peu dtudes ont t menes sur la manire dont les acteurs interprtent et construisent
collectivement les mthodes agiles mettre en uvre dans des structures
70

Il convient de noter que les ouvrages pionniers sur les mthodes agiles sont crits par les fondateurs du
manifeste agile . Il est donc vident que chacun des acteurs va promouvoir sa propre mthode de
dveloppement agile en soulignant la supriorit de celle-ci sur les autres modles de dveloppement et de
management de projet informatique.

87

Chapitre III : Stratgie de recherche : une approche par la pratique

organisationnelles complexes . Dans la bote outils des mthodes agiles quelle(s)


instrumentation(s) privilgier ? Comment interviennent les lments de contingence
organisationnelle dans limplmentation des principes ingnieriques et managriaux propres
aux mthodes agiles ?
Afin de rpondre ces questions, il nous parat opportun de nous intresser une tude de
terrain pour mieux cerner la faon dont les outils classs sous le qualificatif agile sont
implments au sein des organisations. Le choix dune tude de cas instrumentale (David,
2000) nous parat donc pertinent pour analyser, en profondeur, le phnomne de mise en
uvre de ces mthodes dans des structures organisationnelles complexes .
La mthode des cas est un mode dobservation prcis de thmes pralablement dfinis par le
questionnement (Yin, 1994 dans Wacheux, 1996). Elle suppose une analyse en profondeur
des divers aspects dune situation pour en faire apparatre les lments significatifs et les
liens entre eux. Par ailleurs, les tudes de cas peuvent tre classes en trois catgories
(David, 2000) : tude de cas intrinsque, instrumentale et multiple.
Ltude de cas intrinsque porte sur un cas caractre unique ou trs rare, suscitant lintrt
dinvestigation du chercheur. Comme le prcise David (2000), dans une tude de cas
intrinsque, un ensemble de thories est mobilis non pas pour elles-mmes mais pour
analyser et comprendre le cas tudi. Les finalits de la recherche visent principalement la
comprhension dun cas spcifique digne dintrt. Dans une tude de ce type, le cas est
souvent prslectionn en raison de sa particularit (Stake, 1995). Contrairement ltude
intrinsque, ltude de cas instrumentale traite dune question thorique gnrale dans
lobjectif de fournir une nouvelle comprhension dun phnomne ou daffiner une thorie
mergente (David, 2000). Ltude de cas instrumentale est particulirement prconise dans
les situations o le chercheur veut illustrer des phnomnes pralablement dfinis dans un
modle thorique. Une tude de cas peut galement faire lobjet de cas multiples. Elle
consiste identifier des phnomnes rcurrents parmi un certain nombre de situations et a
pour but de parvenir une meilleure comprhension voire une meilleure thorisation du
phnomne tudi. Elle permet au chercheur dexplorer les diffrences manifestes au sein
dun mme cas ou entre diffrents cas.
Dans le cadre de ce travail, nous souhaitons raliser une tude de cas de type instrumental
dans une organisation souhaitant sengager dans la voie de lagilit. Le cas fait lobjet dune
88

Chapitre III : Stratgie de recherche : une approche par la pratique

analyse contextualise mais toujours en vue dun intrt externe. Il ne constitue pas lobjectif
ultime de la recherche. Cette approche nous confre une comprhension gnrale du
phnomne dimplmentation des innovations managriales de type agile dans un
contexte particulier caractris par une complexit organisationnelle. Nous avons donc
identifi un terrain de recherche prsentant des traits typiques par rapport notre objet
dtude. Notre intention est de saisir la faon dont sont implmentes les pratiques agiles
dans un environnement complexe en tant que mthodes de management de projet. Pour ce
faire, nous avons dcid daborder le cas slectionn dans lapproche de la perspective par
la pratique en se focalisant sur ce que font concrtement les acteurs chargs de la mise en
place des outils agiles de management de projet.
Lorganisation slectionne pour cette tude de cas uvre dans un environnement
technologique volutif soumis une pression concurrentielle accrue, ncessitant une forte
ractivit et adaptabilit des projets informatiques mens. Ne parvenant pas respecter les
dlais et la qualit imposs par les clients ainsi que les budgets allous aux projets, la
direction a dcid demprunter la voie dagilit en mettant en place un projet damlioration
des modes de fonctionnement de ses quipes. Le cas retenu a pour enjeu de faciliter la
comprhension de quelque chose dautre que la particularit du cas, en loccurrence le
dveloppement et la mise en uvre des pratiques managriales agiles dans des
configurations organisationnelles complexes. Nous reviendrons dans le chapitre (IV) sur la
prsentation de lorganisation concerne par cette tude de cas.
Dans cette premire section, nous rappelons les principaux lments de lapproche par la
pratique dans laquelle sinscrit ce travail de thse.
La perspective de la pratique en sciences sociales
Depuis cette dernire dcennie nous assistons, en sciences de gestion mais pas seulement,
un vritable practice turn . De nombreux chercheurs en management et en stratgie ont
mis en exergue la notion de pratique pour tudier les organisations et comprendre, de
manire approfondie, comment les activits sont menes sur le lieu de travail (Gherardi,
2000, 2001 ; Whittington, 2003 ; 2007 ; Antonacopoulou, 2006 ; Jarzabkowski & Kaplan,
2008). Ces travaux se sont focaliss sur les micro-pratiques, les conversations et les activits
qui se trouvent au cur des processus organisationnels the practice notion implies a close
89

Chapitre III : Stratgie de recherche : une approche par la pratique

attention to the work done by people inside organizational processes. The practice
perspective focuses on people, routines, and situated activities (Whittington, 2003, p.118).
Diffrentes tudes ont tent de dfinir le sens de la notion de pratique . Si pour certains
auteurs, cette notion reflte un mode dapprentissage people learn by doing through
constant repetition of their activities , pour dautres elle renvoie un champ dactivit
practice is a word able to express the field of activity in which an individual works ou
encore la manire dont les activits quotidiennes sont ralises dans un contexte dtermin
(Corradi & Gherardi & Verzelloni, 2008).
Aujourdhui, plusieurs approches sinscrivent dans le courant des practice-based studies :
practice-based-standpoint (Brown & Duguid, 1991 dans Corradi & Gherardi &
Verzelloni, 2008), community of practice (Lave & Wenger, 1991 dans Corradi &
Gherardi & Verzelloni, 2008), practice lens (Orlikowski, 2000), knowing in practice
(Gherardi, 2000, 2001), strategy-as-practice (Whittington, 1996, Jarzabkowski, 2003),
etc. Chacune delles a introduit une pluralit de concepts et de perspectives innovantes pour
apprhender les phnomnes organisationnels en se focalisant sur les pratiques entreprises
par les acteurs en interactions continues avec les lments de leur contexte matriel et social:
there are literatures on knowing in practice, formal analysis in practice and technology in
practice, each of which share a common focus upon the way that actors interact with the
social and physical features of context in the everyday activities that constitute practice.
Most recently, the practice approach has entered the strategy literature recommending that
we focus upon strategists engaged in the real work of strategizing (Jarzabkowski, 2004,
p.531). Gherardi et ses collgues ont employ la mtaphore de la caravane
( bandwagon ) pour dsigner lexistence dun courant de recherche quun grand nombre
de chercheurs, en management et en organisation, ont progressivement rejoint (Corradi,
Gherardi & Verzelloni, 2008).
Bien que les variantes du courant de la pratique saccordent sur la vision pragmatique de
la ralit et valorisent, toutes, les activits rptitives ( mundane activity ) des individus,
elles visent nanmoins des objets et thmes de recherche varis. Parmi les subdivisions de ce
courant renseignes dans larticle Ten good reasons for assuming a Practice Lens in
Organization Studies (Corradi, Gherardi & Verzelloni, 2008), nous prsentons brivement
cinq, ayant fait lobjet de multiples recherches (tableau 8). Par ailleurs, nous nous focalisons
90

Chapitre III : Stratgie de recherche : une approche par la pratique

davantage sur le courant de la fabrique de la stratgie qui nous apparat le plus pertinent
dans le cadre de ce travail. Nous reviendrons sur ce choix dans la sous-section suivante.
Tableau 8 : Les tudes bases sur la pratique
Label

Auteurs

Objet de lapproche

La pratique comme une


pistmologie : elle lie le travail,
lapprentissage et linnovation
( Practice stand-point )

Brown &
Duguid (1991)

La pratique permet de comprendre les


processus dapprentissage situs. Dans
cette perspective lapprentissage est le
lien entre le travail et linnovation.

La pratique comme une activit


sociale, situe.
( Practice as a social and
situated activity )

Gherardi,
Nicolini &
Odella, (1998)

Se focaliser sur les actions situes qui


relvent dun contexte dans lequel les
relations sociales, matrielles et
culturelles ont lieu.

Orlikowski,
(2000)

Observer comment les gens nactent la


technologie et comment en lutilisant au
cours de leurs actions sociales, ils
contribuent lactualiser par une relation
rcursive qui lie la technologie aux
actions situes et la structure
organisationnelle.

Le savoir comme
accomplissement pratique
( Knowing in practice )

Gherardi,
(2000) ;
Orlikowski,
(2002)

La connaissance nest pas quelque chose


que les gens possdent dans leurs ttes
mais plutt quelque chose que les gens
font ensemble travers leurs interactions
humaines et non humaines. La
participation une pratique est un moyen
dacqurir, modifier et partager une
connaissance.

La stratgie comme pratique : ce


que font les individus
(Strategy-as-practice )

Whittington,
(1996, 2006) ;
Jarzabkowski,
Balogun &
Seidl, (2007).

Le courant de la fabrique de la
stratgie cherche tudier les
innombrables micro-actions travers
lesquelles les acteurs humains organisent
lactivit de manire gnrer des
rsultats stratgiques.

Lapproche de la pratique
pour tudier ce que les gens font
et le produit de leurs actions
( Practice lens )

1. La fabrique de la stratgie : champ de recherche mergent en sciences sociales


Un nombre croissant de confrences et de publications rcentes ont trait de la perspective
de la stratgie en pratique (cinquante deux articles publis en 2010 contre un article en 2001,
Egos 2011). Suite la parution de larticle de Richard Whittington dans Long Range
Planning, en 1996, le courant de strategy-as-practice a progressivement t popularis.
Nous retrouvons, lheure actuelle, une varit de travaux de partisans de ce courant,
publis dans des revues spcialises dans ltude des organisations : Organization science,
91

Chapitre III : Stratgie de recherche : une approche par la pratique

Organization studies, Journal of organizational change, Journal of management studies,


Human relations, etc. Un site web, ddi au thme strategy-as-practice (www.strategyas-practice.org), a galement t dvelopp en vue de favoriser les changes sur le thme de
la fabrique de la stratgie. Aujourdhui, un rseau international de plus de 2000 membres
(praticiens et acadmiciens) constitue la communaut de strategy-as-practice connue
sous lacronyme (S-As-P).
Le courant de la fabrique de la stratgie aborde la stratgie non plus comme une
proprit des organisations mais comme quelque chose que les acteurs font au quotidien
travers leurs interactions (Whittington, 1996, 2003 ; 2006 ; Jarzabkowski, Balogun & Seidl,
2007). Les travaux qui sinscrivent dans le courant de la fabrique de la stratgie se sont
particulirement centrs sur les acteurs et leurs interactions avec leur environnement social.
La stratgie comme pratique renvoie ce que font les individus au quotidien (niveau
micro) et aux pratiques socialement dfinies (niveau macro) sur lesquels ils sappuient au
cours de leurs actions (Jarzabkowski, Balogun & Seidl, 2007). Des liens explicites sont ainsi
crs entre les actions situes des individus et les contextes institutionnels dans lesquels ils
agissent et auxquels ils contribuent (Jarzabkowski, Balogun & Seidl, 2007). La stratgie
comme pratique peut tre vue comme un souci dhumaniser la recherche sur le
management et les organisations en sintressant aux activits les plus fines des individus
qui ont un impact sur la stratgie de lorganisation (Jarzabkowski, Balogun & Seidl, 2007
dans Chanal, 2009). Avant daller plus loin et dexpliquer les raisons qui justifient notre
rapprochement de la perspective de la stratgie comme pratique , il apparat utile de nous
interroger sur les concepts cls qui fondent cette approche mergente : quest-ce quune
stratgie dans une perspective de la pratique et quest ce que le strategizing ? Qui sont
les stratgistes et que font-ils ?
1.1 Le strategizing : lintersection des pratiques, praxis et praticiens :
Dans une perspective de la stratgie comme pratique , la stratgie est conceptualise
comme une activit situe et socialement accomplie et le strategizing renvoie aux
actions, interactions et ngociations de multiples acteurs et aux pratiques situes sur lesquels
ils sappuient, qui a des consquences en termes de rsultats pour la direction et/ou la survie
de lentreprise (Jarzabkowski, 2005 ; Jarzabkowski, Balogun & Seidl, 2007). De ce point de
vue, toute activit peut tre considre comme stratgique dans la mesure o elle aura des
92

Chapitre III : Stratgie de recherche : une approche par la pratique

consquences sur lorientation de lentreprise. Afin de saisir le sens oprationnel des


concepts de stratgie et de strategizing , nous nous rfrons au modle conceptuel de
(Jarzabkowski, Balogun & Seidl, 2007) qui diffrencie les notions de pratiques ,
praxis et praticiens.
La praxis ou ce qui constitue la pratique de la stratgie, relve de linterconnexion entre
les actions des diffrents groupes et personnes et les institutions sociales, politiques et
conomiques travers lesquelles les individus agissent et auxquels ils contribuent. Pour Van
de Ven et Poole (1995), le concept de praxis fait rfrence au flux dactions,
doprations et dactivits qui permettent de faire voluer lorganisation de linstant (t)
linstant (t +1), dun tat (A) un tat (B) . La notion de pratiques au pluriel, quant
elle, renvoie aux divers types de ressources qui se combinent travers les pratiques :
procdures, ressources cognitives, motivationnelles, normes et outils utiliss et partags par
les individus pour faire de la stratgie (Jarzabkowski, 2011). Ces pratiques (la recherche des
ides, lidentification des opportunits, les routines 71, lcriture des documents formels, la
prparation des prsentations, etc.) sont considres comme une infrastructure travers
laquelle le processus de strategizing a lieu, engendrant un flux continu dactivits
stratgiques reprsent par la pratique ou praxis (Jarzabkowski, 2003). Enfin les
praticiens sont les acteurs qui font le lien entre la praxis et les pratiques . Ils possdent
un rpertoire de pratiques issues de leurs expriences passes et de leur environnement
(culture dentreprise, outils, rgles, etc.) sur lequel ils sappuient pour sengager dans
laction praxis . Il est utile de prciser que ces trois concepts sont interconnects. Il est
donc impossible dtudier un concept sans toutefois sintresser sur certains aspects des deux
autres (Jarzabkowski, Seidl & Balogun, 2007). Le strategizing est le point dintersection
entre la praxis , les pratiques et les praticiens. Si toute question de recherche fait
invitablement le lien entre ces trois aspects du strategizing , sur le plan empirique, les
recherchent se focalisent sur lune des trois zones dintersection (A, B ou C) (figure IV).

71

Les routines sont dfinies comme des modles rpts de comportement qui sont borns par des rgles et
des coutumes et qui ne changent pas beaucoup dune itration une autre (Feldman, 2000 dans Teulier,
2008).

93

Chapitre III : Stratgie de recherche : une approche par la pratique

P raxis : flux dactivits situes,


socialement accomplies qui,
stratgiquement, affectent la
survie du groupe, de
lorganisation ou de lindustrie.

Fabrique de la stratgie

C
P ratic ie ns : Les acteurs

P ratique s : les ressources


cognitives, procdurales,
discursives, motivationnelles et
physiques qui sont combines,
coordonnes et adaptes pour
construire la pratique.

qui influencent la
construction de la pratique
au travers de qui ils sont,
la manire dont ils
agissent, les ressources
dont ils disposent.

Figure IV: Parties constitutives de la fabrique de la stratgie


(Jarzabkowski, Seidl & Balogun, 2007)
Les tudes qui se situent dans la section (A) sintressent qui est le stratge et quelles sont
les pratiques quil mobilise dans sa pratique de la stratgie. Les recherches qui se trouvent
dans la section (B), lintersection des pratiques et de la pratique praxis , sintressent
ce que font les stratges. Quant aux recherches qui se situent dans la section (C), elles
sintressent la faon dont lidentit du stratge (cadre intermdiaire, les oprationnels,
etc.) peut influencer la pratique de la stratgie. Toutefois, ces tudes sont encore peu
nombreuses.
Larticle de Jarzabkowski (2005) par exemple, sest intress au rle des runions dans la
stabilisation et la dstabilisation des activits stratgiques des top managers . Pour ce
faire, lauteure sest focalise sur lanalyse des pratiques en sappuyant sur les thories
sociales de la pratique. Dautres chercheurs (Balogun & Johnson, 2005) ont abord
limplmentation dun changement stratgique dans de multiples divisions en sappuyant sur
la thorie du sensemaking. Afin de mener terme leur recherche, ils se sont focaliss sur les
activits de cration de sens des praticiens et sur leurs interactions sociales.
1.2 Qui sont les stratgistes et que font-ils ?
Pendant longtemps, la stratgie a t considre comme un processus de formulation topdown , rserv aux cadres suprieurs et dirigeants et spare de limplmentation. En
revanche, dans une perspective de la stratgie comme pratique , les cadres intermdiaires
94

Chapitre III : Stratgie de recherche : une approche par la pratique

et les oprationnels sont considrs comme des acteurs stratgiques importants. Bien que
leur rle stratgique ne soit pas formalis, celui-ci est significatif pour la survie de la firme et
sa comptitivit. De ce point de vue, il savre essentiel de sintresser aux connaissances
sociales, interprtatives et personnelles de ces acteurs travers lesquelles ils transforment la
stratgie (Balogun, 2003 ; Rouleau, 2005 ; Jarzabkowski, Seidl & Balogun, 2007). Dans une
mme optique, les acteurs se trouvant en dehors de lorganisation (prestataires externes,
clients, fournisseurs, etc.) semblent galement influencer mais indirectement, la stratgie de
lentreprise. Toutefois, peu de travaux empiriques ont trait, lheure actuelle, du rle de ces
acteurs et de la manire dont leurs identits professionnelles et leur engagement au sein de
lentreprise influencent la stratgie de cette dernire. Tout systme dactivit peut ds lors
tre compris travers lexamen de la manire dont les pratiques de management traduisent la
stratgie en pratique (Jarzabkowski, 2003).
Une question assez rcurrente dans les recherches centres sur la fabrique de la stratgie
concerne ce que font les stratgistes . Cette question se focalise sur le contenu de la
stratgie comme pratique ( doing ) et particulirement, sur la manire dont la
pratique ( doing ) modifie et transforme la stratgie. Se donnant pour objectif de
comprendre le contenu de la pratique , cette question est thoriquement soutenu par le
concept de pratiques exposs plus haut. Autrement dit, elle renvoie aux pratiques
spcifiques, situes, sur lesquels les praticiens sappuient quand ils font de la stratgie. Ainsi
la perspective de la fabrique de la stratgie va au-del de la classification des pratiques
spcifiques que les praticiens font (runions, outils analytiques, workshops, etc.) pour
sintresser comment ils les font, en mobilisant leurs savoirs situs et personnels. Afin
dillustrer ce propos, Jarzabkowski et ses collgues se rfrent aux chercheurs qui, en
voulant comprendre la conduite dune runion, se focalisent sur la manire dont les
interactions

discursives

et

les

intrts

manifests

par les

acteurs

transforment

laccomplissement social de la stratgie.


Une autre question courante dans les discussions menes sur la fabrique de la stratgie
est : quelle est la base thorique des recherches qui sinscrivent dans cette approche et
comment laligner avec les approches sociales et organisationnelles existantes ? Lintrt
central des tudes menes dans une perspective de la stratgie comme pratique est de
rpondre aux questionnements que nous avons poss au dbut de cette sous-section. Ce
courant ne requiert pas de nouvelles thories mais sappuient sur un ensemble de thories
95

Chapitre III : Stratgie de recherche : une approche par la pratique

existantes qui permettent dexplorer la stratgie partir de trois niveaux danalyse (praxis,
pratiques, praticiens) et davancer les explications sur comment la stratgie est accomplie en
utilisant ces diffrents niveaux danalyse. Lobjectif commun toutes ces tudes est
dexpliquer lintersection entre la praxis , les pratiques et les praticiens et ses
consquences au niveau de laccomplissement de la stratgie.
En ce qui concerne les mthodologie de recherche, certains auteurs sinscrivant dans le
courant de la fabrique de la stratgie (Samra & Fredericks, 2004 dans Jarzabkowski,
Seidl & Balogun, 2007) ont mis en avant les mthodes qualitatives comme
lethnomthodologie ou lanalyse conversationnelle pour analyser, de faon trs fine, le sens
des pisodes et des flux dinteractions des personnes impliques dans llaboration de la
stratgie, les discussions informelles, les ngociations et les usages des outils stratgiques.
Nous inscrivons ce projet de recherche dans le niveau danalyse (A) au sens de
(Jarzabkowski, Seidl & Balogun, 2007) pour nous intresser principalement aux
pratiques des praticiens et la manire dont ils organisent les mthodes agiles
pour aboutir des rsultats stratgiques au sein de leur organisation (amlioration de la
productivit des quipes, rduction des cots des processus de dveloppement, etc.). Nous
nous focalisons, ds lors, sur les ressources discursives, cognitives et comportementales
mobilises par ces praticiens. Ces derniers vont contribuer la construction des outils
agiles en fonction de qui ils sont et des caractristiques du contexte dans lequel ils se
trouvent. De fait, il nous a paru opportun de mobiliser la grille danalyse de sensemaking
(Weick, 1995) pour mieux comprendre comment les praticiens, par le jeu de leurs
interactions, de leurs expriences passes, identit organisationnelle, etc. font sens des
mthodes mergentes dites agiles et de leur contexte dapplication et par consquent
contribuent leur fabrication .
Lapproche danalyse par la pratique dans laquelle sinscrit ce travail vise analyser et
rendre compte du contexte social dans lequel la fabrique de la stratgie a lieu en se
focalisant sur les pratiques routinires des acteurs, leurs ressources motivationnelles,
discursives et cognitives mobilises et combines. Laction humaine est alors mise en avant
pour mieux comprendre le fonctionnement des groupes et les liens que ces derniers
entretiennent avec des structures plus larges que sont lorganisation et la socit.

96

Chapitre III : Stratgie de recherche : une approche par la pratique

2. Le modle du sensemaking
Le processus de sensemaking ou de cration de sens renvoie au processus social par lequel
les individus et les groupes, projets dans des interactions ininterrompues, construisent
socialement un sens de ce quils font et de ce quils peroivent des situations en cours
dachvement (Vandangeon-Derumez & Autissier, dans Autissier & Bensebaa, 2006). Le
sensemaking relve du contexte dans lequel une action est situe. Par consquent, pour
comprendre une action, il est important dapprhender les circonstances ayant contribu la
cration du sens et par la suite influenc laction mme.
Plusieurs chercheurs ont mobilis la notion de sensemaking pour tudier la manire dont les
individus et les collectifs font sens des phnomnes organisationnels et agissent en
consquence (Louis, 1980 ; Gioia & Chittipeddi, 1991 ; Sackman, 1991 dans Weick, 1995,
Weick, 1995). Si ces chercheurs saccordent sur la connotation du terme de sensemaking,
celui-ci a t abord sous diffrents angles dapproche. Meryl Louis (1980) offre une vision
plutt micro-cognitive du sensemaking o celui-ci est peru comme un processus de
rflexion qui sappuie sur des comptes rendu rtrospectifs permettant dexpliquer des
vnements imprvus. Il sagit dun cycle rcurrent compos dune squence dvnements
se droulant au fil du temps, conduit par les occasions de surprises72 . De ce fait, les
individus se trouvent confronts des vnements non conformes leurs attentes et
prdictions, dclenchant un besoin dexplication et dinterprtation des divergences
constates. Le sens ainsi attribu aux vnements est considr comme le rsultat du
processus de sensemaking, traduit en activits concrtes. Sackman (Sackman 1991 dans
Weick, 1995) voque le terme de sensemaking pour dsigner les mcanismes que les
membres organisationnels utilisent pour attribuer du sens aux vnements. Ces mcanismes
regroupent les rgles et les croyances mobiliss par les individus pour percevoir, interprter
et agir dans un contexte caractris par une culture organisationnelle spcifique. De ce point
de vue, les modles de rfrence des individus influencent la manire dont les vnements
sont perus et apprhends. La cration de sens reflte ainsi les aspects culturels de
lorganisation. Pour dautres chercheurs, le sensemaking relve dune interaction rciproque
entre la recherche dinformations, linterprtation et laction (Thomas, Clark & Gioia, 1993).
A ce titre, linterprtation en tant quactivit est place au cur du processus de
Il sagit de lcart entre les anticipations et les expriences subsquentes. Elles renvoient galement aux
ractions affectives dune personne lgard dun changement, dun contraste, dune diffrence. Les
surprises font partie des expriences de lindividu (Louis, 1980).
72

97

Chapitre III : Stratgie de recherche : une approche par la pratique

sensemaking. Le cycle de sensemaking dbute par la collecte dinformation (scanning). Cette


dernire prcde linterprtation et laction (Daft & Weick, 1984 dans Thomas, Clark &
Gioia, 1993). Sinscrivant dans une approche interprtativiste, Gioia et Chittipeddi (1991) se
sont focaliss sur les processus de sensemaking et de sensegiving des managers impliqus
dans la mise en place du changement stratgique. Si le sensemaking renvoie la manire
dont les individus pensent et attribuent du sens des vnements en cours, le sensegiving,
quant lui, vise donner un sens particulier au discours et influencer la manire dont
laudience peut percevoir les messages the process of attempting to influence the
sensemaking and meaning construction of others toward a preferred redefinition of
organizational reality (Gioia & Chittipeddi, 1991, p.442). Pour Schn, le sensemaking
relve de la manire dont les acteurs pensent au quotidien. Ces derniers sont investis dans
des pratiques quotidiennes dans lesquelles les problmes ne se prsentent pas comme tels
mais sont construits partir de situations ambiges et instables. Dans cette perspective,
Schn labore le schma suivant : poser le problme, slectionner ce qui va tre trait,
focaliser son attention dessus et identifier la cause problem setting is a process in which,
interactively we name the things to which we will attend and frame the cont ext in which we
will attend to them (Schn, 1983, p. 40 dans Weick, 1995). Quant au modle de
sensemaking de Weick, il a souvent t mobilis pour comprendre leffondrement du sens
dans les organisations et la capacit de celles-ci retrouver leur tat initial suite une
situation dambigit et dincertitude. Weick sest beaucoup intress lanalyse des
incidents catastrophiques (Weick & Roberts, 1993; Weick, 1993a) en vue dapprhender la
manire dont les organisations construisent du sens des situations de crise et nactent73
leur environnement de telle manire augmenter leurs capacits de rsilience 74.
Dans le cadre de cette thse, nous mobilisons le concept de sensemaking de Weick (1995)
pour comprendre comment les acteurs font sens des conditions dans lesquels ils se trouvent
et sengagent dans laction. Cependant notre travail ne concerne pas les situations de crise
mais plutt des situations problmatiques, moins extrmes, auxquelles les acteurs sont
confronts. A ce titre, la notion de problme ncessite dtre clarifie. Nous retenons la
dfinition de (Smith, 1989) o le problme renvoie une situation indsirable et
Ce concept connote lide quun organisme sadapte son environnement en agissant directement dessus en
vue de le modifier (Weick, 1979).
74
La rsilience est un processus dapprentissage et de dcouverte, tourn vers la prise en charge de limprvu,
tend rduire la dynamique temporelle de cet apprentissage une accumulation, un empilement ou un
rpertoire dexpriences passes (Wildavsky, 1988 dans Hollnagel ; Journ & Laroche, 2009).
73

98

Chapitre III : Stratgie de recherche : une approche par la pratique

significative pour un agent, pouvant tre rsolue par celui-ci. Les problmes reprsentent
donc une entit conceptuelle qui nexiste pas en tant que telle, mais qui renvoie une
relation non harmonieuse entre la ralit et les prfrences dune personne.
Alors qu lheure actuelle il nexiste pas doutils agiles de gestion de projet cls en
mains , les acteurs chargs de leur mise en uvre sont vraisemblablement confronts des
situations problmatiques diverses. Il est donc lgitime, de nous intresser aux pratiques
des acteurs partir desquels ils font sens des outils agiles et contribuent leur
construction et mise en uvre.
Le sensemaking organisationnel, au sens de Weick, rend compte de deux questions majeures
qui se posent au sein des organisations : whats the story here? et now what ? . Face
des vnements inintelligibles, les individus essayent de comprendre cest quoi
lhistoire ? . En sinterrogeant sur une situation donne, ils en font une situation existante et
en se posant la question and now what should i do? , ils attribuent une signification
cette existence.
Le point de dpart du sensemaking est donc labsence dordre intrinsque people
organize to make sense of equivocal inputs and enact their sense back into the world to make
the world more orderly (Weick, Sutcliffe & Obstfeld, 2005, p. 410). Le processus est
dclench par lattention accorde un phnomne inhabituel, congruent. Le sens se
construit partir dune indtermination qui surgit dans le flux dexprience. Les perceptions
des signaux ambigus relvent des expriences passes des individus, de leurs formations, etc.
Les individus vont donc extraire et isoler certains lments de leur contexte pour lesquels ils
vont donner un sens et donc un certain ordre. Les connaissances des individus leur
permettent de crer du sens des conditions rencontres et donc de rapporter des lments de
rponse aux situations problmatiques identifies. Weick voque le terme bracketing
pour dsigner lactivit dextraction dindices ou de cues de lenvironnement. Le
bracketing permet de simplifier la ralit en dlimitant le champ dintervention des
acteurs Notice that once bracketing occurs, the world is simplied (Weick, Sutcliffe &
Obstfeld, 2005, p. 411). Une tiquette ou un label est ainsi attribu(e) aux lments
reprs en vue dtre partage de faon collective. A ce stade, les acteurs procdent
linterprtation des vnements. Ils mobilisent leurs connaissances, leurs expriences passes
et leurs prdispositions personnelles pour expliquer les symptmes des situations et les
99

Chapitre III : Stratgie de recherche : une approche par la pratique

conditions dans lesquelles ils se trouvent. Toutefois, linterprtation des phnomnes ne se


limite pas seulement au lien entre les connaissances des individus et la situation concrte
mais relve aussi des relations sociales entre ces derniers.
Ainsi, le sensemaking rsulte des interactions, des changes dinformations, de coordination,
etc. Les motions, les sentiments, lintuition et limagination, identifies comme propices
lapprentissage contribuent galement la construction du sens. Les activits de cration de
sens des phnomnes conduisent les acteurs saccorder sur des formes de solutions et
dactions plausibles. A ce stade, les acteurs tentent de rpondre la question now what ?
travers leurs anticipations des vnements futures.
Lapproche organisationnelle du sensemaking de Weick permet de saisir comment les
acteurs organisationnels font sens de leur environnement et participent sa construction
partir des reprsentations quils se donnent de celui-ci.
Dans son modle, Weick propose daller au-del de lactivit dinterprtation de la ralit,
celle-ci tant une composante du processus de cration de sens. Linterprtation est dfinie
comme une forme dexplication ncessitant une connaissance particulire, une imagination,
une sympathie, etc. (Weick, 1995). Elle est se prsente comme une squence de collecte de
donnes (balayage des informations), dinterprtation, (attribution des significations aux
donnes) et daction (apprentissage). La premire tape (balayage de linformation) consiste
analyser lenvironnement travers une collecte de donnes qui serait neutre et objective.
Linterprtation consiste ainsi attribuer des significations aux donnes collectes et
lapprentissage intervient dans la dernire tape (Autissier & Bensebaa, 2006). Si
linterprtation renvoie un texte dj crit mais en attente dtre dcouvert, lactivit de
sensemaking, quant elle, concerne la fois la manire dont le texte est interprt et cr.
Llment cl qui diffrencie ces deux notions est donc la manire dont les gens procdent
pour dterminer ce qui sera soumis linterprtation. Afin de comprendre la manire dont
les individus engags dans de nouvelles histoires contribuent la cration de celles-ci,
nous prsentons les diffrentes proprits du sensemaking (Weick, 1995).

100

Chapitre III : Stratgie de recherche : une approche par la pratique

2.1 Les proprits du sensemaking


Dans ses travaux, Weick sest attard la description des diffrentes proprits du processus
de sensemaking.
Le contexte social : dans les crits de Weick, lunit danalyse est le groupe. Celui-ci
renvoie des individus projets dans des squences dinteractions au cours desquelles ils
crent un sens de leur environnement (Weick, 1995). Le contexte social constitue le matriau
dobservations des actions menes. Linteraction est le moment o les individus se
construisent une reprsentation des autres, deux mmes et de leur environnement
(Autissier& Bensebaa, 2006). La cration de sens se fait donc travers les interactions
interindividuelles influenant les comportements et les actions entreprises human thinking
and social functioning are essential aspects of one another (Weick, 1995, p.38). Le sens
cr nest pas uniquement subjectif mais aussi contraint par le contexte et les objectifs que
les acteurs visent atteindre (Daft & Weick, 1984 dans Gioia & Chittipeddi, 1991).
Lidentit : la cration de sens est ancre dans les multiples identits des individus et des
membres dun groupe. Lidentit individuelle concerne la question qui suis-je ? et
lidentit organisationnelle qui sommes-nous ? . La cration de sens est ainsi influence
par la personne que nous croyons tre et que nous voulons faire apparatre ainsi que par
lidentit organisationnelle et la manire dont celle-ci est reprsente. Dans un
environnement turbulent, les personnes sont amenes crer du sens afin de sorganiser et
dagir convenablement, de manire plausible. Toutefois, les actions refltent souvent les
reprsentations de ce qui se passe conformment avec ce que la personne souhaite tre ou
paratre. Lapproche de sensemaking sintresse la manire dont les individus construisent
le monde partir de ce quils sont. Les comportements des individus et leurs modes de
pense sont ainsi influencs et guids par leur identit individuelle et organisationnelle.
Cest partir de notre identit que slabore le processus par lequel nous donnons du
sens. Lidentit est constitu dune multitude de soi entre lesquels les individus circulent
(Vidaillet, 2003, p.40).
La rtrospection : le sensemaking met en valeur la rtrospection, la manire dont les
individus observent rtrospectivement les vnements passs en leur attribuant un sens. De
ce fait, les individus examinent rflexivement leurs propres actions pour dcouvrir le sens de
101

Chapitre III : Stratgie de recherche : une approche par la pratique

ce quils ont fait (Weick, 1979). Lide dernire la rtrospection drive de lanalyse des
expriences significatives vcues (Schutz, 1967 dans Weick, 1995). Weick et Schutz
postulent que lindividu ne peut pas donner un sens laction tant que celle-ci ne sest pas
produite. Les personnes ne se rendent pas compte de ce quils font quune fois le fait est
accompli How can i know what i think until i see what i say ? . La ralit est donc perue
comme un processus continu dindividus crant du sens rtrospectivement des situations
dans lesquelles ils se trouvent. En gnral, la rtrospection met laccent sur la manire dont
les actions ralises par les individus leur permettent de dcouvrir leurs prfrences,
principes, valeurs, croyances, etc. La rtrospection se nourrit de lcart entre les intentions
initiales et leur ralisation (Autissier & Bensebaa, 2006).
Lextraction dindices ou cues : dans une situation donne, les individus ont tendance
isoler des lments du flux des vnements. La focalisation sur certains morceaux de
lenvironnement se fait en fonction des schmas mentaux des individus et de leurs
expriences passes. Les schmas mentaux incarnent les moments passs de socialisation
tandis que les fractions des flux dexpriences renvoient au moment prsent. Si la personne
arrive faire le lien entre ces deux moments, le sens est ainsi cr the content of
sensemaking is to be found in the frames and categories that summarize past experience, in
the cues and labels that snare specifics in the present experience, and in the ways these two
settings of experience are connected (Weick, 1995, p.111). Les indices ou cues
permettent au chercheur de rendre compte de ce que les gens remarquent et donc didentifier
les points dentre ou input du processus de sensemaking.
La continuit : Afin de mieux comprendre le sensemaking, il est important de se rendre
compte de la manire dont les gens identifient les lments du flux continu dvnements
(Weick, 1995). Le sensemaking prsuppose que les individus et leur monde voluent de
faon continue. Dans cette perspective, la notion de fluidit des vnements prvale celle de
la stabilit.
La Plausibilit : le modle de sensemaking suppose que le raisonnement humain est guid
par la plausibilit plutt que lexactitude to deal with ambiguity, interdependent people
search for meaning, settle for plausibility and move on (Weick, Sutcliffe & Obstfeld, 2009,
p.409). En dautres termes, les individus ont tendance rduire les dissonances des
vnements en recherchant des explications plausibles, leur permettant davancer. Le
processus de sensemaking cherche dcrire la manire dont les choses sont plutt que la
102

Chapitre III : Stratgie de recherche : une approche par la pratique

manire dont elles doivent tre. Dans une masse dinformations complexes, il est important
de simplifier le rel afin pour pouvoir agir. De ce fait les individus sappuient sur des actions
qui leur paraissent plausibles et envisageables. Par consquent, laccord ne porte pas sur les
finalits mais sur les possibilits daccder aux moyens permettant la ralisation des
objectifs. La notion de plausibilit rejoint ici la notion de satisficing de Simon (1997). La
rationalit limite des agents ne leur permet pas de traiter lensemble des informations et
donc de calculer les consquences possibles de chacune des dcisions prises. Par consquent,
ils se contentent de choisir une solution leur permettant de rpondre leurs besoins et
aspirations sans toutefois rechercher la solution optimale.
Lactivation ou enactment : le sensemaking renvoie la manire dont les individus
enacte leur environnement (Weick, 1995) Enactement can be understood as acting
according to the specific understanding of the situation, which is believed to be true the
process of sensemaking is better understood by examining whats in peoples head and
imposed by them on a stream of events than by trying to describe what is out there (Weick
1979, p.271). Lenvironnement est peru comme socialement construit et interprt. Cette
perspective diffre des descriptions de lenvironnement en tant qulment concret, externe
lorganisation. Celui-ci est invent plutt que dcouvert. Les individus agissent ainsi en
fonction de leur comprhension de la situation quils estiment vraie. De ce fait,
lenvironnement ne simpose pas lindividu mais il est cr par celui-ci partir de ses
reprsentations et ses interprtations. De ce fait, lorganisation relve de processus continus
dinterrogation et de cration de sens raliss par des individus en interactions sociales.
2.2 Lorganisation apprhende comme un processus dorganizing
Dans la perspective du sensemaking, lorganisation est vue comme une tentative dorganiser
le flux intrinsque dactions humaines, de les orienter vers un certain but travers une
gnralisation et une institutionnalisation des rgles et des significations (Tsoukas & Chia,
2002). Les gens sorganisent pour crer du sens des situations quivoques et donc
reproduisent leur environnement en vue de le rendre plus organis organizing is directed
initially at inputs that are not self-evident, and, hence, organizing serves to reduce
equivocality (Weick, 1979, p.4).

103

Chapitre III : Stratgie de recherche : une approche par la pratique

Weick (1995) dfinit lorganizing comme une squence de changement de lenvironnement


impliquant lactivation, la slection et la rtention (figure V). Lactivation ou
l enactement concerne lactivit didentification d indices et leur attribution de
significations. La slection renvoie aux choix raliss entre les interprtations et les options
envisageables. Quant la rtention, elle consiste capitaliser sur les solutions slectionnes.
Le modle dorganizing s enchsse dans celui du sensemaking. De ce point de vue,
lorganisation merge travers le processus de sensemaking the operative image of
organization is one that emerge through sensemaking, and not in which organizations
emerge precedes sensemaking, or one in which sensemaking is produced by organization
(Weick, Sutcliffe & Obstfeld, 2005, p.10). Le sensemaking et lorganisation se co-construit
ainsi mutuellement.

Mise jou r continue

Changement
cologique

Activation

Extraction
rtrospective
dindices

Slection

Plausibilit

Rtention

Feedback de la slection et
lactivation

Figure V : Processus du sensemaking dans une organisation (Weick, 1995)

Synthse du modle de sensemaking


Le modle de sensemaking est une occasion pour tudier comment les individus, confronts
des situations problmatiques, crent progressivement du sens de celles-ci et mettent en
place des actions plausibles. De ce fait, les acteurs sappuient sur leurs connaissances et
expriences passes et mobilisent des ressources qui se trouvent leur disposition.
Cependant, diverses contraintes contextuelles influencent la manire dont le sens est
construit : lenvironnement physique immdiat, lenvironnement macro-organisationnel,
culturel, rglementaire, social, etc. Par ailleurs, les proprits caractrisant le processus de
sensemaking mettent en exergue cinq lments principaux : (1) la nature mergente et
continue de la ralit sociale, (2) la prise en compte des interactions et du contexte sociale
104

Chapitre III : Stratgie de recherche : une approche par la pratique

dans l'analyse des phnomnes organisationnels, (3) la nature rtrospective des actions
entreprises, (4) la plausibilit des actions mises en uvre par les individus et (5) lisolation
de faits contextuels, dclencheurs du processus de sensemaking (figure VI).

Interaction

Structure

Expriences

Situation
problmatique

Identit

Extraction des
faits ou cues

Cration de
sens/interprtation

Rgles

Formes daccords
sur des solutions

Actions
plausibles
Rsilience

Expriences
Formations

Prdispositions
personnelles

Ressources

Contexte

Figure VI : Grille danalyse du sensemaking

105

106

PARTIE II : DE LA FABRIQUE DUNE


INNOVATION MANAGERIALE : LA
CONSTRUCTION DUNE DEMARCHE
AGILE

La seconde partie est consacre lanalyse de la construction dune dmarche agile de


management de projet : le cas dune fabrique de stratgie agile .
Le chapitre (IV) prsente lorganisation dans laquelle sest droule ltude de cas et prcise
la mthode de recherche retenue.
Le chapitre (V) rend compte de nos observations et de nos analyses de ltude de cas ralise
durant 17 mois.
Le chapitre (VI) est centr sur la mise en discussion des rsultats danalyse.

107

Chapitre IV : Conduire une approche par la pratique

Ce chapitre se divise en deux sections.


Dans la premire section, nous prsentons lentreprise dans laquelle nous avons men une
tude longitudinale de 17 mois. Nous montrons comment la dmarche damlioration des
projets a t entreprise par lquipe responsable. Limplmentation de la dmarche lean a
fait lobjet de deux phases : une phase pilote (daot 2009 janvier 2010) et une phase de
gnralisation (de fvrier 2010 dcembre 2010).
Dans une seconde section, nous exposons et justifions notre mthodologie de recherche. La
collecte des donnes sest faite travers des observations semi-participantes et des entretiens
semi-directifs. Le corpus de donnes a t complt par des documents et des mails changs
entre les acteurs. Nous nous sommes appuys sur une dmarche inductive pour analyser
lensemble des donnes collectes.

108

Chapitre IV : Conduire une approche par la pratique

Nous avons men une tude de cas au sein dune direction, dun grand groupe franais
de tlcommunication, ayant dcid de mettre en place une dmarche damlioration de
modes de fonctionnement de ses quipes projets. Pour ce faire, elle sest base sur un
ensemble de principes et outils issus des mthodes agiles75 .
1. Prsentation plat du cas dentreprise tudi
Nous prsentons l les principaux lments de contexte organisationnel de lentreprise et du
chantier de management tudi. Nous reviendrons dans le chapitre suivant sur certains
lments essentiels de ceux-ci afin de les mettre en perspective dune analyse et dune
problmatisation relatives notre projet de recherche.
1.1 Description du contexte dtude
La direction des plateformes de services (DPS), dans laquelle sest droul ce travail de thse,
fait partie du groupe Orange, lun des principaux oprateurs de tlcommunication au monde
servant 209, 6 millions de clients dans 32 pays. Cet oprateur leader 76 (la 50me marque
mondiale) est implant dans plus de 220 pays sur les 5 continents. Il dveloppe et
commercialise des produits et services de tlcommunications divers : la tlphonie mobile
avec 150,4 millions de clients, le 3G haut dbit avec 33.5 millions de clients et linternet
ADSL avec 13.5 millions de clients. Son chiffre daffaires a atteint, en fin 2010, 45.5
milliards deuros.
Au sein du groupe, la direction de plateformes de services (DPS) a pour missions de
concevoir, dvelopper mettre en service et maintenir les plateformes qui supportent les offres
dOrange (le mobile, la voix sur IP, lOrange TV, l'administration des livebox, laccs
internet, etc.) pour toutes les units du groupe. Elle regroupe plusieurs directions
fonctionnelles qui contribuent au dveloppement et la livraison de ces plateformes : la
75

Par souci de clart, nous rappelons que nous avons dcid dutiliser le terme agile pour dsigner les
principes et outils issus des mthodes agiles et de lapproche de dveloppement lean.
76
World Television Market , dcembre 2010 et World Telecom Market , Janvier 2011.

109

Chapitre IV : Conduire une approche par la pratique

direction de dveloppement (DDP77), la direction de qualification (IEP 78), la direction


darchitecture, la direction de maintenance (DIM), la direction Nextv79 qui travaille pour la
tlvision ainsi que dautres directions travaillant sur des projets comme la tlphonie mobile,
la messagerie vocale, etc.
La direction Nextv, concerne par notre tude de cas, est responsable du pilotage et de la
livraison des produits de tlvision numrique par cble, satellite et sur le rseau IP. Elle
comprend environ deux cents acteurs mtiers (chefs de projet, architectes, managers de
composants, programmeurs, etc.) exerant leurs activits autour de la plateforme de la
tlvision en intervenant sur des projets placs sous sa direction soit sous la direction dautres
entits. Outre des acteurs internes, les projets pilots par la direction Nextv impliquent des
acteurs mtiers transverses rattachs dautres entits de la direction DPS (architectes
logiciels, dveloppeurs, qualifieurs techniques, qualifieurs fonctionnels, responsable de
maintenance, etc.), des acteurs mtiers externes la direction de plateformes de services mais
internes au groupe (marketing, R&D, mise en production, etc.) et des prestataires externes tels
que des fournisseurs de composants de logiciels. La figure (VII) illustre, de faon globale, la
structure organisationnelle de lentit investigue.

Groupe

Direction des plateformes de services


(DPS)

Marketing
R&D
RH Groupe
Communication

Entit Nextv
(200 collaborateurs internes godistribus)
Achat-vente
international

Equipe
lean

Achat-vente
international

Entits
transverses
Dveloppement
(DDP)
Qualification
(IEP78)

Autres entits
Architectes
Achat-vente
international

Achat-vente
international

Achat-vente
international

Concepteurs
Autres entits
Entreprise
prestataires

Figure VII : Structure macro-organisationnelle de lentit Nextv


77

Direction de dveloppement des plateformes


Intgration Et Performance
79
Next Television
78

110

Chapitre IV : Conduire une approche par la pratique

1.1.1 Cycle de vie des projets


Les projets sont conduits de manire squentielle et dcoups en jalons80. Ces derniers aident
au contrle de l'avancement des tches et constituent un moment dcisif pour la poursuite du
projet. Chaque jalon consiste en une ou plusieurs phases allant de ltude de lopportunit
lactivation et la gnralisation de la solution dveloppe (figure VIII).
Concevoir la
solution
tude
dopportunit
exploration

T-1

Conception
gnrale

T0

Que veut- Quest-ce que


lon fait
on faire

Offrir un
service
rgulier

Fabriquer la solution

Conception
dtaille

Dveloppement

Assemblage

T1 A

T0 A

Qualification

T2

On livre le
produit

Mise En
Production
(MEP)

Activation
Gnralisation

T1 X

T1

Comment
on le fait ?

Validation

On vrifie
le service

T3

On le vend

T-4

On fait le
bilan

Figure VIII : Cycle de vie des projets DPS


Le mode de gouvernance des projets mens DPS relve de trois acteurs principaux : le
marketing, le R&D et la direction DPS. La dfinition et la description des besoins du nouveau
produit ou service se fait par le marketing. Celui-ci va identifier les critres de contenu, de
qualit, de performance et fixer les cots de ralisation de la nouvelle solution. Quant au
dpartement R&D, il va effectuer un travail de prospection sur les nouvelles tendances
technologiques dans le but didentifier les solutions techniques les mieux adaptes pour
rpondre aux besoins du marketing. Enfin, la direction de DPS se charge de lindustrialisation
et du pilotage des solutions telles quelles ont t dfinies. Ces trois partenaires collaborent
ds la phase initiale du projet (phase T-1), durant laquelle les solutions correspondantes aux
besoins des clients sont bien identifies et chiffres. A ce niveau, plusieurs scnarios peuvent
tre proposs et soumis un comit de suivi des activits (CSA) qui prendra en charge la
validation du volume de ressources alloues par les directions contributrices. Laccord du
Les jalons dun projet se dfinissent comme des repres prdtermins et significatifs dans le cours du projet
(Norme Afnor X50-115).
80

111

Chapitre IV : Conduire une approche par la pratique

client (donneur dordre) et du CSA sur le document dengagement conduit la phase de


conception globale de la solution.
Durant cette phase (T0-T0A), les livrables attendus sont les spcifications gnrales, les
documents darchitecture technique et fonctionnelle (DAT et DAF), le rfrentiel dexigences
et la revue de jalon. Une deuxime version du document dengagement est ainsi rdige
conduisant la phase de conception dtaille. Au cours de cette dernire, les spcifications
sont crites en dtail, les documents darchitecture technique et fonctionnelle sont finaliss,
les dossiers dinterface, dingnierie et le plan de qualification sont initialiss et enf in le
planning et le budget sont actualiss.
La solution est ensuite dveloppe au cours des phases (T1-T1A) pendant lesquelles les
activits de qualification et dassemblage sont prpares. Il convient de noter que mme si le
plan de qualification est initialis entre le (T0 et le T1) il sera complt au fur et mesure de
lavancement du projet et en fonction des informations dont disposent les quipes (exigences
fonctionnelles et non fonctionnelles, cartographie, volutions des fonctionnalits, les risques,
la criticit, etc.). Les livrables attendus la fin de cette phase relvent dune version du
produit livr et dun bilan de tests unitaires. Ce nest quau niveau des phases (T1A et T2) que
lassemblage et la qualification sont raliss donnant lieu aux livrables suivants : documents
dinstallation, dexploitation et de supervision, rapports de qualification, scnarios et
stratgies de mise en production, bilan global des tests. La solution est alors teste et valide
avant dtre mise en production (T2).
Entre les phases (T2-T3), la solution est active techniquement et exprimente sur un
chantillon dutilisateurs. Les documents de support de formation, le bilan dexprimentation
et les documents dexploitation sont livrs la fin de cette phase. Ce nest quaprs une
priode de vrification du service rgulier (VSR) que la solution est lance sur le march
(T3). Au-del de cette phase la solution est prise en charge par les quipes de maintenance.
Un bilan global est ralis aprs une priode dobservation des ventes (phase T4).
Si le cycle de vie de projet est commun toutes les quipes de la direction Nextv, ces
dernires peuvent sappuyer sur des mthodes managriales diffrentes. A chaque direction
correspond un mode de fonctionnement adapt son propre contexte. Nous pouvons donc
retrouver des quipes de dveloppement travaillant en mode agile et dautres quipes
sappuyant plutt sur un cycle de dveloppement en V .
112

Chapitre IV : Conduire une approche par la pratique

En effet, le dveloppement de projets au sein de DPS renvoie une approche squentielle o


chaque phase est matrialise par un ensemble de livrables prdfinis. Les projets sont
habituellement dune longue dure (suprieur un an minimum) et impliquent un grand
nombre dacteurs.
Dune manire gnrale, dans un cycle de vie linaire, le dveloppement de la solution passe
de mtier en mtier refltant limage de course de relais. Cependant, dans le cas prsent, les
phases amont et aval peuvent se recouper. Certaines activits de laval sont, par exemple,
anticipes avant lachvement de celles de la phase amont. Les acteurs mtiers de la premire
peuvent tre impliqus sur dautres phases du projet en tant quacteurs secondaires et
travailleront en parallle sans ncessairement organiser leurs relations avec les acteurs en
amont. Prenons pour exemple la qualification. Si la ralisation effective de la qualification na
lieu qu la phase (T1A), la prparation des oprations de qualification (stratgies de
qualification initialise, plans de qualification) se fera entre (T0 et T1). Le tableau (9) donne
un aperu gnral de lintervention des acteurs principaux et secondaires dans les phases du
cycle de vie des projets conduits DPS.
Tableau 9: Intervention des acteurs mtiers dans le cycle de vie du projet
Phases
Acteurs

Phase
T-1-T0

Phase
T0-T0A

Marketing

R&D

quipes
darchitectes
quipe de
dveloppement
quipe de
qualification
quipe de
maintenance

Phase
T0A-T1

Phase
T1-T1A

Phase
T1A-T2

Phase
T2-T3

: acteur principal
: acteur secondaire

113

Chapitre IV : Conduire une approche par la pratique

1.1.2 Structure des projets


Lentit Nextv couvre lensemble du cycle du projet, de la prparation du T-1 jusquau T3,
tout en tant charge du support et de la maintenance. Pour monter un projet Nextv, le chef
de projet sollicite lexpertise de diffrents acteurs : acteurs mtiers travaillant au sein de son
entit (architectes, manageur de composant, programmeurs), acteurs transverses provisoires
(quipe de dveloppement, quipe de qualification, architectes, quipe de maintenance),
acteurs externes la direction des plateformes de services (marketing, R&D, support) et des
acteurs rattachs des entreprises prestataires. Lintervention temporaire des acteurs renvoie
linstabilit de lquipe pilote par le chef de projet. Au niveau des projets, ce dernier dispose
dune autorit hirarchique limite. Son rle est dassurer la coordination de diffrentes units
fonctionnelles impliques dans un projet et de veiller la ralisation des objectifs dans les
limites temporelles et budgtaires prdfinies. Les projets sont ainsi dvelopps dans une
structure lightweight selon la terminologie de Clark et Wheelwright (Clark et Wheelwright
dans Midler, 1993). La figure (IX) illustre la structure dune quipe projet pilote par lentit
Nextv.
DPS

Coordinateur de
projet Nextv

DDP

IEP

Architecture

Autres directions
mtiers

Chef de projet
dveloppement

Chef de projet
Qualification

Chef de projet
architecte

Chefs de projet
mtiers

Dveloppeurs

Qualifieurs
techniques

Architectes
fonctionnels

Acteurs mtiers sur


le projet

Liaison non hirarchique


Prestataires externes

Figure IX : Structure de type lightweight

114

Chapitre IV : Conduire une approche par la pratique

1.2 Mise en place de la dmarche lean


Le dpassement des budgets allous aux projets, le non respect des dlais initialement fixs et
la non-conformit des produits aux attentes des clients ont amen la direction de lentit
Nextv remettre en question le mode de fonctionnement de ses quipes. Pour ce faire, elle a
dcid de mettre en place une dmarche damlioration des modes de management de projet
quelle qualifiera de projet lean . Ce dernier est n de lintime conviction du directeur
gnral quant lefficacit de la dmarche lean et la lourdeur des autres mthodes
damlioration (CMMI 81 ou DMAIC82 titre dexemple). Par ailleurs, durant cette mme
priode, le lean management tait appliqu avec succs sur les centres dappel et les services
aprs ventes du groupe ce qui aurait pu galement influencer la dcision de la direction
gnrale. Le lancement du projet lean a t officialis lt 2009. Il visait la totalit des
collaborateurs de lentit Nextv (approximativement 200 acteurs internes). Sa ralisation a t
confie une quipe, qui sest attribue le nom dquipe lean , compose initialement,
dun coach, spcialiste kaizen, charg daccompagner les membres de lquipe, dun
responsable qualit, dsign directeur du projet lean et de trois personnes slectionnes
par leur management. Toutefois, au cours du projet lean , un apprenti a t recrut en vue
dassister lquipe dans la mise en place de la dmarche. En outre, un directeur de projet a
rejoint lquipe alors quun autre membre labandonnera quelques semaines plus tard. Le
tableau (10) dresse le profil des acteurs et leurs rles respectifs dans la dmarche
damlioration.
Tableau 10: Profil des membres de l'quipe lean
Profil des acteurs

Rle des acteurs au sein de la dmarche

Senior performance manager, spcialiste kaizen

Coach accompagnateur de lquipe (RB)

Responsable qualit du programme TV Nextv

Directeur du projet lean (TR)

Responsable du ple HPM pays

Porteur dactivits sur le plan oprationnel (JP)

Responsable CPM IPTV

Porteur dactivits sur le plan oprationnel (ER)

Directeur de projets Easy TV

Porteur dactivits sur le plan oprationnel (DT)

Directeur de projet

Porteur dactivits sur le plan oprationnel83 (DF)

Apprenti sur la dmarche lean

Assistant du directeur de projet (QR)

81

Capability Maturity Model Integration. Il sagit dune approche damlioration de la qualit des logiciels.
Cest un acronyme dune mthode damlioration de la qualit qui consiste en cinq tapes : Dfinir, Mesurer,
Analyser, Innover et Contrler.
83
Il convient de prciser que cette personne a abandonn le projet quelques semaines aprs son lancement.
82

115

Chapitre IV : Conduire une approche par la pratique

Afin de se familiariser avec cette nouvelle dmarche managriale, les membres de lquipe
ont suivi, au sein du groupe, une formation de quelques jours sur le lean management. Cette
formation a consist leur expliquer les principes du lean management et la manire dont le
lean fut appliqu au niveau des centres dappels du groupe. Par ailleurs, les acteurs lean se
sont galement appuys sur des articles et prsentations traitant du lean dans les industries de
logiciels et des mthodes agiles de management de projet informatique.
La dmarche entreprise au sein de Nextv se fonde sur quatre principes fondamentaux :
llimination du gaspillage, la simplification des modes de fonctionnement des quipes, la
gnralisation des meilleures pratiques et la standardisation. La dmarche a t prsente, aux
quipes projets de lentit, comme un changement dun tat desprit visant lamlioration
continue.
Nous recherchons ensemble en permanence lamlioration dans nos faons de travailler
et la mettons en uvre au sein de lquipe (TR).
Dans cette perspective, lquipe lean sest lance dans la dfinition et le dveloppement
des pratiques et outils managriaux permettant de rpondre aux enjeux de la direction. Les
pratiques retenues relvent, des mthodes agiles et des principes et outils du lean
management. Le tableau (11) synthtise les diffrents outils et principes sur lesquels lquipe
lean sest base pour mener bien sa dmarche.
Tableau 11: Principes et pratiques adopts dans la dmarche lean
Principes et outils bass sur les mthodes
agiles
(Beck & Andres, 2004 ; Schwaber, 2004)

Principes et outils bass sur le lean


thinking
(Poppendieck, 2006)

Daily brief de type stand-up meeting ou


daily scrum

Principe damlioration continue : ateliers


kaizen, PDCA, QQCQOP, 5 Pourquoi

Partage virtuel des story-boards et des


indicateurs de performance

Principe dempowerment des oprationnels et


respect des personnes

Limplmentation de la dmarche lean a fait lobjet de deux phases: une phase pilote
(daot 2009 janvier 2010) visant tester et vrifier la faisabilit de la dmarche sur un
nombre limit dacteurs projets et une phase de gnralisation (de fvrier 2010 dcembre
2010).
116

Chapitre IV : Conduire une approche par la pratique

Durant la phase pilote, sept quipes ont t retenues : trois quipes mtiers qui font partie de
lentit Nextv (architectes, chefs de projets, manageurs de composants) et quatre quipes
projets pilotes par celle-ci. Les projets slectionns se trouvent des niveaux davancement
diffrents (tableau 12).
Tableau 12: Projets pilotes retenus
Projets retenus

Phase davancement

R3PC

Projet en phase de dmarrage

FTTH

Release 1.0

ZE R2

Projet en phase dassemblage / qualification

R3ZNE

Projet en phase dassemblage / qualification

Au total, trente personnes, travaillant uniquement au sein de lentit Nextv mais sur diffrents
sites gographiques (Paris, Rennes, Blagnac, Guyancourt) ont t concernes par cette phase
pilote mene sous formes dateliers.
La premire tape a dbut par la mise en place dateliers de remontes de
dysfonctionnements sur diffrents sites gographiques (Paris, Rennes, Blagnac, Guyancourt).
Ils avaient pour mission dexpliquer lobjectif et lutilit de la dmarche lean et faire
remonter les problmes majeurs rencontrs au cours des projets. Ces ateliers ont galement
t loccasion de former les participants aux outils 84 danalyse de dysfonctionnements adopts
par lquipe. Par consquent, quatre ateliers orients projet et trois ateliers orients mtiers
ont t mis en place. Nous avons, de notre ct, assist cinq ateliers de remontes de
dysfonctionnements.
Lors de la deuxime tape de la phase pilote, des rendez-vous dinformation ont t
organiss, cette fois ci, avec lensemble des membres de lentit Nextv. Leur but est de
sensibiliser les acteurs aux enjeux et objectifs du projet lean , de les tenir aux courant par
rapport lvolution de la dmarche et de rpondre leurs questionnements. Des runions
complmentaires ont t organises avec le Codir auxquelles nous navons pas t convies.
Ces runions avaient pour objectifs de discuter et de valider les dysfonctionnements traiter
et les plans daction mettre en place (tableau 13). Parmi les 98 dysfonctionnements
identifis dans les premiers ateliers, seuls huit ont t retenus en vue dtre traits
84

Cf. tableau (11).

117

Chapitre IV : Conduire une approche par la pratique

collectivement. Nous reviendrons infra sur les raisons qui expliquent le choix de ces
dysfonctionnements.
Plusieurs runions avec les chefs de projet ont succd aux ateliers de remontes de
dysfonctionnements. Ces runions se sont donnes pour objectifs de recueillir les feedback
par rapport la dmarche et son adaptabilit au contexte des projets. Enfin, lors de la
dernire tape de cette phase pilote un bilan de projet lean a t tabli et prsent au
Codir.
Tableau 13: Plans d'actions valids par le Codir
Plans daction

Mtier concern

Proposer un plan de formation cibl pour les chefs de projets

Chef de projet

Identifier les informations ncessaires pour la prise de dcision aux


passages de jalons : prciser les documents ncessaires et leur contenu

Chef de projet

Dfinir les acteurs, leurs rles et responsabilits

Chef de projet

Atelier en commun avec R&D afin daligner les jalons DPS et R&D pour
le projet R3PC

Chef de projet

Compltude et pertinence de la documentation des composants du projet


R3 : quantification des charges (prparation, rdaction, lecture) lies la
documentation du projet R3PC et identification des documents inutiles ou
incomplets

CPM

Proposer un processus ou outillage adapt la gestion technique des


composants TV

CPM

Proposer une mthode et des critres simples permettant de rguler la


demande et de dcider rapidement le lancement ou non dune tude

Architecte

Dcrire les livrables attendus de la part des acteurs (architectes, Cdp) et


prciser les informations importantes pour la prise de dcision au jalon
T-1-T0.

Architecte

En ce qui concerne la phase de gnralisation du projet (de fvrier 2010- dcembre 2010),
de nouvelles units fonctionnelles, externes lentit Nextv mais internes la direction de
plateformes de services (DPS), ont t convies intgrer la dmarche. De nouveaux plans
dactions ont ds lors t dvelopps impliquant, cette fois, des acteurs externes lentit
Nextv : le marketing, qualification, dveloppement. De nouvelles runions et formations ont

118

Chapitre IV : Conduire une approche par la pratique

t mises en place pour initier les nouveaux arrivants aux outils 85. Des entretiens additionnels
ont t galement mens auprs de ces acteurs en vue damliorer ladaptabilit de la
dmarche en fonction de leur contexte.
La figure (X) montre le droulement de la dmarche entreprise par lquipe lean .

Pre-dmarrage

Phase Pilote

Identification des quipes


pilotes : 3 quipes mtiers et
4 quipes projets (5 8
personnes/quipe).

Lancement du projet
lean par la direction

Mise en place de la
dmarche au niveau des
quipes pilotes et bilan de la
phase pilote
Juin 2009-Aout 2009

Septembre2009- Janvier 2010

Gnralisation

Implication de nouvelles
quipes dans la dmarche : le
marketing, les responsables
des quipes de
dveloppement, la
qualification.

Fvrier 2010-Dcembre 2010

Figure X : Droulement du projet lean


2. Dmarche dinvestigation
Notre dmarche qualitative mobilise un ensemble de techniques de collecte et danalyse de
donnes permettant didentifier, de comprendre et dinterprter les vnements dans leur
contexte. Dans la partie qui suit, nous exposons, tout dabord, notre choix dtude
longitudinale et les sources de donnes ayant contribu la construction de notre cadre
empirique. Ensuite, nous prsentons la manire dont nous avons procd pour analyser
lensemble des donnes rassembles
2.1 Choix dune tude longitudinale
Notre tude de cas obit aux caractristiques dun processus de recueil longitudinal (Forgues
& Vandangeon-Derumez, 2003 dans Stake, 1995) : (1) les donnes collectes relvent de

85

Cf. tableau (11)

119

Chapitre IV : Conduire une approche par la pratique

deux priodes distinctes, (2) elles nous permettent de retracer lvolution du cas investigu et
(3) les sujets observs sont comparables dune priode lautre.
Nous avons pass dix sept mois sur le terrain de recherche. La focalisation sur un cas
particulier nous a permis de situer le phnomne dans son contexte spcifique, caractris
dun ct, par des conditions physiques, techniques et organisationnelles bien particulires et
de lautre, par des acteurs en interaction, dterminant et donnant sens leurs activits. Le but
ultime de notre tude longitudinale consiste procurer une description riche des situations
sociales, de faire tat des significations et du sens que leur attribuent les acteurs et
dapprhender, en profondeur, le contexte dans lequel les vnements y prennent place. Une
prsentation synthtique de notre tude longitudinale est illustre dans la figure (XI).
Phase Pilote

Gnralisation

Participation aux runions


des membres de lquipe
lean : 23 runions
(Paris+tlphone)

Participation aux runions


des membres de lquipe
lean : 14 runions
(Paris+tlphone)

Pre-dmarrage

Prise de contact avec


lquipe charge du
projet lean

Participation 5 ateliers de
remontes de
dysfonctionnements
(Paris+Guyancourt+tlpho
ne) et 3 sessions de
rendez-vous
dinformation

Participation 2 ateliers de
formation (Paris)

2me vague dentretiens : 16


entretiens avec les acteurs
internes et externes
lentit Nextv et 1 entretien
avec le directeur du projet
lean (Paris+tlphone).

-1re vague dentretiens : 5


entretiens avec les chefs de
projets et 1 entretien avec le
directeur du projet
lean (Paris+ tlphone).
Juin 2009-Aout 2009

Septembre 09- Janvier 2010

Fvrier 2010-Dcembre 2010

Figure XI : tude longitudinale


2.2 Procds de collecte de donnes
La recherche empirique est alimente par diverses sources de collecte de donnes :
documentation, enregistrement des archives, entretien, observation directe, observation
participante et simulation (Yin, 1990). Le choix entre ces multiples sources de donnes
dpend tant de lobjet de la recherche que des possibilits offertes par le terrain investigu.
120

Chapitre IV : Conduire une approche par la pratique

Dans le cadre de ce travail, nous avons men des observations semi-participantes au sein de
lentit et conduit des entretiens semi-directifs avec diffrents profils dacteurs. Des
documents et prsentations ont galement t collects et analyss.
2.2.1 La technique de lobservation semi-participante
Dune manire gnrale, la prsence du chercheur sur le terrain peut se manifester sous deux
formes dobservation : participante, lorsque le chercheur occupe un rle dacteur au mme
titre que les personnes observes et passive lorsque le chercheur est autoris dtre prsent
dans lorganisation pour regarder la ralit quotidienne, assister aux vnements pour les
enregistrer et les analyser (Wacheux, 1996, p.215).
Notre dmarche empirique repose sur une observation semi-participante qui nous a permis
denrichir considrablement lanalyse et linterprtation des activits discursives des acteurs.
Le recours lobservation directe constitue un moyen efficace pour tudier la faon dont se
fabrique une stratgie agile . Si notre prsence sur le terrain de recherche fut en grande
majorit passive , nous avons nanmoins t amens, plusieurs reprises, partager nos
points de vue et expriences avec le groupe dacteurs observs. Les observations ont dbut
avec le lancement du projet lean . Nous avons particip trente sept runions, au total,
ddies la construction et la mise en uvre de la dmarche. Durant ces runions, nous
avons t sollicits pour rpondre un certain nombre de questions concernant les outils
agiles et la manire dont ils sont habituellement appliqus 86.
Les tableaux (14) dcrit, par ordre chronologique, les objectifs des runions ralises et
auxquelles nous avons particip, ds le lancement du projet. Outre les notes de synthse prises
la fin de chaque runion, le suivi de mails changs entre les acteurs avant les runions nous
a permis de mieux cerner le contenu de celles-ci et leurs principales vises.

Les questions poses par lquipe lean concernent les mthodes agiles , les enseignements et les
prconisations souligns dans la littrature.
86

121

Chapitre IV : Conduire une approche par la pratique

Tableau 14 : Tableau descriptif des runions ralises


Runions

Date

Dure

27 Aout 2009

7 heures

28 Aout 2009

5 heures

4 Septembre 2009

1 heure

14 Septembre 2009

2 h30 min

25 Septembre 2009

2 heures

2 Octobre 2009

3 heures

13 Octobre 2009

1 heure

-Finaliser la proposition de la dmarche lean sur


deux projets pilotes (R2ZNE) et (R3PC)
-Prparation du reporting pour le Codir
-Finalisation de la lettre dinformation (n1)

16 Octobre 2009

1 h30 min

-Prparation du support de prsentation des runions


quotidiennes de type daily-brief

20 Octobre 2009

1 h30 min

22 Octobre 2009

1 heure

23 Octobre 2009

1 h30 min

2
3
4
5
6
7

10
11

Objectifs
-Orientation du sens de la dmarche
-Identification des quipes pilotes
-Prparation des ateliers de remontes de
dysfonctionnements
-Prparation des entretiens mener auprs de chefs
de projets pilotes
-Retour dexpriences sur les entretiens mens avec
deux chefs de projets pilotes
-Retour sur les ateliers de remontes de
dysfonctionnements mens
-Prparation de la prsentation pour le Codir
-Prparation de la lettre dinformation (n1)
-Retour sur la prsentation du Codir
-Construction des outils de la dmarche lean
-Construction des outils de la dmarche lean
(runions quotidiennes, KPI)

-Prparation du rendez vous dinformation sur la


dmarche lean
-Suivre les plans daction en cours
-Partage des rsultats et validation

12

-Prparation de la lettre dinformation (n2)

30 Octobre 2009

1 h00 min

13

-Retour sur les sessions de rendez-vous dinformation


-Retour sur le lancement des runions quotidiennes
(daily brief)
-Prparation de la lettre dinformation (n3)

6 Novembre 2009

1 h30 min

14

-Partage des rsultats des actions en cours

20 Novembre 2009

1 heure

15

-Suivre lavancement des chantiers

24 Novembre 2009

1 heure

16

-Prparation de la prsentation pour le Codir

27 Novembre 2009

1 heure

-Bilan sur les daily briefs mis en place au niveau


du projet R3PC
-Bilan sur les daily briefs mis en place au niveau
de lquipe mtier CPM
-Retour sur un entretien men avec un scrum
manager dune quipe de dveloppement

1er Dcembre 2009

1 h30 min

4 Dcembre 2009

1 heure

9 Dcembre 2009

3 heures

18 Dcembre 2009

1 h30 min

17
18
19
20

-Partage dexpriences dune personne chez


Motorola ayant mis en place des pratiques agiles

122

Chapitre IV : Conduire une approche par la pratique

21

22

23
24
25

-Bilan des plans daction 2009


-Prparation de la lettre dinformation (n4)
-Prparation de la synthse du bilan
-Identification de difficults rencontres
-Prparation du plan de dploiement 2010
-Mise en forme de la prsentation au Codir
-Finalisation de la lettre dinformation (n4)
-Retour sur la runion avec le Codir
-Prparation du plan de gnralisation 2010
-Prparation de la lettre dinformation (n5)
-Prparation des sessions de formations sur la
dmarche lean
-Revoir et finaliser le contenu et la prsentation des
sessions de formation

8 Janvier 2010

1 heure

14 Janvier 2010

6 heures

29 Janvier 2010

1 h30 min

17 Fvrier 2010

1 h30 min

2 Mars 2010

1 heure

26

-Retour sur les formations mises en place

26 Mars 2010

45
minutes

27

-Planification et prparation des nouvelles sessions


de formation
-Prparation de la lettre dinformation (n6)

2 Avril 2010

1 heure

28

-Prparation du reporting mensuel pour le Codir

16 Avril 2010

1 h30 min

29

-Finaliser la lettre dinformation


-Prparation de nouveaux plans daction mettre en
uvre (intgration des tests unitaires au niveau de la
qualification)

23 Avril 2010

1 h30 min

30

-Retour sur la lettre dinformation


-Prparation des prochaines sessions de formation

30 Avril 2010

1 h30 min

28 Mai 2010

2 heures

16 Juin 2010

1 heure

8 Juillet 2010

1 h30 min

6 Octobre 2010

1 heure

31
32
33
34

-Prparation du bilan du premier semestre


-Prparation des entretiens raliser avec les
managers dquipe
-Retour sur les entretiens raliss avec les managers
dquipe
-Prparation et validation du bilan du premier
semestre
-Prparation pour le semestre 2
-Partage de lavancement des actions et propositions
futures

35

-Point sur lavancement de la dmarche

14 Octobre 2010

1 heure

36

-Prparation du bilan 2010


-Prparation des entretiens mener avec des
membres de diffrentes directions (DDP, IEP, Nextv)

24 Novembre 2010

1 heure

37

-Retour sur les entretiens raliss


-Premier trame du bilan 2010
-Perspectives 2011

15 Dcembre 2010

1 h30 min

123

Chapitre IV : Conduire une approche par la pratique

Au-del des runions, nous avons galement assist des ateliers conduits par les acteurs
lean (tableau 15). Durant ces ateliers, nous avons adopt une attitude passive (en
posture dobservation) et, dans une perspective ethnographique, nous nous sommes contents
de transcrire les vnements et de noter nos impressions concernant les situations observes.
Tableau 15 : Ateliers organiss par lquipe lean
Types dateliers

Acteurs concerns

Nombre de
participants

Dure

Atelier de remontes de
dysfonctionnements (1)

Acteurs intervenant dans


le projet R2ZNE

6 participants

3 heures

Atelier de remontes de
dysfonctionnements (2)
Atelier de remontes de
dysfonctionnements (3)
Atelier de remontes de
dysfonctionnements (4)
Atelier de remontes de
dysfonctionnements (5)

Membres des quipes


(CPM87)

5 participants

2 h30 min

Architectes

5 participants

2 h30 min

Chefs de projets

5 participants

3 h00 min

3 participants

2 h30 min

6 participants

13 heures

Atelier de formation (1)

Acteurs intervenant dans


le projet R3PC
Membres des quipes
(CPM)

Atelier de formation (2)

Architectes

6 participants

13 heures

3 runions de rendezvous dinformation

Lensemble des membres


de lentit Nextv

Environs 30
personnes/session

1 heure/session

2.2.2 Technique de lentretien semi-directif


La ralisation des entretiens semi-directifs avec les acteurs concerns par le projet lean
constitue la seconde source de collecte de donnes sur laquelle repose notre dmarche
qualitative.
Dans un premier temps, cinq entretiens ont t conduits avec des chefs de projets. Lensemble
de ces entretiens a t enregistr. Par mesure de confidentialit, nous prsenterons les
entretiens travers des extraits (verbatim) et ne relverons pas les noms des personnes
interviewes. Les personnes seront identifies par deux lettres et leur rle au sein de
lorganisation sera prcis. Ces entretiens consistent dune part, faire tat du contexte dans
lequel uvrent les chefs de projet (les pratiques et outils managriaux utiliss, forme

Le rle du CPM consiste coordonner lvolution des composants ou briques applicatives qui assurent un
certain nombre de fonctionnalits (briques qui servent de portail pour les utilisateurs, qui font linterface avec
des applications de facturation, de commande, etc.). La mobilisation dun mme composant par diffrents
services ou plateformes ncessite un suivi rgulier de la part du CPM qui, lui, va veiller ce que le composant en
question a suivi les mmes volutions sur les diffrentes plateformes.
87

124

Chapitre IV : Conduire une approche par la pratique

organisationnelle de la gestion de projet, la composition des quipes projets, le rle du chef de


projet, etc.) et dautre part, reprer leurs perceptions lgard des outils managriaux
retenus par lquipe lean . Ils constituent un moyen essentiel pour accder aux
reprsentations et interprtations des situations par les acteurs. Les perceptions et les
expriences soulignes par les interviews nous ont permis dapprofondir notre
comprhension de certains lments peu divulgus durant les observations. Ensuite, un
entretien a t conduit, cette fois-ci avec le directeur de lquipe lean . Cet entretien avait
pour objectif dapprofondir certains aspects lis la dmarche et dclairer les subtilits du
contexte et des actions entreprises. Le nombre limit dentretiens avec les acteurs lean
sexplique par les changes et les discussions informelles que nous avons continuellement
mens avec eux.
Ensuite, durant la phase de gnralisation, nous avons ralis une seconde vague dentretiens,
cette fois-ci avec des acteurs internes et externes lentit Nextv. Nous avons interview des
architectes, des directeurs et des chefs de projets, des managers dquipes de dveloppement
et de qualification. Plus de la moiti des acteurs interrogs na pas fait partie de la phase pilote
de la dmarche. Ces entretiens visaient dune part, dvelopper une image assez prcise des
modes managriaux adopts par les quipes ; et dautre part, identifier les perceptions de ces
quipes de la dmarche propose par les acteurs lean et de leur collaboration entre elles.
Ces entretiens ont t conduits en prsence dun membre de lquipe lean . 16 entretiens
ont t conduits durant cette seconde phase du projet lean .
Au total 21 entretiens dune dure moyenne dune heure et demie ont t raliss (tableau 16).
Tableau 16 : Recension des entretiens raliss
Acteur

Entit

Fonction

AM

DDP (Dveloppement)

Directeur de projet R&D sur les services TV

JPR

DDP (Dveloppement)

Manager dquipe de dveloppement

CM

DDP (Dveloppement)

Manager dquipe de dveloppement

PC

DDP (Dveloppement)

Manager dquipe de dveloppement

FB

DDP (Dveloppement)

Scrum manager

PM

IEP (Qualification)

Responsable dquipe de qualification


125

Chapitre IV : Conduire une approche par la pratique

JF

IEP (Qualification)

Responsable du domaine dintgration

FB

Entit Nextv

Directeur technique des plateformes de services


TV

GC

Entit Nextv

Directeur technique du projet trs haut dbit

LM

Entit Nextv

Chef de projet rattach la direction technique

RM

Entit Nextv

Chef de projet rattach la direction technique

OC

Entit Nextv

Directeur de projet (Direction Solutions TV)

OD

Entit Nextv

Directeur de projet (Direction solutions TV)

JFR

Entit Nextv

Chef du dpartement design center rattach


direction Solutions TV

PLP

Entit Nextv

Directeur de projets (Direction Grands projets)

DN

Entit Nextv

Chef de projet (FTTH) rattach la direction


Grands projets

CR

Entit Nextv

Chef de projet (R2ZNE) rattach la direction


Grands Projet

PD

Entit Nextv

PB

Entit Nextv

MC

Entit Nextv

JMW

Entit Nextv

Chef de projet (ZER2) rattach la direction


Grands Projet
Chef de projet (R3PC) rattach la direction
Grands Projet
Chef de projet (ZER2) rattach la direction
Grands Projet
Program Management Officer

2.2.3 Sources secondaires de recueil de donnes


Les documents et les discussions changes par ml constituent une source complmentaire
de donnes nous permettant dapprofondir nos connaissances relatives notre contexte
dtude. En effet, nous avons pu avoir accs (1) aux prsentations rdiges par les membres
de lquipe lean et diffuses auprs des quipes pilotes, (2) aux rapports de runions
organiss par lquipe lean avec le Codir, (3) lensemble des mails changs entre les
membres de lquipe et ce, ds le lancement du projet. Notre prsence sur la liste de diffusion
de lquipe lean nous a permis de suivre en temps rel les questionnements des acteurs,
leurs proccupations, leur raisonnement, etc.

126

Chapitre IV : Conduire une approche par la pratique

2.3 Choix dune mthode danalyse thmatique


Bien quil nexiste pas de moments particuliers pour commencer lanalyse des donnes, il est
communment admis de se baser sur une approche mthodique bien prcise afin de traiter les
donnes collectes et daccrotre la validit des rsultats. Les donnes qualitatives engendrent
des descriptions et des explications riches. Leur analyse consiste, tout dabord, rduire les
informations pour les catgoriser, les mettre en relation, avant daboutir une description,
une explication ou une configuration (Wacheux, 1996, p.227).
Si la dmarche danalyse a commenc ds notre intgration sur le terrain de recherche,
lorganisation et la catgorisation des donnes sest faite aprs la collecte et la retranscription
de celles-ci. Les retranscriptions ont t ralises au fur et mesure de nos observations. Un
fichier de synthse a t labor la fin de chaque observation restituant les informations
essentielles des vnements observs (date, participants, thmes, principaux lments
voqus, etc.). Ces fichiers comprennent galement nos intuitions et impressions gnrales
des phnomnes observs (Annexe XI-XII).
Lhistorique des vnements a t dvelopp au fur et mesure de lavancement du projet. La
prsentation chronologique des donnes nous a permis davoir une comprhension
progressive des phnomnes et du contexte apprhend. Ensuite, nous avons procd
lanalyse thmatique des donnes collectes et transcrites : thematic analysis refers to the
process of analyzing data according to commonalities, relationships and differences across a
data set. The word thematic relates to the aim of searching for aggregated themes within
data (Gibson & Brown, 2009, p.127). Nous avons opr par mthode inductive. Les ides
auxquelles renvoie(nt) chaque mot, phrase et/ou paragraphe du corpus de donnes ont t
identifies pour ensuite tre classes par catgories 88 puis par thmes. Le principe de lanalyse
thmatique consiste aboutir une dcontextualisation-recontextualisation du corpus des
donnes collectes.
Concrtement, comment avons-nous procd lanalyse de lensemble des donnes
recueillies et transcrites ?

88

Pour dfinir la notion de catgorie nous nous rfrons la dfinition suivante : une production textuelle se
prsentant sous forme dune brve expression et permettant de dnommer un phnomne perceptible travers
une lecture conceptuelle dun matriau de recherche. () la diffrence de la rubrique ou du thme , elle
va au-del de la dsignation de contenu pour incarner lattribution mme de la signification (Paill &
Muchielli, 2003 dans Blais & Martineau, 2006).

127

Chapitre IV : Conduire une approche par la pratique

Dans un premier temps, nous avons commenc par coder les informations recueillies lors des
runions auxquelles nous avons assist all codes are simply categories of data that
represent a thematic concern (Gibson & Brown, 2009, p.133). Aprs plusieurs relectures
des donnes transcrites nous avons rduit les paragraphes ou les phrases en de simples
tiquettes o chacune renvoie un sens prcis. Nous rappelons ici que notre objet dtude
consiste comprendre la manire dont les acteurs, responsables de la mise en uvre des outils
agiles , contribuent, par le jeu de leurs interactions, leur fabrication . De fait, lanalyse
des runions sest largement imprgne de la grille danalyse de sensemaking89 que nous
avons mobilise pour saisir les pratiques situes de ces acteurs, leur mobilisation des
ressources, leurs activits interprtatives, etc. Cette grille nous a permis didentifier les
passages critiques et utiles pour notre projet de recherche.
Il apparat important, lors de lanalyse, que le chercheur ne sloigne pas de sa problmatique
et de ses questions de recherche. Un ensemble de codes a ainsi t cr renvoyant aux
proprits de la dmarche de construction de sens des innovations managriales de type
agile . Cette tape sest, par consquent, matrialise par une premire vague de codes :
questionnements des acteurs , plausibilit de la dmarche , dmarche prospective ,
aspect rtrospectif , dlimitation de la dmarche , etc. Nous illustrons cette premire
tape de codage en nous appuyant sur des extraits de deux runions codes.

Plausibilit

Plausibilit

Dans les runions quotidiennes aujourdhui soyons ralistes, ne pas faire un brief
avec tout le monde, n'allons pas tout de suite l'objectif final quoi . On va tre
modeste et on va se contenter de notre entit, on va sattacher des choses quon peut
grer...
Nombre limit de participants

Choix dacteurs internes


Plausibilit

Illustration I : Analyse d'un extrait d'une runion de lquipe lean

89

Cf. chapitre (III).

128

Chapitre IV : Conduire une approche par la pratique

Aspect rtrospectif

Il est important davoir un retour sur ses points de vue et perceptions de la


dmarche notre proposition nest pas quelque chose de dfinitif, le chef de projet va
pouvoir ragir
Aspect rtrospectif

Aspect volutif

Illustration II : Analyse dun extrait dune runion de lquipe lean


Lensemble des catgories a t dfinie de faon itrative et justifie par des verbatim. Les
donnes indexes ont t rexamines plusieurs reprises et classifies au fur et mesure
dans des catgories because code definitions are iterative, applying codes is often cyclical
rather linear (Brown & Jacobs, 2009, p.136).

Catgorie

Dfinition

Plausibilit

Le raisonnement des acteurs est guid par


la plausibilit plutt que lexactitude. Leur
primtre dintervention se limite aux
choses quils estiment tre capables de
raliser.

Verbatim
soyons raliste, ne pas faire un
brief avec tout le monde
on va se contenter de notre
entit on a sattacher des
choses quon peut grer

Rtrospectif

Les acteurs examinent leurs actions


passes pour agir nouveau

il est important davoir un retour


sur ses points de vue

Aspect volutif

Lorsque les actions sont continuellement


reconstruites

notre proposition nest pas


quelque chose de dfinitif

Illustration III : Classification des catgories des illustrations : I et II.


Au cours de lanalyse des runions, dautres catgories ont merg renvoyant aux facteurs
contextuels ayant affect les choix dactions mises en uvre par les acteurs lean .
Lanalyse des pratiques situes des acteurs concerns par le projet a donn lieu une
deuxime vague de codes : taille des projets , structure organisationnelle , mode de
management existant , godistribution des quipes , quipes instables , rduction de
la frquence des briefs , culture de non prise de risque , documentation extensive ,
faible intrt des parties prenantes , manque de temps , etc.
Les catgories extraites de lexemple suivant renvoient aux difficults remontes par les
acteurs lean par rapport la mise en place de la dmarche.

129

Chapitre IV : Conduire une approche par la pratique

Implication du top Management

Il y a un besoin dimplication du top management, part le directeur gnral qui est


trs sponsor sur le sujet, je nai pas limpression que les autres membres du top
management soient autant impliqus Le chef de projet est un chef dorchestre, il ne
matrise pas les activits des contributeurs qui ont leurs contraintes et priorits
Profil de coordinateur du projet

Indisponibilit

Illustration IV : Analyse dun extrait dune runion de lquipe lean


Dans un deuxime temps, nous avons cod lensemble des entretiens en suivant la mme
logique danalyse. Les ides prsentant un mme sens ont t classes sous une mme
catgorie. Un ensemble de catgories a t cr renvoyant (1) aux dterminants contextuels
qui semblent affecter la mise en uvre des pratiques agiles , (2) aux reprsentations des
acteurs de leur mode managrial, (3) aux perceptions de la collaboration intra et inter-quipes,
(4) aux perceptions de lutilit de la dmarche propose, etc.
Acteurs mtiers transverses

Les personnes qui sont partages sur plusieurs projets peuvent tre sollicites sur
plusieurs brief si je vais encore faire ces daily briefs, je vais passer mon temps faire
Multiplicit des runions

des runions

Illustration V : Analyse dun extrait dun entretien avec le chef de projet

Complexit organisationnelle

Golocalisation

Cest un gros problme pour nous organiser plus facilement sachant quon est
reparti En tant que chef de projet, on n'a pas de management d'quipe, on gre
notre quipe sur un projet mais il ny a personne qui m'est rattache. Je n'value le
travail de personnes par exemple
Profil de coordinateur de projet

Illustration VI : Catgories renvoyant aux difficults perues par les acteurs pilotes

130

Chapitre IV : Conduire une approche par la pratique

Catgories

Dfinition

Multiplicit des
runions

Abondance des runions existantes.

Coordinateur du
projet

Autorit limite du chef de projet. Rle


de coordinateur des diffrentes units
fonctionnelles.

Acteurs mtiers

Acteurs rattachs des services


fonctionnels et mobiliss
ponctuellement.

Equipe
complexe

Golocalisation

Verbatim

Equipe de grande taille, disperse,


mobilisant des ressources communes
avec dautres quipes, compose
dacteurs transverses.
Si les personnes travaillant sur un
mme projet sont disperses
gographiquement
Support de la direction en termes
dorientation de la dmarche, de
moyens

Implication de
la direction

si je vais encore faire ces daily briefs, je


vais passer mon temps faire des
runions
le chef de projet est un chef dorchestre, il
ne matrise pas les activits des
contributeurs ; on n'a pas de
management d'quipe il ny a personne
qui m'est rattache Je n'value le travail
de personnes
les personnes qui sont partages sur
plusieurs projets peuvent tre sollicites sur
plusieurs brief ; des contributeurs qui
ont leurs contraintes et priorits
cest un gros problme pour nous
organiser plus facilement
sachant quon est reparti
il y a un besoin dimplication du top
managementje nai pas limpression que
les autres membres du top management
soient autant impliqus

Illustration VII : Classification des catgories (illustrations IV, V et VI)


En ce qui concerne les altiers de dysfonctionnements, nous avons procd la classification
des problmes en fonction des causes explicites auxquelles chacun renvoie. Ensuite, nous
avons class ces problmes en fonction du type de gaspillage 90 auquel chacun renvoie.
(Illustration VIII).

Arrt/reprise du travail

Absence de stratgie de priorisation

Il nous arrive souvent darrter un travail parce quil est moins prioritaire et puis on
essaye de le reprendre et donc de se remettre dans le contexte... Certains sujets sont
traits plusieurs fois par les diffrents niveaux hirarchiques ce qui entrane une perte
globale de temps, une dilution de linformation..
Tches redondantes

Multiplicit des chelons

Illustration VIII: Les dysfonctionnements et leurs causes

Afin didentifier les formes des gaspillages gnrs nous nous sommes bass sur la liste des sept gaspillages
dcrite dans louvrage des Poppendieck (2006).
90

131

Chapitre IV : Conduire une approche par la pratique

Enfin, les mails changs entre les acteurs de lquipe lean ont t cods selon la mme
mthode danalyse.
Au fur et mesure de lavancement du processus danalyse les catgories ont t regroupes
par thme crant ainsi une cohrence entre elles (Illustration IX). Des similarits dans les
reprsentations des acteurs observs et interrogs ont toutefois merg.

Thme

Catgories
Golocalisation

Caractristiques des quipes

Acteurs mtiers
Complexe

Illustration IX : Regroupement des catgories par thme


Pour ce qui est du regroupement des dysfonctionnements remonts, ceux-ci ont t recenss
dans un tableau part o ils ont t illustrs par des verbatim.

Dysfonctionnements

Effets engendrs

Absence de stratgie de
priorisation

Arrt et reprise dun


mme travail

Multiplicit des chelons


hirarchiques

Tches redondantes

Dpendance entre les


phases des projets

Temps dattente

Citations
Il nous arrive souvent darrter un travail
parce quil est moins prioritaire et puis on
essaye de le reprendre et donc de se remettre
dans le contexte... On se trouve face un
travail moiti fait et donc inutile.
Certains sujets sont traits plusieurs fois par
les diffrents niveaux hirarchiques ce qui
entrane une perte globale de temps
Jai tendance me focaliser sur les
dpendances entre les projets le problme
cest quun retard sur un projet impacte un
autre projet.

Illustration X : Regroupement des dysfonctionnements et de leurs effets


Aprs avoir catgoris lensemble des donnes textuelles, nous avons procd lexplication
de celles-ci : quest ce qui a conduit les acteurs un tel nonc ? Quel est limpact de tel ou
tel facteur contextuel ? Pourquoi tel choix daction ?, etc. Des liens ont t crs entre les
diffrentes catgories.
Bien que notre analyse thmatique se veuille inductive, le cadre conceptuel autour duquel se
construit notre objet de recherche, a fortement influenc le type de catgories identifies.
132

Chapitre IV : Conduire une approche par la pratique

Cependant, lagrgation des catgories et linterprtation de celles-ci dpendent des questions


de recherche, des modles recherchs, etc. whatever strategy is used there will always be an
uncodifiable step that relies on the insight and imagination of the researcher (Weick, 1989,
p.707 dans Langley, 1999). A cet effet, peu importe la mthode danalyse adopte par le
chercheur, linterprtation relve des connaissances de celui-ci, de ces capacits didentifier
les commentaires subtils des personnes observes.
2.4 Triangulation des donnes et des chercheurs
Les dfinitions et les objectifs du concept de triangulation varient. Denzin (Denzin, 1978 dans
Stake 1995) identifie quatre types de triangulation: (1) triangulation des donnes qui consiste
utiliser diffrentes sources de donnes : temps, situations et individus ; (2) triangulation des
chercheurs lorsque plusieurs personnes sont impliques dans la collecte des donnes et leur
interprtation present the observations (with or without your interpretation) to a panel of
researchers for discuss alternative interpretations . to the extent they describe the
phenomenon with similar details, the description is triangulated to the extent they agree on its
meaning, the interpretation is triangulated (Stake, 1995, p.113). La troisime forme de
triangulation est celle des thories concurrentes : the achievements of useful
hypothetically realistic constructs in a science requires multiple methods focused on the
diagnosis of the same construct from independent points of observation through a kind of
triangulation (Campbell & Fiske, 1959 ; p.81 dans Stake, 1995) ; enfin, une quatrime
approche correspond la triangulation mthodologique : les chercheurs utilisent diffrentes
mthodes de collecte de donnes pour tudier un mme phnomne when we speak of
methods in case study, we are again speaking principally of observation, interview and
document review (Stake, 1995, p.114).
Dans le cadre de notre travail de recherche, la combinaison des diverses sources de donnes
(acteurs occupant diffrents statuts et uvrant dans diffrents contextes) et dinstruments de
collecte de donnes (observations-entretiens-documentation) nous a permis denrichir notre
champ de connaissances et dapprofondir nos analyses. En outre, les workshops auxquels
nous avons particip (notamment en forme de data sessions), en prsence dexperts en
sciences de gestion, nous ont permis daccrotre la validit des donnes transcrites et
interprtes. Ces workshops nous ont offert la possibilit de faire part de nos analyses et
interprtations de donnes. Les retours remonts durant ces workshops ont, dun ct,
133

Chapitre IV : Conduire une approche par la pratique

particip valider notre processus danalyse et dun autre ct, fait merg de nouveaux
questionnements et points investiguer. Par ailleurs, les rapports danalyse des entretiens
mens auprs des chefs de projets ont t soumis aux membres de lquipe lean . Laccord
de ces derniers sur les donnes interprtes nous a permis daccrotre la validit de nos
interprtations. Le processus de member-checking (Stake, 1995) consiste ce que les
acteurs, participant ltude, examinent les interprtations du chercheur et procurent celuici des informations et interprtations supplmentaires. Enfin, les entretiens conduits avec le
directeur du projet lean furent une occasion de nous assurer de la validit des donnes
recueillies et de clarifier certains questionnements relatifs la dmarche et au contexte tudi.

134

135

Chapitre V : Variables de cration de sens

Ce chapitre rend compte de nos observations et analyses. Il comprend deux sections.


La premire expose les dysfonctionnements tels quils ont t remonts par les quipes
projets. Lidentification des dysfonctionnements a permis de dresser ltat des lieux des
projets et de lgitimer la dmarche damlioration entreprise.
La seconde met en avant les facteurs dordre contextuel tels quils ont t identifis par les
acteurs organisationnels et qui ont manifestement influenc la manire dont la dmarche
managriale a t mise en place.

136

Chapitre V Variables de cration de sens de la dmarche

La stratgie de recherche adopte a pour but de rendre compte de la manire dont les
acteurs responsables de la mise en uvre des innovations managriales que seraient les
mthodes agiles font sens de celles-ci et de leur contexte dapplication. Lapproche
danalyse par la pratique sest ainsi focalise sur les pratiques de ces acteurs, la manire
dont ils combinent et coordonnent leurs ressources discursives, motivationnelles et cognitives
pour construire et mettre en place une stratgie managriale de type agile .
Nos observations et analyses rvlent que la notion de gaspillage constitue un point dappui
essentiel pour les acteurs souhaitant sengager dans une dmarche damlioration de type
agile . Toutefois la construction et la mise en uvre de cette dernire relvent dun
ensemble dlments dordre contextuel.
1. Le gaspillage dans les projets pilots par Nextv
La mise en place dateliers didentification des dysfonctionnements a constitu le point de
dpart de la dmarche lean . Sept ateliers ont t organiss avec des membres dquipes
projets91 et dquipes mtiers92 en vue de dresser ltat des lieux des projets. Ces ateliers ont
donn loccasion aux acteurs lean dexaminer le fonctionnement des quipes de lentit
Nextv, den valuer les faiblesses et de mettre en place une stratgie dvolution base sur les
mthodes agiles .
Au cours de ces ateliers, les participants ont t amens lister les dysfonctionnements,
mesurer lampleur des zones problmes en termes de temps perdu (J/H) et en analyser les
causes racines travers les outils 93 prsents par lquipe lean . Quatre vingt dix-huit
dysfonctionnements ont t souligns.

91

Cf. tableau (12).


Chefs de projet, managers de composants, architectes.
93
QQCQOP, la mthode des 5 Pourquoi.
92

137

Chapitre V : Variables de cration de sens de la dmarche

Afin de mieux cerner les formes de dysfonctionnements cites, nous les avons classs par
type de gaspillage en nous appuyant sur la liste classique des sources de muda rpertories par
Shigeo Shingo 94 dans louvrage des Poppendieck (2006).
1.1 Analyse et classification des dysfonctionnements par type de gaspillage
La production excessive constitue une premire forme de gaspillage prsente dans les projets
mens Nextv. De nombreuses fonctionnalits et documentations sont dveloppes alors
quelles se rvlent, par la suite, inutiles. La raret des occasions de communication entre les
acteurs mtiers (runions hebdomadaires organises par le chef de projet avec des bouts
dquipes) et labsence dun environnement visuel (diffusion des informations par le biais des
reporting, documentation exhaustive des diffrentes activits) rendent difficile la cohsion
inter-quipes et la cration de vision commune du projet (tableau 17). Les acteurs mtiers ont
tendance anticiper certaines activits et prendre des initiatives sans pour autant les
communiquer systmatiquement leurs paires. Lapproche base sur la planification et
lanticipation, valorise par les chefs de projet, semble gnrer des cots additionnels: cots
de qualification et de maintenance de codes inutiles, documentations obsoltes, etc.
Bien que certaines quipes de dveloppement se base sur des cycles itratifs pour
programmer, elles sont parfois amenes anticiper leurs activits de dveloppement pour
pouvoir rpondre aux dlais imposs par les chefs de projet qui, selon elles, ont tendance
sous-estimer la charge du travail requis. Les activits planifies lavance peuvent ainsi
conduire une production de fonctionnalits inutiles et de charges supplmentaires. Dans une
perspective lean, les processus de dveloppement doivent tre flux tirs: les activits sont
dclenches en fonction des besoins exprims durant les phases prcdentes. Ce sont les
changes permanents entre les acteurs mtiers et la mise en uvre doutils de management
visuel qui permettent doffrir une vision partage des besoins. Le dploiement des techniques
pull , sur lensemble des phases du cycle de vie de projet aiderait galement les quipes
produire la quantit exacte des demandes requises en termes de spcifications, de codes, de
documentations (Poppendieck, 2006, 2009). Parmi les nombreuses causes de surproduction,
les acteurs lean ont focalis leur attention sur le manque de vision globale entre les
quipes. Afin de combler ce manque, ils ont dcid de mettre en place des runions

94

Cf. tableau (3), chapitre (I).

138

Chapitre V : Variables de cration de sens de la dmarche

quotidiennes et un management visuel instruments par un tableau blanc et des indicateurs de


performance.
Tableau 17: Les causes de la surproduction
Types de dysfonctionnements

Manque de vision globale

Pilotage par les dlais et anticipation


des activits

Citations
le rat avec eux est par exemple qu'ils vont corriger plus que
tu leur as demand ils ont tendance des fois se substituer au
client en voulant faire mieux et livrer plus que tu demandes ;
il y a parfois des prises dinitiatives des quipes de
dveloppement qui ne sont pas communiques au CPM voire au
projet et qui ont un impact. On a l une optimisation des codes
qui va gnrer une qualification or ce ntait pas du tout
prvu .
moi javais un point sur le pilotage par les dlais quon nous
impose...Cest dire on nous impose en gros une date de
remise de livraison en assemblage sans forcement tenir compte
de la charge au niveau de dveloppement pour pouvoir raliser
le primtreon se retrouve anticiper les dveloppements,
quasiment dvelopper avant le T-1. il nous arrive donc de
faire des dveloppements inutiles

Lattente renvoie une deuxime forme de gaspillage remonte lors de ces ateliers. Elle se
manifeste par des acteurs inoccups, en situation dattente dinformations prcises, de
dcisions hirarchiques, de validation de rsultats ou de ressources momentanment
indisponibles. Les acteurs peinent identifier les interlocuteurs capables de les assister dans
les problmes rencontrs ou de les aider rpondre leurs questionnements. Les dlais
dattente sur les phases des projets peuvent ainsi sexpliquer par : la multiplicit des canaux
de communication et de dcideurs, la conduite simultane de plusieurs projets et leur
mobilisation de ressources communes, la dpendance entre les phases dun projet,
lindisponibilit des informations recherches et/ou la faible fiabilit des donnes disponibles
(tableau 18). Pourtant, dans une organisation lean, le temps consacr la recherche
dinformations est considr comme une source de gaspillage majeure quil convient
dliminer. De fait, les changes rguliers entre les acteurs ( daily meetings , ateliers
kaizen) peuvent amliorer la collaboration entre les membres de lquipe et rduire le temps
consacr la recherche dinformations. La rduction des temps dattente sobtient aussi par le
biais dune meilleure synchronisation entre les acteurs projets : la colocalisation de lquipe et
lautonomie accorde aux membres de celle-ci, prconises par le courant agile , semblent
rduire ces dlais et acclrer les prises de dcisions et le dploiement dactions correctives.
De plus, la simplification des chanes de dcisions et la dcomposition des projets en modules
139

Chapitre V : Variables de cration de sens de la dmarche

indpendants ont t prsentes comme des mesures efficaces pour favoriser les changes
rapides dinformations et viter quune mme ressource soit sollicite par diffrents acteurs. Il
est tout de mme important quune information soit disponible au moment exact ; trop tt, elle
risque dtre modifie et trop tard, oublie (Poppendieck, 2006).
Dans le prsent contexte, les acteurs lean se sont contents de mettre en place des ateliers
kaizen et des runions quotidiennes afin damliorer la collaboration entre les quipes et la
capitalisation sur les bonnes pratiques. Si ces deux solutions peuvent rduire le temps
consacr la recherche dinformations, elles peuvent difficilement irradier les temps dattente
causs par la multiplicit des canaux de communication, les processus rigides de prises de
dcision et la dpendance entre les phases du projet.
Tableau 18: Les causes des temps dattente
Types de dysfonctionnements

Citations

Mobilisation de ressources
communes

il y a toujours donc quelqu'un qui attend sur la plateforme sur


laquelle tu te trouves, la ressource que tu mobilises ; le
nombre de projets quon a en parallle compliquent la gestion des
ressources ; les responsables transverses sont extrmement
sollicits c'est vrai qu'on a des gens qui sont des positions
assez cruciales qui se retrouvent quand mme un petit peu
cheval sur deux projets qui sont assez pris au chaud ; les
dveloppeurs se comportent comme des SSII si on leur donne pas
du boulot pendant un mois, ils partent sur un autre sujet .

Dpendance entre les phases des


projets

Multiplicit des acteurs


dcideurs

Rigidit du cycle de vie


squentiel

jai tendance me focaliser sur les dpendances entre les


projets le problme cest quun retard sur un projet impacte un
autre projet ; lorsquon a un retard sur un projet, a retarde
le planning global
Les chefs de projet sont en attente du comit des services
dachats pour les dcisions budgtaires donc l les dveloppeurs
rentrent dans les problmes de rapports, de prises de dcisions ;
aujourdhui on demande quelque chose on passe par le cpm, le
cpm par larchitecte, larchitecte par les 3P ou le market qui
demande ces 5 collgues si cest bon, etc. et donc a revient
aprs 3 semaines et cest toujours le mme circuit.. ; aprs
deux semaines du T0, le R&D navait toujours pas fourni le
planning.En consquence on ne sait pas si le T3 annonc est
ralisable ou pas
au fait, on nous propose une solution, nous on va la proposer
sur papier ct ingnierie et puis aprs il faut quelle soit
qualifie par IEP et donc il peut y avoir du temps entre les deux ce
qui fait quon met plein de temps pour la mettre en uvre et on
sen rend compte au final quelle ne fonctionne pas.

140

Chapitre V : Variables de cration de sens de la dmarche

Indisponibilit de linformation
recherche

on va dans IRMA95 le faire et on constate que les informations


dont dispose cet outil ne sont pas fiables et suffisamment prcises
pour faire un bon bilan

Les transports et manutentions inutiles constituent un troisime type de muda en


dveloppement informatique. Les dplacements physiques des documents et les allers-retours
de mails peuvent ralentir le processus de traitement des demandes et par consquent les
activits des diffrents collaborateurs. Au sein de Nextv, les changes inutiles dinformations
relvent de la structure des projets, de la multiplicit des acteurs et du manque de clarification
des rles lintrieur de lorganisation. Cette forme de gaspillage rejoint celle prsente plus
haut (lattente). Citons comme exemple, une activit de dveloppement bloque par lattente
dune dcision du marketing. Dans lentit tudie, le transfert dune demande au marketing
doit passer par diffrents acteurs (chefs de projets, CPM, etc.) avant dtre compltement
traite (tableau 19). Linformation peut alors sgarer avant datteindre son destinataire
engendrant ainsi des attentes et des retards. Il apparat donc lgitime de court-circuiter le trajet
de la demande en diminuant le nombre dacteurs dcideurs et de clarifier les rles et les
responsabilits au sein des quipes projets. Toutefois, ce type de solution na pas t envisag
par les acteurs lean principalement en raison du temps et des efforts quun tel changement
ncessiterait. Cela dit, il faudrait redfinir les responsabilits et les rles de chacun et
convaincre lorganisation de rduire la rigidit des processus en crant des liens directs
entre les parties prenantes dun projet.
Tableau 19: Les causes des transports inutiles
Types de dysfonctionnements

Mauvaise identification des bons


interlocuteurs

Citations
tu as des demandes dvolution qui viennent dune vision
produit de marketing mais qui remontent par les mauvais
tuyaux et donc finalement a prend du temps pour tre trait et
prioris ; cest vrai que parfois les gens se demandent un
peu par qui le projet est pilotcomme je te le disais on a
normment de collaborateurs ; on a des lacunes mettre
des noms sur les personnes travaillant sur une activit ou un
composant

Les tapes supplmentaires en dveloppement de logiciels concernent principalement les


activits redondantes ainsi que les arrts et reprises dune mme tche ou activit. Ce type de
gaspillage a souvent t remont dans les discours des acteurs participant la dmarche pilote
95

Il sagit dun outil de gestion de base de donnes.

141

Chapitre V : Variables de cration de sens de la dmarche

(tableau 20). En effet, la reprise dune tche suspendue engendre des pertes de temps
considrables. Elle ncessite des efforts supplmentaires de la part de lacteur responsable
dans la mesure o celui-ci est amen se remettre dans les conditions pralables alors quil
sest dj impliqu dans dautres tches. Ces formes de gaspillage sont dues dune part, au
manque de communication et de vision globale du projet et dautre part, labsence de
stratgies de priorisation des demandes. Ajoutons que les risques de retravail augmentent
dans les projets de grande taille au sein desquels les quipes consacrent beaucoup de temps
aux phases de planification et dtudes. Dans un tel contexte, les dcisions sont souvent
traites plusieurs reprises en raison du grand nombre dacteurs et dchelons hirarchiques
impliqus dans les projets. Linstabilit des quipes et lintervention des acteurs transverses
sur diffrents projets les conduisent dlaisser une tche au profit dune autre. Enfin, la
dispersion gographique des acteurs et lautorit limite dont dispose le chef de projet rendent
difficile le contrle et le suivi rgulier des activits effectues. Llimination dun tel
gaspillage pourrait tre envisage par une redfinition de la structuration des projets et de la
composition des quipes. A lheure actuelle, les acteurs lean sont incapables de sattarder
sur des lments qui relvent de la structure globale des projets et des quipes.
Tableau 20: Les causes du travail supplmentaire
Types de
dysfonctionnements

Absence de stratgie de
priorisation

Manque de vision globale

Multiplicit des niveaux


hirarchiques
Planification et
documentation extensives
Autorit limite du chef
de projet

Citations
il nous arrive souvent darrter un travail parce quil est moins
prioritaire et puis on essaye de le reprendre et donc de se remettre dans le
contexte... On se trouve face un travail moiti fait et donc inutile ;
lLe problme est quil nous arrive darrter le droulement du projet en
phase tude ou dveloppement pour nous mettre sur quelques chose
dautrea gnre des pertes de temps
il y a des difficults avoir une vision globale. Il y a du travail refait
par le projet du fait de manque de vision globale de la proposition des
solutions des architectes sur la partie tude, il y a une difficult
davoir une vision globale de ce qui va tre faitbeaucoup de fois on a
t amen reprendre la partie tude parce quil y a des conclusions qui
sont fausses
certains sujets sont traits plusieurs fois par les diffrents niveaux
hirarchiques ce qui entrane une perte globale de temps, une dilution de
linformation et parfois une mauvaise interprtation vu quil manque des
informations et des dcisions non comprises
on dpense beaucoup dnergie dans la phase dtude faire des
estimations, faire le planning et aprs on se rencontre quon est amen
faire de nouvelles estimations de planning
son chef lui a dit de ne plus bosser sur le truc mais sans me prvenir.
Souvent tu leur dlgues des trucs et ce n'est pas forcement suivi comme
tu attends ; le chef de projet est un chef dorchestre, il ne maitrise pas
les activits des contributeurs qui ont leurs contraintes et priorits.
142

Chapitre V : Variables de cration de sens de la dmarche

Une cinquime forme de gaspillage que nous retrouvons dans les projets relve de
linventaire. En industrie automobile linventaire renvoie aux stocks inutiles qui gnrent des
gaspillages parce quils occupent un espace physique, ncessitent des dplacements et une
maintenance. Dans le dveloppement informatique, ce type de gaspillage concerne plutt le
travail partiellement effectu ainsi que la documentation et les fonctionnalits non
ncessaires. Dans le contexte qui nous intresse, le manque dchanges rguliers entre les
acteurs, labsence de stratgies de priorisation et la mauvaise clarification des demandes
peuvent expliquer ce type de muda remont par les quipes (tableau 21). Deux autres facteurs
contextuels se trouvent lorigine de ce gaspillage : la longue dure des projets accrot les
probabilits dabandon du travail dune part et les livrables des activits de planification et de
documentation, valorises par les quipes, risquent lobsolescence dautre part. Les reporting
raliss et les spcifications fonctionnelles dtailles ont un cot considrable en termes de
temps accord leur production et de gaspillages lis leur non utilisation. Selon les acteurs
interrogs, de nombreuses documentations sont produites durant les phases de planification et
de conception dun produit engendrant des stocks inutiles, particulirement, lorsque le produit
final nest pas mis en production. La documentation extensive peut sexpliquer par la culture
de non prise de risque de lorganisation. A cette fin, un plan daction a t mis en place en vue
de rduire le taux de la documentation.
Tableau 21: Les causes de linventaire
Types de dysfonctionnements
Absence de stratgies de
priorisation

Mauvaise clarification des


demandes du marketing

Planification et documentation
extensives

Citations
il y a des changements de priorit entre les diffrentes
fonctionnalits et entre diffrents projetson passe du temps
faire un truc et finalement ils nous demandent de laisser tomber
et de commencer un nouveau truc
les clients changent souvent leurs demandes et nous
demandent par consquent de changer nos priorits, on modifie
le primtre dun projet dj lanc pour intgrer une autre
partie .
on dpense beaucoup dnergie dans la phase dtude faire
des estimations, faire le planning et aprs on se rencontre
quon est amen faire de nouvelles estimations de planning et
a jestime que cest un gros problme

La multiplication des runions, les dplacements physiques et la ralisation de diverses tches


simultanes, constituent une autre forme de gaspillage : les mouvements inutiles. La
distribution physique des membres dune quipe accrot les probabilits de dplacement des
acteurs entre les sites. Dans un tel contexte, le manque de communication spontane sera
143

Chapitre V : Variables de cration de sens de la dmarche

compense par des runions de longues dures, organises distance, durant lesquelles divers
sujets et problmes seront abords et traits. Or, un ensemble de cots est associ aux
dplacements physiques des acteurs (taxi, train, htel, sjour, etc.) et la communication et
partage virtuel de documents. Dans le prsent contexte, le chef de projet organise des runions
hebdomadaires avec des bouts dquipes mtiers en raison de la grande taille des quipes.
Ces runions ncessitent, ds lors, beaucoup defforts en termes de documentation - une
quantit de reporting est ainsi diffuse la fin de chaque runion - sans toutefois garantir le
partage dune vision globale du projet (tableau 22). Les demandes et les exigences sont
souvent mal clarifies engendrant un retravail , des retards et des cots supplmentaires. A
premire vue, ce type de gaspillage peut tre rduit par des runions organises, distance,
avec lensemble des acteurs projets. La mise en place doutils technologiques performants
pourrait tre une solution pour amliorer la qualit de la communication et assurer un partage
rapide de documents. Dans cette optique, lquipe lean a dcid de recourir aux runions
quotidiennes afin de favoriser les changes entre les diffrentes quipes et amliorer la vision
globale du projet.
Tableau 22: Les causes des mouvements inutiles
Types de dysfonctionnements

Multiplicit des reporting

Multiplicit des runions

Citations
jai un compte rendu global dans lequel je donne les liens
vers tous les comptes rendus (reporting) avec les clients, les
oprationnels, les architectes. Ils se trouvent sur Roll et envoy
par mail mais franchement ils ne sen servent pas. Ils ne les
lisent pas du tout. Il y a que moi qui m'en sert
j'arrive faire des points avec des bouts d'quipes car tous
ensemble a dure des heures. On fait des points hebdomadaires,
on se fait des invitations toutes les semaines la mme heure
pour les participants. J'ai plusieurs points d'quipes .

Enfin un dernier type de gaspillage rpertori en industrie automobile et que nous retrouvons
dans notre terrain de recherche concerne les dfauts. Dans une industrie automobile, le
reprage tardif des pices dfectueuses et des rebuts se trouvent lorigine de nombreux
surcots. La grande taille des projets et le pilotage par les dlais imposs par les chefs de
projets entranent les quipes anticiper leurs activits mettant en pril la qualit de leur
travail. Souvent la solution livre nest pas conforme aux attentes des clients. A cet effet, des
surcots et des retards de livraison sont engendrs induisant une insatisfaction des clients. La
bote outils lean (landon, 5 pourquoi, Pareto des causes, A3, etc.) pourrait tre utile pour
dtecter rapidement les dfauts, analyser les causes racines et standardiser les bonnes pratique
144

Chapitre V : Variables de cration de sens de la dmarche

jusqu ce quelles soient remplaces par dautres meilleures pratiques (principe


damlioration continue). Au sein de Nextv, les acteurs se plaignent dune part, de nombreux
bugs qui apparaissent aprs le dveloppement et dautre part, de la qualit des documents
produits. Leurs systmes danticipation et de dtection rapide des dfauts savrent peu
efficaces. Afin de remdier ce type de difficults, les acteurs lean ont opt pour la mise
en place doutils 96 didentification et de rsolution de problmes. Les outils quils ont retenus
ne permettent pas danticiper les problmes mais de les identifier et de les rsoudre aprs leur
apparition. Dun point de vue lean, le recours des dtrompeurs , tels que les tests
unitaires automatiss, les tests fonctionnels, lintgration continue, etc. permet danticiper les
problmes et de rduire les anomalies. Cependant, la mise en place de ces outils na pas t
envisage par les acteurs lean . Cela sexplique par le fait que les quipes concernes par la
dmarche ntaient pas impliques dans les activits de programmation. Dautres
dysfonctionnements ont t souligns renvoyant la dpendance entre les composants, au
manque de capitalisation sur les bonnes pratiques, au manque de communication avec le
client, etc. (tableau 23). Mais ces dysfonctionnements nont pas t traits dans la dmarche
lean pour des raisons lies aux investissements que leur traitement ncessitent en termes
de temps, defforts, dimplication du marketing, de support, etc.
Tableau 23: Les causes des dfauts
Types de
dysfonctionnements
Grande taille des
projets
Dpendance entre les
composants
Faible ractivit face
aux problmes
rencontrs
Non capitalisation des
bonnes pratiques

Pilotage par les dlais


Mauvaise dfinition
des demandes du client

Citations
il nous faut 12 mois pour sortir quelque chose Et en plus quand on le
sort, nos clients sont rarement satisfaits parce que a ne correspond pas trop
ce quils attendaient.
quand on fait une volution a va forcment impliquer un autre composant
et donc quand a arrive dans le dveloppement ont met en pril la cohrence
de lensemble de la solution technique au niveau projet
sil y a un bug sur une livraison, lquipe ne fait rien. on attend le
temps dattente est dun mois. , il y a un problme de suivi de bugs
il nya pas de capitalisation des comptences lors de changement de
prestation ; Il y a une difficult de capitaliser sur les comptences en
cas de changement de prestataire
lanticipation des dveloppements partir des dlais imposs par le projet
sans tenir compte des charges de dveloppement impacte la qualit des
dveloppements : fonctionnalits absentes, beaucoup de bugs, et performance
non optimale
au niveau de la phase tude, on dveloppe selon les ides des architectes et
des CPM et non pas comme le client veut

96

La dmarche PDCA, la mthode des 5 Pourquoi, le QQCQOP.

145

Chapitre V : Variables de cration de sens de la dmarche

Multiplicit des
interlocuteurs

Manque de fiabilit de
la documentation

il nous arrive souvent de dtecter un problme mais on na pas un point


dentre bien prcis On a plusieurs acteurs mais on ne sait pas qui
contacter ; le suivi de la rsolution dun problme est trop long du fait
de multiplicit des acteurs engags ou concerns je suis daccord avec toi,
pour moi il y a trop dacteurs sur un mme sujet .
on a un vrai problme de dficit de documents sur certains composants qui
sont relativement anciens.quand tu arrives sur un sujet et tu essayes de
faire des documents sur certains sujets tu es vraiment paum

1.2 Dmarche plausible de rsolution des dysfonctionnements


Dun point de vue gnral, les rares occasions dchanges entre les parties prenantes (chefs de
projets, architectes, marketing, quipes de dveloppement, de qualification, de maintenance,
CPM, etc.) ont affect la coordination, le suivi et le contrle de activits ralises. Des prises
dinitiatives et des changements ont eu lieu tout au long du cycle de vie des projets sans tre
communique

systmatiquement,

ce

qui

eu

pour

consquence,

lapparition

dincomprhensions et dinsatisfactions par rapport aux dcisions et actions entreprises. Outre


ce dficit de communication entre les acteurs projets, dautres facteurs organisationnels et
managriaux se trouvent lorigine des dysfonctionnements identifis. Nous les avons
regroups dans les catgories suivantes : le mode de management, les caractristiques des
projets et la structure organisationnelle dans laquelle ces derniers sont pilots.
Le style de management appliqu par les managers de lentit Nextv repose, en gnral, sur
une vision squentielle de projets, des activits de documentation et de planification
extensives et sur un pilotage par les dlais. Ce mode managrial, bien que valoris par
certains chefs de projets, a t remis en cause par diffrents acteurs de la direction des
plateformes de services (DPS). Il est fort probable quil soit lorigine du manque de
visibilit des projets, des demandes non clarifies, de la mauvaise qualit des codes
dvelopps et des dlais dattentes. Quant aux caractristiques des projets, habituellement de
grande taille et de longue dure, elles semblent constituer une source significative de
gaspillage induisant des pertes de temps (en raison de la multiplicit des acteurs
dcideurs ), des surcots et des retards (du fait que les changements sont plus coteux et
difficiles grer dans des projets de longue dure). Enfin, dautres problmes voqus
remontent la structure de type lightweight des projets pilots par Nextv. Lautorit limite
dont dispose le chef de projet pour coordonner ses quipes mtiers et lintervention
temporaire de celles-ci dans divers projets, compliquent la gestion des ressources (acteurs
146

Chapitre V : Variables de cration de sens de la dmarche

sollicits sur diffrents projets), la capitalisation des connaissances (quipes instables) et la


recherche dinformations (multiplicit des niveaux hirarchiques et des interlocuteurs).
Les projets tels quils sont mens au sein de la direction des plateformes de services (DPS) et
en particulier au niveau de lentit Nextv renvoient diffrents types de dysfonctionnements
managriaux et organisationnels qui sont lis et se recoupent. Ces dysfonctionnements ne
relvent pas uniquement des pratiques de management de projet des quipes de lentit Nextv
mais aussi de lorganisation de la direction dont elle fait partie.
Si les acteurs lean se sont attachs analyser, avec les participants des ateliers, les causes
majeures dun certain nombre de dysfonctionnements, ils ne sont pas alls au-del de la
relation binaire entre le problme et la cause initiale. Autrement dit, ils ne se sont pas attards
sur les origines multiples que chaque problme voqu peut avoir. Par consquent,
sintresser uniquement la cause explicite du problme ne conduit pas ncessairement sa
rsolution. Par exemple, un produit non-conforme aux attentes du marketing ne sexplique pas
uniquement par une mauvaise dfinition de la demande. Il peut rsulter dune mauvaise
gestion des priorits, des changements qui ne sont pas pris en compte, dune mauvaise
communication entre les architectes et les dveloppeurs, etc.
Dune manire gnrale, les problmes remonts au cours de ces ateliers ont t interprts
comme un manque de communication et dchanges entre les quipes. On peut supposer que
les quelques facteurs suivants ont affect le choix des acteurs : le manque de temps et de
ressources, les possibilits dactions limites, les difficults dimplication de certains acteurs
cls, les intrts personnels et collectifs, etc. De fait les acteurs lean se sont contents des
solutions plausibles qui se trouvent leur porte. Nous reviendrons dans le chapitre (VI) sur
cette notion de plausibilit. Ainsi, ils se sont attachs identifier et dfinir les outils
agiles capables de rpondre aux problmes majeurs retenus : le manque de communication
et de visibilit sur les projets.
On ne communique pas assez entre nous au sein dune quipe projet, entre les paires
faisant le mme mtier. Il manque une certaine animation entre le chef de projet et son
quipe (TR) ;
Je crois qu'il n'y a pas de partage d'expriences et un enrichissement entre les
personnes. (RB) ;

147

Chapitre V : Variables de cration de sens de la dmarche

A mon avis, il y a donc un lment essentiel cest de rendre les acteurs plus concerns par
les interactions (TR) ;
Lanimation par le brief, le tableau de bord et les indicateurs peuvent apporter quelque
chose aux chefs de projets (TR).
Lidentification des dysfonctionnements a constitu un point dentre lgitime pour justifier la
dmarche damlioration entreprise par lquipe lean . Cependant, parmi les quatre vingt
dix huit dysfonctionnements cits, seuls huit ont fait lobjet dune analyse approfondie et, par
consquent, ont conduit des plans daction97 assez relativement prcis. Les actions
damlioration ont t menes, sous forme dateliers anims par diffrents porteurs98 et
dans lesquels est impliqu un certain nombre de contributeurs. Chaque plan daction vise
agir de faon ponctuelle sur le dysfonctionnement par lequel le groupe dacteurs (porteur et
contributeurs) est concern. Le tableau (24) expose deux problmes avec leurs plans dactions
tels quils ont t formuls par les acteurs lean et valids subsquemment par le Codir.
Dans le cadre de ce travail, ne nous attarderons pas sur la manire dont le contenu des plans
daction a t ngoci et dcid entre les acteurs lean et le Codir et ce, pour deux raisons
principales : (1) nous navons pu avoir accs aux runions organises entre le Codir et
lquipe lean , ce qui nous empch dexaminer de prs la construction et la validation des
plans dactions ; (2) ces plans dactions ne constituent pas une fin en soi. En dehors de la
solution ponctuelle laquelle chacun renvoie, ils se prsentent comme un moyen mobilis par
les acteurs lean pour illustrer la mthode99 damlioration que les quipes projets sont
invites intgrer dans leur mode de fonctionnement. En revanche, nous nous focaliserons
davantage sur les raisons, donnes par lquipe lean , qui expliquent leurs choix quant aux
dysfonctionnements et plans dactions retenus : (1) la faisabilit des solutions mettre en
uvre, (2) le gaspillage en terme (J/H) engendr par chaque problme et (3) les enjeux
politiques du Codir rsoudre les problmes retenus. Divers facteurs semblent avoir affect le
choix stratgique des dysfonctionnements traiter et des solutions100 mettre en uvre : les
intrts collectifs, les possibilits daction, leurs reprsentation quant limpact des
dysfonctionnements sur les projets, etc. Afin de mieux clarifier ce propos, nous consacrerons,
97

Cf. tableau (13).


Il sagit dune personne identifie par lquipe lean pour se charger de la mise en place de laction au
niveau dun groupe de contributeurs interne et/ou externe lentit quil parait important dimpliquer.
99
Elle consiste identifier les dysfonctionnements, les analyser, mettre en place des plans de rsolution et
samliorer de faon continue.
100
Par solutions, nous entendons les outils lean prsents dans le tableau (11) et les plans dactions qui ont
fait lobjet dun accord entre lquipe lean et le Codir.
98

148

Chapitre V : Variables de cration de sens de la dmarche

la section suivante, la prsentation des lments contextuels partir desquels les acteurs ont
construit le sens des opportunits saisir, des difficults viter et des actions mettre en
place.
Tableau 24 : PDCA mobilis par lquipe lean
Dysfonctio
nnement

nonc claire du
problme traiter

Quantifica
tion des
problmes

Beaucoup de RFC101
Peut aller
demandes par les 3P
jusqu'
sont tudies
50%
inutilement entre T-1
d'tudes. 17
et T1 car lors de
RFC
l'estimation des cots
demandes
par les dveloppeurs
au T-1 pour
il apparat qu'elles ne
3 retenues
sont pas prises en
pour le
compte dans le
projet ZNE
planning
Impact cot
qualit
dlais : par
On prononce le T0
exemple la
voire le T1 alors que
conception
la proposition de
doit tre
solution n'est pas
revue en
finalise.
cours de
dveloppe
ment

Causes du
problme
Accepter
trop d'tudes,
Impacts sous
estims en
pr-tude,
fournisseur
trop cher,
solution
inadapte ou
indisponible

la phase
d'tude n'est
pas finalise.
Document
proposition
de solution
incomplet

Action
valorise
Avoir
lensemble
des RFC
candidates
au
scope
traduit sous
forme de
RFC avant
le T-1

Nommer le
Cdp pour
soutenir
l'architecte
leader au
T-1.

Porteur

Contrib
uteur

cha
nce

GA

SD, DF,
ET.

01/10

GA

SD, DF,
ET.

02/10

2. Facteurs dinfluence de la dmarche lean


2.1 La taille et la distribution des quipes
Lors des discussions des acteurs, la taille des quipes a souvent t aborde comme une
difficult majeure entravant lesprit agile encourag par la dmarche. Si les managers
dquipes de taille rduite (les quipes de dveloppement par exemple) considrent les
pratiques agiles tels que le dveloppement itratif, les runions quotidiennes, les changes
rguliers, etc. comme un moyen permettant damliorer la cohsion de celles-ci et la
satisfaction des parties prenantes du projet, les managers de projets de grande taille semblent,
eux, tre plus sceptiques quant lapplication de ces pratiques de collaboration.

101

Request For Change (les demandes de changement qui arrivent en cours du projet).

149

Chapitre V : Variables de cration de sens de la dmarche

Je suis positive par rapport la dmarche mais je pense quelle est peut tre non dclinable
avec un volume dquipe aussi grand (DN) ; Je suis juste sceptique par rapport la taille
de lquipe (DN) ;
Jaime bien que tout le monde ait une vision globale du projet mais a va prendre beaucoup
de temps en essayant de runir toutes les personnes concernes (CR).
Comme le montrent nos observations, plus une quipe sagrandit plus il lui devient difficile
de communiquer en direct, davoir une collaboration troite entre ses membres et de
promouvoir le partage de connaissances tacites. Laccroissement de la taille dune quipe est
habituellement accompagn dune formalisation des procdures et dun systme de gestion
rigoureux sloignant des spcificits organisationnelles propres une quipe agile :
processus longs de prise de dcisions, multiplicit des canaux hirarchiques, etc.
Il y a de nombreuses instances le long dun projet, la chane de dcision est complexePar
exemple on a un grand nombre dinterlocuteurs du ct du marketing il est important
davoir un dcideur (CM).
La godistribution des quipes constitue un autre facteur sur lequel les acteurs se sont attards
lors de la mise en place des outils agiles . Face des quipes de grande taille et
godistribues (40 personnes en moyenne), les membres de lquipe lean ont longuement
ngoci les propositions soumettre aux chefs de projets. Leur but est dallger la tche au
chef de projet en lui mettant disposition des outils prconstruits facilement adaptables et
applicables son contexte. A ce titre, les acteurs lean se sont attachs dfinir la
bonne frquence des runions de type daily-scrum , leur contenu, le nombre des
participants, les outils de partage mettre en place, etc.
Ma premire proccupation est de voir les chefs de projet avec une proposition construite
sur laquelle ils peuvent ragir (TR) ; Il faut quand mme avoir assez dlments concrets
et prcis pour lui montrer comment a pourrait tre mis en uvre, avec tel contenu, telles
mthodes (TR) ;
Lobjectif daujourdhui est donc de voir quels seront les acteurs concerns par le brief,
quelle est la bonne frquence, quels sont les indicateurs, etc. et donc ne pas arriver avec
une feuille blanche en lui disant dbrouille toi avec ces pratiques (TR).
Les activits discursives prolonges des acteurs lean mettent en exergue les difficults de
dploiement, sur des quipes clates gographiquement, des pratiques de collaboration
ncessitant gnralement un cadre structur, une communication permanente et des feedback
continus. Les runions quotidiennes de quinze minutes, par exemple, semblent inappropries
150

Chapitre V : Variables de cration de sens de la dmarche

pour des quipes de grande taille sauf si leur dure se voit prolonge. Mais dans ce cas, ces
runions dvieront de leur vise initiale et sloigneront des principes quelles sous-entendent.
Par ailleurs, la communication quotidienne, distance, ne semble pas pouvoir remplacer les
interactions de face face. Selon certains, elle perd de son efficacit et gnre une perte de
temps.
Comment pourrait-on mettre un brief priodique pour ne pas dire quotidien sur les projets
pilotes sachant quon est dispers gographiquement ? (TR) ;
Si on se dit que tous les jours on se runit 15 minutes pour prparer les actions venir,
quand on est ensemble sur un mme lieu, cest facile, mais quand on est reparti entre
Blagnac, Chatillon cest dj diffrent (TR) ;
La dlocalisation gographique ne facilite pas le suivi de la performance Cest dj
diffrent dans la mise en place du brief quotidien, on est oblig dutiliser le tlphone, la
CoopNet102, et donc a conduit un biais Cest tellement plus facile quand on est au mme
endroit, quand le chef de projet, la direction de projet et technique qui travaille ensemble
dans un mme endroit (CR) ;
Lclatement des quipes sur des primtres diffrents gnre de lentropie et un maximum
dinteractions qui ne sont pas efficaces et beaucoup de perte de temps (CM).
Dans ces conditions, lquipe lean a dcid conjointement avec les chefs de projets de
mettre en place des runions plus ou moins rgulires en limitant le nombre de participants. A
ce titre, seuls les acteurs impliqus dans la phase sur laquelle se situe le projet seront convis
ces runions. Certes, cette solution permet au chef de projet de runir les personnes
concernes directement par une phase donne dun projet, nanmoins elle ne rpond pas la
vise essentielle des runions de type daily-scrum et stand-up meeting o les membres
de lquipe entire se runissent quotidiennement pour partager leurs expriences passes,
rpondre aux problmes rencontrs et dcider collectivement du travail futur raliser. Par
consquent, elle ne constitue pas un moyen permettant de rendre des comptes rguliers
lensemble de lquipe. Le manque de vision globale remonte par les acteurs pilotes, ne peut
tre palli par une participation de bouts dquipes des runions rgulires.
Selon les acteurs observs, la multiplicit des intervenants et leur godistribution compliquent
lanimation en direct et les changes entre les diffrentes personnes. Dans de telles
circonstances, les pratiques agiles risquent de perdre leur flexibilit et leur faible cot.
CoopNet est le nom de la solution utilise par les salaris du Groupe Orange pour leurs runions distance.
Elle permet de montrer et de partager, distance, des applications informatiques ou bureautiques, voir tout le
bureau Windows.
102

151

Chapitre V : Variables de cration de sens de la dmarche

Je vois mal comment on peut ne pas rduire le cercle des participants si on veut faire en
quinze minutes et si on veut vraiment se focaliser sur les lments drangeants (DT) ;
Si demain on doit grer en direct ou quon doit animer lensemble des interlocuteurs du
second niveau cest ingrable (PB) ;
Cest un gros problme pour nous organiser plus facilement sachant quon est reparti
(CR).
Ces observations et analyses nous conduisent mettre laccent sur la complexit
dadaptabilit de ces outils collaboratifs et leur acceptation dans un environnement caractris
par des quipes larges, godistribues. Bien quaujourdhui mdiate par de nombreuses
technologies dinformation et de communication de qualit, la communication distance
remplace difficilement la communication spontane et directe entre des individus travaillant
dans un mme espace physique. La dispersion gographique a par consquent une incidence
sur le plan organisationnel et technique : trouver un horaire convenable pour tous, sassurer
que tout le monde est bien connect, disposer de services de tlcommunication qui
permettent la transmission des images, des donnes et de la voix sur de longues distances.
Par ailleurs, les acteurs lean ont tout de mme tent dimplmenter ces runions sur un
cercle restreint dacteurs distribus gographiquement. Celles-ci taient ralises par
tlphone et travers la CoopNet. Dune manire gnrale, ces runions ont connu une faible
participation qui peut tre priori explique, premire vue, par lindisponibilit des
personnes et leur engagement auprs dautres projets. Cela dit, les acteurs ayant russi
maintenir leur participation ont t amens, plusieurs reprises, se connecter depuis leur
tlphone portable et pendant leurs transports, pour changer sur leurs activits et sur les
problmes rencontrs. Dans de telles circonstances, lefficacit des runions quotidiennes
ralises peut facilement tre remise en question dans la mesure o lenvironnement
informatif vis par celle-ci perd de sa valeur.

Certains experts en dveloppement agile (Herbsleb & Grinter, 1999 ; Sutherland, Blount
& Puntikov, 2007 ; Paasivaara Durasiewicz & Lassenius, 2008) prconisent la dcomposition
du projet en diffrents modules indpendants o chacun est pris en charge par un nombre
restreint dacteurs autonomes, capables de communiquer de faon frquente et de prendre des
dcisions. En ce sens, le regroupement des acteurs par module leur permet de communiquer
en direct et de rduire les activits de documentation trs coteuses ainsi que les temps
152

Chapitre V : Variables de cration de sens de la dmarche

dattente des dcisions et dinformations. Il serait possiblement intressant de mettre en uvre


une telle dcomposition au sein dquipes impliques dans une mme activit, en loccurrence
la programmation. Or, lorsque diffrentes quipes mtiers sont concernes par le projet et
chacune, possde un mode de fonctionnement propre et est engage dans plusieurs projets
simultanment, la dcomposition du projet en diffrents modules indpendants devient
difficilement envisageable puisquelle exige une restructuration organisationnelle et de gros
investissements en termes de temps et de moyens.
2.2 La structure organisationnelle
Limplmentation des pratiques agiles nest pas la mme sil sagit dune structure
organisationnelle adhocratique ou sil sagit dune structure complexe et rigide .
Une structure de type adhocratique constitue un cadre idal pour les quipes agiles car
elle favorise la communication informelle, la flexibilit et la ractivit. Cependant, le cas qui
nous intresse se caractrise par une structure de type lightweight , selon la terminologie de
Clark et Wheelwright (Clark & Wheelwright, 1992 dans Midler, 1993b), o le statut du chef
de projet est dpourvu dinfluence forte. Ce dernier collabore avec diffrents acteurs (acteurs
projets, acteurs transverses provisoires, sous-traitants, etc.) et ne dispose pas dautorit
hirarchique sur les personnes quil gre.
En effet, la structure organisationnelle de lentit tudie, affecte les formes daccords et les
actions entreprises par rapport la dmarche. Les acteurs lean ont largement mis sur la
flexibilit des outils agiles retenus en vue de les adapter aux contextes des projets.
Revenons sur lexemple des runions quotidiennes. Ces dernires ont t dtournes de la
manire dont elles sont dfinies par leurs auteurs (Schwaber, 2004 ; Beck, 2004) et ont t
remplaces par des runions de frquence variable (deux trois fois par semaine) sloignant
ainsi de leur finalit principale.
Lide du brief quotidien cest un petit quart dheure, o le chef de projet connait le boulot
de chacun au jour le jour. cest ce quon dit dans les mthodes agiles mais aprs est ce
que dans la ralit on le fait deux fois par semaine (RB), - on peut tre flexible et le faire
tous les deux jours en fonction de la phase du projet (TR).
Par ailleurs, nous pouvons croire quil suffit au chef de projet dinsister auprs des diffrents
responsables mtiers afin que leurs collaborateurs respectifs participent aux runions
quotidiennes quil pilote. Bien que lintervention de ces responsables soit une condition
153

Chapitre V : Variables de cration de sens de la dmarche

ncessaire pour limplication des acteurs mtiers dans ce type de runions, celle-ci demeure
insuffisante. Dans le cadre de la structure des projets Nextv, les acteurs mtiers sont
sollicits par diffrents projets. En ce sens, ils peuvent tre amens participer plusieurs
runions en parallle. Ainsi lanimation de runions quotidiennes avec lensemble de lquipe
devient difficile envisager.
En tant que chef de projet, on n'a pas de gestion d'quipe. On gre notre quipe sur un
projet mais il ny a personne qui nous est rattach. Je n'value le travail de personne par
exemple, je ne dis pas voil, lui a fait un bon boulot ou pas, je ne fixe pas des objectifs On
pioche dans des pools de ressources grs par d'autres chefs.cest compliqu car on va
demander des tches des personnes dont on nest pas le chef (CR) ;
Les personnes qui sont partages sur plusieurs projets peuvent tre sollicites sur plusieurs
briefs (DT).
La capitalisation sur les connaissances et le suivi rgulier des activits des quipes projets ne
sont galement pas garanties car dune part, les quipes impliques dans un projet sont
instables et dune autre, chacune de ces quipes est rattache un responsable fonctionnel
diffrent et bnficie dun mode de fonctionnement qui lui est propre : diffrents indicateurs
de performance, modes de communication et de collaboration intra-quipe, modes de
planification, etc.
Cest difficile de mettre en uvre le partage de connaissance car chaque personne gre son
propre planning. Le chef de projet est un chef dorchestre, il ne matrise pas les activits des
contributeurs qui ont leurs contraintes et priorits (TR) ;
Le problme est un problme de mettre autour de la table des personnes qui ny viennent
pasil y a des acteurs avec qui le chef de projet na pas trop de visibilit ni de rigueur
(RB).
Comment lont fait remarqu les acteurs concerns par ce travail de recherche, linstabilit
des quipes et lautorit hirarchique limite du chef de projet ont ainsi compliqu la mise en
mise en place des outils agiles proposs. Les changements dacteurs en cours de projets
requirent des efforts supplmentaires en termes de renforcement de la cohsion des quipes
et de communication entre les membres de celles-ci. De plus, lintervention ponctuelle des
acteurs engendre une perte dinformations et de connaissances empchant par consquent la
capitalisation sur les projets mens. Cela nous conduit repenser lagilit et son adaptabilit
diffrents types de contexte. Non seulement les pratiques agiles ncessitent des quipes de
154

Chapitre V : Variables de cration de sens de la dmarche

taille rduite, colocalises o les individus coordonnent leur travail en communiquant de


faon informelle les uns avec les autres, mais leur mise en place requiert des quipes stables,
travaillant ensemble et engages dans un projet maximum, voire deux. Or, laune des
organisations par projets, la constitution dquipes permanentes est assez rare. Les acteurs
sont amens, systmatiquement, apprendre travailler et collaborer ensemble. Dans un tel
contexte, lesprit dquipe qui qualifie les quipes agiles est difficile cultiver.
Il y a un mouvement dans lquipe, les personnes concernes par le brief ne seraient pas les
mmes les architectes ne sont pas les mmes quand on est dans ltude ou dans la
production. En plus il y a des gens qui arrivent en cours de route je ne matrise pas les
activits des contributeurs il y a vraiment une perte dinformations lie au dpart des
personnes au cours du projet (CR) ;
Il y a des quipes qui sous-traitent avec lextrieur et donc on na pas de visibilit ldessus (CR).
En effet, les caractristiques de la structure organisationnelle ont fait lobjet de diverses
discussions entre les membres de lquipe lean . Elles se prsentent comme des contraintes
affectant la manire dont la dmarche est conduite. Lorganisation tudie repose sur une
structure complexe qui rend difficile la transposition des pratiques managriales portes
par le courant agile . Prenons lexemple du suivi rgulier de la performance. En effet, les
quipes projets semblent manquer dindicateurs de gestion leur permettant davoir une vision
dynamique de la performance du projet. Chacune des quipes avec qui collabore le chef de
projet dispose dindicateurs qui lui sont propres. La granularit des indicateurs varie en
fonction des phases du projet : lquipe de dveloppement, utilisant la mthode scrum ,
dispose dindicateurs quantitatifs permettant de mesurer le travail au quotidien, lquipe de
qualification communique au chef de projet, de faon hebdomadaire, son avancement en
termes de pourcentage par rapport aux chances. En ce qui concerne les architectes, ils ne
disposent pas dindicateurs quantitatifs, ils communiquent leur avancement de faon trs
macro .
La difficult quon a au niveau de notre cycle de vie cest bien de pouvoir mesurer notre
productivit aux diffrentes tapes de celui-ci Laspect de la performance au quotidien
nest pas tout fait une culture que nous avons, on a donc une valuation globale sur
lensemble de nos activits (TR).

155

Chapitre V : Variables de cration de sens de la dmarche

Dans une structure de type adhocratique , la proximit entre les individus permet davoir
des clarifications rapides sur lavancement des tches et dassurer leur contrle en temps rel.
En revanche, dans une structure complexe o les acteurs sont attachs hirarchiquement
diffrentes units fonctionnelles, lvaluation de la performance est plus difficile raliser sur
le court terme. Il nest pas vident pour le chef de projet dexiger un compte rendu quotidien
sur les activits des acteurs mtiers quil coordonne dans la mesure o il ne dispose que dune
faible autorit hirarchique cest compliqu car on va demander des tches des personnes
dont on nest pas le chef... (CR).
Outre la structure organisationnelle, le systme de management de projets existant semble
avoir galement affect lorientation de la dmarche.
2.3 Mode de management de projet
Dans lentit Nextv, les projets sont gnralement mens selon un mode squentiel
sappuyant sur une sparation des expertises entre les diffrents mtiers et valorisant la
planification et la documentation exhaustives. Ces pratiques managriales, propres lentit,
constituent une variable de cration de sens pour lquipe lean . Nous tenterons, ds lors,
de comprendre leur influence sur la manire dont la dmarche a t apprhende.
Le temps consacr lanticipation des demandes et la planification dtaille du projet
semble aller dans le sens inverse des principes soutenus par le courant agile . La mise en
pratique de ces principes dans un environnement pilot par la planification et la
documentation se heurte plusieurs difficults.
Dans lentit Nextv, le style de management des quipes se transforme au fur et mesure de
lavancement du projet. Un chef de projet norganise pas de la mme manire une phase de
conception et une phase de qualification durant laquelle il sera en contact permanent avec son
quipe. Habituellement, des runions hebdomadaires de longue dure sont menes sparment
et successivement avec chacune des entits impliques dans la ralisation du projet. Suite
ces runions, un ensemble de compte-rendu est labor et diffus au sein de lorganisation.
Lide de mettre en place des runions quotidiennes de courte dure a cependant t mal
accueillie. Ces runions taient perues comme une charge supplmentaire grer, bien que
leur objet diffre largement des runions de revues hebdomadaires. La difficult de motiver

156

Chapitre V : Variables de cration de sens de la dmarche

les acteurs projets assister des runions supplmentaires et dintercaler celles-ci aux
runions dj existantes ont t les principaux arguments avancs par les chefs de projet.
Aujourdhui on termine 19 heures, il faut voir la raction des gens pour rajouter encore
une autre runion (ER) ;
Si je vais encore faire ces daily briefs, je vais passer mon temps faire des runions Les
responsables transverses sont trs sollicits et donc ils sont surchargs (CR) ;
Un des problmes cest quon a beaucoup de runions et je ne pense pas que a serait bien
des runions qui se doublonnent Les gens se plaignent car les runions sont trs longues,
a dure 4 heures... (DT).
Sur la base des arguments avancs par les acteurs pilotes, il a t dcid dadapter les outils de
collaboration et de coordination en fonction du contexte de chaque projet. La frquence de ces
runions a t rajuste selon la phase du projet. Comme nous lavons dj prcis, ces
runions peuvent tre quotidiennes ou rduites une frquence de deux trois fois par
semaine selon les besoins du chef de projet. Comment savoir lavance quelle(s) phase(s) du
projet ncessite(nt) un partage rgulier dinformations alors que les projets informatiques
relvent de nombreuses incertitudes ? Ce constat nous amne remettre en question les
critres sur lesquels les acteurs lean se sont bass pour dterminer la frquence de ces
briefs et nous intresser aux raisons qui justifient leurs choix.
La complexit de la structure organisationnelle et les caractristiques des projets ne
constituent pas les seuls facteurs ayant conduit les acteurs lean rduire la frquence des
runions et limiter le nombre des participants. Le manque dintrt des chefs de projet
lgard de ces nouveaux outils et leur encombrement ont galement eu un impact sur les
choix dactions entreprises par les acteurs lean .
Pour les briefs a va dpendre du contexte et du moment du projet. Peut tre en phase
dtude il ny a pas matire faire des briefs tous les jours, ou en phase de conception cest
diffrent, Donc on nadaptera en fonction du moment, du contexte et des enjeux (TR) ;
On fait le brief quavec les personnes qui sont sur le chemin critique... pour moi le point
important cest les acteurs actifs. dans la littrature, on dit quau quotidien le manager fait
un brief, mais l on peut tre flexible et le faire tous les deux ou trois jours en fonction de la
phase du projet (RB).
Par ailleurs, la documentation exhaustive constitue une autre activit valorise par les quipes
de Nextv et un facteur additionnel de cration de sens de la dmarche. Comme nous lavons
157

Chapitre V : Variables de cration de sens de la dmarche

constat dans la premire section de ce chapitre, le mode de communication formelle gnre


beaucoup de gaspillages : temps de rdaction et de lecture des documents, documents
obsoltes, etc. De plus, la documentation produite est rarement conforme aux attentes des
acteurs projets : documents incomplets, documents livrs tardivement.
On a un paquet de reporting faire J'ai un compte rendu global dans lequel je donne les
liens vers tous les comptes-rendus avec le client, les oprationnels, les architectes. Ils se
trouvent sur Roll et sont envoys par mail mais franchement ils ne s'en servent pas. Ils ne les
lisent pas du tout. Il y a que moi qui m'en sert (CR).
On na pas de spcifications dtailles qui consolident le tout on a un vrai problme de
dficit de documents sur certains composants qui sont relativement anciens.quand tu
arrives sur un sujet et tu essayes de faire des documents sur certains sujets tes vraiment
paum (LM).
Du point de vue des partisans des mthodes agiles , la documentation doit tre rduite aux
maximum et tre remplace par des livrables concrets matrialisant les diffrentes phases du
projet : design, conception, dveloppement, tests, etc. ( working

software over

comprehensive documentation , Agile Manifesto). Pour cette raison, lquipe lean a


dcid de mettre en uvre un plan daction qui vise rduire la quantit de la documentation
produite. Conscients des cots engendrs par la documentation, les acteurs projets ne sont pas
prts abandonner ce type de pratiques Laurence (chef de projet) considre que tous les
documents qu'elle a eu sont indispensables pour son projet (JP). Cette attitude peut
sexpliquer par la culture organisationnelle qui est une culture de non prise de risque
valorisant les processus et procdures trs formels : les prises de dcisions ncessitant
laccord de diverses instances hirarchiques, le besoin de traabilit des actions entreprises
conduisant une documentation extensive tout le monde prend trop de prcaution ce qui
rend toutes les actions trs longues (GC). Dans cette optique, la documentation constitue
une sorte dassurance pour les acteurs mme si, trs souvent, elle savre inutile. Dans de tels
environnements, les pratiques agiles encourageant la communication orale au dpend de la
documentation crite sont rarement apprcies.
Le mode de fonctionnement squentiel adopt par lentit Nextv semble avoir influenc
implicitement lorientation de la dmarche. Le cycle de vie squentiel des projets freine la
mise en uvre de pratiques agiles qui elles, mettent en avant la flexibilit et ladaptation
aux changements. Prenons lexemple du dveloppement itratif. En dveloppement
158

Chapitre V : Variables de cration de sens de la dmarche

informatique, il parat impensable de contourner les changements qui arrivent en cours du


projet. Les quipes sont invites sadapter aux demandes volutives du march et intgrer
continuellement les retours sur les solutions dveloppes. La proximit entre les members
dune quipe et les courts cycles de livraison facilitent les feedback rapides et permettent les
changements. En revanche, dans une organisation de type classique o les projets sont
habituellement de longue dure et sont mens de faon squentielle, les processus et les outils
formels seront privilgis car ils permettent dassurer un meilleur contrle des risques. Dans
un tel contexte, la mise en place dun systme de dveloppement itratif ncessite un
changement radical du mode de fonctionnement des quipes qui, en raison de sa complexit,
na pas t envisag par les acteurs lean .
Normalement, au dbut d'un projet t'as un scope qui est dfini l le rate avec eux est par
exemple, qu'ils vont corriger plus qu'ils ont demand, moi a pourrait me foutre le projet dans
l'air (CR) ;
On essaye de rajouter des trucs mais on na pas le temps et donc je passe du temps
dfendre cela et donc je rate du temps dfendre au lieu de faire autre chose (CR) ;
Tous les trucs de replanification qu'on peut me redemander me fait perdre normment de
temps (DN).
2.4 Les ressources mobilises
Le sens de la dmarche a t largement imprgn par les retours dexpriences
dorganisations prsentant un contexte similaire : quipes godistribues, transverses, larges
projets. Ces retours dexprience sont, pour les acteurs lean , une aide pour concevoir la
mise en uvre de la dmarche dans leur propre contexte organisationnel. Lors de la
construction des outils agiles , lquipe lean sest appuye sur des prsentations
dorganisations ayant implment, au sein de leurs quipes, des runions quotidiennes et un
management visuel (Annexe VI-VII). Toutefois dans ces prsentations, les organisations
nont pas prcis comment elles ont procd pour mettre en place ces outils. En outre, la
majorit des prsentations mobilises ont concern des quipes colocalises (Annexe VII).
Par consquent, le manque dinformations et de cadres pour implmenter ces outils a t
peru comme une difficult dans la mise en place de la dmarche.
De manire plus concrte, les acteurs se sont attachs dune part, analyser la manire dont
les runions quotidiennes et le partage visuel de tableaux de bord et dindicateurs se font au
niveau dquipes godistribues et dune autre, reporter les effets dusage de tels outils. Les
159

Chapitre V : Variables de cration de sens de la dmarche

supports de prsentations ainsi mobiliss ont pour objectif de rpondre deux facteurs
problmatiques identifis par lquipe lean : la godistribution et la transversalit des
quipes.
Sur la problmatique de la dispersion gographique et donc du pilotage transverse, les gens
dOS ont le mme souci, et ils ont quand mme mis en place une modalit danimation de
brief, un management visuel et un suivi de performance Nous avons aussi eu des retours
dexpriences de personnes travaillant prcdemment chez ML On utilise les retours
dexpriences, pour illustrer les formations (TR);
Je pensais demander OS sur la manire dont ils procdent pour organiser et animer les
briefs. cest comme notre contexte. Il nest pas question davoir des gens qui se dplacent
car ils sont dans les 4 coins du monde (RB) ;
On peut sappuyer sur le support quutilise la socit TL dans leur brief.... Dans la pice
jointe, ils prsentent plus en dtails comment ils mettent en place le brief -lobjectif est donc
de regarder ce quils font et den tirer les meilleures pratiques (RB) ;
Je connais quelquun qui travaille la SG et il ma dit quils ont eu des rsultats
formidables, on pourra faire un point avec lui pour avoir quelques lments explicatifs de
quest ce que a change et donc profiter des retours dexprience avant de procder
(RB).
Si ces supports ont permis lquipe lean de mieux comprendre et communiquer la vise
des outils collaboratifs retenus (contenu des runions quotidiennes, diffrenciation dune
runion quotidienne par rapport une runion dquipes, rle du chef de projet dans ces
runions, exemple de tableau blanc et dindicateurs de performance partags, etc.), ils
nillustrent pas, toutefois, la manire dont ces outils sont concrtement dploys au niveau
dquipes de pilotage transverses, godistribues. En dautres termes les retours dexpriences
ne prcisent pas, du moins explicitement, la manire dont les runions sont organises dans de
tels contextes, les technologies utilises, les outils de collaboration et de coordination
complmentaires mobiliss, les dfis majeurs rencontrs et la manire dont ils ont t
surmonts, etc. Les acteurs lean se sont alors rendus compte du manque dexemples
concrets qui leur aurait permis de dcliner ces outils dans leur propre environnement. Par
ailleurs, si ces nouvelles mthodes managriales ont dj t apprhendes dans un
environnement global, elles ont souvent concern les quipes de dveloppement. Or dans le
contexte prsent, les acteurs concerns par la dmarche appartiennent des quipes qui ne
sont pas impliques dans la programmation.

160

Chapitre V : Variables de cration de sens de la dmarche

Le manque de retours dexprience et les connaissances limites des acteurs par rapport la
mise en place de ces outils pourraient justifier, dune part, les longues heures passes en
runion ngocier les propositions soumettre aux quipes pilotes et dautre part, lide
abstraite et thorique que se sont faites ces dernires de la dmarche. Nous sommes, par
consquent, amens considrer que ces supports thoriques mobiliss nont pas facilit la
mise en uvre et lacceptation des outils et pratiques agiles . Les quipes pilotes ne
voyaient gure dintrt dans la manire dont la dmarche a t propose. Lquipe lean
manquait dlments concrets pour envisager ladaptation de la dmarche au contexte des
projets pilots par lentit Nextv.
On dit quon va changer un tat desprit, un mode de fonctionnement, un systme de
management, etc. mais il faudrait quon puisse donner quelques cas dillustration (TR) ;
Jai t au rendez vous dinformation lean mais je nai pas retir grand-chose Je trouve
cest trs conceptuel. Il faut adapter notre discours en tant plus dans les exemples (OD) ;
Il faut certainement prsenter des exemples de russite et des cas concrets de la dmarche
(FB) ;
On a du mal comprendre le bien fond de la dmarche (PM) ;
Le kaizen est trop abstrait, il faut sadresser de faon plus oprationnelle aux quipes
(JMW) ;
A priori on na pas trouv des expriences sur les briefs au niveau des quipes qui ne sont
pas hirarchiques.. Aujourdhui on est encore en manque de retours dexpriences et de
boites outils, il serait important de faire appel la crativit de chacun (TR).
Il apparait donc utile quune organisation, souhaitant emprunter la voie de lagilit, dispose
dexemples prcis et dtaills sur lapplicabilit des pratiques et outils ports par ce courant
managrial mergent. Ceci est dautant plus vrai lorsquil sagit dune organisation
complexe caractrise par une structure matricielle et des quipes mtiers transverses
distribues gographiquement. Nanmoins, lheure actuelle, la majorit des tudes de cas
ralises ont port sur des quipes de taille rduite impliques dans des projets de courte
dure, contrairement au contexte prsent.
Il convient ici de rappeler que mme si les organisations prsentent des caractristiques
contextuelles communes, elles ne ragissent pas toutes de la mme faon. Comme nous
lavons prcdemment indiqu, les individus agissent sur leur environnement en fonction des
interprtations et des significations quils attribuent celui-ci. Plusieurs facteurs contextuels
peuvent ainsi rentrer en jeu, influencer le sens cr et par consquent les actions menes. Dans
161

Chapitre V : Variables de cration de sens de la dmarche

cette perspective, un systme managrial adopt par une organisation ne peut pas tre
simplement copi et appliqu de la mme manire dans une autre. Les individus vont
sappuyer sur des variables de lenvironnement quils peroivent mais qui peuvent aussi le
dpasser. Le sens des pratiques et principes managriaux diffrent et voluent en fonction des
situations. Il est donc important de prendre en compte ce quils reprsentent dans leur propre
contexte. Ce cas de figure nous fait penser lexemple donn par les Poppendieck (2006) sur
les entreprises ayant tent, dans les annes 1990, de copier le systme kanban chez
Toyota. Les rsultats mdiocres affichs par ces entreprises sexpliquent par le fait que cellesci navaient pas peru le lean comme un systme de management dont lobjectif principal
vise liminer le gaspillage ou quelles sont passes ct du principe central de cette
approche : le respect des personnes.
2.5 Les parties prenantes du projet lean
Bien que le rle quoccupent les parties prenantes est inhrent la mise en place de la
dmarche, lquipe lean sest principalement focalise sur trois acteurs mtiers (chefs de
projets, architectes, CPM) et en particulier les chefs de projets avec lesquels ils ont men
divers entretiens et runions : Pour que a marche il faut que le chef de projet soit
convaincu que la dmarche va bien laider pour que lui derrire russisse convaincre ses
interlocuteurs (RB). Peu dattention a ds lors t accorde aux autres parties prenantes :
les acteurs oprationnels, le marketing, les mtiers transverses, etc. Ce choix peut sexpliquer
par le fait que lquipe tait contrainte par le temps, que son autorit assez limite lui
empchait de mobiliser le reste des entits ou simplement, quelle prfrait emprunter la
voie qui, selon elle, paraissait la moins complexe pour aborder la mise en place de la
dmarche. Ce cas de figure nous renvoie la notion de plausibilit qui semble tre au cur de
la dmarche lean .
Si la phase pilote de la dmarche na concern que quelques acteurs mtiers cest aussi parce
quelle na pas t considrablement consolide par la hirarchie, reprsente ici par lquipe
N-1 ou le top management. Les enjeux soulevs par la direction gnrale, lors du
sminaire organis avec les quipes projets de lentit, taient insuffisants pour mobiliser ces
dernires et les inciter sengager dans la dmarche. Malgr le soutien de la direction
gnrale, les acteurs lean se sont ainsi retrouvs noys dans la dfinition et la mise en
uvre de ces nouvelles approches managriales.
162

Chapitre V : Variables de cration de sens de la dmarche

Dans notre situation, le support on la toujours eu ds le dpart, de JM (directeur gnral)


et l il na jamais fait de dfaut.par contre au niveau intermdiaire, les N-1 de JM
(directeur gnral), la situation tait plus mitige (TR) ;
Il y a un besoin dimplication du top management, part le directeur Gnral qui est trs
sponsor sur le sujet, je nai pas limpression que les autres membres du top management
soient autant impliqus la direction a un rle fondamental jouer pour mobiliser les
gens (RB) ;
Passer un message au Codir quil doit tre exemplaire dans cette dmarche damlioration,
de les mobiliser, ils sont quand mme un peu spectateur quoi (RB).
Outre le pouvoir lgitime du top management et sa capacit influencer le dploiement des
outils et pratiques agiles , les managers dquipes (chefs de projet, directeurs de projets)
occupent galement une place centrale au sein de la dmarche, dans le sens o ils sont
capables de renforcer limage de cette dernire auprs des acteurs quils grent et augmenter,
par consquent, son taux dacceptabilit.
Peut tre quil y a une autre manire de procder, je pense quon na pas assez travaill
avec les managersNous sommes revenus sur ce sujet, et donc plus largement comment les
managers simpliqueront progressivement dans la conduite des ateliers ? (TR) ;
Les managers doivent montrer de lintrt au travail qui a t faitLR est due et sest
refroidie aprs les runions (JP).
La faible implication des managers a compliqu ladoption et la m ise en uvre de la
dmarche. La dmotivation des managers est ds lors considre comme une contrainte
affectant limplmentation du projet.
Il y a un manque de volont managriale pour lancer les groupes de travail Plusieurs
managers nont pas particip (PB) ;
La dmarche est peu utilise ici et donc je me sens un peu seul (GC) ;
La dmarche de changement il faut dj la travailler avec les managers (TR).
Lefficacit de la dmarche dpend galement de limplication de acteurs dautres services
fonctionnels : les mtiers transverses (dveloppement, qualification, architecture, etc.), le
marketing, le R&D, etc. Dans cette perspective, la centralisation de la dmarche sur les
mtiers de lentit na pas favoris les gains potentiels lis aux outils utiliss (runions
quotidiennes, analyse des dysfonctionnements, QQCQOP, tableau blanc) et encore moins
lorganisation lean vise par la direction. Cette constatation a t souleve par diffrents
acteurs pilotes qui ont mis laccent sur les limites dappliquer les pratiques et outils agiles
163

Chapitre V : Variables de cration de sens de la dmarche

sur un primtre restreint o seuls quelques mtiers de lentit Nextv sont inclus Pourquoi
ne pas impliquer dans la dmarche plus dingnieurs qualit car jai limpression que
plusieurs choses se recoupent (CM) ; Il serait pas mal de refaire une sance de
recherche de problmes mais avec plusieurs services (PLP). Les acteurs transverses
occupent un rle primordial au sein des projets pilots par celle-ci. En effet, rares sont les
problmes qui peuvent tre rsolus en interne sans limplication des mtiers transverses. En ce
sens, les directions de marketing, de dveloppement, de qualification, de maintenance, etc.
doivent galement faire partie de la dmarche et des plans dactions. Prenons lexemple de
lamlioration de la satisfaction du client. En gnral, le client est satisfait si le produit livr
est conforme ses besoins, trs souvent volutifs. De ce fait, une quipe de pilotage de projet
qui va mettre en place des runions rgulires avec ses quipes, sans toutefois impliquer le
marketing, aura du mal rpondre ses demandes volutives. Dailleurs, les personnes
impliques dans la phase pilote ont voqu le besoin ultime de faire participer le marketing
la dmarche et cela parce que la majorit des difficults auxquels elles sont confrontes
relvent de leurs rapports avec celui-ci et du faible intrt quil leur accorde.
Je me posais la question si on pouvait mettre les outils un primtre plus large et
impliquer dautres acteurs notre problme est dchanger souvent avec le marketing
(PC) ;
Je pense quil manque des acteurs aujourdhui comme le marketing impliquer dans le
projet A FT je veux bien mais bon je pense quil manque des acteurs. (LM) ;
Nous on va travailler dans le sens damlioration de rduction de gaspillage, mais est-ce
que ce travail se fait aussi dune autre manire mais paralllement du ct du marketing.
(Participant au rendez-vous dinformation).
Ce nest quau fur et mesure de lavancement du projet, que les membres de lquipe
lean se sont rendus compte de limportance de certaines parties prenantes dans la mise en
uvre de la dmarche. Partant dune logique conduite par la plausibilit, ils se sont accords
se focaliser davantage sur les directeurs de projets rattachs lentit Nextv afin de les
intgrer dans la phase de gnralisation du projet. Or ces derniers ne montrrent gure
denthousiasme. Diffrents facteurs peuvent expliquer ce manque dintrt prouv : la
lassitude du changement, la surcharge de travail et le changement de posture managriale
quexige cette nouvelle approche de management.
Aujourdhui, les directeurs de projets affichent une certaine rticence quant la multiplicit
des programmes de changement organisationnel. Lincertitude lie aux avantages de la
164

Chapitre V : Variables de cration de sens de la dmarche

dmarche lean propose, peut expliquer la dmotivation de ces acteurs et leur manque
dimplication. Il apparat quune lassitude par rapport aux plans damlioration sest
progressivement instaure au sein de lentit. Une lassitude qui sest traduite par un faible
engagement des managers dans les plans dactions ports par la dmarche.
Globalement il est difficile de mobiliser les acteurs sur la nime tentative damlioration
des processus (GC) ;
Il faut voir quon est dans le changement permanent FT donc du coup, moi le premier, on
est parfois dubitatif. Au bout dun moment, la lassitude qui sinstaure, on dit voil les
nouveaux mthodes, les outils jen ai vu, et jen verrai dautres, ce que vous dites mintresse
mais jai du boulot (TR).
La surcharge de travail, quant elle, constitue une autre raison pour expliquer le manque
dintrt des directeurs de projets. Tout dabord, le temps que ncessitent les formations et les
priodes dappropriation des pratiques et outils agiles nencourage pas les managers
faire partie de la dmarche lean . Ces derniers doivent faire preuve de rigueur et de soutien
continu auprs de leurs quipes alors quils sont surchargs et pris par leur travail habituel.
Prenons le cas des runions quotidiennes et des ateliers kaizen : les runions imposent au
manager davoir une certaine discipline pour rassembler, au quotidien, les membres de son
quipe et maintenir une cadence rgulire dans le suivi et le contrle des projets. Quant aux
ateliers kaizen, ils exigent un comportement rigoureux dcoute et une prsence rgulire du
manager sur le terrain, difficile raliser lorsque plusieurs projets et quipes sont pilots en
parallle. Les efforts induits par la mise en place de ces outils, la complexit des projets
existants et le manque de temps peuvent, ds lors, expliquer ce faible enthousiasme lgard
de la dmarche.
La ralit est que le quotidien passe avant le projet lean .. Vis--vis des pratiques
proposes, les acteurs ne le clament pas car ils ne veulent pas avoir tous les outils sur le dos,
a gnre une perte de temps (ER).
Une troisime raison pour interprter la faible participation des directeurs de projets est le
changement de posture suscit par cette nouvelle approche managriale. En effet, une
organisation lean suit une logique bottom-up . Ce systme de management repose sur
les comptences des personnes qui occupent diffrents niveaux hirarchiques et en particulier
celles qui se situent au niveau oprationnel front-line . Ces dernires constituent un
lment cl dans le cycle de vie des projets. Elles sont impliques dans les dcisions et
165

Chapitre V : Variables de cration de sens de la dmarche

lamlioration continue des processus et jouent un rle vritable pour atteindre les objectifs
fixs. Dans cette logique, les responsabilits de prise de dcisions et de dfinition des
objectifs sont rparties entre les quipes et leur manager. Ce nouveau style de management
ncessite donc un changement de mentalit des managers qui, gnralement, nont pas
lhabitude de dlguer leurs pouvoirs et de se concerter avec leurs collaborateurs pour les
opportunits damlioration dans lentreprise. Il nest donc pas surprenant que certains
managers peroivent ce principe de renforcement des quipes comme une menace leur
statut hirarchique et une dvalorisation du rle quils occupent au sein de lorganisation. Cet
lment peut permettre dinterprter le faible intrt accord ce style de management.
Dailleurs, cette raison fut galement remonte dans les discussions des acteurs lean .
Dans lanimation lean + kaizen on cherche de faire en sorte que lamlioration vienne des
quipes et ce sont les quipes qui disent sur quoi il faut travailler, sur quoi il faut samliorer.
Ce nest plus le manager qui sait tout, qui intervient comme ultime sauveur.Et donc
videmment que pour des personnes, se mettre dans cette posture l nest pas aussi simple
do aussi la rsistance de leur part.. (TR).
Divers facteurs tant organisationnels, politiques quindividuels peuvent ainsi conduire les
parties prenantes abandonner la dmarche managriale suggre. La prise en compte des
attentes de ces dernires est un lment dterminant pour parvenir limplmentation de ces
nouvelles pratiques de management de projets. Toutefois certaines parties prenantes occupent
un rle plus critique dans lorganisation et par consquent leur participation savre
dterminante pour mener bien la dmarche.
Tout au long de la dmarche, les acteurs lean ont tent de concilier les objectifs du projet,
les caractristiques organisationnelles et les exigences des acteurs pilotes en vue de mettre en
place des pratiques managriales cohrentes avec leur contexte.
Lanalyse des pratiques discursives des acteurs et leurs interactions avec leur environnement
nous a permis de mettre en lumire les lments dordre contextuel qui semblent avoir
influenc la mise en uvre des outils agiles . Diffrents lments ont t identifis par les
acteurs lean comme dterminants dans limplmentation des innovations managriales
de type agile : (1) la taille et la godistribution des quipes ; (2) la structure
organisationnelle (structure de type lightweight, lautorit limite du chef de projet) ; (3) la
composition des quipes (acteurs mtiers transverses rattachs diffrents services
166

Chapitre V : Variables de cration de sens de la dmarche

fonctionnels, prestataires externes), (4) le manque dimplication des parties prenantes


(manque de support du top management, manque dintrt des manageurs de projet), (5) le
manque de ressources informationnelles sur limplmentation des outils agiles dans des
organisations transverses et godistribues ; (6) le style de management actuel (la
documentation extensive, le cycle de vie squentiel, la planification extensive, runions
hebdomadaires de longue dure) qui ne semble pas faciliter lintgration des pratiques et
outils agiles ; (7) la non implication des acteurs transverses cls (quipes de
dveloppement, marketing, quipes de qualification, etc.) ; (8) la faible autorit hirarchique
de lquipe charge de la mise en place de la dmarche damlioration, (9) le manque de
support du top management et (10) la lassitude des quipes quant aux programmes de
changement. Ces facteurs peuvent expliquer les difficults entravant lappropriation et la
contextualisation des outils agiles au sein de Nextv. Les substrats techniques associs
ces mthodes mergentes de management de projet sont peu adapts des structures
organisationnelles complexes.
Dans ce chapitre, notre attention sest focalise sur les proccupations des individus et les
significations quils ont attribues leur environnement. Nous avons ainsi tent de
comprendre et dinterprter, du point de vue de ces acteurs, les facteurs contextuels qui
semblent avoir contraint la mise en uvre de la dmarche managriale.
Comme le montrent ces rsultats, limplmentation dune dmarche base sur des principes
agiles est loin dtre facile raliser, en particulier, lorsquil sagit dune structure
organisationnelle complexe.

167

168

Chapitre VI : Discussion

En nous appuyant sur la grille danalyse de sensemaking, nous expliquons la manire dont la
dmarche lean a t construite partir des pratiques situes des acteurs et de leurs
interactions.
Ce chapitre est une occasion pour discuter nos observations et analyses et mettre en avant les
pratiques sur lesquelles sappuient les acteurs impliqus dans la fabrication dune
dmarche managriale agile .

169

Chapitre VI : Discussion

Comprendre

comment

une

organisation,

caractrise

par

une

structure

organisationnelle complexe, sengage dans la mise en place dune stratgie managriale de


type agile est l'un des principaux buts viss par cette thse. La quasi inexistence d'tudes
consacres ce sujet nous a conduit nous interroger sur ce que font les acteurs chargs de la
mise en uvre des mthodes agiles en tant qu' innovations managriales et comment ils
font pour aboutir des rsultats stratgiques au sein de leur entreprise.
Afin de rpondre notre problmatique de recherche, il nous a paru opportun de nous
rapprocher des tudes qui sinscrivent dans le tournant de la pratique et daborder
limplmentation des outils agiles comme pratique . Le phnomne dimplmentation
de la dmarche lean a donc t apprhende dans son contexte en articulant le niveau
micro (activits dinterprtation, outils mobiliss, les activits de cration et de diffusion
de sens, etc.) et le niveau macro (structure, rgles, ressources, etc.). Il a t abord du
point de vue des acteurs qui participent sa construction et des liens quils entretiennent avec
leur environnement matriel et social.
Dans le chapitre prcdent, nous nous sommes contents de faire ressortir les lments
dordre contextuel tels quils ont t identifis par les acteurs concerns par la dmarche et qui
semblent avoir affect la mise en place de celle-ci. Si ces facteurs relvent dun contexte
particulier (profil du chef de projet, quipes instables, manque doutils cls en mains ,
etc.), ils constituent des difficults gnrales auxquelles peuvent tre confrontes dautres
quipes souhaitant sengager dans la voie de lagilit. Toutefois, les pratiques103 stratgiques
et les cadres de rfrence des individus diffreraient dun contexte un autre.

103

Par pratiques stratgiques nous dsignons les types routiniers de comportement qui consistent en diffrents
lments interconnects : formes dactivits physiques, formes dactivits mentales, choses et leur utilisation,
connaissances antrieures permettant la comprhension, savoir-faire, motions (Reckwitz, 2002, p.249, dans
Jarzabkowski, Balogun & Seidl, 2007).

170

Chapitre VI : Discussion

Ainsi, il apparat judicieux dexaminer de prs, en sappuyant sur la grille danalyse du


sensemaking, les pratiques partir desquelles les acteurs ont tent, par le jeu de leurs
interactions, de fabriquer , au sein de leur contexte, une stratgie managriale de type
agile .
La fabrique de la dmarche lean
La mise en pratique des principes et outils agiles auxquels les acteurs lean ont t
forms fut loin dtre facile raliser : les acteurs ont rapidement pris conscience de lcart
entre leurs attentes lgard de la dmarche et la ralit du terrain. Ils ont ainsi cherch
comprendre et catgoriser les lments problmatiques afin de les analyser, les mettre en
perspective les uns des autres, les coordonner et les rsoudre.
Au dbut, en tant que bons lves, on stait dit quon va mettre en place ce quon a appris
dans le cours, mais les effets quon a eu entre nous, en changeant, on a trouv quune
grande majorit des pratiques relevant du lean et des mthodes agiles ntaient pas possibles
sur une activit de pilotage transverse (TR).
Le point de dpart de la dmarche lean a t labsence dordre intrinsque partir
duquel les acteurs ont cherch organiser le flux dvnements en traitant certains indices
reprs dans leur contexte. La dmarche a t dlimite par lattention accorde un
ensemble de questionnements dordre managrial et organisationnel. Ces questions ont permis
aux acteurs lean de cadrer leur ralit organisationnelle avant de sengager dans
laction.
Comment on va travailler pour identifier les dysfonctionnements ? Quelles pratiques et outils
managriaux retenir ? Comment sadapter aux activits de pilotage de projets avec de
nombreuses contributions transverses ? Quels seront les acteurs concerns par notre
dmarche? Comment les convaincre par la dmarche ? Comment sorganise-t-on de telle
manire produire des rsultats tangibles dici trois mois ? (Acteurs lean ).
Cette premire srie de questions renvoie des situations problmatiques (la contrainte du
temps, le type dacteurs pilotes impliquer dans la dmarche et les pratiques agiles
mettre en uvre) auxquelles les membres de lquipe lean ont tent de rpondre. Au fur et
mesure de lavancement du projet, de nouvelles interrogations ont merg concernant
dautres aspects de la dmarche et de lorganisation :

171

Chapitre VI : Discussion

Comment est utilis le tableau blanc ? Est-ce qu'il y a un affichage du tableau blanc sur
chaque site ? Est-ce qu'il y aura des ateliers de rsolution de problmes au sein de lquipe,
qui regroupera des personnes de sites diffrents ? (Acteurs lean ).
Le profil des membres de lquipe lean et leurs expriences pourraient avoir influenc la
direction de la dmarche emprunte. Notons toutefois que les deux membres essentiels de
lquipe (le responsable et le coach) ne possdent dexpriences ni dans le dveloppement
agile ni dans la mise en place de ces mthodes. Ceci peut ventuellement expliquer les
questions dordre basique auxquelles les acteurs ont tch dapporter une solution : quels
pratiques et outils retenir, comment sadapter au contexte, comment est utilis le tableau
blanc ? . Les situations problmatiques telles quelles ont t cernes par lquipe lean
auraient peut-tre t diffrentes dans une autre quipe plus exprimente ou spcialise dans
ces pratiques managriales tout comme la collecte dinformations, linterprtation et laction.
Le recours des experts en ces mthodes aurait pu constituer, premire vue, une aide
primordiale pour lquipe ; et la dmarche aurait ainsi certainement pris une direction
diffrente : largissement du primtre de la phase pilote (implication de plusieurs services
fonctionnels, implication de diffrentes entits, etc.), mise en uvre de pratiques et/ou rgles
supplmentaires (rduction du cycle de vie du projet, livraisons itratives et incrmentales,
implication du client dans le dveloppement, etc.).
Les connaissances pratiques104 des individus partir desquelles ils ont cadr les situations
et leur ont attribu un sens semblent tre critiques dans la mise en uvre dune stratgie
agile . Ces connaissances sont mobilises dans les conversations formelles et informelles
des acteurs (runions, discussion, ngociations, interprtation, etc.) et dans les routines105 lies
leur poste de gestionnaire (validation du Codir, planification, dfinition des objectifs, etc.).
A ce titre, nous pourrons nous interroger, dans des recherches futures, sur les types de
connaissances pratiques que doivent avoir les acteurs impliqus dans la fabrication et la
mise en place dune dmarche managriale agile .
A travers leurs interactions, les acteurs communiquent leurs visions du rel pour aboutir une
entente sur les actions entreprendre et les comportements adopter. Lextrait ci-dessous
nous invite voir comment le sens de la dmarche sest construit collectivement travers les
changes de points de vue et darguments entre les membres de lquipe lean .
104

Les connaissances pratiques renvoient au savoir-faire du praticien de la stratgie (Rouleau & Balogun, 2007).
Ces connaissances sont explicites et tacites.
105
Les pratiques locales spcifiques un groupe dacteurs.

172

Chapitre VI : Discussion

Le fait davoir plusieurs profils dans notre dmarche pilote on va gagner normment, on
va collecter beaucoup dinformations (DF), - Si on raisonne par projet, on va remonter
beaucoup plus des difficults sur les cycles de vie du projet, sur les interactions et donc moins
des difficults propres un mtier en termes de concret, du quotidien dun mtier Par
contre par mtier, cest l quon a un enrichissement dune communaut mtier (TR) ; - Si
on fait par mtier on aura toutes les requtes sur les autres mtiers pour moi a navancera
pas les choses et il ny aura pas de dbats (DF) ;
a serait bien dintgrer un projet qui est en train de se mettre en place surtout qu la
phase de dmarrage les gens rencontrent beaucoup de problmes quils pourraient nous faire
remonter (JP) ;
On doit rflchir sur comment mettre en place le projet lean sur les deux axes : mtiers et
projets (RB).
Si certains acteurs ont considr que limplication dquipes mtiers 106 pourrait tre plus
bnfique pour la dmarche pilote, dautres ont plutt privilgi la diversit des profils
dacteurs concerns par un mme projet. Le raisonnement des membres de lquipe lean a
t guid par la nature et la varit des problmes que peut ventuellement mettre en avant
chacune des quipes concerne par la dmarche.
Ainsi, une attention particulire a t accorde par les acteurs lean lidentification des
dysfonctionnements dans le droulement des projets. Lide de dresser ltat des lieux des
projets souligne lintrt quaccordent les praticiens la notion de gaspillage pour lgitimer
leur dmarche managriale. Nous reviendrons infra sur cette notion de lgitimit et
limportance quelle occupe dans la mise en place de la dmarche.
On travaillera ensemble sur les outils proposer aux chefs de projet pour lanimation de
leur quipe (TR) ;
Qu'est ce qui va faire que les gens soient motivs pour venir un brief rgulier o on sait
qu'on doit tre ponctuel quand on sait que rgulirement chaque runion organise t'as la
moiti des personnes qui arrivent avec un quart d'heure de retard ? (TR).
La construction collective du sens de la dmarche lean semble avoir t conduite par la
plausibilit. Lquipe par exemple a dcid dimpliquer les acteurs quelle estimait pouvoir
contacter : dans tel projet, il y a du monde et on connait des personnes quon pourrait
contacter et faire participer la dmarche. on va faire des ateliers projets et des ateliers
mtiers qui seront globalement reprsentson va tre modeste et on va se contenter de notre
Il sagit des groupes dacteurs travaillant au sein dun mme mtier : chefs de projets, architectes techniques,
architectes fonctionnels, dveloppeurs, etc.
106

173

Chapitre VI : Discussion

entit, on va sattacher des choses quon peut grer . A ce titre, bien quimportantes, les
quipes transverses ont t exclues du projet. Dans un mme registre, lquipe sest contente
dun nombre assez limit doutils agiles 107 mettre en place. Elle sest attache ce qui
tait envisageable dans son contexte organisationnel en optant pour les solutions quelle
estimait ralisables et pouvant satisfaire ses objectifs, qui par ailleurs sont instables. Ainsi, les
accords des membres de lquipe ont davantage port sur les moyens dont ils disposaient.
Cette notion de plausibilit met laccent sur un point dune importance cruciale dans la
fabrication de la stratgie : linfluence du contexte au sens macro (proprits
organisationnelles, ressources disponibles, rgles, etc.) sur ce qui se passe au niveau micro
de lorganisation. Le choix des actions est effectu en fonction des aptitudes des individus et
de leurs capacits faire voluer ces aptitudes au sein de leur environnement, celui-ci tant
enact partir de leur comprhension des situations et de leurs choix stratgiques. Cela
dit, avant de sengager dans laction, les acteurs vont valuer les solutions quils estiment tre
capables dapporter compte tenu des facteurs quils identifient au sein de leur contexte. Dans
cette perspective, le lien entre les niveaux micro et macro de la stratgie comme
pratique est mis en vidence.
Dans les runions quotidiennes aujourdhui soyons ralistes, ne pas faire un brief avec tout
le monde, n'allons pas tout de suite l'objectif final quoi (RB) ;
Le risque que je vois cest de vouloir trop traiter et de se noyer. Il faut essayer daboutir
quelques points dactions (RB) ;
On traite 8 dysfonctionnements. Les autres dysfonctionnements on les traitera plus tard. Le
choix a t fait par rapport leur poids, la possibilit quon avait pour avancer sur le
sujet (TR).
Si la construction de la dmarche est le fruit des interactions entre les acteurs lean , son
orientation est galement affecte par les changes avec dautres parties prenantes : les
quipes pilotes, la direction gnrale, le top management, etc. Ces divers groupes dacteurs se
trouvent, ds lors, indirectement impliqus dans le dveloppement et la mise en uvre de ces
outils managriaux. Les activits dinterprtation et de ngociation ainsi que les pratiques
situes, notamment la prise en compte du contexte du chef de projet, sur lesquelles sappuient
les acteurs lean , ont contribu laccomplissement de lactivit stratgique.

107

Cf. tableau 11.

174

Chapitre VI : Discussion

Une runion est programme avec CR (chef de projet) pour dfinir avec elle la priodicit
du brief, les personnes impliquer . Il est important davoir un retour sur ses points de vue
et perceptions de la dmarche (TR) ;
a serait peut-tre important de laisser la parole au chef de projet, il a peut-tre des choses
remonter (DT) Ce qu'on peut faire aussi cest lancer une premire runion avec un
chef de projet avec une trame et on en saura pas mal pour voir comment la personne va
ragir (RB) ;
Cest pour a le point de validation au niveau du Codir est fondamental . Le Codir a
travaill sur les contenus des ateliers de rsolution et valid l'essentiel des thmes (TR).
A titre dexemple, limplication du chef de projet dans la fabrication des outils met en
vidence laccomplissement social de la stratgie agile . En fonction de ses reprsentations
du contexte, de ses intrts et de ses prdispositions personnelles, etc. le chef de projet va
adopter loutil mis sa disposition, se lapproprier108 dans ses activits, le contextualiser
ou simplement le rejeter . Do lintrt de nous interroger sur la manire dont les outils
agiles sont introduits au sein des organisations. Dans le cas prsent, les acteurs se sont mis
daccord pour proposer aux quipes pilotes un cadrage sur les outils puis de les laisser
adapter ces derniers leur contexte.
Par ailleurs, le choix et le dploiement des outils agiles ont t influencs par les objectifs
et les intrts parfois divergents des parties prenantes. Les runions quotidiennes de type
daily-scrum et les ateliers damlioration continue de type kaizen ont t considrs
par certains chefs de projet comme une charge supplmentaire conduisant lquipe lean
repenser leurs pratiques dimplmentation :
Je pense que c'est une bonne ide, pourquoi pas... mais je pense que a serait pour faire
plus de choses et a ne sera pas pour faire mieux... (PD) ;
La mise en place de la mthode est un peu fastidieuse ce que je vois ici en tant que
manager cest quon peut passer un temps indtermin pour analyser les causes (PB) ;
On a limpression de passer notre temps dans des runions (DN) ;
On sest adapt en fonction de ce que chacun voulait (TR).

Sapproprier un outil, cest littralement pour une organisation rendre propre un usage cet outil et le
faire sien , action qui passe possiblement par une adaptation ou une modification de loutil par lorganisation.
Sa diffrence avec le concept de contextualisation interne tel que dfini par Albert David voque non
seulement lide dune transformation de loutil par lorganisation, mais aussi celle de lorganisation par loutil
(Rouquet, 2009).
108

175

Chapitre VI : Discussion

Bien que les lutilit des runions quotidiennes et des sessions kaizen soit mise en avant
dans le discours des acteurs, leur mise en pratique parat difficile au sein de lorganisation
Nextv : elle ncessite beaucoup dinvestissement en termes de temps et defforts. Pour les
chefs de projet, lanimation rgulire des quipes et les sessions damlioration continue de
type kaizen exigent discipline et rigueur et requirent beaucoup de temps que ces premiers
affirment ne pas disposer. Il est donc loin dtre envident, pour un manager dquipe,
dorganiser des runions quotidiennes ou danimer rgulirement des ateliers kaizen avec
des acteurs de diffrentes quipes alors que chacun est engag dans plusieurs projets en
parallle et a ses propres contraintes et proccupations.
La mise en place de la mthode est un peu fastidieuse ce que je vois ici en tant que
manager cest quon peut passer un temps indtermin pour analyser les causes (PB).
Cependant, les connaissances dont disposent les parties prenantes sur le lean management et
les mthodes agiles , semblent avoir galement influenc la manire dont ces approches
managriales sont apprhendes et mises en uvre. Les parties prenantes ntant pas
suffisamment informes sur ces nouvelles mthodes de management de projet, leurs changes
se sont avrs peu constructifs. Le manque de cadre de rfrence commun et de matrise de
ces mthodes mergentes a entrav la cration de sens de la dmarche compliquant ds lors
son dveloppement et dploiement. Outre les difficults lies lapplicabilit des outils
agiles , les quipes projets nont pas t formes sur ces mthodes ce qui a eu pour effet de
compliquer davantage leur mise en place. Lintention dusage de ces outils a par consquent
t affecte. La formation des quipes aux mthodes agiles et leur sensibilisation aux
objectifs et effets dusage de ces dernires auraient sans doute pu aboutir une meilleure
contribution collective la dfinition et au dploiement de la dmarche.
Les personnes ne connaissent pas spcialement le lean et ce nest pas vident pour elles de
voir quest ce quelles vont gagner dans leur domaine en mettant en place le lean (ER);
La plupart des personnes impliques dans la dmarche nont pas entendu parler du lean
(JP).
La prsence relle ou imagine des autres a peut tre aussi eu un impact sur limplmentation
des outils lean . La cration de sens est ainsi conditionne par les prfrences et les
comportements rellement exprims par autrui ou tout du moins que nous interprtons comme
tels. Les enjeux de la direction et ses attentes lgard de la dmarche ont t exposs
176

Chapitre VI : Discussion

plusieurs reprises dans les discours conversationnels des acteurs lean . Ils constituent, pour
eux, les cadres de rfrence des actions mettre en uvre.
lissu du pilote, JM (DG) insiste sur le fait davoir un objectif chiffr, comme par exemple
on peut gagner tant pour cent sur le cot de dploiement de telle action, ctait certainement
ses attentes .. Je ne sais pas, cest une interprtation (TR) ; La direction a pour but de
gagner en agilit. lide est de rpondre aux enjeux de la direction entre la priode 20102012 avec nos moyens constants (RB).
Mis part les enjeux dfinis et prsents par la direction gnrale gagner en agilit,
rpondre aux besoins de nos clients, faire des projets plus courts et mieux tenir nos dlais ,
les membres de lquipe lean ne disposaient ni de points de repres ni de directives
concrtes les assistant dans llaboration de leur projet globalement ce qui attend de nous en
termes damlioration cest quon soit plus agile de faon ce quon puisse rpondre aux
enjeux dici 2012 (TR). En effet, le terme dagilit, bien que souvent mis en avant dans les
discours du directeur gnral demeurait trs global et noffrait aucune possibilit daction
concrte facilement applicable au contexte. La dmarche lean a par consquent pris, ds le
dbut, une allure abstraite et thorique. Suite aux retours quils ont eu du terrain (quipes
pilotes, Codir) par rapport au bilan de la phase pilote de la dmarche, les acteurs lean se
sont rendus compte de son image abstraite . Par consquent, ils ont tent, nouveau,
travers leurs conversations et pratiques, de la rorienter. Si les mthodes agiles se veulent
pragmatiques, leur mode dapplication, en dehors des quipes de dveloppement de taille
rduite, demeure vague et abstrait.
La dmarche lean est donc la rduction des dysfonctionnements. Pour cela on va chercher
appliquer des procdures standards, des modes opratoires standards. On va trouver une
bonne mthode, on va la dcrire et la rpter (TR) ;
Ce qui me manque sont les objectifs clairs de la dmarche On a trop dilu les messages.
Je pense quil faut tre beaucoup plus directif il faut tre plus rigoureux dans laction
plutt que dans la mthode (RB).
Comme ils le font remarquer dans leurs changes, les acteurs lean manquent de solutions
cls en mains faciles mettre en place. Par consquent, ils sont amens modliser
des outils appliqus dans dautres contextes en vue de les adapter au leur. A titre dexemple,
les acteurs lean se sont appuys sur une prsentation dun tableau visuel qui montre
comment une quipe peut, grce cet outil, changer et partager les indicateurs de
performance. Or, limage du tableau visuel mobilise montre un environnement de travail o
177

Chapitre VI : Discussion

les personnes sont prsentes physiquement et non pas virtuellement, ce qui est loin dtre leur
cas. Cette focalisation sur le contenu des outils mobiliss par lquipe lean nous amne
mettre laccent sur le rle des outils dont disposent les praticiens dans la fabrication de
leur stratgie.
La dmarche lean telle quelle a t initialement construite a subi de nombreux
changements au fur et mesure de lavancement de la phase pilote. Le sens du projet a t
modifi plusieurs reprises conduisant, chaque fois, de nouveaux plans daction. Les
runions rtrospectives auxquelles ont particip les membres de lquipe lean ont t, pour
eux, loccasion de revenir sur les actions ralises, de dcouvrir le sens de ce quils ont fait et
de mettre en place de nouvelles actions. Le caractre rtrospectif de leurs pratiques a ds lors
permis lintgration des changements et la rorientation de la dmarche. La mise en uvre des
outils agiles sest manifeste par des allers-retours sur le terrain permettant aux acteurs de
dcouvrir leurs prfrences et celles des acteurs pilotes et dajuster leurs comportements. Les
stratgies de ces acteurs ont ainsi t radaptes aux besoins mergents du contexte.
Je trouve un peu abrupt et peu explicite le fait davoir rsum la reformulation de la
dmarche, elle-mme dj synthtique ce qui ne veut pas forcment dire claire,
malheureusement. (ER) ;
Je partage le fait quon na pas t bon collectivement dans la restitution du travail, parce
quon a t soit trop dans la dmarche, dans les outils soit trop dans lapproximation ou on a
trop dilu les messages (RB) ;
On vient de faire un point avec CR (chef de projet) pour la mise en place de la dmarche
lean sur le projet R3 ZNE, et donc la premire raction est quon arrive un peu aprs la
bataille puisque le projet est quasiment termin (TR) ;
On essayera de profiter des retours dexprience avant de procder dans la dmarche
(PB).
Nos observations et analyses montrent que les acteurs ont tendance rflchir avant dagir. Ils
planifient leurs activits, examinent leurs stratgies en anticipant les consquences des actions
ventuelles et de ce fait, sengagent, en fonction des moyens leur disposition, dans celles qui
leur paraissent les plus utiles. La dmarche est ds lors guide, de faon incrmentale, par le
biais des anticipations des acteurs et leurs reprsentations de lenvironnement. Leurs
projections dans des plans dactions futurs soulignent le caractre anticipatif de leurs
actions on va sortir; ce quon peut faire cest.. ; lobjectif est de continuer .

178

Chapitre VI : Discussion

Peut tre quil y a une autre manire de procder, je pense quon na pas assez travaill
avec les managers (RB) ;
L'objectif tait de continuer ce qu'on a commenc mardi pour avoir une proposition pour
mettre en place la dmarche sur des projets pilotes (TR) ;
Ce qu'on peut faire aussi, cest lancer une premire runion avec un chef de projet avec
une trame et on en saura pas mal pour voir comment la personne va ragir (RB).
Par ailleurs, nos observations et analyses ont mis en avant linfluence de lidentit
organisationnelle des acteurs sur la manire dont la demarche est entreprise from the
perspective of sensemaking, who we think we are (identity) as organizational actors shapes
what we enact and how we interpret, which affects what outsiders think we are (image) and
how they treat us, which stabilizes or destabilizes our identity. Who we are lies importantly in
the hands of others, which means our categories for sensemaking lie in their hands (Weick,
Sutcliffe & Obstfeld, 2005, p.416). Les acteurs impliqus dans la fabrique de la stratgie
cherchent produire une reprsentation de ce qui se passe, conformment avec ce quils
souhaitent tre ou paratre cest partir de notre identit que slabore le processus par
lequel nous donnons du sens. Lidentit est constitu dune multitude de soi entre lesquels les
individus circulent (Vidaillet, 2003, p.40).
Diffrentes conceptualisations de lidentit organisationnelle existent (Gioia, 1998). Nous
retiendrons celle qui sinscrit dans une approche interprtativiste o lidentit est considre
comme une exprience subjective vcue par les membres de lorganisation. De ce point de
vue, lidentit organisationnelle fait rfrence la vision des membres au sujet de leur propre
organisation et se construit par le biais de leurs ngociations continues.
Dans le prsent contexte, lidentit organisationnelle sest progressivement dveloppe
travers les activits discursives des membres de lquipe lean et leurs interactions avec
leur environnement. La dfinition des attributs de la dmarche a par consquent fait lobjet de
nombreuses runions au cours desquelles les acteurs ont cherch avoir une comprhension
collective de celle-ci, communment partage. Un ensemble de croyances et de valeurs a
merg renvoyant la manire dont les acteurs se sont auto-dfinis et affichs par le biais de
leur projet. Une attention particulire a t accorde limage vhicule auprs de leur
organisation. Les termes utiliss pour qualifier la dmarche lean (organisation agile ;
esprit dquipe; transparence, etc.) ont longuement t ngocis et interprts.

179

Chapitre VI : Discussion

On a prsent le projet comme tant du lean et donc il faut respecter lidentification de


marques (TR) ;
On a des mots importants transparence, communication, identification des problmes
(JP) ;
On dit quon va changer un tat desprit, un mode de fonctionnement, on va rapporter un
systme de management (TR).
Lidentit organisationnelle travers laquelle saffiche lquipe lean vise principalement
dmarquer la dmarche actuelle des projets antrieurs de changements organisationnels.
Lappellation de la dmarche renvoie lcole Japonaise du lean qui a connu un succs
considrable dans lindustrie automobile. Les avantages associs cette approche
managriale, trs parlante, ont fait delle une dmarche particulirement attractive dans le
monde de dveloppement informatique. Cependant, il existe un dcalage entre limage
organisationnelle que lquipe souhaite donner par le biais de la dmarche lean et la
connotation relle de celle-ci. En dautres termes, la dmarche, rellement entreprise, diverge
considrablement de la philosophie managriale lean. Ce constat renforce lintrt
dapprhender la stratgie comme pratique afin de saisir ce que les acteurs lean font
rellement et par consquent, ne pas se limiter ce quils affirment tre en train de faire.
Tout au long du projet, les acteurs lean se sont appuys sur leur reprsentation prtablie
de la dmarche lean et sur le discours du directeur gnral afin de sinfluencer entre eux et
dinfluencer les autres acteurs concerns par la dmarche (acteurs pilotes, organisation ou
acteurs lean ).
Dun point de vue gnral, le niveau hirarchique des acteurs chargs de conduire une
dmarche de changement impacte fortement la manire dont le changement sera apprhend
par les individus concerns. Dans le prsent contexte, les acteurs lean ne disposent ni de
pouvoirs de position109 ni de pouvoirs personnels 110 , au sens strict du terme, pour
influencer ladhsion de lorganisation aux outils et plans daction proposs. La recherche de

109

Les pouvoirs de position comprennent le pouvoir coercitif fond sur la capacit de menacer et
dexercer des sanctions, le pouvoir de renforcement fond sur la capacit doffrir une faveur ou une
rcompense la personne et enfin le pouvoir lgitime fond sur lautorit formelle associe un poste
hirarchique (French & Raven 1992).
110
Les pouvoirs personnels regroupent le pouvoir de rfrence fond sur la capacit dinfluencer parce
que lon est sujet de rfrence et le pouvoir de lexpertise fond sur les connaissances relles ou supposes,
sur la comptences professionnelles qui autorise le dtenteur de ce savoir formuler des avis faisant autorit
(French & Raven 1992).

180

Chapitre VI : Discussion

lgitimit dans la prsentation et linterprtation du projet lean devient alors indispensable


pour convaincre les quipes projets de son utilit.
Avant de nous focaliser sur la manire dont les acteurs ont cherch accrotre leur lgitimit
auprs des quipes pilotes et de leur organisation, nous nous attarderons sur la manire dont le
coach de lquipe lean a russi convaincre son quipe du bien fond de ses
propositions. En effet, ses connaissances et son expertise dans les programmes damlioration
de type kaizen lui ont permis de saffirmer fermement autour de la conduite du projet,
dinfluencer les perceptions de ses collaborateurs et de transformer, ds lors, lactivit
stratgique. Cela nous conduit mettre laccent sur limportance des connaissances et des
prdispositions personnelles, en loccurrence lexpertise et la sensibilit du coach lean aux
ateliers kaizen, dans la fabrication de la stratgie.
Le lean cest bien un levier majeur de mise en place de lamlioration continue pour
satisfaire le client. l'aspect managrial du lean on la sur les programmes kaizen.. Le
lean ne peut pas tre fait dans un ocan o tout le monde sen fout. Le premier volet du
lean est du kaizen et le second volet cest du brief et du coaching (RB) ;
Pour moi, si je peux y aller, ce qui me parat avoir du sens mais je suis dj dans la
rponse, c'est qu'il y a des projets pour lesquels on a un primtre trs large et le problme
est un problme de mettre autour de la table des gens qui ny viennent pas parce qu'ils ne
sont pas concerns. (RB) ; - Donc cest bien a? Rendre les acteurs plus concerns par
les interactions ?.... je suis daccord avec toi. (TR).
Dans la majorit des cas, les membres de lquipe lean ont acquiesc sans discuter les
propos avancs lgard des diffrents aspects de la dmarche (les plans dactions mettre en
place, la manire de procder, les outils adopter, etc.). Cette attitude assez passive
sexplique par le manque de connaissances et dexpriences des acteurs dans le domaine du
lean et de lagilit.
Quand RB nous a aid mettre en place le projet, il avait dit que cest important davoir
des personnes oprationnelles au sein de lquipe, et on a donc suggr aux managers de
regarder au sein de leur quipe et didentifier des personnes qui auraient cette sensibilit
pour participer ce projet (TR),
RB nous a dit de procder diffremment et de mettre en place des ateliers (TR).
Outre le sens cr des situations et des reprsentations prtablis par leur coach , les
membres de lquipe lean ont, leur tour, tent dinfluencer les quipes pilotes dans
181

Chapitre VI : Discussion

ladoption de la dmarche. Leur objectif est de convaincre les acteurs pilotes du sens
construit de la dmarche pour que ces derniers sengagent dans son expansion au niveau
de leurs quipes projets.
Il est important de montrer que ce nest pas une activit supplmentaire de faire du lean
mais un vrai investissement (RB) ;
Jinsiste pour que les managers soient l et il faut les convaincre, pour quils soient autour
de la table et quon les lche pas. Je ne vois pas dautres solutions que dinsister auprs
deux et les pousser simpliquer.Il faut que les managers acceptent de sy mettre sinon a
ne peut pas marcher (RB).
Parmi les stratgies adoptes par lquipe lean pour mettre en avant les apports de la
dmarche, citons les ateliers de remontes des dysfonctionnements partir desquels les
projets ont t analyss. Outre lintrt en soi de ces ateliers (analyser ce qui ne va pas dans le
droulement des projets), ils ont constitu un moyen, pour lquipe lean , de mettre en
avant les dfaillances des modes organisationnels et managriaux existant et de souligner le
besoin de changement des modes de fonctionnement. Ils constituent ds lors un moyen pour
promouvoir les outils agiles .
Quand on identifie un problme on fait le tour avec un outil pour prciser et expliquer les
problmes. Cest le QQOQCP (RB) ;
Quand on aura fini les premiers ateliers, on aura des inputs complmentaires pour faire
dautres ateliers. (TR) ;
Avant le dploiement des outils sur le projet FTTH, il faut montrer comment les besoins de
coordination et dchanges dinformation peuvent tre rsolus par un brief (TR).
Les dysfonctionnements voqus par les participants ont permis aux acteurs de justifier,
auprs du top management et des quipes de lentit Nextv, le sens et lutilit de la dmarche
managriale entreprise. A cette fin, lquipe lean a mis laccent sur la quantification des
problmes remonts en termes de gaspillages. Selon les acteurs lean , le fait davoir des
lments quantitatifs, parlant , pourrait intresser le top management et convaincre les
managers de la ncessit du changement malgr le fait que la valeur des pertes quantifies
tait biaise. Lidentification et quantification des dysfonctionnements a ainsi permis
lquipe lean daccrotre la lgitimit de leurs actions et dinfluencer les autres vers le
changement des modes de fonctionnement.

182

Chapitre VI : Discussion

Chacun est cens avancer ces problmes et on ne demande pas lvaluation de tous. Nous
sommes l pour dcrire le problme dune faon la plus prcise. Cest nous de les
quantifier aprs (RB) ;
Limportant cest dessayer de quantifier en termes de temps perdu mme si cest la
louche, il faut essayer de quantifier chaque dysfonctionnement (RB) ;
a serait bien de trouver une unit de mesure, l tu as lindicateur, et lide est de dire ce
qui va bouger avec cette action. La manire dont on peut aussi approximer cest en gros
quest-ce quon peut gagner en temps, en moyenne (RB) ;
Aujourdhui on va sattacher noncer les problmes afin de les quantifier. Dans nos
rsultats a serait bien de mettre quelques choses comme quest ce que a apporte, quest ce
que a change prsenter un kit de communication en mettant en lumire le gain des
rsultats (TR).
Face au besoin damliorer les managriaux des projets pilots par lentit Nextv, les outils
agiles ont t prsents comme des moyens offrant la possibilit daccrotre la
productivit des quipes et de rduire les gaspillages gnrs dans les projets actuels. Diverses
stratgies de communication ont ainsi t mises en place. Des rendez-vous dinformation
ont t organiss, un mois aprs le lancement du projet, avec lensemble des acteurs de
lentit pour prsenter les objectifs et lavancement de la dmarche lean .
Nous vous proposons ces rendez-vous pour vous prsenter plus en dtail le projet lean
Nextv, les actions ralises et les actions en cours. Au cours de ce point vous pourrez posez
toutes les questions que vos souhaitez sur la dmarche (RB).
Afin de justifier le bien fond de leur projet et de sensibiliser les quipes projets, les acteurs
lean se sont continuellement rfrs, lors de leur prsentation, au discours du directeur
gnral en insistant sur les enjeux de la dmarche : aujourdhui sur la tlvision on est plus
de cent personnes et au niveau de la direction DP on est plus de 300 personnes impliques
dans le projet, et donc il y a pas mal de monde et tre plus nombreux nest pas forcement plus
productif il y a un vrai besoin de changer de mode de fonctionnement et de production.
(Directeur Gnral). Ces rendez-vous leur ont permis de rappeler les dysfonctionnements,
dinsister sur la ncessit de changer les modes de fonctionnement actuels, de promouvoir les
outils agiles et de rpondre aux questions que se posent les quipes par rapport la
dmarche : nous vous proposons ces rendez vous pour vous prsenter plus en dtail le
projet lean management Nextv Une large part du rendez vous sera rserve aux
questions/rponses. Ces points se drouleront par CoopNet (TR).

183

Chapitre VI : Discussion

En effet, au cours de ces rendez-vous dinformation , des remarques subtiles ont t


soulignes par les participants : absence du marketing, implication des diverses entits, etc.
Bien que ces constatations renvoient des lacunes importantes quant la mise en uvre de la
dmarche, elles nont toutefois pas t prises en compte par lquipe lean . Elles auraient
impliqu llargissement du primtre de la dmarche et donc lintervention dautres parties
prenantes ce qui ntait pas la porte de lquipe lean (manque de temps, manque de
sponsors sur la dmarche, faibles possibilits daction, etc.). Conscients de leurs possibilits
limites daction, la fabrication de la stratgie a t conduite par la plausibilit.
Nous on va travailler dans le sens damlioration de rduction de gaspillage, mais est -ce
que ce travail se fait aussi dune autre manire mais paralllement ct marketing pour
optimiser la faon dont sont gres les demandes, de faon ce quon ait aussi une rduction
de gaspillage li un aspect de la demande qui ne se justifie pas toujours (LM).
Une lettre dinformation bimensuelle a galement t diffuse au sein de lorganisation. Elle
sadresse un grand nombre de personnes travaillant au sein du groupe. Cet outil stratgique
a permis aux acteurs lean de transmettre leur reprsentation prtablie de la dmarche,
dinitier les quipes au vocabulaire lean , de rappeler les objectifs de la dmarche et de
communiquer sur l'avancement des travaux (projets pilotes retenus, dysfonctionnements
remonts, plans dactions mis en place, tmoignages dquipes ayant dploy des pratiques
agiles , etc.) (Annexe X).
Je suggre qu'une phrase (en gras) les nomme : devenir plus agiles avec des moyens
constants, devenir meilleurs sur les dlais, amliorer la transparence, faire plus court, Il
serait bien qu'ils soient rappels lors de toutes nos communications (RB) ;
La communication sur le projet se fait notamment travers une revue dinformation qui
parait tous les 15 jours o on dfinit quelques concepts cls du lean management, on souligne
lavancement du projet et on fait tmoigner quelquun sur son exprience ou perceptions
lgard de cette dmarche managriale (TR).
Au travers ces moyens de communication et leur contenu (lettre dinformation, ateliers de
remontes de dysfonctionnement, rendez-vous dinformation), les acteurs ont tent
dapporter, aux parties prenantes de la dmarche, une interprtation de la ralit
prconstruite et par la mme occasion, dinfluencer leurs comprhensions et perceptions
de celle-ci.

184

Chapitre VI : Discussion

Il nest toutefois pas garanti que le sens cr par lquipe lean par rapport la dmarche
soit pris en compte et approuv par les acteurs pilotes et cela malgr les nombreuses tentatives
de cette premire. Dailleurs, par la suite, peu dquipes ont continu utiliser les outils
agiles soutenus par le projet. Selon certaines personnes interroges, la dmarche telle
quelle a t propose, manque doriginalit Cette dmarche aurait pu tre plus
rvolutionnaire, plus sympathique, elle ressemble une nime dmarche de qualit (JFR).
Mme si le besoin de renforcer la collaboration entre les quipes et damliorer la
communication et la vision commune des projets est fort, la mise en place des outils agiles
na pas pu tre gnralise, en tout cas lheure actuelle, au niveau des quipes projets de
lentit.
Malgr lexpansion des mthodes agiles et leur adoption par de nombreuses socits
informatiques, beaucoup dquipes aujourdhui, recourant des mthodes classiques de
management de projet, ont du mal accepter et intgrer ce type de pratiques managriales
qui ncessitent une ractivit, un suivi permanent et donc une dynamique organisationnelle
peu prsente dans les approches classiques. Ce constat est encore plus accentu au niveau
de larges quipes uvrant dans un environnement complexe o lagilit exige une
restructuration et une rorganisation. Les mthodes agiles en tant qu innovations
managriales ne sont pas formalises de faon ce quelles puissent constituer des
mthodes de gestion de projet cls en mains prts tre confronts aux organisations.
Elles renvoient une logique dorganizing dacteurs impliqus dans leur fabrication et
mise en application.
Dans le cadre de ce travail, la perspective de la stratgie comme pratique nous semble
avoir constitu un cadre danalyse pertinent pour comprendre comment les acteurs, travers
leurs pratiques, contribuent la fabrication de la stratgie. Afin de mieux saisir la
fabrication de la stratgie, nous avons mobilis la grille danalyse du sensemaking qui
nous a permis dapprhender le phnomne dimplmentation de la dmarche dans la
perspective des sujets participant sa cration. Par consquent, en nous focalisant sur les
conversations des individus, leurs activits interprtatives, leurs interactions avec leur
environnement, leur mobilisation des outils, etc. nous avons pu identifier une liste assez
gnrale de pratiques situes sur lesquelles sappuient les acteurs chargs de la mise en uvre
dune stratgie agile . Parmi ces pratiques , citons : les runions stratgiques, les ateliers
organiss avec les quipes pilotes, les rflexions collectives sur les caractristiques
185

Chapitre VI : Discussion

contextuelles, la dlimitation des situations problmatiques, le cadrage des outils


agiles , la diffusion du sens de la dmarche, les allers-retours sur le terrain qui servent
adapter les outils agiles retenus, la recherche dinformations auprs des organisations
uvrant dans un contexte similaire, la mobilisation du discours du directeur gnral pour
lgitimer la dmarche, etc.
Ainsi, nous positionnons notre projet de recherche sur les deux dimensions de
comprhension ( verstehen ) : la premire concerne la manire dont les acteurs
attribuent un sens aux phnomnes organisationnels, leurs activits quotidiennes et celles
des personnes avec qui ils interagissent ; et la seconde renvoie la stratgie de recherche
adopte pour expliquer et traduire la ralit organisationnelle telle quelle est exprimente et
vcue par les acteurs comprendre, c'est--dire donner des interprtations aux
comportements, implique ncessairement de retrouver les significations locales que les
acteurs en donnent (Girod-Sville & Perret, 2007, p. 24). Notre rflexion relve, ds lors,
dune posture pistmologique comprhensive et interprtativiste.
Lenvironnement complexe dans lequel opre lquipe lean et labsence doutils agiles
dfinis de manire prcise et dtaille semblent avoir compliqu la mise en uvre de la
dmarche. Si les acteurs lean prtendent adhrer une philosophie gestionnaire de type
agile , leur vision de celle-ci demeure simplifie et leur matrise des substrats techniques
associs ces mthodes managriales est faible. Au stade de notre recherche, la dmarche
lean ne semble pas avoir abouti ses fins dans le sens o les outils nont pas t adopts,
et appropris par les quipes pilotes. Seuls quelques plans daction ont t mis en place au
niveau dun groupe restreint dacteurs. Cependant, ces plans daction ne renvoient pas une
dmarche dynamique de rsolution de problme telle quelle est valorise par ces approches
managriales mergentes. Ils rpondent un problme prcis et dune manire bien structure
(porteurs et contributeurs dfinis ; plan damlioration fix lavance, etc.). Dans cette
perspective, les acteurs sont amens respecter leur plan daction tel quil a t dfini. Ainsi,
nous nous loignons des logiques managriales portes par les approches agiles et en
particulier par le lean management o la dmarche damlioration doit tre intgre dans le
mode de fonctionnement des quipes. En ce sens, les managers interviennent sur le terrain de
faon continue pour rsoudre les problmes ds leur apparition. Par ailleurs, il convient de
noter que la mise en place de ces plans daction fut, de loin, plus facile tre accepte par
rapport aux outils agiles (runions quotidiennes, tableau blanc, ateliers kaizen, etc.) qui,
186

Chapitre VI : Discussion

elles, relvent des dynamiques dorganizing. Ce propos met en avant les difficults des
organisations de grande taille et complexe, assumer les activits dorganizing et leur
tendance privilgier les procdures et les activits formalises .

187

188

Conclusion gnrale

Conclusion gnrale

Alors quaujourdhui les cabinets de conseil en systme dinformation et management


de projet informatiques proposent des solutions agiles la carte et une large gamme de
certifications professionnelles (certification scrum master, certification product owner,
certification scrum professionnel, certification coach xp , etc.), sintresser de prs ces
innovations managriales et la manire dont elles sont confrontes la ralit des
entreprises, nous a sembl revtir une importance cruciale. Dans cette conclusion gnrale
notre document de doctorat, nous rsumons les principales tapes du raisonnement de notre
travail et exposons les apports de cette thse mais aussi ses limites ainsi que des pistes de
recherche futures.

1. Rsum des principaux rsultats de recherche


Les mthodes agiles , celles qui relvent du dveloppement informatique comme
scrum , XP mais aussi celles, plus englobantes comme le lean SI , rencontrent
aujourdhui un succs considrable dans le discours des praticiens en management de projets
logiciels. A quel(s) type(s) dapproches managriales ces mthodes renvoient-elles? Quelles
sont les points communs entre les diffrentes mthodes dnommes agiles et comment se
diffrencient-elles ? En quoi constituent-elles des innovations managriales ?
Lintrt actuel pour les mthodes agiles renvoie la remise en cause du modle
classique de management de projet relativement des enjeux de ractivit des entreprises
soumises un environnement concurrentiel de plus en plus intense. Les entreprises
empruntant la voie de lagilit cherchent concilier les exigences antagonistes du
tryptique qualit-cot-dlai et sadapter un contexte caractris par lincertitude.

189

Conclusion gnrale

Dans le chapitre (I) de cette thse, nous avons prsent les mthodes agiles dans leur
dimension dinnovations managriales revendiques par leurs promoteurs et au travers
dune revue de la littrature concerne. Dans cette perspective, nous les avons analyses du
point de vue de la philosophie gestionnaire et des substrats techniques quelles sousentendent. La philosophie des mthodes agiles sinscrit principalement dans lcole
japonaise du lean qui a trouv ses sources dans le Toyota Production System dvelopp dans
les annes 1980. Des diverses mthodes agiles ayant vu le jour, nous avons retenu trois
mthodes (la mthode scrum , la mthode extreme programming et le dveloppement
lean) qui apparaissent, dans la littrature et dans les milieux concerns, comme
emblmatiques de trois modes ou voies dagilit . Dans ce chapitre, nous montrons que ces
trois mthodes reprsentent une forme dagilit diffrente. La mthode extreme programming
constitue un support pour les pratiques dingnierie et les aspects techniques du
dveloppement logiciel ; la mthode scrum qualifie un ensemble dartefacts et de
pratiques ingnieriques spcifiques au management et suivi des projets ; le lean renvoie une
approche globale, holistique, sintressant lorganisation dans son ensemble et allant au-del
des activits de dveloppement informatique. De fait, lensemble de ces trois approches offre
une certaine compltude lanalyse du substrat thorique du courant agile .
Lanalyse de la littrature portant sur ces diffrentes approches agiles nous a permis de
mettre en avant les points suivants : les mthodes agiles ne constituent pas une doctrine de
gestion de projet agile cls en mains . La philosophie gestionnaire que ces mthodes
sous-tendent et les substrats techniques qui y sont associs soulignent un aspect dynamique de
lorganisation qui se construit au fur et mesure de lavancement des projets. Ces
mthodes reposent sur un outillage lger , peu formalis dont on pressent quil peut
tre particulirement bien adapt des quipes de taille rduite, o la collaboration et
lajustement mutuel sont faciles raliser. Mais les mthodes agiles de management de
projet, celles qui participent dune approche englobante du management laissent en suspens la
question de leur contextualisation interne (David, 1996) tant la philosophie gestionnaire qui
les sous-tendent parat peu outille par les artefacts de management proposs.
Comment lchelle dune quipe projet de grande taille et relativement une problmatique
de management de projet qui dpasse le primtre rduit des quipes de dveloppement
informatique, peut-on implmenter une mthode de management agile ? Que dit la
littrature de ces mthodes lorsquelles sont mises en pratique ?
190

Conclusion gnrale

De faon tenter de rpondre ces questionnements, nous avons consacr le chapitre (II) de
cette thse lanalyse la littrature rendant compte de cas dentreprises ayant mis en pratique
des mthodes agiles . Les travaux de recherche tudis rassemblent des positionnements
contradictoires quant aux domaines dapplication des mthodes agiles . Ils mettent en
vidence des lments de contingence organisationnelle susceptibles de faciliter ou pas la
mise en uvre de ces mthodes. Tous convergent sur lide que ces mthodes participent
dapproches alternatives qui semblent pallier les insuffisances et limites des pratiques
managriales classiques . Mais si ces premires semblent amliorer sensiblement la
productivit des quipes et rduire significativement les cots engendrs par les cycles de
dveloppement squentiel, la planification et la documentation extensives, elles se heurtent
nanmoins plusieurs difficults ; leur mise en place exige un environnement de travail
facilitant lajustement mutuel : la collaboration troite entre les acteurs, le partage rgulier
dinformations et ladaptation continue aux sollicitations de lenvironnement soit une
configuration organisationnelle qui nest pas toujours aussi facile raliser, en particulier,
lorsque les quipes de projet sont transversales et gographiquement distribues. Les travaux
rendant compte de cas dimplmentation de mthodes agiles se penchent essentiellement sur
des quipes de dveloppement, par ailleurs de taille rduite. Les quelques recherches qui
concernent les mthodes agiles dans les grandes organisations, se sont, dans la majorit
des cas, uniquement focalises sur les quipes impliques dans des activits de
dveloppement informatique ; elles laissent totalement en suspens la question de larticulation
entre un mode de management agile dploy dans des quipes dinformaticiens et des
modes plus classiques qui supportent le pilotage global des projets concerns.
Les cabinets de conseil et les instigateurs du mouvement agile mettent en avant
ladaptabilit de ces approches de gestion de projet informatique aux organisations de grande
taille et aux quipes projets godistribues. Mais lheure actuelle, leur implmentation dans
ce type dorganisations reste peu explore111.
Comment les mthodes agiles peuvent-elles tre implmentes dans des configurations
organisationnelles plus complexes que celles dcrites dans les tudes de cas parues dans la
Afin dapprocher la manire dont fonctionnent les socits sengageant dans la voie de lagilit, nous avons
organis un cycle de sminaires sur le Lean et Systme dInformation (Annexe XVII). Ces sminaires ont
pour objectifs de runir des praticiens franais dans le dveloppement logiciels agile/lean pour observer et
partager leurs pratiques. Un site est ddi pour lanimation de cette communaut : http://leansi.wp.instituttelecom.fr/.
111

191

Conclusion gnrale

littrature ? Comment, partir de cette bote outil que constituent les mthodes agiles,
soit dun outillage qui parat quelques fois trs basique , peut-on instrumentaliser une
dmarche gestionnaire nourrie dune philosophie gnrique dorganizing ?
Pour rpondre ce questionnement, il nous a sembl opportun de recourir une stratgie de
recherche reposant sur une approche par la pratique . Comment en pratique construiton une stratgie agile ? Comment, en contexte organisationnel donn, peut-on faire sens
de ces innovations managriales ?
Le chapitre (III) prsente notre stratgie de recherche fonde sur lapproche par la
pratique . Dans ce courant de pense112, lcole de la fabrique de la stratgie aborde la
stratgie comme une activit situe et socialement accomplie, construite par les actions, les
interactions et les ngociations de multiples acteurs. Cest dans cette perspective que nous
avons choisi daborder notre objet de recherche en nous intressant aux acteurs impliqus
dans la fabrication dune stratgie agile dans leurs interactions avec leur
environnement socio-organisationnel.
Nous nous sommes appuys sur une tude de cas qui fonde notre perspective
instrumentale 113 . Le terrain de recherche retenu est contingent notre problmatique : une
entit de management de projets informatiques appartenant un large groupe franais de
tlcommunication et ayant dcid de mettre en uvre une dmarche managriale base sur
les principes des mthodes agiles .
Notre tude de cas (chapitre IV) sest droule durant 17 mois au cours desquels nous avons
conduit des observations semi-participantes (37 runions dune dure moyenne de deux
heures et 8 ateliers dune dure moyenne de 5 heures). Nous avons conduit 21 entretiens
semi-directifs dune dure moyenne dune heure et demie avec les acteurs concerns par
ltude. Les donnes de ce corpus ont t compltes par les documents changs entre les
acteurs (mails, documents supports prparatoires ou synthses des runions).
112

Whittington, 1996, 2003 ; 2007 ; Gherardi, 2000, 2001 ; Orlikowski, 2000 ; Jarzabkowski, 2003 ;
Jarzabkowski, Balogun & Seidl, 2007 ; Jarzabkowski & Kaplan, 2008).
113
Ltude de cas instrumentale traite dune question thorique gnrale dans lobjectif de fournir une nouvelle
comprhension dun phnomne ou daffiner une thorie mergente (David, 2000). Le cas fait lobjet dune
analyse contextualise mais toujours en vue dun intrt externe. Il ne constitue pas lobjectif ultime de la
recherche. Ltude de cas instrumentale nous confre ainsi une comprhension gnrale du phnomne
dimplmentation des innovations managriales de type agile dans un contexte particulier caractris par
une complexit organisationnelle.

192

Conclusion gnrale

Nous avons adopt une dmarche inductive pour analyser le corpus de donnes brutes. Aprs
plusieurs lectures des donnes transcrites, nous avons identifi les ides cls auxquelles
renvoi(ent) chaque mot, phrase et/ou paragraphe. Ces ides ont ensuite t classes dans des
catgories. Lensemble des catgories a t dfini de faon itrative et justifi par des
verbatim. La combinaison de diverses sources de donnes (acteurs occupant diffrents statuts
et uvrant dans diffrents contextes) et dinstruments de collecte de donnes (observationsentretiens-documentation) nous a permis denrichir notre champ de connaissances et
dapprofondir nos analyses.
Si cette analyse inductive a t guide par notre objet de recherche, les rsultats, quant eux,
proviennent des donnes brutes et non pas de nos rponses souhaites . Nous avons
particip des workshops (notamment en forme de data sessions), en prsence dexperts en
sciences de gestion, qui nous ont permis daccrotre la validit des donnes transcrites et
interprtes. Ces workshops nous ont offert la possibilit de faire part de nos analyses et
interprtations de donnes. Les retours remonts durant ces workshops ont, dun ct,
particip valider notre processus danalyse et dun autre ct, fait merg de nouveaux
questionnements et points investiguer.
En nous intressant la manire dont les acteurs fabriquent une stratgie managriale de
type agile , dans une structure organisationnelle complexe, notre travail contribue un
enrichissement du corps de connaissances en gestion de projet agile .
Lapproche danalyse par la pratique nous a permis dexaminer des ralits sur lesquelles
les praticiens sappuient pour construire une stratgie agile . Puisquil nexiste pas de
pratiques et doutils institutionnaliss pour implmenter une dmarche agile , la mise
en uvre de ces outils pose de faon centrale la question du sens que les acteurs vont faire de
ces mthodes et de leur contextualisation. Dans cette perspective, nous avons mobilis le
concept de sensemaking pour saisir les dynamiques cognitives des acteurs responsables de la
mise en uvre de ces mthodes managriales et comprendre comment, par le jeu de leurs
interactions, ils se sont engags dans la construction dune stratgie agile . Cette
dmarche danalyse nous a permis dapporter un clairage nouveau sur la manire dont les
acteurs bricolent la bote outils des mthodes agiles et fabriquent une mthode de
management agile .

193

Conclusion gnrale

Lanalyse des procds itratifs d enactment et dinterprtation des acteurs a mis en


lumire un ensemble dlments fondamentaux dans la mise en uvre dune dmarche
agile . Le chapitre (V) est consacr la prsentation des principaux rsultats danalyse. La
notion de gaspillage semble tre au cur des proccupations des acteurs souhaitant sengager
dans une dmarche agile . Elle constitue une cl dentre pour analyser lexistant et
mettre en place une dmarche de rsolution des problmes. Les acteurs se sont appuys sur les
dysfonctionnements remonts danalyses du terrain pour convaincre les parties prenantes
du besoin damliorer les modes de fonctionnement des quipes et par consquent accrotre la
lgitimit de leur dmarche.
Par ailleurs, plusieurs facteurs dordre contextuel, identifis par les acteurs lean , semblent
avoir fortement influenc la dmarche managriale entreprise :
1) La taille et la godistribution des quipes : le dploiement des outils agiles savre
difficile lorsque les quipes sont de grande taille et clates gographiquement ; nous avons
retrouv l des lments voqus dans la littrature et dans le premier volet de cette thse ;

2) La structure organisationnelle : le rattachement des acteurs diffrents services


fonctionnels et lautorit limite du chef de projet entravent le suivi rgulier des activits et
le contrle des quipes ; ce point constitue un apport de notre recherche ;
3) La composition des quipes projets : les changements dacteurs en cours de projets et leur
rattachement diffrents services requirent des efforts supplmentaires en termes de
synchronisation et de renforcement de la cohsion des quipes et ne garantissent pas la
capitalisation sur les projets mens ; l encore, ce point constitue un apport de notre
recherche ;
4) Le style de management de lentreprise : la conduite classique des projets base sur
lanticipation et la documentation ne facilitent pas lintgration des pratiques et outils
agiles ; les rsistances culturelles sont fortes ;
5) Le manque dexemples concrets ou doutils cls en mains : cela conforte une de nos
hypothses de recherche avance lissue de notre revue de la littrature ;

194

Conclusion gnrale

6) La faible implication des parties prenantes : manque du support du top management,


dmotivation des managers et des chefs de projets ; analyse assez classique dans des projets
innovants ; la lassitude lgard du changement ; la surcharge de travail ; le changement de
posture du manager que ncessite une telle dmarche, etc.
Bien que ces facteurs relvent dun contexte particulier, ils semblent transposables des
structures organisationnelles similaires. Ils peuvent tre envisags, pour nombre dentre eux,
comme des facteurs invariants une analyse contingente pour la mise en uvre russie dune
dmarche agile .
La dmarche managriale de type agile a demble t guide par lattention des acteurs
accorde des questionnements dordre managrial et organisationnel. A travers leurs
interrogations, les acteurs ont tent de circonscrire les situations problmatiques quils
souhaitaient traiter. Ils ont ainsi privilgi certains lments de contexte en les simplifiant et
en les interprtant. Ils ont mis en uvre nombre dactions et ont ragi nouveau au produit de
leurs actions. Leur manque dexpriences et de connaissances en dveloppement et gestion de
projet agile , leur volont de safficher en tant ququipe lean , les dcisions du Codir,
leur rationalit limit, les outils leur disposition (PDCA, QQCQOP, 5 Pourquoi, etc.), les
allers-retours sur le terrain et leurs faibles pouvoirs de position par lesquels ont t rgies
leurs ngociations et interprtations, ont ainsi influenc la manire dont la dmarche a t
construite et mise en uvre.
A lumire de ces rsultats, il apparat que la cration dun environnement agile au sens des
agilistes ncessite une rflexion ex ante sur le contexte dapplication. Nos observations et
analyses montrent que limplmentation des outils agiles se heurte plusieurs difficults.
Ainsi, la dmarche managriale qui a t entreprise au sein du contexte tudi ne semble pas
avoir abouti ses fins dans le sens o les outils nont pas t adopts, et appropris par les
quipes pilotes. Seuls quelques plans daction ont t mis en place au niveau dun groupe
restreint dacteurs.
Nous assistons aujourdhui ce qui peut apparatre comme un changement de paradigme de
gestion de projet. Dans un environnement o rgne lincertitude, les entreprises sont amenes
accrotre leurs capacits dadaptabilit et de ractivit. La philosophie prdictive et
rigide des approches traditionnelles qui souligne le besoin de planifier et destimer de
195

Conclusion gnrale

faon dfinitive lensemble du projet devient trs risque et inadapte. Par-del le courant des
mthodes agiles , nous assistons une diffusion dapproches gestionnaires qui favorisent
des organisations apprenantes , capables de rpondre aux besoins du march par leurs
capacits dadaptation, damlioration et dinnovation. Cest dans cette perspective de
souplesse dadaptation et dvolution permanente que les mthodes agiles se sont
inscrites. Elles valorisent, dans les discours gestionnaires qui les supportent, la capitalisation
sur les connaissances, l'apprentissage interindividuel, lamlioration continue, etc. Toutefois,
ces mthodes se heurtent des problmes divers qui relvent de leur manque de
formalisme rendant difficile leur application dans les structures qui dpassent le primtre
dune quipe rduite de dveloppement informatique.
De fait, deux situations peuvent tre envisageables pour les structures organisationnelles plus
complexes souhaitant emprunter la voie de lagilit :
(1) une structure et une culture dorganisation qui, dans son ensemble, favorise le
dveloppement dune organisation apprenante dans laquelle le travail collectif et
lenvironnement informatif sont mis en avant. Ce cas de figure implique une dmarche
soutenue par la direction gnrale qui pour sa part, doit assurer le support ncessaire en
termes de temps, de moyens, de formations, etc. et favoriser la conduite du changement. Ce
type de chantier dinnovation managriale peut puiser dans la bote outils des mthodes
agiles sans toutefois puiser par cela, la question de la fabrique dune nouvelle
approche managriale,
(2) ladaptation des pratiques agiles aux ralits de lorganisation concerne. Ce cas de
figure accrot le risque de sloigner de la philosophie managriale agile . En effet, un
environnement agile favorise la collaboration, le travail en binme, lapprentissage
interindividuel, le partage des connaissances tacites, les feedback continus, la transparence, le
contrle continu, etc. Or, la cration dun tel environnement est difficile construire dans une
grande organisation, structure complexe. Un travail de contextualisation des mthodes
agiles doit alors tre effectu.
Fondamentalement, il ressort de notre travail de thse que contrairement ce que la notion
dagilit laisse croire, les mthodes agiles requirent un cadre bien structur o les quipes
intervenant sur un projet doivent tre stables, communiquer de faon rgulire et tre
196

Conclusion gnrale

rassembles sous lautorit dun responsable de projet. Autrement dit, les pratiques
managriales qui y sont associes prsentent une forme de rigidit organisationnelle qui
relve du cadre trs structur et structurant des mthodes agiles : livraison itrative toutes
les deux quatre semaines, runions quotidiennes avec lensemble de lquipe, disposition du
mobilier pour favoriser le travail en binme, murs accessibles sur lesquels sont affichs les
fonctionnalits, les tches, lagenda de la runion, etc. Ce cadre est plus adapt aux
organisations apprenantes o les quipes sont de taille rduite, travaillent dans un mme
espace physique et se coordonnent par ajustement mutuel. Dans des structures plus
complexes, il importe aux managers qui rflchissent la fabrique dune dmarche
agile dinventer des cadres structurants qui rigidifient certaines lments de
lorganisation afin de lui permettre dtre agile . Il convient en effet de formaliser les
procdures dapprentissage sans prjuger des enseignements tirer face aux situations
nouvelles rvles par l'apparition de dysfonctionnements. Lacquisition des connaissances
provient en grande partie de la rsolution des problmes. Les dysfonctionnements sont autant
doccasion dapprendre condition daccepter de les rendre visibles, didentifier leurs causes
profondes et dexprimenter des contre-mesures. Ds lors, les actions conduites par les
managers doivent faciliter lmergence de dysfonctionnements, permettre la recherche de
leurs causes profondes et encourager lexprimentation. Les mthodes agiles deviennent
ainsi des mthodes de formation des collaborateurs. La formation de ces collaborateurs est
encadre par un ensemble doutils mais renvoie lacquisition de connaissances
indtermines ex ante.
2. Les apports de ce travail de recherche
Ce travail de thse aborde les mthodes de gestion de projet agiles partir dun nouvel
angle dapproche, celui de lapproche par la pratique . Aujourdhui, rares sont les crits
avoir mobilis un construit thorique de ce type pour tudier la mise en place des outils
agiles et encore moins nombreux sont ceux stre intresss la manire dont les acteurs
contribuent leur fabrication dans une structure organisationnelle complexe.
Ce travail contribue ainsi au domaine naissant de la fabrique de la stratgie en examinant
les pratiques stratgiques partir desquels les praticiens transforment la stratgie managriale
de leur entreprise. A ce titre, cette thse met en avant limportance de se focaliser sur les

197

Conclusion gnrale

micropratiques et les caractristiques contextuelles pour apprhender la construction et


laccomplissement social de la stratgie.
En mobilisant la grille danalyse du sensemaking nous avons pu montrer comment une
approche par la pratique peut reposer sur un modle thorique existant en sciences de
gestion afin dexaminer les activits stratgiques des praticiens.
Sur le plan empirique, cette thse a permis dapporter un nouveau regard sur les lments
dordre contextuel susceptibles daffecter la fabrication dune stratgie agile . Grce
ltude longitudinale mene et lapproche danalyse par la pratique adopte, nous avons
pu recenser une liste de facteurs contextuels identifis par les acteurs comme contraignant la
mise en place de la dmarche et mettre davantage laccent sur la logique dorganizing
laquelle renvoient ces mthodes de gestion de projet informatique. La prise de conscience de
ces facteurs contextuels permettra dviter ou tout du moins danticiper une partie des risques
lis la mise en uvre de ces pratiques dans une structure organisationnelle complexe et par
consquent daccrotre les possibilits de contextualisation de ces outils mergents de
dveloppement et de management de projet informatique.
En outre, lapproche danalyse par la pratique nous a permis dexaminer de prs les
pratiques qui semblent jouer un rle critique dans laccomplissement de la stratgie. Peu
nombreux sont les travaux qui se sont focaliss sur les prdispositions, les savoirs, lidentit
organisationnelle des parties prenantes dune entreprise dans laccomplissement dune
stratgie agile .
3. Limites et pistes futures
Tout en contribuant la littrature en gestion de projet agile et lapproche de la
fabrique de la stratgie, notre recherche prsente plusieurs limites quil nous faut signaler.
Nos constatations ne sont pas gnralisables lensemble des organisations souhaitant mettre
en place une dmarche agile . Notre analyse empirique concerne un contexte dtude
particulier et tel tait lenjeu au travers du choix mthodologique que nous avons fait : une
tude de cas instrumentale qui permet dexaminer et denrichir le substrat thorique des
mthodes agiles. Toutefois, dans une perspective de gnralisation, certains lments mis en
avant ici nous semblent prsenter un caractre gnrique ; mais bien videmment dautres
198

Conclusion gnrale

tudes de terrain seront ncessaires pour aller dans la voie de la gnralisation. Il serait
galement intressant dobserver comment dautres groupes dacteurs, uvrant dans des
structures organisationnelles similaires, mettent en place une dmarche de management de
projet agile .
En outre, le cas tudi mobilise un nombre limit de pratiques agiles . Bien quau dpart
lquipe lean se soit intresse plusieurs pratiques et outils agiles , elle les a
progressivement abandonns pour se contenter finalement dune liste assez restreinte. Il serait
donc intressant, dans la continuit de nos travaux, de nous pencher sur lapplication dun
plus grand nombre doutils et pratiques agiles . Par ailleurs, une tude comparative pourrait
faire ressortir une liste de pratiques stratgiques concernant lapplication de ces mthodes
dans de telles structures.
Enfin, nous nous sommes intresss l la fabrique dune stratgie agile et non son
adoption et appropriation par les acteurs de terrain. Ce volet danalyse reste explorer.

199

200

Bibliographie

Bibliographie

1. Abrahamsson P., Salo O. & Ronkainen J. (2002), Agile Software Development Methods
Review and Analysis , VTT Publications.
2. Agerfalk P.J. & Fitzgerald B. (2006), Flexible and distributed software processes: Old
petunias in new bowls? , Communications of the ACM, vol 49, n10, pp. 27-34.
3. Agourram H. (2009), Defining information system success in Germany , International
Journal of Information Management, vol 29, n2, pp. 129-137.
4. Ajzen I. (1991), The theory of planned behavior , Organizational Behavior and Human
Decision Processes, vol 50, n2, pp. 179-211.
5. Al-Gahtani S.S., Hubona G.S. & Wang J. (2007), Information technology (IT) in Saudi
Arabia : culture and the acceptance and use of IT , Information and Management, vol 44,
n8, pp. 681-691.
6. Allard-Poesi F. & Marchal C. (2007), La construction de lobjet de recherche , in
Thitart R.A. & al., Mthodes de recherche en management, Dunod, Paris, pp. 34-56.
7. Allison I. & Merali Y. (2007), Software process improvement as emergent change : a
structurational analysis , Information and software technology, vol 49, n6, pp. 668-681.
8. Al-Rawas A. & Easterbrook S.M. (1996), A field study into the communications
problems in requirements engineering , Conference on Professional Awareness in Software
Engineering, London.
9. Ambler S. (2002b), Lessons in agility from internet-based development , IEEE
Software, vol 19, n2, pp. 66-73.
10. Antonacopoulou E. (2006), Strategizing as practising : strategic learning as a source of
connection , AIM Research Working Paper Series, pp. 1-35.
11. Autissier D. & Bensebaa F. (2006), Les dfis du sensemaking en entreprise : Karl Weick
et les sciences de gestion, Economica.
12. Autissier D., Guillard A. & Moutot J.M. (2010), La capacit de transformation comme
composante du capital humain : une tude exploratoire dans un groupe cot , Revue
management & avenir, vol 1, n31, pp. 95-117.
13. Bahli B. & Zeid E.S.A. (2005), The role of knowledge creation in adopting extreme
programming model: an empirical study , ITI 3rd International Conference on Information
and Communications Technology: Enabling Technologies for the New Knowledge Society.

201

Bibliographie

14. Balogun J. & Johnson G. (2004), Organizational Restructuring and Middle Manager
Sensemaking , Academy of Management Journal, vol 47, n4, pp. 523-549.
15. Basili V.R. & Turner A.J. (1975), Iterative enhancement : a practical technique for
software development , IEEE Transactions on Software Engineering, vol 1, n4, pp. 390396.
16. Baumard P. (1997), Constructivisme et processus de recherche : lmergence dune
posture pistmologique chez le chercheur , Cahiers du LAREGO, UVSQ, n 27.
17. Beauvallet G. & Chabiron C. (2006), Le Muda sous la moquette : comment dmarrer
une dmarche de lean office , Working paper n3, Projet Lean Entreprise.
18. Beavers P.A. (2007), Managing a large agile software engineering organization ,
IEEE Computer Society, pp. 296-303.
19. Beck K. & Andres C. (2004), Extreme Programming Explained: Embrace Change,
Addison-Wesley Professional, 2nd edition.
20. Begel A. & Nagappan N. (2007), Usage and perceptions of agile software development
in an industrial context : an exploratory study , Proceedings of the First International
Symposium on Empirical Software Engineering and Measurement, IEEE Computer Society,
Madrid, pp. 255-264.
21. Berczuk S. (2007), Back to basics : the role of agile principles in success with an
distributed scrum team , Proceedings of Agile Conference, IEEE Computer Society,
Washington, pp. 382-388.
22. Berger H. (2007), Agile development in a bureaucratic arena : a case study experience ,
International Journal of Information Management, vol 27, n6, pp. 386-396.
23. Blais M. & Martineau S. (2006), Lanalyse inductive gnrale : description dune
dmarche visant donner un sens des donnes brutes , Recherches Qualitatives, vol 26,
n2, pp. 1-18.
24. Blumer H. (1969), Symbolic interactionism : perspective and method, Englewood Cliffs,
NJ: Prentice Hall.
25. Boehm B. (1988), A spiral model of software development and enhancement , IEEE
Computer, vol 25, n5, pp.61-72.
26. Boehm B. (2002), Get ready for agile methods with care , Computer Publications, vol
35, n1, pp. 64-69.
27. Boehm B & Turner R. (2003), Observations on balancing discipline and agility ,
proceedings of the Conference on Agile Development, IEEE Computer Society, pp. 165-194
28. Boehm B. & Turner R. (2005), Management challenges to implementing agile processes
in traditional development organizations , Software, IEEE, vol 22, n5, pp. 30-39.
29. Braithwaite K. & Joyce T. (2005), XP expanded : distributed extreme programming ,
6th International Conference on Extreme Programming and Agile Processes in Software
Engineering, Lecture Notes in Computer Science, vol 3556, pp. 180-188.
30. Chan M.L & Pan S.L. (2008), User engagement in e-government systems
implementation : a comparative case study of two Singaporean e-government initiatives ,
The Journal of Strategic Information Systems, vol 17, n2, pp. 124-139.

202

Bibliographie

31. Chanal V. (2000), Communauts de pratique et management par projet : A propos de


l'ouvrage de Wenger (1998) , Management, vol 3, n1, pp. 1-30.
32. Chanal V. (2008), La stratgie en pratiques , in Management, fondements et
renouvellement, Schmidt G., Sciences Humaines, pp. 42-50.
33. Charreire S. & Huault I. (2001), Le Constructivisme dans la pratique de recherche: une
valuation partir de seize thses de doctorat , Finance Contrle Stratgie, vol. 4, n3, pp.
31-55.
34. Chong J. (2005), Social behaviors on XP and non XP : a comparative study ,
Proceedings of Agile Development Conference, Computer Society, pp. 39-48.
35. Chow T. & Cao D.B. (2008), A survey study of critical success factors in agile software
projects , The journal of Systems and Software, vol 81, n6, pp. 961-971.
36. Cockburn A. (2000), Selecting a projects methodology , IEEE Software, vol (17), n4,
pp. 64-71
37. Cockburn A. & Highsmith J. (2001), Agile software development : The People Factor ,
Computer, pp. 131-133.
38. Cockburn A. (2002b), Agile software development joins the would be crowd , Cutter
IT Journal, vol 15, n1, pp. 6-12.
39. Cockburn A. & Williams L. (2003), Agile software development : it's about Feedback
and Change , Computer, vol 36, n6, pp. 39-43.
40. Cohen D., Lindvall M. & Costa P. (2004), An introduction to agile methods , Advances
in computers, vol 62, pp. 1-66.
41. Cohn M. & Ford D. (2003), Introducing an agile process to an organization , IEEE
Computer Society, pp. 74-78.
42. Collerette P. (1997), Ltude de cas au service de la recherche , Recherche en soins
infirmiers, n50, pp. 81-88.
43. Conboy K. & Fitzgerald B. (2004), Toward a conceptual framework of agile methods: a
study of agility in dierent disciplines , Proceedings of XP/Agile Universe, Springer Verlag.
44. Corradi J., Gherardi S. & Verzelloni L. (2008), Ten good reasons for assuming a
practice lens in organization studies , 3rd OLKC Conference.
45. Cristal M., Wildt D. & Prikladnicki R. (2008), Usage of scrum Practices within a global
company , Proceedings of ICGSE, pp. 22-226.
46. Dalcher D., Benediktsson O. & Thorbergsson H. (2005), Development life cycle
management: a multiproject experiment, Proceedings of the 12th International Conference
and Workshops on the Engineering of Computer-Based Systems.
47. Danait A. (2005), Agile offshore techniques - a case study , Proceedings of Agile
Conference, Denver, Colorado, pp. 214-217.
48. David A. (1996), Structure et dynamique des innovations managriales , Cahier du
Centre de Gestion Scientifique, Ecole des Mines de Paris, n12.
49. David A. (2000), Logique, mthodologie et pistmologie en sciences de gestion : trois
hypothses revisites in David A., Hatchuel A. & Laufer R., Les nouvelles fondations des
sciences de gestion, Vuibert, collection FNEGE.
203

Bibliographie

50. David A. (2004), Etudes de cas et gnralisation scientifique en sciences de gestion ,


Actes du colloque Association Internationale du Management Stratgique (AIMS),
Normandie, pp. 1-21.
51. Davis F.D. (1989); Perceived usefulness, perceived ease of use, and user acceptance of
information technology , MIS Quarterly, vol 13, n3, pp. 318-340.
52. Dyba T. (2000), Improvisation in small software organizations , IEEE Software, vol 17,
n5, pp. 82-87.
53. Dyba T. & Dingsoyr T. (2009); Empirical studies of agile software development : A
systematic review , Information and software Technologies, vol 50, n9-10, pp. 833-859.
54. Dingsoyr T., Dyba T. & Abrahamsson P. (2008), A preliminary roadmap for empirical
research on agile software development , Proceedings of Agile 2008 Conference, IEEE
Computer Society, pp. 83-94.
55. Dyer W.G. & Wilkins A.L. (1991), Better stories, not better constructs, to generate
better theory: a rejoinder to Eisenhardt , The Academy of Management Review, vol. 16, n3,
pp. 613-619.
56. ECOSIP, 1993, Pilotages de projet et entreprise : diversits et convergences, sous la
direction de Midler C. et Giard V., Economica, Paris.
57. Eisenhardt K. M. (1989), Building theories from case study research , The Academy of
Management Review, vol. 14, n4, pp. 532-550.
58. Eriksson J., Lyytinen K. & Siau K. (2005), Agile modeling, agile software development
and extreme Programming: the state of research , Journal of database Management, vol 16,
n4, pp. 88-100.
59. Farmer M. (2004), Decision space infrastructure : agile development in a large
distributed team , Agile Development Conference, Salt Lake City, Utah, pp. 95-99.
60. Fitzgerald B., Hartnett G. & Conboy K. (2006a), Customising agile methods to software
practices at Intel Shannon , European Journal of Information Systems, vol 15, n2, pp. 200213.
61. Flavin C., Guinalu M. & Gurrea R. (2006), The role played by perceived usability,
satisfaction and consumer trust on website loyalty , Information and Management, vol 43,
n1, pp. 1-14.
62. Fowler M., Using an agile software process with offshore development ,
http://www.martinfowler.com/articles/agileOffshore.html.
63. Frooman J. (1999), Stakeholder influence strategies , The Academy of Management
Review, vol 24, n2, pp. 191-205.
64. Furugaki K., Tagaki T., Okayama D. & Sakata A. (2006), Innovation in software
development process by introducing Toyota Production System , Fujitsu sci. Tech. J., vol
43, n1, pp. 139-150.
65. Garel G. (2003), le management de projet, La dcouverte.
66. Garel G. (2003), Pour une histoire de la gestion de projet , Grer et Comprendre, n74.
67. Gherardi S. (2000), Practice based theorizing on learning and knowing in
organizations , Organization, vol 7, n2, pp. 211-223.
204

Bibliographie

68. Gherardi S. (2001), From organizational learning to practice based knowing , Human
relations, vol 54, n1, pp. 131-139.
69. Gherardi S. & Silli A. (2007), Agile information systems as a double dream in
Desouza K.C, Agile Information Sytems : conceptualization, construction and management,
Oxford, pp. 110-121.
70. Gibson W. &Brown A. (2009), Working with qualitative data, Sage Publications.
71. Gioia D.A. & Chittipeddi K. (1991), Sensemaking and sensegiving in strategic change
initiation , Strategic Management Journal, vol 12, pp. 433-448.
72. Girod-Sville M. & Perret V. (2007), Fondements pistmologiques de la recherche, in
Thitart R.A. & al., Mthodes de recherche en management, Dunod, Paris, pp. 13-33.
73. Gunasekaran A. & Yusuf Y.Y. (2002), Agile manufacturing: a taxonomy of strategic
and technological imperatives , International Journal of Production Research, vol 40, n6,
pp. 1357-1385.
74. Herbsleb J.D. & Grinter R.E. (1999), Splitting the organization and integrating the code
: Conways law revisited , Proceedings of the 21st International Conference on Software
Engineering, CA, USA, pp. 85-95.
75. Herbsleb J.D. & Moitra D. (2001), Global software development , IEEE Software, vol
18, n2, pp. 16-20.
76. Highsmith J. & Cockburn A. (2001), Agile software development : the business of
innovation , Computer, vol 34, n9, pp. 120-122.
77. Hilkka M-R., Tuure T. & Matti R. (2005), Is extreme programming just old wine in new
bottle : a comparison of two cases , Journal of Database Management, vol 16, n4, pp. 4161.
78. Hossain E., Babar M.I. & Paik H.Y. (2009), Using scrum in global software
development : a systematic literature review , 4th IEEE International Conference on Global
Software Engineering, Sydney, pp. 175-184.
79. Houy T. (2009), Articulation entre pratiques managriales et systmes d'information :
construction d'un idal type et modlisations , thse de Doctorat en Sciences de Gestion,
dpartement Sciences conomiques et Sociales, Tlcom Paristech.
80. Hollnagel E., Journ B. & Laroche H. (2009), Fiabilit et rsilience comme dimensions
de la performance organisationnelle , Management, vol 12, n4, pp. 224-229.
81. Howcroft D., Newell S. & Wagner E. (2004), Understanding the contextual influences
on the enterprise system design, implementation, use and evaluation , The Journal of
Strategic Information Systems, vol 13, n4, pp. 271-277.
82. Hu P.J.H., Clark T.H.K. & Ma W.W. (2003), Examining technology acceptance by
school teachers: A longitudinal Study , Information and Management, vol 41, n2, pp. 227241.
83. Im I., Kim Y. & Han H.J. (2008); The effects of perceived risk and technology type on
users acceptance of technologies , Information and Management, vol 45, n1, pp. 1-9.
84. Jalali S. & Wohlin C. (2010), Agile practices in global software engineering - A
systematic map , Proceedings of the 5th International Conference on Global Software
Engineering, IEEE Computer Society, pp. 45-54.
205

Bibliographie

85. Jarzabkowski P. (2003), Strategic practices: an activity theory perspective on continuity


and change , Journal of Management Studies, vol 40, n1, pp. 23-56.
86. Jarzabkowski P. (2004), Strategy as practice: recursive, adaptive and practices-in-use ,
Organization Studies, vol 25, n4, pp. 529-560.
87. Jarzabkowski P. (2005), Strategy as practice : an activity based approach, Sage
Publications, London.
88. Jarzabkowski P., Balogun J. & Seidl D. (2007), Strategizing: The challenges of a
practice perspective , Human Relations, vol 60, n1, pp. 5-27.
89. Jensen B. & Zilmer A. (2003), Cross-continent development using scrum and XP ,
Lecture Notes in Computer Science, vol 2675, pp. 146-153.
90. Jokela T. & Abrahamsson P. (2004), Usability assessment of an extreme programming
project : close co-operation with the customer does not equal to good usability , Product
Focused Software Process Improvement, Lecture Notes in Computer Science, vol. 3009,
Berlin, pp. 393-407.
91. Journ B. & Raulet-Croset N. (2008), le concept de situation : contribution lanalyse
de lactivit managriale dans un contexte dambigut et dincertitude , Management, vol
11, n1, pp. 27-55.
92. Kahkonen T. (2004), Agile methods for large organizations - Building communities of
practice , Proceedings of Agile Development Conference, IEEE Computer Society.
93. Khknen T. & Abrahamsson P. (2004), Achieving CMMI level 2 with enhanced
Extreme Programming approach, Lecture notes in computer science, vol 3009, pp. 378-392.
94. Karlstrm D. & Runeson P. (2005), Combining agile methods with stage-gate project
management , IEEE Computer Society, vol 22, n3, pp. 43-49.
95. Katayama H. & Bennett D. (1999), Agility, adaptability and leanness : a comparison of
concepts and a study of practice , International Journal of Production Economics, vol 60-61,
pp. 43-51.
96. Kettunen P. (2009), Adopting key lessons from agile manufacturing to agile software
product development - a comparative study , Technovation, vol 29, n6-7, pp. 408-422.
97. Kidd P.T. (1995), Agile manufacturing: a strategy for the 1st century , Agile
Manufacturing, IEE Colloquium, Coventry.
98. Kim Y.J., Chun J, Hsu J.S.H., Chan C.L. & Chen H.G. (2008), The impacts of user
review on software responsiveness : Moderating requirements uncertainty , Information and
Management, vol 45, n4, pp. 203-210.
99. Kircher M., Jain P., Corsaro A. & Levine D. (2001), Distributed extreme
programming , Proceedings 2nd Conference on Extreme Programming and Flexible
Processes in Software Engineering, Sardinia, Italy.
100. Kniberg H. (2007), Scrum et XP depuis les tranches, C4Media, diteur de InfoQ.
101. Kniberg H. & Skarin M. (2009), Kanban et Scrum- tirer le meilleur des deux, C4 Media,
diteur de InfoQ.
102. Koch S. (2004), Agile principles and open source software development : a theoretical
and empirical discussion , Extreme Programming and Agile Processes in Software
Engineering, Lecture Notes in Computer Science, vol 3092, Germany; pp. 85-93.
206

Bibliographie

103. Koenig G. (2003), lorganisation dans une perspective interactionniste, in Vidaillet B., le
sens de laction, Vuibert, pp. 15-34.
104. Koskela J. & Abrahamsson P. (2004), on site customer in an XP project : empirical
results from a case study, Software Process Improvement 11th European Conference,
Lecture Notes in Computer Science, vol 3281, Berlin, pp. 1-11.
105. Kumar D.R. (2005), Lean software development , The project perfect white paper
collection, pp. 1-9.
106. Langley A. (1999), Strategy for theorizing from process data , Academy of
Management Review, vol 24, n4, pp. 691-710.
107. Larman C. & Basili V. (2003), Iterative and incremental development : a brief
history , Computer, pp. 47-56.
108. Layman L., Williams L. & Cunningham L. (2004), Exploring extreme programming in
context : an industrial case study , Proceeding of the Agile Development Conference, IEEE
Computer Society.
109. Layman L., Williams L., Damia D. & Bures H. (2006), Essential communication
practices for extreme programming in a global software development team , Information and
Software Technology, vol 48, n9, pp. 781-794.
110. Lee S., Kim I., Trimi S. (2006); The role of exogenous factors in technology
acceptance: The case of object-oriented technology , Information and Management, vol 43,
n4, pp 469-480.
111. LeJeune N.F. (2006), Teaching software engineering practices with extreme
programming , Journal of Computing Sciences in Colleges, vol 21, n3, pp. 107-117.
112. Lindvall M. & Rus I. (2000), Process diversity in software development IEEE
Software, pp. 14-18.
113. Lindvall M., Basili V., Boehm B., Costa P., Dangle K., Shull F., Tesoriero R., Williams
L. & Zelkowitz M. (2002), Empirical Findings in Agile Methods , Proceedings of the
Second XP Universe and First Agile Universe Conference on Extreme Programming and
Agile Methods, XP/Agile Universe, vol 2418, London, pp. 197-207.
114. Llieva S., Ivanov P. & Stefanova E. (2004), Analyses of an agile methodology
implementation , Proceedings of the 30th EUROMICRO Conference, IEEE Computer
Society, pp. 326-333.
115. Louis M.R. (1980), Surprise and sense making: What newcomers experience in
entering unfamiliar organizational settings , Administrative Science Quarterly, vol 25, pp.
226-251.
116. Maarit L. (2008), Implementing program model with agile principles in a large
software development organization , Proceedings of 32nd IEEE International Computer
Software and Applications Conference, Turku, pp. 1383-1391.
117. Maitlis S. (2005), The social process of organizational sensemaking , Academy of
Management Journal, vol 48, n1, pp. 21-49.
118. Mann C. & Maurer F. (2005), A case study on the impact of scrum on overtime and
customer satisfaction , Proceedings of the Agile Development Conference, IEEE Computer
Society, Washington, pp. 70-79.
207

Bibliographie

119. Mannaro K., Melis M. & Marchesi M. (2004), Empirical analysis on the satisfaction
of IT employees comparing XP practices with other software development methodologies ,
Extreme Programming and Agile Processes in Software Engineering, Proceedings, Lecture
Notes in Computer Science, vol. 3092, pp. 166-174.
120. Mar K. & Schwaber K. (2002), Scrum with XP , InformIT.
121. Martin A., Biddle R. & Noble J. (2004), The XP customer role in practice : three
studies , Proceedings of the Agile Development Conference, Computer Society, Utah, pp. 4254.
122. Melnik G. & Maurer F. (2002), Perceptions of agile practices : a student survey ,
Proceedings of the Second XP Universe and First Agile Universe Conference on Extreme
Programming and Agile Methods, Lecture Notes in Computer Science, vol 2418, pp. 241-250.
123. Melnik G. & Maurer F. (2005), A cross-program investigation of students perceptions
of agile methods , International conference of Software Engineering, pp. 481-488.
124. Messager Rota V. (2008), Gestion de projet vers les mthodes agiles, Eyrolles.
125. Middleton P., Flaxel A. & Cookson A. (2005), Lean software management case study:
Timberline Inc. , Extreme Programming and Agile Processes in Software Engineering,
Lecture notes in computer science, vol 3556, n 1297-1298, pp. 1-9.
126. Middleton P. & Joyce D. (2010), Lean software management: BBC worldwide case
study , IEEE Transactions engineering management, pp. 1-13.
127. Midler C. (1993b), Gestion de projet, lentreprise en question , in ECOSIP Pilotages
de projet et entreprises : diversits et convergences, sous la direction de Midler C. & Giard V.,
Economica, pp. 17-31.
128. Miles M.B. & Huberman A.M. (1994), Qualitative data analysis: An expanded source
Book, Sage Publications:
129. Mintzberg H. (1984), le manager au quotidien : les dix rles du cadre, Organisation.
130. Mockus A. & Herbsleb J. (2001), Challenges of global software development ,
Proceedings 7th International Software Metrics Symposium, London, pp. 182-184.
131. Morien R. (2005), Agile management and the Toyota way for software project
management , Proceedings of the 3rd IEEE International Conference on Industrial
Informatics, IEEE Computer Society, pp. 516-522.
132. Morley C. (2006), Management dun projet systme dinformation, Dunod, 6 me dition.
133. Murru O., Deias R. & Mugheddu G. (2003), Assessing XP at a European Internet
Company , IEEE Software, vol 20, n3, pp. 37-43.
134. Navarre C. (1993), Pilotage stratgique de la firme et gestion de projet : de Ford et
Taylor agile et IMS , in ECOSIP Pilotages de projet et entreprises : diversit et
convergences, sous la direction de Midler C. & Giard V., Economica, pp. 181-215.
135. Nagel R.N., Dove R., Goldman S. & Preiss K. (1991), 1st century manufacturing
enterprise strategy : an industry led view , Iacocca Institute, Bethlehem, PA.
136. Narasimhan R., Swink M. & Kim S.W. (2006), Disentangling leanness and agility : an
empirical investigation , Journal of Operations Management, vol 24, n5, pp. 440-457.

208

Bibliographie

137. Orlikowski W.J. & Gash D.C. (1994), Technological frames : making sense of
information technology in organizations , ACM Transactions on Information Systems
(TOIS), vol 12, n2, pp. 174-207.
138. Orlikowski W. (2000), Using Technology and Constituting Structures : a Practice Lens
for Studying Technology in Organizations , Organization Science, vol 11, n4, pp. 404-428.
139. Orlikowski W.J. &Yates J. (2006), ICT and Organizational Change , The journal of
applied behavioral sciences, vol 42, n1, pp. 127-134.
140. Ozanne J.L. & Hudson L.A. (1989), Exploring diversity in consumer research , in
Hirschman E.C, Interpretive Consumer Research, Business and Economics, pp. 1-9.
141. Paasivaara M. & Lassenius C. (2004), Using Iterative and Incremental Processes in
Global Software Development , Proceedings of the ICSE Workshop on Global Software
Development, Edinburgh, Scotland, pp. 42-47.
142. Paasivaara M., Durasiewicz S. & Lassenius C. (2008), Distributed agile development :
Using Scrum in a large project , IEEE International Conference on Global Software
Engineering, Bangalore, pp. 87-95.
143. Paasivaara M., Durasiewicz S. & Lassenius C. (2009), Using scrum in distributed agile
development : A multiple case study , 4th IEEE International Conference on Global
Software Engineering, Limerick, Ireland, pp. 195-204.
144. Paetsch F., Eberlein A. & Maurer F. (2003), Requirements engineering and agile
software development , Proceedings of the IEEE International Workshops on Enabling
Technologies: Infrastructure for collaborative enterprises, Austria, pp. 308-313.
145. Pan G. (2005), Information systems project abandonment: a stakeholder analysis,
International Journal of Information Management, vol 25, n2, pp. 173-184.
146. Petersen K. & Wohlin C. (2009), A comparison of issues and advantages in agile and
incremental development between state of the art and an industrial case , Journal of systems
and software, vol 82, n9, pp. 1479-1490.
147. Poole C.J. (2004), Distributed product development using extreme programming ,
Lecture Notes in Computer Science, vol 3092, pp. 60-67.
148. Poppendieck M. &T. (2003), Lean software development : an agile toolkit, AddisonWesley.
149. Poppendieck M. & T. (2006), Implementing lean software development : from concept
to cash, Addison-Wesley.
150. Poppendieck M. & T. (2009), Leading lean software development : results are not the
point, Addison-Wesley.
151. Quinet C. (1994), Herbert Simon et la rationalit , Revue franaise d'conomie. vol 9,
n1, pp. 133-181.
152. Qumer A. & Henderson-Sellers B. (2008), A framework to support the evaluation,
adoption and improvement of agile methods in practice , The Journal of Systems and
Software, vol 81, pp. 1899-1919.
153. Ramesh B., Cao L., Mohan K. & Xu P. (2006), Can distributed software development
be agile? Communications of the ACM, vol 49, n10, pp. 41-46.

209

Bibliographie

154. Rising L. & Janoff N. (2000), The scrum software development process for small
teams , IEEE Software, vol 17, n4, pp. 26-32.
155. Robinson H. & Sharp H. (2004), The characteristics of XP Teams , Extreme
Programming and Agile Processes in Software Engineering, Lecture Notes in Computer
Science, vol 3092, Berlin, pp. 139-147.
156. Robinson H, Sharp H. (2005); Organizational culture and XP : three case studies ,
Proceedings of the agile conference, Computer Society, pp. 49-58.
157. Robinson H., Segal J. & Sharp H. (2007), Ethnographically-informed empirical studies
of software practice , Information and Software Technology, vol 49, n6, pp. 540-551.
158. Rouleau L. (2005), Micro-practices of strategic sensemaking and sensegiving : How
middle managers interpret and sell change every day , The Journal of Management Studies,
vol 42, n7, pp.1413-1441.
159. Rouleau L. (2006), Comprendre la fabrique de la stratgie partir des rcits de
pratique in Golsorkhi (ed), La fabrique de la stratgie (pp.219-239), Paris, Vuibert.
160. Rouleau L. & Balogun J. (2007), Exploring the middle managers strategic
sensemaking role in practice , paper presented at the academy of management.
161. Rouleau L., Allard-Poesi F. & Warnier V. (2007), Le numro spcial de la RFG-AIMS
fait peau neuve , Revue Franaise de Gestion, vol 33, n174, pp. 13-14.
162. Rouleau L. & Balogun J. (2008), Exploring middle managers strategic sensemaking
role through practical knowledge , paper presented at the JMS Conference, Oxford.
163. Saeed K.A. & Helm S.A. (2008), Examining the effects of information system
characteristics and perceived usefulness on post adoption usage of information systems ,
Information and management, vol 45, n6, pp. 376-386.
164. Samra-Fredericks D. (2003), Strategizing as lived experience and strategists everyday
efforts to shape strategic direction , Journal of management studies, vol 40, n1, pp. 141174.
165. Schwaber K. & Beedle M. (2002), Agile software development with scrum, Prentice
Hall.
166. Schwandt T.A. (2000), Three epistemological stances for qualitative inquiry , in Kirk
D., MacDonald D. & O'Sullivan M., Handbook of physical education, Sage Publications.
167. Sekimura T. & Maruyama T. (2006), Development of enterprise business application
software by introducing Toyota Production System , Fujitsu sci. Tech. J., vol 42, n3, pp.
407-413.
168. Serignese K. (2011), A sprinkle of agile, a dash of lean, SPTechWeb.
169. Sharp H. & Robinson H. (2004); An ethnographic Study of XP Practice , Empirical
Software Engineering, vol 9, n4, pp. 353-375.
170. Sharp H. & Robinson H. (2007); Collaboration and coordination in mature Extreme
Programming teams, International Journal of Human Computer Studies, vol 66, n7, pp. 506518.
171. Sharp H., Hall T., Baddoo N. & Beecham S. (2007), Exploring motivational
differences between software developers and project managers , ESEC/FSE.
210

Bibliographie

172. Sharp H., Robinson H. & Petre M. (2009), The role of physical artifacts in agile
software development : Two complementary perspectives , Interacting with Computers, vol
21, n1-2, pp. 108- 116.
173. Sillitti A., Ceschi M., Russo B. & Succi G. (2005), Managing uncertainty in
requirements : a survey documentation driven and agile companies , 11th IEEE International
Software Metrics Symposium, Computer Society, pp. 10-17.
174. Simon H. (1997), Models of Bounded Rationality: Empirically Grounded Economic
Reason , vol 3, Massachusetts Institute of Technology Press.
175. Simons M. (2002), Internationally Agile , InformIT.
176. Smith G.F. (1989), Defining managerial problems: A framework for prescriptive
theorizing , Management science, vol 35, n8, pp. 963-981.
177. Smits H. (2007), Implementing scrum in a distributed software development
organization , Proceedings of the conference on agile, pp. 371-375.
178. Smits H. (2007), The impact of scaling on planning activities in an agile software
development context , Proceedings of the 40th Annual Hawaii international conference on
system sciences, IEEE Computer Society.
179. Smits H. & Pshigoda G. (2007), Implementing scrum in a distributed software
development , Proceedings of Agile Conference, Delhi, pp. 371-375.
180. Stake R.E. (1995), The art of case study research, Sage Publications.
181. Sugimori Y., Kusunoki K., Cho F. & Uchikawa S. (1977), Toyota production System
materialization of Just-in-time and respect-for-human system , International Journal of
Production Research, vol 15, n6, pp. 553-564.
182. Summers M. (2008), Insights into an agile adventure with offshore partners ,
Proceedings of the Conference on Agile, pp. 333-338
183. Sutherland J. (2001), Agile can scale : inventing and reinventing scrum in five
companies , Cutter IT Journal, vol 14, n12, pp.5-11.
184. Sutherland J. (2004), Agile development : lessons learned from the first scrum ,
Cutter Agile Project Management Advisory Service: Executive Update, vol 5, n20, pp. 1-4.
185. Sutherland, J. (2007). A brief introduction to scrum , in Sutherland J., The scrum
papers: nuts, bolts, and origins of an agile process, The Scrum Training Institute.
186. Sutherland J., Viktorov A., Blount J. & Puntikov N. (2007), Distributed scrum : agile
project management with outsourced development teams , 40th Annual Hawaii International
Conference on System Sciences, Waikoloa, pp. 274-274.
187. Sutherland J., Jakobsen C.R. & Johnson K. (2007), Scrum and CMMI level 5 : the
magic potion for code warriors , IEEE Computer Society, pp. 272-278.
188. Sutherland J. & Schwaber K. (2010), Nuts, bolts and origins of an agile framework
(http://jeffsutherland.com/ScrumPapers.pdf).
189. Svensson H. & Host M. (2005), Views from an organization on how agile
development affects its collaboration with software development team , International
conference on product focused software process improvement, Lecture Notes i n Computer
Science, vol 3547, Finland, pp. 487-501.
211

Bibliographie

190. Takeuchi H. & Nonaka I. (1986), The new product development game , Harvard
Business Review, pp. 137-146.
191. Tessem B. (2003), Experiences in learning XP practices : a qualitative study ,
Proceedings 4th International conference on Extreme Programming and Agile Processes in
Software Engineering, Italy, pp. 131-137.
192. Teulier R. (2006), Routines, micro-pratiques et caractrisation des connaissances ,
manuscrit prsent la semaine de la connaissance , Nantes, France.
193. Thomas J.B., Clark S.M. & Gioia D.A. (1993), Strategic sensemaking and
organizational performance: linkages among scanning, interpretation, action, and outcomes ,
The Academy of Management Journal, vol 36, n2, pp. 239-270.
194. Tsoukas H. & Chia R. (2002), On organizational becoming : Rethinking organizational
change , Organization Science, vol 13, n5, pp. 567-582.
195. Tudor D. & Walter G.A. (2006), Using an agile approach in a large, traditional
organization , Proceedings of Agile 2006 Conference, IEEE Computer Society, pp. 373-380.
196. Turner R. (2002), Agile Development: good process or bad attitude? , Lecture notes
in computer science, pp. 134-144.
197. Van de Ven A.H. & Poole M.S. (1995), Explaining Development and Change in
Organizations , The academy of Management Review, vol 20, n3, pp. 550-540.
198. Vavpotic D. & Bajec M. (2009), An approach for concurrent evaluation of technical
and social aspects of software development methodologies , Information and software
Technology, vol 51, n2, pp. 528-545.
199. Vax M. & Michaud S. (2008), Distributed agile : growing a practice together ,
Proceedings of the Conference on Agile, IEEE Computer Society, pp. 310-314.
200. Venkatesh V. (2000), Determinants of perceived ease of use: Integrating perceived
behavioral control, computer anxiety and enjoyment into the technology acceptance model ,
Information Systems Research, vol 11, n4, pp. 342-365.
201. Venkatesh V., Morris M.G., Davis G.B. & Davis F.D. (2003), User acceptance of
information technology : Toward a unified view , MIS Quarterly, vol 27, n3, pp. 425-478.
202. Vickoff J.P. (2008), Agile : controverses et rflexions (www.Entreprise-Agile.com).
203. Vidaillet B. (2003), Comment lenvie dclenche des processus de sensemaking dans les
organisations, in Les dfis du sensemaking en entreprise: Karl Weick et les sciences de
gestion, Autissier D. & Bensebaa F. (2006), Economica.
204. Wacheux F. (1996), Mthodes qualitatives et recherche en gestion, Economica, Paris.
205. Wagner E. & Newell S. (2005), Making software work : producing social order via
problem solving in a troubled ERP implementation , 26th ICIS Conference Proceedings, Las
Vegas.
206. Wang X. (2011), The combination of agile and lean in a software development : an
experience report analysis , 2011 Agile Conference, IEEE Computer Society.
207. Weick K.E. (1979), The social psychology of organizing, Addison-Wesley.
208. Weick, K. (1988), Enacted sensemaking in crisis situations , Journal of Management
Studies, vol 25, n4, pp. 305-317.
212

Bibliographie

209. Weick K.E. & Roberts K.H. (1993), Collective mind in organizations: Heedful
interrelating on flight decks , Administrative Science Quarterly, vol 38, pp. 357-381.
210. Weick K.E. (1993a), The collapse of sensemaking in organizations: The Mann Gulch
Disaster , Administrative Science Quarterly, vol 38, pp. 628-652.
211. Weick K.E. (1995), Sensemaking in organizations, Sage Publication, Thousand Oaks,
CA.
212. Weick K.E., Sutcliffe K., & Obstfeld D. (2005), Organizing and the process of
sensemaking , Organization Science, vol 16, n4, pp. 409-421.
213. Wellington C.A., Briggs T. & Girard C.D. (2005), Comparison of student experiences
with plan-driven and agile methodologies , Proceedings of the 35th Annual Conference,
IEEE Frontiers in Education, pp. T3G-18.
214. Wenger E. (2004), Knowledge management as a doughnut: Shaping your knowledge
strategy through communities of practice , IVEY Business Journal, pp. 1-8.
215. Whitworth E. & Biddle R. (2007), The social nature of agile teams , IEEE Computer
society, pp. 26-36.
216. Whittington R. (1996), Strategy as Practice , Long Range Planning, vol 29, n5, pp.
731-735.
217. Whittington R. (2003), The Work of Strategizing and Organizing: For a Practice
Perspective , Strategic Organization, vol 1, n1, pp. 117-125.
218. Whittington R. (2006), Completing the Practice Turn in Strategy Research ,
Organization, vol 27, n5, pp. 613-634.
219. Williams L., Kessler R., Cunningham R.W. & Jeffries R. (2000), Strengthening the
Case for Pair Programming , IEEE Software, vol 17, n4, pp. 19-25.
220. Williams L. (2003), The XP Programmer: The Few Minutes Programmer , IEEE
Software, vol 20, n3, pp. 16-20.
221. Williams L. & Cockburn A. (2003), Agile software development : its about feedback
and change , IEEE Computer Society, pp. 39-43.
222. Wren D. (2004), The history of management thoughts, Wiley, 5th edition.
223. Yap M. (2005), Follow the sun: distributed extreme Programming development ,
Proceedings of Agile Conference, Kirkland, pp. 218-224.
224. Yin R. (1990), Case study research design and methods, Sage Publications.
225. Young S.M., Edwards H.M., McDonald S. & Thompson J.B. (2005), Personality
characteristics in an XP team : a repertory grid study , Proceedings of the Human and Social
Factors of Software Engineering, St. Louis, USA.
226. Yusuf Y.Y., Sarhadi M. & Gunasekaran A. (1999), Agile manufacturing : the drivers,
concepts and attributes , International Journal of Production Economics, vol 62, pp. 33-43.

213

Rfrences we b

http://www.pmi.org/

(site ddi au management de projet).

http://agilemanifesto.org/

(site ddi au manifeste agile).

http://www.lean.enst.fr

(site centr sur le lean management).

http://www.cheshirehenbury.com/agility/index.html

(site centr particulirement


lagile manufacturing).

http://agilescout.com/top-agile-blogs-200/

(Site rfrenant les 200 meilleurs


blogs agiles).

http://leansi.wp.institut-telecom.fr/

(site centr sur le lean et les systmes


dinformation).

http://www.agilealliance.org/

(site ddi au dveloppement agile).

http://institut-agile.fr/

(Site ddi lensemble des pratiques


agiles).

http://www.ambysoft.com/

(site ddi aux best practices en


dveloppement de logiciels).

http://martinfowler.com/agile.html

(Site ddi au dveloppement agile de


logiciels).

http://alistair.cockburn.us/

(Site ddi au dveloppement agile de


logiciels).

http://scrumalliance.org/

(Site ddi au dveloppement agile


avec une focalisation sur la mthode
scrum).

http://www.controlchaos.com

(Site ddi principalement


mthode scrum).

http://xprogramming.com/index.php

(Site ddi la mthode extreme


programming).

http://www.rad.fr

(Site ddi aux techniques de gestion


de projet, aux pratiques agiles et la
mthode RAD).

sur

la

214

Annexes

Annexe

I- Traduction du manifeste agile 114

Nous avons trouv une voie amliorant le dveloppement logiciel en ralisant ce travail et
en aidant les autres le faire. De ce fait nous avons dduit des valeurs communes.
-

Les personnes et les interactions priment sur les processus et les outils
Une application qui fonctionne prime sur une documentation exhaustive
La collaboration avec le client prime sur la ngociation du contrat
Louverture au changement prime sur le suivi dun plan

Autrement dit, mme si il existe de la valeur dans les lments de droite, nous accordons plus
dimportance ceux de gauche.
Nous respectons les principes suivants :
-

114

Notre premire priorit est de satisfaire le client en livrant tt et rgulirement des


logiciels utiles.
Le changement est accept, mme tardivement dans le dveloppement. Les processus
agiles exploitent le changement comme avantage comptitif pour le client.
Livrer frquemment une application fonctionnelle, toutes les deux semaines deux mois,
avec une tendance pour la priode la plus courte.
Les experts mtier et les dveloppeurs doivent collaborer quotidiennement au projet.
Btir le projet autour de personnes motives. Leur donner l'environnement et le soutien
dont elles ont besoin, et croire en leur capacit faire le travail.
La mthode la plus efficace pour transmettre l'information est une conversation en face
face.
Un logiciel fonctionnel est la meilleure unit de mesure de la progression du projet.
Les processus agiles promeuvent un rythme de dveloppement soutenable.
Commanditaires, dveloppeurs et utilisateurs devraient pouvoir maintenir le rythme
indfiniment.
Une attention continue l'excellence technique et la qualit de la conception amliore
l'agilit.
La simplicit - l'art de maximiser la quantit de travail ne pas faire - est essentielle.
Les meilleures architectures, spcifications et conceptions sont issues d'quipes qui
s'auto-organisent.
intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace, puis accorde
et ajuste son comportement dans ce sens. .

(http://agilemanifesto.org/)

215

Annexes

II- Glossaire des mthodes agiles

- A3 problem solving : Document bas sur un format A3 o sont captures les informations
relatives aux problmes apparus (conditions actuelles, objectifs attendus, analyse des causes,
contre-mesure, confirmation des rsultats, suivi des actions).
- Andon : Signal ou tableau lumineux qui s'allume lorsque l'oprateur appuie sur un bouton
d'alerte ou tire sur un fil d'alarme.
- Burndown chart : Cest un graphe permettant de visualiser lavancement des tches
ralises par lquipe. Il comprend la quantit de travail restante dans une itration travers le
temps de cette itration.
- Client sur le site : Le client est prsent avec lquipe de dveloppement tout au long du
projet afin de rpondre ses questions, deffectuer les tests dacceptation et de sassurer que le
dveloppement se fait conformment ses attentes.
- Daily Scrum : Cest une runion quotidienne de 15 minutes concernant lquipe scrum .
Durant cette runion, chaque membre de lquipe explique ce quil a fait depuis la dernire
runion, ce quil va faire avant la prochaine runion et expose les obstacles ventuels
rencontrs.
- Done : tat dune exigence ou dune fonctionnalit lorsquelle est globalement accepte par
toutes les parties prenantes et lorsquelle rpond aux attentes du client : dveloppe, teste,
documente, valide et potentiellement mise en production.
- quipe Scrum : Elle est constitue de quatre dix personnes maximum. Lquipe Scrum
est responsable de la conversion des items du product-backlog en de sous-ensemble de
fonctionnalits livrables la fin de chaque itration.
- Incrment : La ou les fonctionnalit(s) supplmentaire(s) dveloppe(s) et livre(s) par
lquipe chaque itration. Cest lapport de valeur pour le client chaque itration.
- Instant Messenger : La messagerie instantane ou le dialogue en ligne permet lchange
instantan de messages textuels entre plusieurs ordinateurs connects.
- Intgration continue : Cette pratique vise ce que le systme, dans son intgralit, soit
rgulirement et frquemment, assembl puis test. Il sagit de lintgration quotidienne de
nouveaux codes aux codes existants.
- Jira : Cest un outil collaboratif permettant dassurer le suivi et la gestion du tableau des
tches, des bugs, des demandes dvolution, etc. Les demandes peuvent tre affiches sous
forme de cartes virtuelles.
- Kaizen : Organisation des discussions en quipe pour stimuler l'amlioration continue.
L'objectif du kaizen est l'limination du gaspillage sous toutes ses formes.

216

Annexes

- Kanban : Des systmes dtiquettes ayant pour objectif denvoyer une indication aux units
de production en amont de la chane de production pour leur signaler la consommation de leurs
produits.
- Lead Time : Le temps total pass entre le moment o le client a effectu sa demande et le
moment o le produit lui a t livr.
- Les 5 Pourquoi : Il sagit de se poser cinq fois la question pourquoi? pour aller au-del
des causes symptomatiques et trouver les causes fondamentales (sur lesquelles on pourra alors
agir pour liminer le problme une fois pour toutes). Cest une mthode fondamentale de
rsolution de problmes dans le lean management.
- Management visuel : Mise en place de moyens physiques pour crer un environnement
informatif.
- Modle de tests intgrs : Il sagit dun outil open-source qui automatise les tests
fonctionnels des clients. Il intgre le travail des analystes, des clients, des testeurs et des
dveloppeurs.
- Muda : Les gaspillages: toute activit qui consomme des ressources sans ajouter de valeur
pour le client.
- Pareto des causes : Outil visuel permettant de visualiser les causes des problmes et de
trouver, en fonction de leur frquence dapparition, celles traiter en priorit. Cet outil obit
la loi 20/80 o 20% des causes produisent 80% des effets.
- Planning-Game : Il sagit dune runion effectue au dbut de chaque itration o les
demandes des clients sont produites sous formes de user-stories nots sur des storycards . Dans ce type de runion, le client dtermine les demandes fonctionnelles
implmenter, les programmeurs estiment le temps ncessaire pour limplmentation de
chacune des story-cards et ensemble ils dcident des story-cards retenir pour la prochaine
itration.
- Poka-Yoke : Il sagit de petits systmes pratiques qui permettent didentifier
immdiatement que l'on fait de la non-qualit ou que l'on ne suit pas le standard de travail.
- Possession collective des codes : Les codes sont partags dune manire collective. Les
dveloppeurs ont le droit dapporter des modifications aux codes nimporte quelle occasion.
- Post-sprint Meeting : A la fin de chaque itration, lquipe est cense prsenter son travail
au product-owner . A ce stade, le product-owner sassure par rapport au contenu du
sprint-backlog le travail effectu par lquipe.
- Product Backlog : Cest un document danalyse dtaill qui liste lensemble des
fonctionnalits implmenter. Les items nots sur le product-backlog peuvent contenir les
critres, les fonctionnalits, la fixation des bugs, les dfauts, etc.
- Product-Owner : Le propritaire de produit ou le product-owner est lunique personne
responsable de la gestion du product-backlog . Il communique la vision du produit
lquipe de dveloppement et dtermine les caractristiques du produit et fixe sa date de
lancement.
217

Annexes

- Programmation en paire : La production de code se fait en binme partir de deux


personnes travaillant ensemble sur une seule machine, un clavier et une souris. La rotation des
paires se fait de manire quotidienne.
- Pull system : Une entreprise lean agit en flux tir o le client devient demandeur et donc la
production est tire suite aux besoins exprims par le client.
- QQOQCP : (pour Qui fait Quoi ?, O ? Quand ? Comment ? Combien ? et Pourquoi ?). Il
sagit dune mthode qui consiste collecter les donnes ncessaires pour rendre compte et
analyser une situation ou un problme.
- Runion pr-sprint : Il sagit dune runion de planification de livrable permettant de
rpartir les items du product-backlog sur diffrentes itrations, destimer les cots, le
budget et la date de livraison du produit.
- Retrospective meeting : Aprs la runion post-sprint , lquipe et le scrum-master se
runissent pour faire un travail rtrospectif sur le droulement de la runion post-sprint et le
sprint en gnral. Au cours de cette runion, lquipe voque ce qui sest bien pass, souligne
ce qui sest mal pass ainsi que les amliorations faire dans les prochaines itrations.
- Scrum-master : Il fait le relais entre le product-owner et lquipe scrum . Il ne gre
pas lquipe mais aide celle-ci affronter les problmes et atteindre les objectifs fixs pour
litration en cours.
- Sept gaspillages : Trop de fonctionnalits, Retards, Transfert, Rapprentissage/
reprogrammation ; Travail partiellement fait ; Dplacement/ changement de tches ; Dfauts
non dtects par les tests.
- Sprint : Il sagit de litration pendant laquelle lquipe Scrum sauto-organise pour
produire, dans une dure 30 jours, un nouvel incrment. Les itrations ont lieu de manire
conscutive sans aucune interruption.
- Sprint Backlog : Cest le point de dpart de chaque itration. Le sprint-backlog contient
la liste des taches raliser dans la prochaine itration afin de convertir les items du product
backlog en un incrment livrable.
- Sprint Planning Meeting : Cest une runion compose dune double phase. Lors dune
premire phase, les clients, les utilisateurs, le management et lquipe dcident collectivement
de lobjectif du prochain sprint et des fonctionnalits implmenter. Et dans une seconde
phase, le Scrum-Master et lquipe se runissent pour se focaliser sur la manire dont
lincrment sera implment.
- Stand-up meeting : Cest une runion quotidienne de 15 minutes, se droulant dans
lespace occup par les dveloppeurs. Lobjectif est que ces derniers partagent leurs
expriences de la journe prcdente et dcident collectivement des taches effectuer pour la
journe.
- Story-cards : Ils reprsentent des cartes sur lesquelles sont marques les histoires
utilisateurs ou les user-stories .
- Tableau blanc ou whiteboard : Logiciel permettant aux utilisateurs distribus de
collaborer en temps rel et de partager leurs fichiers, graphes, etc.
218

Annexes

- Test Driven development : La dmarche dcriture de codes commence par lcriture des
tests qui permettront de tester les fonctions implmenter puis de mettre en place ces fonctions
pas pas en vrifiant toujours que les tests crits pour la fonctionnalit implmente
passent .
- Tests unitaires : Les tests sont crits pour chaque classe ou portion de codes avant de
commencer coder. Ces tests sont raliss chaque intgration.
- Timeboxing : Principe consistant dnir une chance xe pour dvelopper et livrer un
ensemble de fonctionnalits. Si le travail plani nest pas achev, on ne dcale pas la date de
n, mais on analyse les raisons expliquant ce retard pour apporter rapidement des adaptations.
- Twikis : Une plateforme de travail collaboratif permettant de stocker les informations sous
forme de pages web et de pices jointes. Localis dans lintranet, cet outil est scurisant et
efficace pour communiquer les diffrents aspects du projet (use-cases, daily program status,
burndown charts, etc.).
- User-stories : Il sagit des demandes fonctionnelles et des besoins des utilisateurs
gnralement crits par les utilisateurs ou le client.
- Vlocit : La vlocit renvoie au nombre de scnarios que lquipe estime tre capable de
raliser durant une itration. Elle peut tre dtermine partir de lexprience de lquipe sur le
sujet, des projets antrieurs, etc.
- XPlanner : Cest est un outil de planification et de traabilit pour les quipes XP .

219

Annexes

III- Les modles RAD et DSDM

-Le modle RAD (Rapid Application Development)

Initialisation

Expression des besoins

Conception

N fois

Construction

Mise en uvre

-Le modle DSDM (Dynamic System Development Methodology)

tude de faisabilit

tude de mtier

N fois

Modlisation fonctionnelle

N fois

Conception et construction

Mise en uvre

220

Annexes

IV- Outils de gestion de projet agile


-Exemple de product-backlog et de sprint-backlog

-Exemple dun burndown chart

221

Annexes

V- Outils de gestion de projet agile


-Exemple dun story-board115

115

(Kniberg, 2007)

222

Annexes

VI- Outils116 mobiliss par lquipe lean

-Tableau blanc dans un environnement de travail

Ces outils ont t mobiliss par lquipe lean lors des ateliers et les runions organiss avec les quipes
pilotes.
116

223

Annexes

VII- Outils mobiliss par lquipe lean

-Le management visuel

224

Annexes

VIII- Outil mobilis par lquipe lean


-Tableau comparatif dun brief et dune runion dquipe

Daily brief

Runions dquipes

Objectifs : transmet des flash informations et


des directives, passe en revue les standards de
travail (nouveaux et existants), value l'quipe et
la performance individuelle, l'augmente et suit
(mais ne rsout pas) les problmes, qualifie et
quantifie les secteurs de problmes et pose le
niveau de responsabilit de rsolution de
problme.

Objectifs : relectures des anciens comptes


rendus, relecture approfondie des zones
risques, cela peut inclure les rsolutions de
problmes, la dcouverte des faons de soulever
des barrages. On peut demander lintervention
galement des invits et des experts sur le sujet,
si exig.

Dure : idalement 15 minutes, pas plus que 30


minutes.

Dure : gnralement une heure au minimum.

Frquence : idalement au quotidien, briefs


distance : chaque semaine une date bien dfinie.

Frquence : 1 2 fois par semaine, heure fixe,


plus si besoin.

Comment procder : les sessions sont fixes en


prenant soin dindiquer le prochain brief.
Le manager de lquipe est responsable de conduire
le brief de bout en bout, de garder les membres en
piste afin de ne pas passer ct des 5 Points
essentiels du lean tout en se concentrant sur la
performance.
Le team manager met en scne le brief, assure que
l'quipe comprend quelles sont les attentes de
performance et les actions mettre en uvre pour
les atteindre. Due la courte dure des briefs, les
interactions sont restreintes entre les membres de
l'quipe, pas d'invitations extrieures.

Comment procder :
Les
participations
extrieures sont acceptes par avance.
Le manageur donne tout monde la parole.
La runion dquipe couvre la vue globale du
travail.
La runion rsout les problmes par la constante
interaction de tous les participants.
La participation est suivie et un compte-rendu
est fait et distribu tous les membres et les
participants

Management visuel: Toutes les informations


affiches sur un tableau blanc. Celui-ci a une double
fonction : En plus dassurer le suivi du brief, il permet
aux absents de vite rattraper leur retard. Il peut tre
mis sur une base de donnes.

225

Annexes

IX Outils mobilis par lquipe lean


-La dmarche damlioration continue : kaizen /PDCA

226

Annexes

X- Lettre dinformation bimensuelle 117

LeannerShip

La Newsletter bimensuelle sur le Lean Management

A la u n e
Mais au fait, cest
quoi le lean
Management?
Il s'agit du systme de
production dvelopp par
Toyota qui recherche la
rationalisation optimale de
l'ensemble du systme
travers l'limination des
"gaspillages" et vise
tablir la recherche de la
qualit comme un lment
intrinsque au systme de
production tout en instituant
le principe de rduction des
cots.
Il
comprend
galement
les
accompagnements
technologiques ncessaires
pour atteindre ces buts

Taichii Ohno

Avancement des travaux


Mise en uvre de la dmarche lean management
Actions ralises :
1) Lancement du projet le 18 juin : laboration de nos objectifs : devenir plus agiles avec des moyens constants, devenir

meilleurs sur les dlais, amliorer la transparence, faire plus court.


2) Phase de prparation pendant juillet aout : Formation de lquipe projet.
La dmarche retenue a t de privilgier le travail en atelier.
3) Cette dmarche consiste dans 1er temps identifier et quantifier les dysfonctionnements.
Nous avons donc organis 4 ateliers orients Projet (FTTH, R2 ZE, R3 PC, R3 ZNE), 3 orients Mtiers (architectes, Che f
de projet, CPM) et 5 interviews raliss. Votre active participation a permis de remonter 98 dysfonctionnements parmi
lesquels 8 ont t retenus pour tre traits pendant la phase pilote.
4) Consolidation des rsultats avec le CODIR. Dmarche retenue :
1 axe mtier : atelier de recherche des causes racines et d'identification d'action de rsolution.
1 axe projet : dploiement des mthodes de management par le Lean sur les 4 projets cits plus haut.
Actions en cours et venir (court terme) :
1) Mise au point des outils du management par le Lean pour les projets pilotes :
Comment faire des briefs, pilotage de la performance et indicateurs de celle-ci, etc. L'objectif est de pouvoir
commencer faire une proposition pour chaque projet partir de la fin du mois d'octobre.
2) Newsletter bi-mensuelle et organisation de points d'information sur la dmarche Lean Nextv, une heure, par coopnet (les
dates seront communiques prochainement).
Lquipe charge du Lean management au sein de lentit Nextv
- TR, Responsable Qualit Nextv, Directeur du projet Lean Management,
- JP, Responsable du ple HPM Pays,
- RB, Senior Performance Manager la direction de la transformation,
- DT, Responsable CPM IPTV,
- DT, Project Manager Easy TV.
- QR, Apprenti de lITIN.
-Carine Khalil, Doctorante Lean management Tlcom Paris Tech.

Concept-Lean suivre : On se pose la question Pourquoi ? 5 fois de suite pour tre sr de remonter la cause racine.

Le Leanner de la semaine

VocabuLean

Volontaire ... Je me retrouve dsign volontaire sur le projet Lean. Je me lance donc dans ce projet, sans savoir de
quoi il s'agit. Heureusement, il y a de quoi se former. J'ingre donc quelques centaines de slides (oui, centaine : ce
n'est pas une faute de frappe) sur le Lean (le Collins traduit Lean par mince, maigre ). Ce que j'en retiens : il faut
faire simple et pragmatique : a commence bien Mais dans un lan de compassion envers les quipes Nextv, je
propose mes collgues de ne pas clturer tel que cette formation.
Les principes de base sont alors transcrits dans quelques slides, une dizaine, et le bon sens de chacun fera le
reste.
Pilots par un planning serr, nous lanons donc la premire tape rapidement, et chacun d'entre nous anime un
atelier de remonte de dysfonctionnements. Pour celui me concernant, les remontes sont nombreuses : la
difficult est d'arriver recentrer les discussions sur l'identification des dysfonctionnements, sans tenter de
rsoudre, sans tourner en rond. En plus, je suis contraints par le temps, les runions s'enchainent, et je dois donc
clturer de manire un peu abrupte la sance : toutes mes excuses aux participants ...
La suite est en cours, et j'espre que cette lettre vous apportera rgulirement le bon niveau d'information.
Ce que je retiens de cette premire tape : le Lean, au del de la mthode, doit nous donner les moyens d'amliorer
notre fonctionnement au quotidien, de manire pragmatique, sans attendre que l'organisation, la hirarchie, les
autres, ... le fassent pour nous.
Saisissons cette opportunit, restons pragmatique et peut tre que les rsultats seront au rendez vous. Cela reste
prouver, certes, mais avec notre participation, et un soutien sur la dure de notre hirarchie, pourquoi pas ...

Voix du Client : La VOC est utilise pour dcrire les


attentes des clients ainsi que la valeur qu'ils
peroivent du produit ou service concern.
Coaching : accompagnement d'une personne partir
de ses besoins professionnels pour le dveloppement
de son potentiel et de son savoir-faire.
Atelier Kaizen : identification et rsolution des
dysfonctionnements.
QQOQCP : Le Qui, Quoi, O, Quand, Comment,
Pourquoi ? est un outil de clarification des
dysfonctionnements.
Briefs : Courte runion contenant des actions
managriales centres sur le fonctionnement de
lquipe projet et non sur le projet lui mme.
Management
Visuel :
Partager
les
dysfonctionnements et solutions damlioration sur un
support commun visible de tous.

Le format de la prsente lettre dinformation a t modifi de sa version originale. Nous avons galement
supprim les noms des personnes pour des raisons de confidentialit.
117

227

Annexes

XI- Document de synthse


-Runion de lquipe lean

Date: 13/10/09 ;
Dure : 10h:00-12h30
Lieu : Paris
Nom du document: Runion de lquipe lean
Objectifs de latelier: Construction des outils de la dmarche lean (runions
quotidiennes, KPI)
Participants : RB, TR, DM, JP.
Principaux lments remonts lors de cette runion
-

Questionnements par rapport au kit proposer aux chefs de projet : comment lui
expliquer la dmarche, que doit contenir ce kit ?
Ncessit davoir une proposition prconstruite des outils avant de partir voir le chef
de projet ;
Faire une proposition au chef de projet sur laquelle il pourra ragir ;
Proccupations : comment expliquer la finalit dune runion quotidienne ; comment
diffrencier une runion quotidienne dune runion dquipe ? ; quels outils visuels lui
mettre sa disposition ?
Recourir la prsentation des managers d OS qui ont mis en place des runions
quotidiennes au niveau de leurs quipes distribues (contexte qui semble tre similaire
celui de Nextv).
Comment motiver les acteurs de Nextv participer aux runions quotidiennes alors
quaux runions normales ils ont tendance de ne pas venir ?
Comment rendre les acteurs plus concerns par les interactions ?

Impressions gnrales
-

Les acteurs lean ne semblent pas tre laise avec les outils agiles mettre en
place ;
Ils mettent laccent sur les problmes de communication entre les quipes ou la
transmission tardive dinformations.
Ils essayent de construire ces outils travers leur partage dides, dexpriences.
Les propositions de (RB) semblent prdominer.

228

Annexes

XII- Document de synthse

-Atelier de remontes de dysfonctionnements

Date: 10/09/09 ;
Dure : 09h:30-12h30
Lieu : Paris
Nom du document: Ateliers de remontes des dysfonctionnements (n2)
Objectifs de latelier: Identifier et analyser les problmes rencontrs par les acteurs dans le
droulement de leurs projets
Atelier anim par: RB et TR
Participants : 5 Chefs de projets
Synthse brve du contenu
-

Manque de communication entre les diffrents membres de lquipe (MOE, Marketing,


Architectes, R&D, etc.) ;
Mauvaise synchronisation au niveau du planning ;
Dcalage d'un projet entranant le dcalage dautres projets particulirement en phase de
qualification ;
Changements de priorit, absence de stratgies bien dfinies de priorisation de projets ;
Phase dtude trs longue ;
Travail supplmentaire induit par les changements de priorit,
Absence de vision globale sur le projet
Changements frquents des demandes des clients, modification du primtre.

Premire impression

Les chefs de projets semblent tre insatisfaits lgard de leur collaboration avec le reste
des quipes ;
Un rel manque de communication entre les personnes impliques dans un projet
Les modes de conduite de projet ne semblent pas trs efficaces ;
Beaucoup de gaspillages.

229

Annexes

XIII- Guide dentretien (n1)


-Directeur de lquipe lean
Thme (1) : Organisation et cycle de vie des projets
Question 1 :

Dans quel type dorganisation voluez-vous ? (bureaucratique avec beaucoup


de procdures ; innovante avec ouverture au changement ?)

Question 2 :

Quelles sont les missions de la direction des plateformes de services et celles


de la direction de Nextv ?

Question 3 :

Pouvez-vous nous dcrire le cycle de vie des projets pilots par Nextv?

Question 4 :

Le cycle de vie squentiel est-il commun tous les projets pilots par
(DPS) ?

Question 5 :

Les livrables de chaque jalon sont-ils standardiss?

Question 6 :

Comment les quipes projets pilotes par Nextv sont-elles constitues ?

Question 7 :

Par qui le client donneur dordre est gnralement reprsent?

Question 8 :

A quelle(s) phase(s) du projet le marketing participe-t-il ? Selon vous, sa


participation est-elle suffisante ?

Question 9 :

Les entits transverses ont-elles chacune un mode de fonctionnement


propre ?
Thme (2) : Le lancement de la dmarche lean

Question 1 :

Quelles sont vos attentes vis--vis de la dmarche lean ?

Question 2 :

Considrez-vous ce projet comme une opportunit ou un changement


supplmentaire similaire aux changements prcdents ?

Question 3 :

Quelle est le rle de la direction gnrale dans la mise en place de la


dmarche lean ?

Question 4 :

Quels sont les moyens attribus par la direction gnrale ? (formation, plan
daccompagnement)

Question 5 :

Mise part le lancement du projet qui a eu lieu en Juin 2009, la direction a-telle prvue de communiquer davantage sur la dmarche ?

Question 6 :

Pourquoi avoir dcid de rduire le nombre des dysfonctionnements


traiter ?
230

Annexes

Question 7 :

Pourquoi le recours aux runions quotidiennes, au management visuel et aux


ateliers kaizen ?

Question 8 :

Pourquoi avez-vous procdez par atelier ?

231

Annexes

XIV- Guide dentretien (n2)


-Directeur de lquipe lean
Thme (1) : Raisons de la dmarche lean
Question 1 :

Quelles ont t les raisons qui ont pouss le directeur gnral mettre en
place la dmarche lean ?

Question 2 :

Selon vous, pourquoi le lean prcisment et non pas une autre dmarche?

Question 3 :

Avez-vous suivi des formations sur lean management et les mthodes


agiles ?

Question 4 :

Quelles ont t vos premires impressions lgard de lapplicabilit des


outils associs aux mthodes agiles et au dveloppement lean ?

Question 5 :

Comment les membres de lquipe lean ont-ils t choisis ?

Question 6 :

Avez-vous volontairement dcid de participer cette dmarche ? Si oui,


pourquoi ?
Thme (2) : Mise en place de la dmarche lean

Question 1 :

Quel est le rle du Codir dans la mise en place de la dmarche lean ?


Selon vous, a-t-il t suffisamment impliqu? Si non, pourquoi ?

Question 2 :

Comment expliquez-vous le manque dintrt des managers dquipes


lgard de la dmarche ?

Question 3 :

Quel est limpact de ce manque dintrt sur la russite du projet ?

Question 4 :

Comment expliquez-vous le manque denthousiasme de certains chefs de


projet ?

Question 5 :

Pourquoi le marketing na-t-il pas t impliqu dans la dmarche ?

Question 6 :

Quelles ont t les ractions de la direction gnrale et du Codir quant au


bilan de la phase pilote ?

Question 7 :

Que pensez-vous des retours que vous avez eu sur le fait que la dmarche
fut trs abstraite ?

232

Annexes

Question 8 :

Pourquoi les quipes projets nont finalement pas t concernes par la phase
de gnralisation de la dmarche?

Question 9 :

A lheure actuelle, quels ont t les outils gnraliss sur les quipes de
Nextv? Et pourquoi ?

233

Annexes

XV- Guide dentretien (n3)


-Chefs de projet (Nextv) lean
Thme (1) : caractristiques des quipes projets
Question 1 :

Quelle est la taille moyenne dune quipe projet ?

Question 2 :

Comment les quipes sont-elles composes dune manire gnrale?

Question 3 :

Quelle est la dure approximative dun projet men Nextv?

Question 4 :

Cette dure est-elle respecte ? Si non, pourquoi ?

Question 5 :

Les quipes sont-elles rparties gographiquement ? Si oui, comment


communiquent-elles?

Question 6 :

Les quipes sont-elles familiarises avec une mthodologie de conduite de


projet bien prcise ?

Question 7 :

Les membres des quipes projets sont-ils surchargs ? Si oui, quelles sont les
causes principales de cette surcharge de travail ?
Thme (2) : Gestion de projet

Question 1 :

Quel est votre rle au sein des projets ?

Question 2 :

La vision des projets est-elle clairement dfinie ? Si non, Pourquoi ?

Question 3 :

Combien de runions/semaine sont organises avec les quipes projets ?


Selon vous, cette frquence est-elle suffisante ?

Question 4 :

Quels sont les sujets abords au cours de ces runions ?

Question 5 :

Faites-vous des reporting aprs ces runions ? A qui sont-ils adresss ?

Question 6 :

Comment assurez-vous le suivi des projets ?

Question 7 :

Avez-vous souvent recours la documentation ? Si oui, au niveau de quelles


phases du projet ?

Question 8 :

Existe-t-il un systme de capitalisation sur les projets (erreurs, problmes,


bonnes pratiques, etc.) ? Si oui, comment la capitalisation se fait-elle?

Question 9 :

Les retours sur les phases antrieures dun projet sont-ils envisageables ?

234

Annexes

Thme (3) : Gaspillages


Question 1 :

quels types de problmes organisationnels et/ou managriaux tes-vous


habituellement confronts ?

Question 2 :

Vous arrive-t-il souvent de raliser des tches inutiles ou dj effectues ?


Auriez-vous des exemples prcis nous donner ?

Question 3 :

Existe-t-il des chevauchements au niveau des diffrentes phases dun projet


(quipes qui attendent dautres quipes, etc.) ? Si oui, comment lexpliquezvous ? Quelles en sont les consquences ?
Thme (4) : Dmarche lean

Question 1 :

Avez-vous dj entendu parler des mthodes agiles et du lean


management ?

Question 2 :

Que pensez-vous de la dmarche lean propose ? Comment pourrait-elle


vous aider ?

Question 3 :

Comment envisagez-vous la mise en uvre des runions quotidiennes, du


management visuel et des ateliers kaizen propose par lquipe lean ?

235

Annexes

XVI- Guide dentretien (n4)

-Acteurs internes/acteurs hors Nextv


Thme (1) : Pratiques agiles
Question 1 :

Avez-vous mis en place des runions quotidiennes ? Si oui, quelles sont les
raisons principales ayant motiv leur mise en place ?

Question 2

Les runions quotidiennes se font-elles quotidiennement ? Leur dure de (15


min) est-elle respecte ? Si non, pourquoi ?

Question 3 :

Durant ces runions avez-vous recours un tableau blanc ? Si oui, en quoi


cela vous aide-t-il ?

Question 4 :

Quels acteurs taient concerns par ces runions ?

Question 5 :

Les participants sont-ils toujours connects ? Si non, comment expliquezvous cela ?

Question 6 :

Quelles sont les problmes majeurs que vous rencontrez ?

Question 7 :

A quel(s) type(s) de problme(s) ces runions permettent-elles de rpondre ?

Question 8 :

La mise en place des runions suffit-elle amliorer la communication au


sein de votre quipe ?

Question 9 :

Comment faire participer davantage les quipes ces runions ?

Question 10 :

Quelles autre(s) pratique(s) agiles avez-vous intgr dans votre mode de


fonctionnement ?

Question 11 :

Comment percevez-vous la collaboration inter-quipes au sein de la direction


DPS ?
Thme (2) : Les sessions kaizen

Question 1 :

Avez-vous mis en place des sessions kaizen ? Si oui, quelle frquence et


avec quels profils dacteurs ?

Question 2 :

Quel est lutilit de ces ateliers ?

Question 3 :

Comment les sessions kaizen pourraient-elles tre plus bnfiques ?

Question 4 :

tes-vous impliqus dans des plans daction ? Si oui, dans quel(s) plan(s)
daction ? O en tes-vous quant leur mise en uvre ?
236

Annexes

Thme (3) : Dmarche lean en gnral


Question 1 :

Quelles sont les difficults rencontres par rapport aux outils de la dmarche
lean retenus ?

Question 2 :

Quelles sont vos prconisations pour lanne 2011 ?

237

Annexes

XVII- Sminaires Lean et Systme dInformation

Sur la priode allant de Septembre 2008 Octobre 2011, 19 interventions ont t


ralises, avec succs, dans le cadre de cycles de sminaires sur le Lean et Systme
dInformation . Le public de ces sances est constitu de professionnels des Systmes
dInformation, de praticiens du lean et des mthodes agiles , de consultants,
dinformaticiens, de responsables de qualit, etc. Le nombre de participants chaque
sminaire sest lev 80 personnes en moyenne. Nous listons ci-aprs les diffrents
sminaires en soulignant les thmes traits, le nom des intervenants et le titre de leurs
prsentations.
La liste des sept sminaires lean et systme dinformation
Le premier sminaire Lean et SI sest tenu le 17 Novembre 2008 et a donn lieu 4
prsentations :
-

Lean Software Development , Alexandre Boutin, Yahoo ;

Le Lean et l'histoire de l'informatique , Philippe Nieuwbourg ;

Lean Management et Systmes dinformation , Thomas Houy, Tlcom Paristech ;

Le dveloppement Logiciel Agile , Rgis Mdina, Operae Partners.

Cette premire sance tait trs gnraliste et marquait louverture de la communaut.


Le deuxime sminaire Lean et SI sest droul le 19 Mars 2009 au cours duquel trois
interventions ont t programmes et ralises :
-

Kaizen de la Station Service , Paul Gette et Laurent Piat, Fujitsu ;

Improving Project Management by using VSM and Problem Solving ; Christian


Ignace et Pierre Jannez, Nokia Siemens Network;

Amliorer le travail dquipe: Les Core Protocols , Rgis Mdina et Antoine Contal,
Operae Partners.

Ce sminaire a t consacr lamlioration des projets informatiques travers lapplication


des pratiques lean.

238

Annexes

Le troisime sminaire Lean et SI a eu lieu le 25 Juin 2009 et a fait lobjet de trois


prsentations :
-

Grer l'amlioration continue en informatique au travers des A3 PSA et Faurecia ,


Catherine Chabiron, Faurecia ;

Le Lean dans le dveloppement de la webtv chez Orange , Rgis Mdina et Antoine


Contal, Operae Partners ;

Enqute Lean et systmes d'information 2009 ralise par Fujitsu et Novamtrie avec le
soutien du Projet Lean Entreprise , Christophe Excoffier.

Lors de ce sminaire, nous avons donn la parole des praticiens ayant mis en place une
dmarche lean au sein de leurs activits de dveloppement
Le quatrime sminaire Lean et SI sest tenu le 11 Janvier 2010. Lors de ce sminaire,
deux interventions ont eu lieu :
-

Qu'est-ce que le gaspillage dans le dveloppement informatique, plus particulirement


dans le code? , Rgis Mdina, Operae Partners ;

La production informatique , Hugo Heitz, BNP Parisbas.

Ce sminaire sest focalis sur la notion de gaspillage dans le dveloppement informatique et


sur lean pour amliorer la production informatique.
Le cinquime sminaire Lean et SI sest droul le 10 Juin 2010. Le programme tait le
suivant :
-

Des logiciels au service du client , Rgis Mdina, Operae Partners ;

Mise en uvre des dmarches agiles et lean pour la construction des systmes
critiques , Emmanuel Chenu ;

Retour d'exprience sur une dmarche de formation itrative selon les principes du
TWI , Marie-Noelle Ninteya et Elodie Aidan, Nokia Siemens Network.

Lors de ce sminaire, les interventions ont t varies : une intervention sur la cration de
valeur pour le client, un retour dexpriences sur lintroduction du lean et de lagilit au sein
dune quipe de dveloppement chez Thals et un retour dexprience sur une approche de
mise en uvre de formation sur le terrain.

239

Annexes

Le sixime sminaire Lean et SI sest droul le 7 Octobre 2010. Trois prsentations ont
t prvues pour ce jour :
-

Mise en flux continu des incidents informatiques , Catherine Chabiron, Faurecia ;

Le lean dans la maintenance du SI , Rgis Medina, Operae Partners ;

La Dmarche Lean IT chez Silca , Herv Deniel, Responsable du contrle


permanente, Silca et Paul Gette, Consultant Senior, Fujitsu.

Ce sminaire a t consacr la gestion des incidents et la maintenance des systmes


informatiques.
Enfin le septime Lean et SI a eu lieu 23 septembre 2011. Cette sance a donn lieu trois
prsentations :
-

Standards de travail et amlioration continue : exemples de transposition de l'approche


usine sur les SI , Catherine Chabiron, Faurecia ;

Matriser les dlais des projets informatiques , Rgis Mdina, Operae Partner ;

Quand les quipes agiles dcouvrent le A3 , Antoine Berthelin, 4DConcept et Philippe


Blayo, Orange Business Services.

240